Ai vận hành 1.1.1.1? Kiểm tra một địa chỉ DNS trước khi tin cậy
Địa chỉ DNS dùng cùng VPN không nhất thiết do chính VPN đó vận hành. Hãy xác định trình phân giải, sau đó kiểm tra riêng đường đi và chính sách tên riêng.
Bạn đã dán 1.1.1.1 vào trường DNS của VPN, trang tải được và hướng dẫn có vẻ đã được xác nhận. Quan sát đó hẹp hơn cảm giác: ứng dụng đã hành xử khác đi, và thay đổi vẫn chưa nói gì về việc ai đã trả lời truy vấn hay vì sao cách sắp xếp cũ thất bại. Một hướng dẫn được sao chép thường gọi một địa chỉ công cộng quen thuộc là “DNS của VPN”, và đó là khẳng định về quyền sở hữu chứ không phải về khả năng tiếp cận. Kiểm tra địa chỉ đại diện cho điều gì mất năm phút và ngăn một thay đổi vĩnh viễn được thực hiện vì lý do sai.
Một thiết lập đang hoạt động không phải là danh tính
Địa chỉ trong trường thiết lập là một điểm cuối, và điểm cuối có một đơn vị vận hành. Hai sự thật đó tách biệt, và điều thứ hai là điều mọi người bỏ qua. Với cặp thường được sao chép nhất, câu trả lời là công khai: Cloudflare công bố 1.1.1.1 và 1.0.0.1 là địa chỉ trình phân giải của mình và liệt kê chúng trong tài liệu tham chiếu địa chỉ chính thức. Đó là lý do tên đơn vị vận hành thuộc về bên cạnh địa chỉ, chứ không nằm trong một hướng dẫn riêng.
Nhập cặp đó khi đường hầm đang hoạt động không biến công ty VPN thành đơn vị vận hành của nó và không làm lưu lượng trở nên ẩn danh. Truy vấn rời máy bạn đến một công ty công bố dải địa chỉ, và công ty đó có thể có uy tín mà vẫn không phải bên mà hướng dẫn ngụ ý. Nhãn trong hướng dẫn và đơn vị vận hành trên thực tế là hai khẳng định khác nhau. Không bên nào nói ai vận hành đường mạng ở giữa.
Dùng tài liệu tham chiếu do chính trình phân giải công bố để xác nhận một cặp địa chỉ hoặc một điểm cuối được mã hóa. Khuyến nghị từ nhà cung cấp khác có thể hợp lệ, và “được khuyến nghị bởi”, “được tiếp cận qua” và “được vận hành bởi” vẫn mô tả ba mối quan hệ khác nhau.
So sánh ba thứ mà một bản ghi cần
Một bản ghi sẵn sàng để xem xét tách ba câu hỏi: ai nên nhận truy vấn, trao đổi là văn bản thuần hay được mã hóa, và đường nào nên mang nó. Tên nhà cung cấp không thể điền vào câu thứ hai hay thứ ba, và nhãn quốc gia không thể điền vào bất kỳ câu nào. Viết ba mục trước thay đổi và so sánh chúng sau đó. Những mục đó không thể hoán đổi, và coi chúng là một chính là cách một phỏng đoán trở thành tài liệu.
Chính sự so sánh biến một thiết lập đang hoạt động thành quyết định được ghi lại. Không có nó, người tiếp theo thừa hưởng một địa chỉ không kèm lý do. Hãy đọc cột thứ ba của bảng dưới đây trước, vì đó thực sự là nơi hầu hết các giải thích tự tin dừng lại.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
Bảng cố ý ngắn. Điểm của nó là mỗi mục trả lời một câu hỏi khác nhau, và không trường nào tự điền cả ba.
Một bộ chuyển tiếp cục bộ che giấu nguồn thật
Một thiết bị được cấu hình dùng router của mình làm DNS đang trỏ tới một bộ chuyển tiếp. Địa chỉ đó xác định người nhận tiếp theo của truy vấn, không phải trình phân giải cuối cùng trả lời. Một trình phân giải stub cục bộ thêm đúng bước phụ đó, và rất dễ nhầm nó với thứ thật vì nó xuất hiện trong mọi kết quả trạng thái.
Stub chuyển tiếp tới các nguồn mà cùng kết quả đó cũng liệt kê, thường ở phía dưới. Đọc toàn bộ chuỗi trước khi kết luận bất cứ điều gì về đơn vị vận hành, vì dòng đầu không phải toàn bộ câu trả lời. Nếu không, bạn đang gọi quầy lễ tân là công ty.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'Lệnh thứ hai dùng tên vọng của trình phân giải, nơi đơn vị vận hành công bố một tên, để báo cáo địa chỉ nguồn mà nó thấy. Lệnh thứ ba nêu tên máy chủ đã trả lời, thường không phải địa chỉ bạn đã cấu hình. So sánh cả ba kết quả trước khi ghi lại một đơn vị vận hành.
DNS mã hóa thay đổi cái gì nhìn thấy được, không thay đổi ai nhìn thấy
DNS over HTTPS và DNS over TLS bảo vệ trao đổi giữa máy khách và trình phân giải. Trình phân giải vẫn đọc mọi tên được hỏi, vì trả lời là công việc của nó. Điều thay đổi là ai có thể quan sát trao đổi: mạng cục bộ thấy một kết nối tới một điểm cuối thay vì một dòng truy vấn văn bản thuần.
Điều không thay đổi là quan hệ tin cậy, vẫn trỏ tới tổ chức vận hành điểm cuối đó. Một trình duyệt có thiết lập DNS an toàn riêng có thể bỏ qua hoàn toàn trình phân giải của hệ điều hành. Hãy coi chúng là hai cấu hình có thể không đồng ý với nhau, chứ không phải một thiết lập được áp dụng hai lần.
Tên riêng lại cần quyết định của chính chúng. Một đường hầm công việc có thể định tuyến các miền được chọn tới trình phân giải của tổ chức, và thay thế bằng một dịch vụ công cộng có thể làm hỏng tra cứu nội bộ hoặc tiết lộ tên nội bộ cho bên sai. Kiểm tra chính sách miền trước khi thay thế thiết lập của cả một bộ điều hợp.
Giữ quan sát hẹp
Khi so sánh, hãy giữ cấu hình cũ và đổi một thiết lập mỗi lần. Ghi lại ứng dụng, thao tác, chính sách trình phân giải và liệu tên công cộng cùng tên riêng được phép vẫn phân giải sau khi kết nối lại. Một so sánh có hai thay đổi không chứng minh thay đổi nào. Viết kết quả ở nơi người tiếp theo tìm thấy, ngay cạnh chính thiết lập đó.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comNếu ứng dụng bắt đầu hoạt động, hãy giữ khẳng định nhỏ như bằng chứng cho phép. Thay đổi đó giúp một lần thử, và nó không nói gì về việc trình phân giải trước đó có hành xử thiếu thiện chí hay không, đường hầm có hỏng hay không, hay thiết bị khác có cần cùng thay thế hay không. Kết quả bền vững là một cấu hình mà bạn có thể giải thích đơn vị vận hành và mục đích của nó.