Nếu bạn đã từng phải debug lỗi “site unreachable” lúc 2 giờ sáng, bạn hiểu DNS quan trọng đến mức nào — và nó vô hình đến mức nào cho đến khi có sự cố. Đây là loại hạ tầng chạy lặng lẽ suốt nhiều tháng, rồi bỗng dưng trở thành thứ duy nhất ngăn bạn deploy thành công. DNS không phải kiến thức tùy chọn với engineer quản lý hệ thống thực tế. Bạn hiểu nó càng sâu sớm, bạn càng ít mất ngủ vì những sự cố bí ẩn.
Bắt Đầu Nhanh: DNS trong 5 Phút
Trước khi đi sâu, hãy thực hành ngay. Mở terminal và thử những lệnh này:
# Tra cứu DNS cơ bản
nslookup google.com
# Chi tiết hơn — hiển thị thông tin DNS resolution đầy đủ
dig google.com
# Theo dõi toàn bộ chuỗi phân giải từ root server
dig +trace google.com
# Truy vấn một loại DNS record cụ thể
dig google.com MX # Bản ghi mail exchange
dig google.com A # Bản ghi địa chỉ IPv4
dig google.com AAAA # Bản ghi địa chỉ IPv6
dig google.com TXT # Bản ghi text (SPF, DKIM nằm ở đây)
# Dùng DNS server cụ thể (ví dụ: 1.1.1.1 của Cloudflare)
dig @1.1.1.1 google.comChạy dig +trace google.com ngay bây giờ. Output — khoảng 20 dòng — kể toàn bộ câu chuyện DNS. Một khi bạn đọc được từng phần, việc debug sẽ không còn là mò mẫm nữa.
Đi Sâu: DNS Resolution Thực Sự Hoạt Động Như Thế Nào
Bốn Loại Server Tham Gia
Quá trình phân giải DNS dựa vào bốn loại server. Mỗi loại đóng một vai trò riêng biệt:
- DNS Resolver (Recursive Resolver) — Điểm dừng đầu tiên của bạn. Thường được cung cấp bởi ISP, hoặc dịch vụ công khai như Google (8.8.8.8) hay Cloudflare (1.1.1.1). Nó thực hiện toàn bộ công việc tìm câu trả lời thay bạn.
- Root Name Server — Có 13 bộ trên toàn cầu, ký hiệu từ A đến M. Chúng không biết google.com ở đâu, nhưng biết chính xác cần hỏi ai tiếp theo.
- TLD Name Server — Xử lý các tên miền cấp cao nhất. Server TLD
.combiết server authoritative nào chịu trách nhiệm cho google.com. - Authoritative Name Server — Thẩm quyền cuối cùng. Nó lưu trữ các DNS record thực sự của một domain và trả về câu trả lời chính thức.
Luồng Phân Giải, Từng Bước
Bạn gõ google.com vào trình duyệt. Đây là chuỗi sự kiện diễn ra bên dưới:
- Trình duyệt kiểm tra cache cục bộ của nó. Có câu trả lời gần đây? Dùng nó và dừng tại đây.
- Cache miss — hệ điều hành kiểm tra
/etc/hosts(Linux/macOS) hoặcC:\Windows\System32\drivers\etc\hoststrên Windows. - Vẫn không có gì. Request được gửi đến DNS resolver đã cấu hình của bạn.
- Resolver kiểm tra cache của chính nó. Một lần nữa miss sẽ kích hoạt việc leo lên cấp bậc cao hơn.
- Resolver hỏi một root name server: “Ai xử lý .com?”
- Root server: “Hỏi TLD server .com tại địa chỉ này.”
- Resolver hỏi TLD server .com: “Ai xử lý google.com?”
- TLD server: “Hỏi authoritative name server của Google.”
- Resolver hỏi authoritative server của Google: “IP của google.com là gì?”
- Authoritative server phản hồi với bản ghi A:
142.250.80.46. - Resolver cache kết quả và trả về cho bạn.
- Trình duyệt kết nối đến IP đó. Trang tải xong.
Toàn bộ chuỗi thường hoàn thành trong dưới 100ms. Cache ở mỗi tầng là thứ khiến các truy vấn lặp lại cảm giác tức thì — thường dưới 1ms từ cache đã warm.
Các Loại DNS Record Bạn Sẽ Dùng Hàng Ngày
- A — Ánh xạ hostname sang địa chỉ IPv4. Loại record phổ biến nhất.
- AAAA — Ánh xạ hostname sang địa chỉ IPv6.
- CNAME — Bí danh. Trỏ một hostname sang hostname khác (
www.example.com→example.com). - MX — Mail exchanger. Cho mail server biết nơi nhận email cho domain của bạn.
- TXT — Văn bản tự do. Chứa SPF policy, public key DKIM và token xác minh domain.
- NS — Chỉ định server nào là authoritative cho domain của bạn.
- PTR — DNS ngược. Ánh xạ IP ngược lại thành hostname — quan trọng với việc tính điểm reputation của mail server.
- SRV — Vị trí dịch vụ. Dùng bởi Kubernetes service discovery, SIP, XMPP và các giao thức tương tự.
Nâng Cao: DNS trong Hạ Tầng Thực Tế
Quản Lý TTL và Cache Trong Quá Trình Migration
TTL (Time To Live) là số giây một DNS record có thể được cache trước khi client phải truy vấn lại. Tính sai điều này trong quá trình migration và bạn sẽ phải chờ các record cũ hết hạn trong nhiều giờ.
# Kiểm tra TTL hiện tại của một domain
dig google.com | grep -i ttl
# Xóa cache DNS trên Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
# Xóa cache DNS trên macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdnsSai lầm phổ biến nhất: thay đổi DNS record mà không giảm TTL trước. TTL mặc định 3600 giây (1 giờ) có nghĩa là một số người dùng vẫn hit IP cũ trong suốt một giờ sau khi bạn thay đổi. Giảm TTL xuống 300 giây ít nhất 24 giờ trước khi migration. Rồi mới thực hiện thay đổi. Nếu có sự cố, bạn rollback trong 5 phút thay vì 60 phút.
Override DNS Cục Bộ cho Môi Trường Development
# Thêm override cục bộ — không có DNS query nào ra ngoài máy bạn
echo "127.0.0.1 myapp.local" | sudo tee -a /etc/hosts
# Xác minh nó phân giải đúng
ping myapp.local
curl http://myapp.localChạy Local DNS Resolver với Docker
Quản lý môi trường dev với năm hoặc nhiều service hơn bằng cách chỉnh tay /etc/hosts nhanh chóng trở nên mệt mỏi. Một local DNS resolver sẽ gọn hơn nhiều:
# Chạy dnsmasq trong Docker
docker run -d \
--name dnsmasq \
-p 53:53/udp \
-p 53:53/tcp \
-v $(pwd)/dnsmasq.conf:/etc/dnsmasq.conf \
andyshinn/dnsmasq
# Ví dụ các dòng cấu hình dnsmasq.conf:
# address=/myapp.local/127.0.0.1
# address=/api.local/192.168.1.100Truy Vấn DNS trong Python
Cần DNS lookup trong code ứng dụng? Thư viện dnspython xử lý nó gọn gàng:
pip install dnspythonimport dns.resolver
# Phân giải bản ghi A
answers = dns.resolver.resolve('google.com', 'A')
for rdata in answers:
print(f"IP: {rdata.address}")
# Phân giải bản ghi MX
mx_records = dns.resolver.resolve('gmail.com', 'MX')
for rdata in mx_records:
print(f"Độ ưu tiên: {rdata.preference}, Mail server: {rdata.exchange}")
# Kiểm tra sự tồn tại của domain
try:
dns.resolver.resolve('nonexistent.example.com', 'A')
except dns.resolver.NXDOMAIN:
print("Domain không tồn tại")
except dns.resolver.NoAnswer:
print("Không tìm thấy bản ghi A")Debug DNS: Những Gì Thực Sự Hiệu Quả
Tìm Phân Giải Chậm hoặc Bị Lỗi
# Đo thời gian truy vấn DNS
time dig google.com
# Kiểm tra DNS server mà hệ thống đang dùng
cat /etc/resolv.conf # Linux
scutil --dns | head -20 # macOS
# Kiểm tra từ nhiều resolver để xác định vị trí sự cố
dig @8.8.8.8 yoursite.com # Google
dig @1.1.1.1 yoursite.com # Cloudflare
dig @9.9.9.9 yoursite.com # Quad9
# Vòng lặp qua các resolver để so sánh nhanh
for server in 8.8.8.8 1.1.1.1 208.67.222.222; do
echo "=== $server ==="
dig @$server yoursite.com +short
donePhát Hiện DNS Hijacking
DNS hijacking phổ biến hơn nhiều người nghĩ — một số ISP làm điều này có chủ đích, và attacker thì nhân cơ hội. Cả hai đều redirect truy vấn của bạn mà không có cảnh báo nào. Kiểm tra nhanh trong hai giây:
# So sánh resolver của ISP với resolver công khai
dig google.com +short
dig @8.8.8.8 google.com +short
# Kết quả khác nhau? Có thứ gì đó đang chặn truy vấn của bạn.DNSSEC: Xác Thực Mật Mã
DNSSEC ký các DNS record bằng mật mã khóa công khai. Nó ngăn chặn tấn công cache poisoning — nơi một resolver độc hại chèn record giả — bằng cách cho phép resolver xác minh tính xác thực của record. Để kiểm tra một domain có sử dụng nó không:
# Kiểm tra trạng thái DNSSEC
dig +dnssec google.com
# Tìm cờ "ad" trong header phản hồi ("dữ liệu đã xác thực")
# Cũng tìm bản ghi RRSIG trong phần answerKiểm Tra Sức Khỏe Domain Bằng Một Lệnh
DOMAIN="yourdomain.com"
echo "=== Bản ghi A ===" && dig $DOMAIN A +short
echo "=== Bản ghi MX ===" && dig $DOMAIN MX +short
echo "=== Bản ghi TXT ===" && dig $DOMAIN TXT +short
echo "=== Bản ghi NS ===" && dig $DOMAIN NS +short
echo "=== TTL ===" && dig $DOMAIN A | grep -i "$DOMAIN" | awk '{print "TTL:", $2, "giây"}'DNS là hạ tầng xứng đáng để đầu tư học hỏi. Những engineer hiểu nó sâu sắc dành thời gian xử lý sự cố cho các vấn đề thực sự. Những người không hiểu thì ngồi nhìn dashboard, tự hỏi tại sao deploy hoạt động trên staging lại thất bại trên production.
Khắc dig vào cơ bắp của bạn. Các lệnh ở đây bao phủ phần lớn các tình huống DNS thực tế — từ migration bị lệch hướng đến mail server hỏng. Khi mọi thứ đang cháy, bạn sẽ là người thực sự biết cần nhìn vào đâu.
