CHƯƠNG 07 · APPLICATION · ~100 phút

DNS
How the Internet finds servers

"Hệ thống danh bạ" của Internet. Mỗi lần truy cập google.com, DNS làm việc trước. Chương này dạy: hierarchy root → TLD → authoritative, recursive vs iterative resolver, các record type, TTL, "DNS propagation", DoH/DoT, DNS-over-HTTPS, dùng dig.

7.1 Tại sao cần DNS?

Máy tính dùng IP để tìm nhau. Con người không nhớ 142.250.74.14 nổi — nhớ google.com dễ hơn. DNS (Domain Name System) là hệ thống dịch domain ↔ IP.

Yêu cầu khó

DNS phải:

  • Phục vụ hàng tỷ truy vấn/giây trên toàn cầu
  • Cho phép thay đổi nhanh khi cần (move server, đổi IP)
  • Phân tán — không ai làm chủ toàn bộ
  • Resilient — 1 phần down không sập toàn bộ

Thiết kế DNS thoả mãn cả bằng cây phân tầng + caching.

7.2 DNS Hierarchy — phân tầng tree

. (root) / | \ com org vn / | | | \ google amazon ... .com.vn .edu.vn | www, mail, drive, ...

3 tầng chính

  1. Root (gốc, ".") — 13 logical servers (a.root-servers.net đến m.root-servers.net), quản lý bởi ICANN. Thực tế hàng trăm physical server qua anycast.
  2. TLD (Top-Level Domain): .com, .org, .net, country code .vn, .uk, .jp... Mỗi TLD do 1 registry quản lý (Verisign cho .com).
  3. Authoritative: nameserver của domain cụ thể (vd ns1.google.com) — nơi data thật của domain được lưu.

Domain vs Subdomain

Đọc từ phải sang trái:

www.api.example.com.
│   │   │       │   │
│   │   │       │   └─ root (thường ẩn)
│   │   │       └───── TLD (.com)
│   │   └───────────── second-level domain (example)
│   └───────────────── subdomain (api)
└───────────────────── subdomain (www)

FQDN — Fully Qualified Domain Name

Có dấu chấm cuối: www.example.com. — chỉ rõ "đây là FQDN, không phải relative". Hằng ngày bỏ dấu chấm cuối.

7.3 DNS Resolution Flow — khi truy cập example.com

Đây là chuyện gì xảy ra giây đầu tiên khi bạn gõ URL vào browser:

1. Browser kiểm tra cache (browser cache, OS cache) Có rồi? → dùng IP cached, xong. Chưa? → tiếp. 2. Browser gọi OS resolver (vd systemd-resolved trên Linux) OS check cache. Có? → dùng. Chưa? → gửi cho recursive resolver. 3. Recursive Resolver (vd 8.8.8.8 Google, 1.1.1.1 Cloudflare, hoặc resolver của ISP) ┌─ Recursive resolver công việc: │ │ 3a. Hỏi Root (".") server: "example.com ở đâu?" │ → Root: "Tôi không biết, nhưng .com TLD ở │ a.gtld-servers.net (192.5.6.30)" │ │ 3b. Hỏi TLD (.com) server tại a.gtld-servers.net │ → TLD: "example.com? Hỏi authoritative ns1.example.com │ (203.0.113.5)" │ │ 3c. Hỏi authoritative tại ns1.example.com │ → Authoritative: "example.com → A record 93.184.216.34" │ │ 3d. Cache + return cho client │ └─ 4. Browser nhận IP, mở TCP connect đến 93.184.216.34:443 5. TLS handshake 6. HTTP GET / 7. Page load

Recursive vs Iterative

Iterative

Mỗi server trả lời "Tôi không biết, hỏi server kia". Resolver phải đi từng bước. Đây là cách Recursive Resolver làm việc với Root → TLD → Authoritative.

Recursive

Server tự đi tìm tất cả, trả về kết quả cuối. Đây là cách Recursive Resolver trả lời client cuối.

Client → Recursive Resolver = Recursive query. Resolver → Root/TLD/Authoritative = Iterative query.

7.4 DNS Record Types

