Bản ghi SOA trong DNS là gì?

DNS
Đăng bởi

Nếu bạn từng khám phá các bản ghi DNS của một tên miền bằng dig hoặc công cụ tra cứu trực tuyến, có lẽ bạn đã gặp bản ghi SOA mà không hiểu rõ nó dùng để làm gì. Đây là một trong những bản ghi quan trọng nhất của bất kỳ vùng DNS nào: nó xác định ai có quyền hạn trên vùng đó, các máy chủ DNS phụ phải đồng bộ như thế nào, và dữ liệu còn hiệu lực bao lâu nếu máy chủ chính gặp sự cố.

Bản ghi SOA chứa những gì

SOA là viết tắt của Start of Authority. Mỗi vùng DNS bắt buộc phải chứa đúng một bản ghi SOA. Nó luôn nằm ở đỉnh vùng và bao gồm bảy trường riêng biệt. Một bản ghi SOA điển hình trông như sau:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Phân tích từng trường:

  • MNAME (ns1.example.com.): máy chủ DNS chính có thẩm quyền của vùng. Đây là máy chủ mà các máy chủ phụ kết nối để lấy bản cập nhật
  • RNAME (admin.example.com.): địa chỉ email của người quản trị vùng, nhưng dùng dấu chấm thay cho @. Ở đây tương ứng với [email protected]. Nếu phần tên cục bộ chứa dấu chấm, phải escape bằng dấu gạch chéo ngược (ten\.ho.example.com.)
  • Serial (2025052901): số phiên bản của vùng. Mỗi thay đổi phải tăng số này, nếu không các máy chủ phụ sẽ không phát hiện bản cập nhật. Định dạng phổ biến là YYYYMMDDNN (ngày cộng bộ đếm trong ngày)
  • Refresh (7200): khoảng thời gian tính bằng giây giữa các lần kiểm tra của máy chủ phụ. Ở đây là mỗi 2 giờ
  • Retry (3600): thời gian chờ trước khi thử lại nếu kiểm tra Refresh thất bại. Ở đây là 1 giờ
  • Expire (1209600): thời gian sau đó máy chủ phụ ngừng phản hồi cho vùng nếu không thể liên lạc được với máy chủ chính. Ở đây là 14 ngày. Quá thời hạn này, máy chủ phụ coi dữ liệu của mình đã hết hạn và ngừng phục vụ vùng hoàn toàn
  • Minimum TTL (86400): từ RFC 2308, trường này xác định thời gian cache cho phản hồi phủ định (NXDOMAIN). Ở đây là 24 giờ. Nếu ai đó truy vấn một subdomain không tồn tại, resolver sẽ lưu cache câu trả lời "không tồn tại" trong 24 giờ

Tại sao số serial quan trọng đến vậy

Serial có lẽ là trường gây nhiều rắc rối nhất trong thực tế. Khi máy chủ phụ liên lạc với máy chủ chính trong chu kỳ Refresh, nó so sánh số serial cục bộ với số trên máy chủ chính. Nếu của máy chủ chính cao hơn, máy chủ phụ khởi tạo chuyển vùng (AXFR hoặc IXFR) để cập nhật. Nếu không thay đổi, nó không làm gì.

Lỗi kinh điển: sửa bản ghi DNS trên máy chủ chính mà không tăng serial. Kết quả là máy chủ chính có phiên bản đúng nhưng các máy chủ phụ tiếp tục phục vụ phiên bản cũ trong nhiều giờ hoặc nhiều ngày. Người dùng nhận được câu trả lời khác nhau tùy thuộc vào máy chủ họ truy vấn, và vấn đề khó chẩn đoán nếu không ai nghĩ đến việc kiểm tra SOA.

Định dạng YYYYMMDDNN là quy ước, không phải bắt buộc. Serial là số nguyên 32 bit, nên bất kỳ giá trị nào từ 0 đến 4.294.967.295 đều hoạt động. Nhưng định dạng ngày được khuyến nghị vì nó làm lỗi trở nên rõ ràng: serial 2025052901 rõ ràng là thay đổi đầu tiên của ngày 29 tháng 5 năm 2025.

Refresh, Retry và Expire phối hợp như thế nào

Ba giá trị này tạo thành hệ thống chịu lỗi cho các vùng DNS. Refresh thiết lập nhịp đồng bộ bình thường. Retry hoạt động khi Refresh thất bại. Expire là lưới an toàn cuối cùng: quá thời gian này mà không liên lạc được với máy chủ chính, máy chủ phụ thà không trả lời gì còn hơn phục vụ dữ liệu có thể đã lỗi thời.

Đối với domain tiêu chuẩn, RFC 1912 khuyến nghị:

  • Refresh: 3.600 đến 86.400 giây (1 giờ đến 24 giờ)
  • Retry: 600 đến 3.600 giây (10 phút đến 1 giờ)
  • Expire: 1.209.600 đến 2.419.200 giây (2 đến 4 tuần)
  • Minimum TTL: 3.600 đến 86.400 giây (1 giờ đến 24 giờ)

Nếu vùng của bạn thay đổi thường xuyên (ví dụ CDN hoặc hạ tầng có cân bằng tải động), giảm Refresh xuống 300 hoặc 600 giây. Nếu ổn định, 86.400 hoàn toàn phù hợp và giảm tải cho máy chủ chính.

Cách kiểm tra bản ghi SOA của một domain

Trên Linux và macOS, lệnh dig là tiện nhất:

dig SOA example.com

Trên Windows, dùng nslookup:

nslookup -type=SOA example.com

Kết quả hiển thị cả bảy trường SOA. Đặc biệt chú ý đến serial: nếu trông cũ hoặc bị đóng băng, đó thường là lý do các thay đổi DNS không lan truyền đúng cách.

Các lỗi SOA thường gặp

Một vài vấn đề thường xuyên gặp trong thực tế:

  • RNAME dùng @ thay vì dấu chấm, làm hỏng cú pháp. [email protected] phải viết là admin.example.com. trong SOA
  • Serial bị giảm nhầm sau khi khôi phục bản sao lưu. Các máy chủ phụ sẽ từ chối đồng bộ cho đến khi serial của máy chủ chính vượt lại trên giá trị cục bộ của chúng
  • Expire quá ngắn (vài giờ). Nếu máy chủ chính gặp sự cố vào cuối tuần, các máy chủ phụ ngừng phản hồi trước khi ai đó kịp xử lý
  • Minimum TTL bằng 0, nghĩa là resolver không cache phản hồi phủ định. Mỗi truy vấn đến subdomain không tồn tại tạo ra một round trip đầy đủ, có thể làm quá tải máy chủ DNS khi bị quét hoặc tấn công
Bản ghi SOA hiếm khi là thứ đầu tiên bạn chỉnh sửa khi thiết lập domain, nhưng nó thường là thứ giải thích tại sao "DNS không lan truyền". Trước khi tìm nguyên nhân phức tạp, hãy kiểm tra xem serial đã được tăng đúng chưa và các giá trị Refresh cùng Expire có phù hợp với cách sử dụng của bạn không.