VPN của bạn đẩy ba máy chủ DNS: máy nào trả lời?
Các mục thêm có thể là dự phòng, tuyến theo miền hoặc phần sót lại từ liên kết vật lý. Gán mỗi mục với phạm vi trước khi gọi danh sách là rò rỉ.
Mở trang cài đặt sau khi kết nối và ba địa chỉ DNS được liệt kê; câu hỏi của cuộc kiểm toán là địa chỉ nào đã xử lý truy vấn cuối của bạn. Chỉ con số không trả lời được gì, vì lệnh đẩy từ ứng dụng khách, một giao diện vật lý và một chính sách theo miền đều ghi vào cùng một khung nhìn. Những mục này mang phạm vi khác nhau, và phạm vi, không phải vị trí, quyết định ai trả lời. Hãy bắt đầu bằng việc tách các nguồn, rồi thử nguồn sở hữu cái tên bạn quan tâm.
Vì sao danh sách dài hơn hồ sơ của bạn
Ứng dụng khách VPN đẩy địa chỉ trình phân giải cho liên kết đường hầm, và hệ điều hành giữ chúng bên cạnh những gì giao diện vật lý đã có. Bộ định tuyến, hợp đồng thuê DHCP doanh nghiệp, một VPN thứ hai và chính sách theo miền mỗi thứ đóng góp một mục riêng. Vì vậy ba địa chỉ trên trang có thể nghĩa là ba phạm vi chứ không phải ba ứng viên cho một việc. Đọc con số như bằng chứng rò rỉ là lỗi đầu tiên của cuộc kiểm toán này.
Trong một giao diện, ứng dụng khách thật sự thử máy chủ theo thứ tự, nên danh sách có thứ tự không phải vô nghĩa. Thứ không phải hàng đợi là khung nhìn hợp nhất, nơi các mục từ hồ sơ, từ liên kết vật lý và từ quy tắc theo miền đứng cạnh nhau mà không có một xếp hạng duy nhất. Sự phân biệt đó quyết định bạn thử gì: thứ tự giải thích hành vi trong một phạm vi, còn phạm vi giải thích mọi thứ khác.
DNS được mã hóa phá vỡ bức tranh từ bên trong một ứng dụng. Trình duyệt hoặc ứng dụng trò chuyện có trình phân giải DNS-over-HTTPS riêng gửi truy vấn hoàn toàn vượt qua danh sách của hệ điều hành, nên các địa chỉ trên trang cài đặt mô tả lưu lượng mà ứng dụng chưa từng tạo ra. Kiểm tra cài đặt trình phân giải của chính ứng dụng trước khi đổ lỗi cho hồ sơ vì một cái tên ra sai.
Mỗi một trong ba phép kiểm tra nói gì
Mỗi nguồn để lại dấu vết ở một nơi khác nhau, và không lệnh nào cho thấy tất cả. Đây là ánh xạ đáng giữ bên cạnh trang cài đặt:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
Trên hệ thống dùng systemd-resolved, resolvectl status là căn cứ, vì nó báo cáo DNS theo từng liên kết cùng với các miền định tuyến. macOS trả lời qua scutil --dns, lệnh này liệt kê các trình phân giải có phạm vi theo thứ tự thử. Windows chia hai nửa: Get-DnsClientServerAddress cho máy chủ theo giao diện và Get-DnsClientNrptPolicy cho các quy tắc hậu tố. Chạy lệnh thuộc về trình phân giải thực sự đang được dùng, vì một máy có môi trường chạy container và trình phân giải máy để bàn có thể cài nhiều hơn một.
Một trình phân giải dự phòng không thể trả lời cho vùng của bạn
Mục thứ hai thường có mặt vì tính sẵn sàng, và tính sẵn sàng chỉ hoạt động nếu bản dự phòng biết các tên. Hỏi một trình phân giải công cộng về tên máy chủ nội bộ và nó trả về NXDOMAIN, hoặc một câu trả lời ký tự đại diện từ miền tìm kiếm không liên quan gì đến bạn. Một chuyển đổi dự phòng không ai kiểm tra sau đó tạo ra gián đoạn đúng vào lúc cần đến nó.
Split DNS tồn tại để ngăn điều đó: các hậu tố của công ty đi đến trình phân giải giữ vùng, và các tên công cộng ở lại đường mặc định. Thiết kế vững chắc, và nó phụ thuộc vào việc danh sách hậu tố đầy đủ. Microsoft ghi lại chính sách trình phân giải theo từng hậu tố điều khiển việc này trên Windows, và cùng ý tưởng xuất hiện dưới dạng miền định tuyến trong systemd-resolved và trình phân giải có phạm vi trên macOS.
So sánh các vùng mà bản dự phòng được phép trả lời với các hậu tố có trong chính sách. So sánh đó tìm ra khoảng trống trước khi người dùng báo rằng một trang nội bộ ngừng phân giải sau khi thay đổi đường hầm.
Hỏi qua chính sách, không vòng qua nó
Hỏi qua trình phân giải của hệ điều hành, vì truy vấn trực tiếp đến máy chủ bỏ qua chính sách và chỉ báo cáo điều máy chủ đó sẽ nói. Khoảng trống giữa hai câu trả lời chính là toàn bộ vấn đề:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Nếu truy vấn hệ thống trả về địa chỉ riêng trong khi truy vấn trực tiếp trả về NXDOMAIN, chính sách đang hoạt động và điểm yếu là bản dự phòng. Nếu cả hai trả về cùng một câu trả lời công cộng, cái tên đang được phân giải ngoài phạm vi bạn định, và danh sách hậu tố là nơi cần xem. Giữ cả hai đầu ra, vì một cuộc tranh luận về trình phân giải kết thúc nhanh hơn bằng hai dòng so với ảnh chụp trang cài đặt.
Sau đó luyện tập đường thất bại, vì một bản dự phòng không ai thử chỉ là giả định. Biến trình phân giải ưu tiên thành lỗ đen cho một truy vấn và xem địa chỉ nào quay lại:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Xóa tuyến đó ngay khi truy vấn xong, nếu không người tiếp theo thừa hưởng một bí ẩn. Nếu các tên nội bộ vẫn phân giải trong khoảng thời gian đó, thì có gì đó ngoài phạm vi dự định đã trả lời chúng. Nếu thay vào đó chúng hết thời gian, bản dự phòng thiếu hoặc được giới hạn đúng cách, và nhật ký của chính trình phân giải cho bạn biết đó là trường hợp nào.
Quyết định: giữ, giới hạn hay gỡ bỏ
Giữ trình phân giải thứ hai khi nó trả lời không gian tên bạn cần và vẫn truy cập được dưới hồ sơ. Giới hạn nó khi nó chỉ nên thấy một hậu tố và không gì khác, và gỡ bỏ khi nó không có phạm vi lẫn mục đích được ghi lại. Một mục không có việc là một rò rỉ tương lai không lợi ích, và giá trị mặc định của nhà cung cấp không phải mục đích.
Ghi kết quả thành bốn cột: hậu tố, trình phân giải, giao diện và chủ sở hữu. Dòng đó trả lời câu hỏi kiểm toán kế tiếp nhanh hơn mọi ảnh chụp, và nó sống sót qua bản cập nhật ứng dụng khách lặng lẽ sắp xếp lại danh sách.