DNS Resolution, Start to Finish

Mỗi khi bạn nhập một domain vào trình duyệt, một chuỗi các truy vấn sẽ kích hoạt trước khi một gói dữ liệu nào đó đến được trang web bạn muốn. Hầu hết chuỗi này là vô hình, và hầu hết các giải thích về nó dừng lại ở "nó giống như một danh bạ điện thoại." Đây là những gì thực sự xảy ra, từng bước một, bao gồm các phần mà mọi người thường bỏ qua.

Stub resolver không thông minh

Hệ điều hành của bạn không thực hiện phân giải DNS thực sự trên chính nó. Nó chạy một stub resolver, một đoạn mã mỏng manh chỉ chuyển tiếp truy vấn của bạn đến bất kỳ máy chủ DNS nào được cấu hình trong /etc/resolv.conf trên Linux hoặc trong cài đặt bộ điều hợp mạng của bạn trên Windows. Kiểm tra của bạn bằng:

cat /etc/resolv.conf

Tệp đó thường trỏ đến bộ định tuyến của bạn (như 192.168.1.1), resolver của ISP của bạn, hoặc một công khai như 1.1.1.1 hoặc 8.8.8.8. Stub resolver không có logic cache riêng ngoài những gì OS cung cấp hoặc một daemon cục bộ như systemd-resolved.

Recursive resolver thực hiện công việc thực sự

Khi truy vấn của bạn đến một recursive resolver, máy chủ đó tiếp quản công việc tìm câu trả lời, ngay cả khi nó phải hỏi nhiều máy chủ khác để đến đó. Nếu câu trả lời đã được cache từ một truy vấn trước đó, bạn sẽ nhận được nó ngay lập tức. Kiểm tra TTL bằng:

dig example.com

Nhìn vào ANSWER SECTION — con số trước kiểu bản ghi (như 300 trước A) là TTL tính bằng giây. Đó là thời gian mà resolver được phép cache bản ghi trước khi hỏi lại.

Nếu không có gì được cache, recursive resolver bắt đầu đi xuống hệ thống phân cấp DNS từ gốc.

Root, TLD, và authoritative server

Có 13 địa chỉ máy chủ root (a.root-servers.net đến m.root-servers.net), mỗi cái được hỗ trợ bởi nhiều máy vật lý thông qua định tuyến anycast. Máy chủ root không biết example.com sống ở đâu, nhưng nó biết máy chủ nào xử lý .com, nên nó trả về một giới thiệu.

Resolver sau đó hỏi một máy chủ TLD .com, cái này lại không biết câu trả lời cuối cùng nhưng biết nameserver nào được ủy quyền cho example.com. Bạn có thể thấy delegation này:

dig +trace example.com

Lệnh đó hiển thị mỗi hop: root, rồi TLD, rồi nameserver được ủy quyền cho domain, kết thúc bằng bản ghi A hoặc AAAA thực tế. Nó là lệnh tốt nhất để hiểu DNS về mặt hình ảnh thay vì lý thuyết.

Authoritative nameserver là điểm dừng cuối cùng. Nó là máy chủ mà chủ sở hữu domain thực sự cấu hình, thường thông qua DNS panel của registrar hoặc một dịch vụ như Route 53 hoặc Cloudflare DNS. Đây là máy chủ duy nhất trong toàn bộ chuỗi có câu trả lời thực sự, chính tắc thay vì một bản sao được cache hoặc một giới thiệu.

Kiểu bản ghi bạn sẽ thực sự gặp

Bản ghi A ánh xạ một tên đến một địa chỉ IPv4, AAAA làm điều tương tự cho IPv6. CNAME trỏ một tên đến một tên khác thay vì một IP, đó là cách các CDN như Cloudflare hoặc Fastly định tuyến lưu lượng mà không để lộ IP thô. Bản ghi MX xử lý định tuyến thư, và bản ghi TXT mang text tùy ý, hiện được sử dụng chủ yếu cho SPF, DKIM, và domain verification string. Bản ghi NS cho thế giới biết máy chủ nào được ủy quyền cho một zone, và đó là kiểu bản ghi làm cho delegation có thể xảy ra ngay từ đầu.

Nơi cache thực sự sống

Caching xảy ra ở nhiều lớp cùng một lúc: chính trình duyệt (Chrome có cache DNS riêng có thể xem được tại chrome://net-internals/#dns), cache resolver của OS, router cục bộ, và recursive resolver phía trên. Đây là lý do tại sao thay đổi DNS có thể dường như hoạt động ngay lập tức trên một thiết bị và mất hàng giờ để hiển thị trên một thiết bị khác — bạn không đang truy cập cùng một cache.

Khi bạn hạ thấp TTL của bản ghi trước khi migration được lên kế hoạch, bạn không tăng tốc độ bất cứ điều gì ngay lập tức. Bạn chỉ đang thu hẹp cửa sổ mà trong đó dữ liệu cũ có thể tồn tại sau khi thay đổi thực sự xảy ra. Làm điều này ít nhất một chu kỳ TTL trước, không phải năm phút trước khi cutover.

Tại sao điều này quan trọng để khắc phục sự cố

Khi một trang web không thể tiếp cận, dig +trace cho bạn biết chính xác lớp nào bị hỏng: một vấn đề root/TLD trông hoàn toàn khác với một authoritative server cấu hình sai hoặc một cache cũ trên máy của bạn. So sánh dig example.com với một resolver đã biết là tốt, như dig example.com @1.1.1.1, xác định xem vấn đề là resolver cục bộ của bạn hay DNS thực tế của domain.

DNS trông đơn giản từ bên ngoài vì nó thường phân giải trong dưới 100ms và không ai nghĩ về nó. Bên dưới, nó là một hệ thống truy vấn phân tán, được cache, có phân cấp mà đã chạy phần lớn không thay đổi trong cấu trúc kể từ những năm 1980, điều này là một lập luận khá tốt cho cách thiết kế ban đầu tồn tại.

Nếu bạn muốn tiến xa hơn với việc này, Korra Studio có các segment liên quan trên DEFENSE_GRID bao gồm DNS security extension, DNS tunneling như một kỹ thuật exfiltration, và xây dựng resolver riêng của bạn từ đầu trong Python.