Hiểu Về DNS: Từ Máy Chủ Gốc Đến resolv.conf

Khi bạn gõ google.com vào trình duyệt, mọi thứ dường như diễn ra ngay lập tức. Tuy nhiên, đằng sau đó là một hệ thống mạnh mẽ giúp ánh xạ các tên miền có thể đọc được bởi con người sang các địa chỉ IP thân thiện với máy móc: DNS (Hệ thống Tên miền).

Đối với các kỹ sư DevOps, DNS không chỉ là lý thuyết - nó nằm ở trung tâm của tính khả dụng của ứng dụng, mạng lưới cụm và xử lý sự cố. Hãy cùng tìm hiểu cách hoạt động của DNS và tại sao nó quan trọng trong thực tế DevOps.

🔑 1. Máy Chủ Gốc – Danh Bạ Của Internet

Mọi truy vấn DNS bắt đầu từ các máy chủ gốc.

Có 13 cụm máy chủ gốc được đặt tên (A–M), nhưng nhờ vào anycast, chúng tồn tại dưới dạng hàng trăm máy chủ phân tán trên toàn thế giới.

Dưới đây là quy trình từng bước khi bạn truy vấn google.com:

1. Kiểm Tra Trình Duyệt/Hệ Điều Hành: Trình duyệt kiểm tra bộ nhớ cache, bộ nhớ cache của OS và /etc/hosts. Nếu không có bản ghi, nó sẽ truy vấn đến resolver đã cấu hình (ví dụ: 8.8.8.8).
2. Resolver Đệ Quy → Máy Chủ Gốc: Resolver không biết google.com, vì vậy nó hỏi một máy chủ gốc.
3. Phản Hồi Từ Máy Chủ Gốc: Máy chủ gốc nói: “Tôi không biết google.com, nhưng tôi biết ai quản lý .com. Hãy hỏi máy chủ TLD .com.”
4. Máy Chủ TLD: Máy chủ .com phản hồi, “Tôi không biết IP, nhưng đây là máy chủ ủy quyền cho google.com.”
5. Máy Chủ Ủy Quyền: DNS của Google trả lời: “google.com = 142.250.72.14.”
6. Bước Cuối: Resolver lưu vào cache, và trình duyệt của bạn kết nối trực tiếp đến IP đó.

📌 Trường Hợp Sử Dụng DevOps:
Nếu bạn triển khai myapp.dev trên AWS và cấu hình trong Route53, việc phân phối DNS theo chuỗi này. Một bước sai lầm (ví dụ: phân quyền nameserver sai) = ứng dụng không thể truy cập. Các công cụ như dig hoặc nslookup giúp theo dõi nơi xảy ra lỗi.

🔑 2. Anycasting Của Các Máy Chủ Gốc – Tại Sao DNS Nhanh & Đáng Tin Cậy

Các máy chủ gốc không phải là những máy đơn lẻ. Chúng sử dụng định tuyến anycast:

• Nhiều máy chủ trên toàn thế giới chia sẻ cùng một địa chỉ IP.
• Khi bạn truy vấn, định tuyến BGP đảm bảo bạn sẽ kết nối với máy chủ gốc gần nhất.
• Điều này giảm độ trễ và tăng khả năng chịu lỗi.

📌 Trường Hợp Sử Dụng DevOps:
Đối với các ứng dụng toàn cầu (triển khai tại Mumbai + Virginia), anycasting đảm bảo người dùng luôn kết nối với máy chủ DNS gần nhất, tăng tốc độ yêu cầu. Nếu không có it, DNS sẽ trở thành một nút thắt cổ chai khổng lồ.

🔑 3. Cổng 53 – Cổng Vào Cho DNS

DNS thường sử dụng cổng 53:

• UDP/53 → Mặc định cho các truy vấn (nhanh, nhẹ).
• TCP/53 → Sử dụng nếu phản hồi quá lớn (ví dụ: DNSSEC, chuyển vùng).

