DNS: Phân Giải Tên Miền

Con người nhớ tên (google.com), máy tính định tuyến bằng số (IP — Bài 2). DNS (Domain Name System) là "danh bạ" của Internet, dịch tên thành IP. Đây là chặng đầu tiên trong hành trình mở một trang web (Bài 0), và là nguồn của vô số sự cố ("DNS sai" là chẩn đoán quen thuộc). Bài này đào vào cách nó hoạt động.

DNS là một cây phân cấp

DNS không phải một máy chủ khổng lồ chứa mọi tên — đó là một hệ phân cấp, đọc tên miền từ phải sang trái:

   www . example . com .
    │       │       │   └── gốc (root) — dấu chấm ẩn ở cuối
    │       │       └────── TLD (top-level domain): .com
    │       └────────────── domain: example.com
    └────────────────────── subdomain: www

Tương ứng là ba cấp máy chủ:

• Root servers — biết các TLD (.com, .org, .vn...) nằm ở đâu. Có 13 cụm root (a đến m.root-servers.net).
• TLD servers — máy chủ của .com biết tên miền example.com được quản lý bởi name server nào.
• Authoritative servers — máy chủ "có thẩm quyền" của chính example.com, giữ câu trả lời cuối cùng (IP thật).

Không cấp nào biết tất cả; mỗi cấp chỉ biết "hỏi tiếp ở đâu". Cách phân tán này là vì sao DNS chịu được quy mô cả Internet.

Resolver đệ quy: người đi hỏi giúp bạn

Máy bạn không tự đi hỏi từng cấp. Nó nhờ một recursive resolver (máy chủ DNS của nhà mạng, hoặc dịch vụ công như 8.8.8.8 của Google, 1.1.1.1 của Cloudflare). Resolver lo việc đi hỏi tuần tự thay bạn:

   Trình duyệt cần IP của example.com:

   (1) Có trong cache chưa? ──có──► trả lời ngay
   (2) ──chưa──► hỏi Recursive Resolver (vd 1.1.1.1):
           │
           ├─► Root:          ".com quản lý ở đâu?"      ──► "TLD .com tại ..."
           ├─► TLD .com:      "example.com ở đâu?"       ──► "authoritative ns tại ..."
           └─► Authoritative: "IP của example.com?"      ──► "93.184.x.x"
   (3) Resolver trả IP về cho bạn + LƯU CACHE (theo TTL)

Bạn xem được chuỗi này bằng dig +trace:

dig +trace example.com

.        NS  a.root-servers.net.      ← bắt đầu từ root
.        NS  b.root-servers.net.
...

Nó hỏi từ root, xuống TLD, tới authoritative — đúng trình tự trên. (DNS chủ yếu chạy trên UDP cổng 53 — nhớ Bài 6: câu hỏi/trả lời ngắn, hỏi lại nếu mất còn nhanh hơn bắt tay TCP.)

Các loại bản ghi DNS

Một tên miền có thể có nhiều bản ghi (record) với các loại khác nhau. Những loại bạn gặp nhiều:

dig +short google.com A      # 142.250.198.206
dig +short google.com MX     # 10 smtp.google.com.
dig +short google.com NS     # ns1.google.com.
dig +short google.com TXT    # "google-site-verification=..."

   A      tên → địa chỉ IPv4         vd example.com → 93.184.x.x
   AAAA   tên → địa chỉ IPv6
   CNAME  bí danh, trỏ tên này sang tên khác   www → example.com
   MX     máy chủ nhận email cho miền          (kèm độ ưu tiên)
   NS     name server quản lý miền
   TXT    văn bản tự do (xác minh sở hữu, SPF/DKIM cho email)
   SOA    thông tin quản trị của vùng (zone)

Ví dụ thật về CNAME: www.github.com là một bí danh trỏ về github.com rồi mới ra IP:

dig +short www.github.com

github.com.          ← CNAME: www.github.com là bí danh của github.com
20.205.243.166       ← rồi github.com phân giải ra IP này

CNAME hay dùng để trỏ nhiều tên (www, app...) về một đích, hoặc trỏ tới dịch vụ bên ngoài (CDN, load balancer) mà không cần biết IP của họ.

TTL và cache: vì sao DNS đổi không tức thì

Mỗi bản ghi có một TTL (Time To Live) — số giây được phép cache. Trong output dig:

dig +noall +answer google.com A

google.com.   152   IN   A   142.250.198.206
              └┬┘
              TTL = 152 giây

Resolver (và máy bạn) lưu kết quả trong TTL giây để khỏi hỏi lại — DNS sẽ quá tải nếu mỗi request đều đi hỏi từ root. Cache nhiều tầng (trình duyệt → hệ điều hành → resolver) làm DNS nhanh.

Hệ quả thực tế quan trọng: khi bạn đổi bản ghi DNS (ví dụ trỏ tên miền sang server mới), thay đổi không có hiệu lực ngay — các cache cũ vẫn trả IP cũ cho tới khi TTL hết. Đây là lý do dân DevOps giảm TTL trước khi định đổi DNS, để chuyển đổi nhanh. Và là lý do "tôi đổi DNS rồi mà vẫn vào trang cũ" — cache chưa hết hạn.

DNS trong gỡ lỗi

Rất nhiều sự cố "không kết nối được" thực ra là DNS:

• Tên không phân giải ra IP → dig <tên> trả về rỗng (tên sai, hoặc DNS server lỗi).
• Phân giải ra IP cũ/sai → cache chưa hết TTL, hoặc bản ghi cấu hình sai.
• Phân giải được nhưng vẫn không vào → vấn đề ở tầng khác (TCP, TLS, firewall) — DNS đã xong việc.

Công cụ: dig <tên> (chi tiết), dig +short (gọn), dig +trace (xem cả chuỗi), và file /etc/hosts ghi đè DNS cục bộ (nhớ Bài 13 series Linux). Quy trình chẩn đoán luôn nên bắt đầu từ "DNS có ra đúng IP không?" (Bài 12).

Tổng kết

DNS dịch tên miền thành IP qua một hệ phân cấp (root → TLD → authoritative), với recursive resolver đi hỏi giúp bạn rồi cache kết quả theo TTL. Tên miền có nhiều loại bản ghi (A/AAAA cho IP, CNAME bí danh, MX cho email, NS, TXT). dig là công cụ chính để soi. Nhớ: đổi DNS không tức thì vì TTL/cache — giảm TTL trước khi chuyển.

DNS đã cho bạn IP của server. Bước tiếp theo trong hành trình là nói chuyện với nó. Bài 8 vào ngôn ngữ của web: HTTP và HTTPS.