TypeMục đíchVí dụ
ADomain → IPv4example.com → 93.184.216.34
AAAADomain → IPv6example.com → 2606:2800:220:1::
CNAMEAlias đến domain khácwww.example.com → example.com
MXMail serverexample.com → 10 mail.example.com
TXTText bất kỳ (SPF, DKIM, verification)"v=spf1 include:_spf.google.com ~all"
NSAuthoritative nameserverexample.com → ns1.example.com
SOAStart of Authority — admin info, serial number—
PTRReverse: IP → domain34.216.184.93.in-addr.arpa → example.com
SRVService location (port, priority)_xmpp-server._tcp.example.com
CAAHạn chế CA nào được cấp cert cho domain0 issue "letsencrypt.org"

A vs CNAME vs ALIAS

  • A: trỏ trực tiếp tới IP. Nhanh nhất. Nhưng nếu IP đổi, phải update record.
  • CNAME: trỏ tới domain khác. Resolver phải resolve thêm 1 lần. Không dùng được ở root domain (apex) — vì SOA/NS phải ở apex.
  • ALIAS / ANAME (không chuẩn DNS, do registrar implement): "CNAME ở apex" — DNS provider tự resolve và trả A record.

MX với priority

example.com.   MX  10  mail1.example.com.   ← priority 10 (cao nhất, ưu tiên)
example.com.   MX  20  mail2.example.com.   ← backup
example.com.   MX  20  mail3.example.com.   ← backup (cùng priority → load balance)

Số nhỏ = priority cao. Cùng priority → random/round-robin.

7.5 TTL & Caching — vì sao DNS scale được

Mỗi DNS record có TTL (Time To Live) — bao lâu thì cache hết hạn. Vd 3600 = 1 giờ.

Khi resolver/client cache record, dùng đến khi TTL = 0 mới query lại. Đây là lý do DNS chịu được hàng tỷ query/giây — đa số được phục vụ từ cache, không đi qua hierarchy.

Cache layers

  1. Browser cache (vài phút)
  2. OS cache (DNS resolver như systemd-resolved, mDNSResponder)
  3. Recursive resolver cache (vài giờ)
  4. Authoritative server (source of truth)

TTL trade-off

  • TTL ngắn (60s): đổi DNS nhanh có hiệu lực, nhưng tốn nhiều query → load tăng
  • TTL dài (1 ngày): cache hiệu quả, nhưng đổi DNS phải đợi lâu

Best practice: giảm TTL trước khi đổi DNS:

  1. 1 tuần trước migration: TTL từ 86400 (1 ngày) → 300 (5 phút)
  2. Đợi cũ TTL hết hạn → world dùng TTL mới
  3. Đổi record
  4. Sau migration thành công, tăng TTL lại

7.6 "DNS Propagation" — vì sao đổi DNS phải đợi

Khi bạn đổi A record từ IP cũ sang mới, không phải mọi user thấy thay đổi ngay:

  • Resolver A đã cache record cũ với TTL = 3600s → 1 giờ nữa mới query lại
  • Resolver B query lúc bạn vừa đổi → thấy IP mới ngay
  • Resolver C trên CDN khác có thể có lag riêng

Hệ quả: trong 1 thời gian, một số user vẫn vào IP cũ. Đó gọi là "DNS propagation" — thực ra không phải propagate, mà là cache expiry.

Worst case = max TTL bạn đã cấu hình (vd 24h). Sau đó mọi cache hết hạn.

⚠️ Misconception
"DNS propagation" không phải DNS lan truyền chậm. Authoritative đã update ngay. Vấn đề chỉ là cache cũ ở resolver toàn cầu chưa hết TTL.

7.7 DNS over HTTPS / TLS — DNS có encryption

DNS truyền thống là plaintext qua UDP/53. Vấn đề:

  • Eavesdropping: ISP/Wi-Fi biết bạn đang truy cập domain nào
  • Tampering: ISP có thể return IP giả (DNS hijacking)
  • Censorship: chặn domain bằng DNS (Vietnam chặn Facebook giai đoạn 2009)

DNS over TLS (DoT) — RFC 7858

