Bắt gói Split-DNS: nói rõ mỗi quan sát được lấy ở đâu

Hai người cùng xử lý một sự cố Split-DNS và nhận được các địa chỉ trình phân giải khác nhau. Một người dùng công cụ tra cứu, một người bắt gói trên bộ điều hợp, và người thứ ba đọc chẩn đoán của chính máy khách. Không ai nói dối, và không ai mô tả cùng một giai đoạn. Gọi tên điểm quan sát biến mâu thuẫn thành bản đồ.

Một lần tra cứu, nhiều điểm quan sát

Với một tên nội bộ, có ít nhất năm nơi để xem: ứng dụng và API trình phân giải mà nó gọi, chính sách miền hiệu lực trên máy khách, một lần bắt trên bộ điều hợp hoặc bộ lọc, ranh giới cổng được kiểm soát, và trình phân giải thực sự nhận truy vấn.

Mỗi nơi trả lời một câu hỏi khác nhau, và không nơi nào tự nó chứng minh truy vấn đã đi đâu.

Bắt gói trên bộ điều hợp cho thấy gói tin, không phải ý định. Nó không cho biết máy khách đã chọn trình phân giải nào, và một lần bắt trống có thể nghĩa là câu trả lời đã lưu trong bộ nhớ đệm hoặc một API trình phân giải khác chứ không phải gói bị bỏ. Hãy coi mỗi quan sát là bằng chứng về một giai đoạn. Sau đó ghép các giai đoạn thành một đường đi.

Bộ lọc của máy khách nằm giữa ứng dụng và dây mạng

Máy khách VPN có Split-DNS áp dụng việc khớp miền trước khi gói tin rời máy. Các tên trong hậu tố được đưa vào đường hầm sẽ đến trình phân giải nội bộ; mọi thứ khác đến trình phân giải cục bộ. Bộ lọc là chính sách, và chính sách có thể khác nhau theo nền tảng và phiên bản máy khách.

Hướng dẫn Split-DNS của Secure Client từ Cisco bao gồm việc khớp miền và bộ lọc Windows, và tách những gì ứng dụng thấy khi dùng API trình phân giải gốc khỏi những gì một công cụ như nslookup thấy. Chính những khác biệt đó là điểm mấu chốt.

Hãy bắt đầu từ hồ sơ hiệu lực và một lần tra cứu thông thường của ứng dụng. Mọi bài kiểm tra nêu tên một máy chủ cụ thể là một sự đi đường vòng có chủ đích; hãy giải thích nó bằng chẩn đoán của chính máy khách, và đừng để nó trở thành tiêu chí chấp nhận.

nslookup đi theo một đường khác với ứng dụng

nslookup tự xây dựng truy vấn DNS của mình và có thể bỏ qua chính sách trình phân giải của hệ điều hành. Điều đó khiến nó hữu ích để hỏi một câu cụ thể với một máy chủ cụ thể, và gây nhầm lẫn khi dùng để kiểm tra những gì ứng dụng sẽ trải nghiệm.

Trên Windows, bảng chính sách phân giải tên quyết định hậu tố nào dùng máy chủ nào. Đọc bảng này cho thấy chính sách mà ứng dụng sẽ tuân theo, và thường đó chính là mảnh còn thiếu.

Hãy đọc chính sách rồi hỏi lại câu đó qua trình phân giải thông thường:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Trình phân giải mã hoá giấu truy vấn, không giấu kết nối

Trình duyệt có trình phân giải DNS-over-HTTPS riêng là một trường hợp hoàn toàn khác. Truy vấn đi ra bên trong TLS, nên việc bắt gói cho thấy kết nối tới một địa chỉ trình phân giải nhưng không cho thấy tên được hỏi.

Trước tiên hãy xác định chính sách được quản lý của trình duyệt, rồi so sánh với một lần tra cứu của hệ điều hành. Một trình duyệt được phép tự chọn trình phân giải có thể không bao giờ thấy chính sách Split-DNS.

Sự thận trọng tương tự áp dụng cho mọi máy khách mang theo trình phân giải riêng. Một lần bắt nhận diện kết nối từ xa không phải bằng chứng về tên truy vấn. Nếu cần tên, hãy lấy từ nhật ký của chính trình phân giải hoặc từ chẩn đoán của ứng dụng, kèm theo các quy tắc riêng tư áp dụng.

So sánh với một bài kiểm tra có nhãn

Chọn một tên nội bộ đã được phê duyệt để kiểm tra, cùng một tên công khai không mang ý nghĩa nhạy cảm. Với mỗi tên, ghi lại thời gian, loại bản ghi, câu trả lời và chính sách mà bạn mong đợi.

Ở nơi được phép, hãy so sánh việc nhận tại trình phân giải với một quan sát hẹp từ máy khách hoặc cổng:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Đừng bao giờ gửi tên riêng tư đến các trình phân giải công cộng không liên quan chỉ để tạo so sánh, và hãy che tất cả những gì bạn chia sẻ. Cuối cùng, tách câu trả lời DNS đúng khỏi kết nối dịch vụ theo sau: địa chỉ riêng tư đã phân giải vẫn cần một tuyến và sự cho phép của ứng dụng.