DNS là gì? Đừng chỉ biết mỗi "trỏ Domain", hãy hiểu sâu về luồng đi của gói tin

Chào anh em, Thái Ngân đây.

Nay rảnh rang ngồi config lại mấy con VPS cho khách, tự nhiên nhớ lại hồi mới vào nghề làm web, cứ đụng đến việc trỏ tên miền về host là toát mồ hôi hột. Kiểu cứ copy paste mấy cái IP rồi cầu nguyện cho nó chạy chứ chả hiểu mô tê gì bên dưới. Sau này làm sâu về hệ thống, đụng chạm nhiều ca khó đỡ liên quan đến độ trễ và bảo mật mới thấy kiến thức về DNS nó quan trọng kinh khủng.

Thấy nhiều anh em dev mình, code thì như rồng như phượng nhưng hỏi sâu về mạng máy tính hay cụ thể là DNS thì hơi lúng túng. Nên bài này tui sẽ không nói mấy cái lý thuyết sách vở kiểu "DNS là danh bạ điện thoại" đâu (cái đó ai chả biết), tui muốn đi sâu vào cơ chế behind the scenes để anh em hiểu tường tận, sau này có gặp lỗi DNS hay cần tối ưu tốc độ tải trang thì biết đường mà lần.

CẤU TRÚC PHÂN CẤP CỦA DNS - KHÔNG PHẢI AI CŨNG NHỚ

Bình thường anh em gõ facebook.com vào trình duyệt, nó ra trang web. Nhưng anh em có bao giờ tự hỏi làm sao cái máy tính nó biết facebook.com nằm ở đâu giữa cái internet bao la này không? Nó không hỏi thẳng một phát ra ngay đâu, mà nó đi theo cấp bậc, nghiêm ngặt như quân đội vậy.

Đầu tiên là Root Name Servers. Đây là mấy ông trùm cuối của internet. Khi máy anh em không biết facebook.com ở đâu, nó sẽ hỏi Root trước. Nhưng Root không biết IP cụ thể, nó chỉ biết ai quản lý đuôi .com thôi. Thế là nó chỉ tay xuống cấp dưới.

Tiếp theo là TLD Name Servers (Top-Level Domain). Đây là mấy ông quản lý các đuôi như .com, .net, .vn. Ông TLD .com này sẽ biết được ai là người nắm giữ thông tin chi tiết của facebook.com (thường là Authoritative Name Server) và chỉ anh em tới đó.

Cuối cùng là Authoritative Name Servers. Đây mới là nơi chứa thông tin chính chủ. Nó nắm giữ bản ghi (Record) thực sự nói rằng "À, cái domain này trỏ về IP 1.2.3.4 nè". Tới đây thì trình duyệt mới có IP để kết nối.

PHÂN BIỆT RECURSIVE DNS VÀ ITERATIVE DNS

Đây là phần kiến thức chuyên sâu mà ít tài liệu tiếng Việt nói kỹ. Quá trình phân giải tên miền nó diễn ra theo hai kiểu chính:

Một là Recursive Query (Truy vấn đệ quy). Kiểu này giống như anh em sai thằng đệ đi mua cơm. Anh em chỉ cần bảo "Mua tao hộp cơm", thằng đệ tự chạy đi hỏi quán này quán kia, xong mang hộp cơm về. Trong DNS, cái này thường là máy anh em hỏi con DNS Resolver (như 8.8.8.8 của Google hay 1.1.1.1 của Cloudflare). Resolver sẽ làm mọi việc cực khổ, chạy đi hỏi Root, hỏi TLD, hỏi Auth Server rồi trả kết quả cuối cùng cho anh em.

Hai là Iterative Query (Truy vấn lặp). Kiểu này thì cục súc hơn. Anh em hỏi Resolver, nếu nó không biết, nó bảo "Tao không biết, nhưng tao biết thằng kia biết, mày qua đó mà hỏi". Thế là anh em phải tự chạy qua thằng kia hỏi tiếp. Thực tế thì các DNS Resolver đóng vai trò trung gian thực hiện Iterative Query thay cho máy tính cá nhân của chúng ta để giảm tải.

CÁC LOẠI BẢN GHI (RECORD) QUAN TRỌNG CẦN NẮM VỮNG

Làm web hay quản trị VPS mà không nắm mấy cái này là toang. Đừng chỉ biết mỗi A record.