DNS query qua TCP+TLS, port 853. Encrypt full query.

DNS over HTTPS (DoH) — RFC 8484

DNS query qua HTTPS POST/GET đến endpoint chuyên biệt (vd https://1.1.1.1/dns-query). Trông như HTTP request thường → khó censorship.

Adoption

  • Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9 đều support DoH/DoT
  • Firefox enable DoH default (US)
  • Chrome auto-upgrade nếu resolver hỗ trợ
  • iOS, macOS support DoH/DoT từ 14+

DNSSEC — bảo vệ tính toàn vẹn

DNSSEC sign DNS records bằng cryptographic. Resolver verify chữ ký → không bị tamper. Khác với DoH/DoT (chỉ encrypt). Adoption thấp do phức tạp.

7.8 Tools — dig, nslookup, host

dig — chuẩn của sysadmin

# Truy vấn cơ bản
dig example.com
# ;; ANSWER SECTION:
# example.com.    3600  IN  A  93.184.216.34

# Query specific record type
dig example.com MX
dig example.com NS
dig example.com TXT

# Query specific resolver
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Trace toàn bộ recursive process
dig +trace example.com
# Show: root → .com TLD → authoritative

# Short output
dig +short example.com
# 93.184.216.34

# Reverse lookup (PTR)
dig -x 93.184.216.34

nslookup — quen với Windows

nslookup example.com
nslookup example.com 8.8.8.8     # specific resolver

# Interactive mode
nslookup
> set type=mx
> example.com

host — nhanh, ngắn

host example.com
# example.com has address 93.184.216.34
# example.com has IPv6 address 2606:2800:220:1::

host -t MX example.com

Linux/Mac OS resolver config

# Config file (Linux cũ / macOS)
cat /etc/resolv.conf
# nameserver 192.168.1.1
# nameserver 8.8.8.8

# Linux modern: systemd-resolved
resolvectl status

# macOS
scutil --dns

# Flush cache
sudo killall -HUP mDNSResponder        # macOS
sudo systemctl restart systemd-resolved # Linux

7.9 Anycast DNS — vì sao 1.1.1.1 nhanh từ mọi nơi

Anycast: nhiều server có cùng IP. Router tự động route packet đến server gần nhất (về mặt network).

Vd: Cloudflare có ~300 PoP toàn cầu, mỗi nơi có server với IP 1.1.1.1. Bạn ở Việt Nam ping 1.1.1.1 → tới server Cloudflare ở Vietnam/Singapore. Bạn ở US → tới server US. Cùng IP, server khác.

Lợi ích

  • Latency thấp — luôn gần nhất
  • Resilience — 1 PoP down, traffic tự route đến PoP khác
  • DDoS mitigation — attack 1 IP, traffic chia khắp các PoP

Major DNS resolver dùng anycast: 1.1.1.1, 8.8.8.8, 9.9.9.9, root DNS server cũng anycast.

Bài tập

Bài 1 — dig +trace

Chạy dig +trace example.com. Quan sát flow: root → .com TLD → authoritative. Có bao nhiêu hop?

Bài 2 — Records của domain bạn

Pick 1 domain (vd github.com). Query: A, AAAA, MX, NS, TXT. Liệt kê IP, mail server, name server.

Bài 3 — TTL khác nhau

Compare TTL của A record các site sau: cloudflare.com, google.com, github.com. TTL khác nhau ý nghĩa gì?

Bài 4 — DoH thử nghiệm

Curl đến endpoint DoH của Cloudflare: curl -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=example.com&type=A". Quan sát JSON response.

Bài 5 — Hosts file override

Edit /etc/hosts (Linux/Mac) hoặc C:\Windows\System32\drivers\etc\hosts: thêm 1.2.3.4 mytest.local. Ping mytest.local → đi đến 1.2.3.4. Đây là cấp cache trên cả OS.

Bài 6 — Migration scenario

Bạn cần move web server từ DigitalOcean sang AWS. Mô tả các bước thay DNS đảm bảo không downtime. (Hint: TTL).

🧪 Quiz cuối chương

Câu 1. DNS resolution các bước khi truy cập example.com?

  • Browser → Server
  • Browser cache → OS cache → Recursive resolver → Root → TLD → Authoritative → Server
  • Search engine → Server
  • Hosts file → Server

Đáp án: 4 cấp cache + 3 cấp authority. Đây là flow đầy đủ. Đa số trường hợp dừng ở 1 cấp cache do TTL chưa hết.

Câu 2. A vs CNAME?

  • A nhanh hơn CNAME
  • A trỏ IP, CNAME trỏ domain
  • A trỏ trực tiếp IP; CNAME alias đến domain khác (resolver phải resolve thêm); CNAME không dùng được ở apex
  • A cho IPv4, CNAME cho IPv6

Đáp án: A→IP, CNAME→domain. CNAME thêm 1 lookup; không dùng được ở apex (root domain) vì SOA/NS phải ở đó.

Câu 3. DNS dùng UDP vì?

  • Latency thấp + query nhỏ + nếu mất packet client tự retry
  • UDP an toàn hơn
  • UDP free hơn
  • TCP không hỗ trợ DNS

Đáp án: latency + retry đơn giản. DNS có thể dùng TCP cho response >512 byte hoặc DNSSEC.

Câu 4. "DNS propagation chậm" thực ra là?

  • Server lan truyền chậm
  • Cache cũ ở các resolver chưa hết TTL → một số user vẫn dùng IP cũ
  • Authoritative chưa nhận update
  • BGP route chưa converge

Đáp án: cache expiry, không phải propagation. Authoritative update ngay; vấn đề là cache cũ.

Câu 5. MX record với priority 10 vs 20?

  • 20 ưu tiên hơn
  • Số bằng nhau
  • 10 ưu tiên hơn (số nhỏ = priority cao); 20 dùng làm backup nếu 10 down
  • Không liên quan đến priority

Đáp án: 10 ưu tiên, 20 backup. Cùng priority → load balance.

Câu 6. DNS over HTTPS (DoH) khác DNS thường?

  • Nhanh hơn
  • DNS query qua HTTPS — encrypted, ISP không thấy domain bạn truy cập
  • Free hơn
  • Dùng được offline

Đáp án: encrypted DNS qua HTTPS. Privacy + chống tampering. Khó censor.

Câu 7. Recursive vs Iterative query?

  • Hai cái giống nhau
  • Recursive cho IPv4, Iterative cho IPv6
  • Recursive: server tự đi tìm và trả kết quả cuối; Iterative: server trả "hỏi server khác"
  • Recursive nhanh hơn

Đáp án: Recursive=tự đi tìm, Iterative=referral. Client→Resolver=Recursive. Resolver→Root/TLD/Auth=Iterative.

Câu 8. Anycast DNS (1.1.1.1) vì sao nhanh?

  • Nhiều server cùng IP, router tự route đến server gần nhất theo network distance
  • Cloudflare có Internet riêng
  • Cache lớn
  • Không qua TCP

Đáp án: anycast. Latency thấp + resilience + DDoS mitigation.

Tổng kết chương 7

  • ✅ DNS = hệ thống dịch domain ↔ IP, hierarchy 3 tầng: Root → TLD → Authoritative
  • ✅ Resolution flow: cache → recursive resolver → iterative qua hierarchy → trả IP
  • ✅ Records phổ biến: A, AAAA, CNAME, MX, TXT, NS
  • ✅ TTL + nhiều cấp cache → DNS scale được. TTL ngắn = đổi nhanh nhưng tốn query
  • ✅ "DNS propagation" thực ra là cache expiry
  • ✅ DoH/DoT: DNS encrypted qua HTTPS/TLS — privacy
  • ✅ DNSSEC: ký records, chống tampering (khác encrypt)
  • ✅ Anycast: cùng IP, nhiều location → 1.1.1.1, 8.8.8.8 nhanh từ mọi nơi
  • ✅ Tools: dig, dig +trace, nslookup, host, resolvectl
← Chương trước Chương 06: HTTPS, TLS Chương kế tiếp Chương 08: WebSocket, gRPC, REST →