📌 Trường Hợp Sử Dụng DevOps:
Nếu tường lửa hoặc Kubernetes NetworkPolicy chặn cổng 53, các pod không thể phân giải tên miền (curl google.com sẽ thất bại bên trong các container). Luôn kiểm tra cổng 53 khi gỡ lỗi các vấn đề DNS trong cụm.

🔑 4. resolv.conf – Cấu Hình Resolver

Trên Linux/macOS, /etc/resolv.conf cho biết hệ thống của bạn các máy chủ DNS nào sẽ được sử dụng.

Ví dụ:

nameserver 8.8.8.8      # Google DNS
nameserver 1.1.1.1      # Cloudflare DNS
search default.svc.cluster.local

• Các dòng nameserver chỉ định nơi các truy vấn sẽ được gửi đến đầu tiên.
• Chỉ thị search là rất quan trọng trong Kubernetes:
  • Bạn chỉ cần chạy ping myservice trong một pod.
  • Đằng sau sân khấu, nó mở rộng thành myservice.default.svc.cluster.local.

📌 Trường Hợp Sử Dụng DevOps:
Nếu các dịch vụ trong Kubernetes không phân giải, hãy kiểm tra /etc/resolv.conf bên trong các pod. Các miền search được cấu hình sai có thể làm hỏng khám phá dịch vụ.

🔑 5. Tệp hosts – Sửa Đổi Thủ Công

Tệp /etc/hosts ánh xạ các tên miền đến địa chỉ IP trước khi truy vấn DNS được thực hiện.

Ví dụ:

127.0.0.1    localhost
192.168.1.10 staging.myapp.dev

• Được kiểm tra trước khi tìm kiếm DNS.
• Hữu ích cho kiểm tra cục bộ và sửa đổi.

📌 Trường Hợp Sử Dụng DevOps:

• Chỉ định staging.myapp.dev đến một IP cục bộ cho việc kiểm tra trước khi phân phối DNS.
• Sửa đổi các miền trong quá trình thử nghiệm CI/CD.
• Gỡ lỗi DNS bằng cách bỏ qua các resolver bên ngoài.

🔑 6. Thêm Một Số Khái Niệm Quan Trọng Khác Về DNS

• Resolver Đệ Quy → Google DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), hoặc nhà cung cấp dịch vụ Internet của bạn.
• Máy Chủ Ủy Quyền → Lưu trữ câu trả lời cuối cùng cho một miền (quản lý qua Route53, Cloudflare, GoDaddy, v.v.).
• Caching DNS → Giảm độ trễ, nhưng TTL sai = bản ghi cũ.
• Phân Phối DNS → Độ trễ toàn cầu khi các bản ghi thay đổi (có thể mất từ phút đến giờ).

⚡ Các Tình Huống Thực Tế Nơi DNS Gây Sự Cố Cho DevOps

1. Pods không thể phân giải dịch vụ → CoreDNS cấu hình sai trong Kubernetes.
2. Ứng dụng đã triển khai nhưng không thể truy cập → Bản ghi DNS bị thiếu hoặc chưa được phân phối. 👉 Sắp tới trong chuỗi bài Advanced DevOps của tôi: “Mạng Kubernetes Được Giải Mã: Từ Giao Tiếp Pod đến Ingress”.
3. Lỗi chứng chỉ SSL → Tên miền trỏ đến IP sai.
4. Độ trễ đa vùng → Không sử dụng định tuyến DNS dựa trên độ trễ (Route53, Cloudflare).
5. Bài kiểm tra CI/CD thất bại → Sử dụng ghi đè /etc/hosts để mô phỏng các môi trường mới.

✅ Kết Luận

DNS là xương sống ẩn của internet. Đối với các kỹ sư DevOps, hiểu biết về máy chủ gốc, anycast, cổng 53, resolv.conf và hosts không chỉ mang tính lý thuyết - mà còn thực tiễn.

Lần tới khi một pod không thể kết nối với một dịch vụ hoặc tên miền mới của bạn không phân giải, bạn sẽ biết chính xác nơi để tìm trong chuỗi.