• A Record: Cơ bản nhất, trỏ tên miền sang IPv4.
  
  
• AAAA Record: Tương lai là đây, trỏ sang IPv6. Anh em nào làm server nước ngoài sẽ thấy cái này cực quan trọng vì IPv4 đang cạn kiệt.
  
  
• CNAME: Tạo bí danh (Alias). Ví dụ www.ngan.com trỏ về ngan.com. Lưu ý là CNAME không bao giờ được trùng với A record ở root domain, cái này nhiều ông hay mắc lỗi làm web sập lên sập xuống.
  
  
• MX Record: Dành cho mail server. Ông nào setup mail doanh nghiệp mà mail không về thì kiểm tra ngay cái Priority của thằng này.
  
  
• TXT Record: Cái này ngày xưa ít dùng, giờ thì cực quan trọng để xác thực chủ sở hữu (verify domain với Google/Facebook) hoặc cấu hình SPF/DKIM để gửi mail không bị vào Spam.
  

CƠ CHẾ CACHING VÀ TTL (TIME TO LIVE)

Tại sao có lúc anh em đổi IP server rồi mà khách vẫn vào web cũ? Đó là do DNS Caching. Thông tin DNS được lưu lại ở nhiều tầng:

• Trình duyệt (Chrome/Firefox tự cache).
  
  
• Hệ điều hành (Windows/macOS/Linux).
  
  
• Router mạng ở nhà.
  
  
• ISP (Nhà mạng cung cấp internet).
  

Chỉ số TTL (Time To Live) quyết định thời gian cái cache này tồn tại. Nếu anh em set TTL là 86400 (1 ngày), thì khi đổi IP, có thể mất tới 24h khách hàng mới thấy web mới. Mẹo cho anh em: Trước khi có kế hoạch di chuyển server hay đổi IP, hãy hạ TTL xuống thấp (ví dụ 300s - 5 phút) trước đó khoảng 1-2 ngày. Đến lúc đổi IP thì việc cập nhật sẽ diễn ra gần như tức thì.

ANYCAST DNS - VŨ KHÍ BÍ MẬT CỦA TỐC ĐỘ VÀ CHỐNG DDOS

Anh em có thắc mắc tại sao dùng Cloudflare hay Google DNS lại nhanh hơn DNS mặc định của nhà mạng không? Đó là nhờ công nghệ Anycast.

Bình thường (Unicast), một IP ứng với một máy chủ vật lý cụ thể. Còn với Anycast, cùng một địa chỉ IP (ví dụ 1.1.1.1) nhưng nó được gán cho hàng nghìn con server rải rác khắp thế giới.

Khi anh em ở Việt Nam query 1.1.1.1, hệ thống định tuyến sẽ tự động đẩy anh em vào con server gần nhất (ví dụ đặt tại Hong Kong hoặc Singapore, thậm chí là ngay tại Hà Nội/HCM nếu có PoP). Điều này giúp giảm độ trễ (latency) cực lớn. Hơn nữa, nếu bị DDoS, lưu lượng tấn công sẽ bị phân tán ra toàn cầu thay vì tập trung đánh sập một con server duy nhất. Đây là lý do tui luôn khuyên khách hàng mua VPS nên dùng kèm các dịch vụ DNS trung gian xịn xò chứ đừng dùng DNS mặc định của registrar (nhà đăng ký tên miền).

DNS SEC VÀ DOH/DOT - TƯƠNG LAI CỦA BẢO MẬT

Ngày nay hacker ghê gớm lắm, chúng nó có thể thực hiện DNS Spoofing (Giả mạo DNS). Tức là khi người dùng gõ nganhang.com, thay vì trả về IP thật, hacker tiêm vào cache một IP giả mạo dẫn đến trang web lừa đảo y hệt.

Để chống lại cái này, chúng ta có DNSSEC. Hiểu đơn giản, nó giống như việc ký tên đóng dấu đỏ vào gói tin DNS. Nếu gói tin bị chỉnh sửa trên đường đi, chữ ký sẽ không khớp và trình duyệt sẽ chặn lại ngay.

Ngoài ra, truy vấn DNS truyền thống là không mã hóa (gửi text trần). Tức là ông nhà mạng hoặc hacker bắt gói tin sẽ biết anh em đang lướt web nào (dù web đó có HTTPS thì họ vẫn biết anh em truy cập domain nào). Để giải quyết, DoH (DNS over HTTPS) và DoT (DNS over TLS) ra đời, mã hóa toàn bộ quá trình hỏi đường này, đảm bảo sự riêng tư tuyệt đối. Anh em dev nào đang build app hay hệ thống nhạy cảm thì bắt buộc phải nghiên cứu cái này nhé.

Tạm kết, DNS tưởng đơn giản nhưng đào sâu vào thì nó là cả một bầu trời kiến thức về mạng. Hiểu rõ nó giúp anh em debug lỗi nhanh hơn, tối ưu website tốt hơn và đặc biệt là tránh được những lỗi ngớ ngẩn khi deploy dự án. Anh em nào có câu hỏi hóc búa hay gặp case nào dị dị về DNS hay VPS thì cứ comment bên dưới, Thái Ngân tui sẽ giải đáp hết trong tầm hiểu biết.