Lần theo truy vấn DNS từng bước để tìm ra nguồn thực sự
Địa chỉ resolver được đẩy xuống không quyết định nguồn mà resolver nhìn thấy. Hãy lần theo máy khách, bộ chuyển tiếp và máy chủ nhận, rồi ghi lại đường đi.
Trao cho máy khách một địa chỉ resolver chỉ quyết định truy vấn được gửi đi đâu, không quyết định nguồn mà resolver sẽ thấy. Định tuyến, chuyển tiếp và dịch địa chỉ lần lượt xen vào giữa hai đầu. Một cẩm nang cho các câu hỏi về nguồn sẽ lần theo truy vấn từng bước và ghi lại điều mỗi bên quan sát thực sự thấy. Thứ tự rất quan trọng, vì một khẳng định đưa ra trước khi quan sát chỉ là phỏng đoán với định dạng đẹp hơn.
Ghi lại cách bố trí trước khi thu thập bằng chứng
Bốn nơi có thể cho bạn biết điều gì đó về nguồn DNS, và không phải nơi nào cũng nói cùng một điều. Nhân của máy khách biết nó sẽ dùng nguồn nào, bộ chuyển tiếp biết nó đã gửi gì lên trên, thiết bị dịch biết nó đã viết lại gì, và resolver nhận biết điều gì đã đến. Hãy ghi lại những nơi bạn thực sự có thể chạm tới trước khi thu thập bất cứ thứ gì.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Cũng hãy ghi lại kỳ vọng của bạn, kể cả resolver mà bạn cho là đang được dùng. Một tuyến bị tách có thể gửi truy vấn tới nơi hoàn toàn khác, và bộ nhớ đệm có thể trả lời mà không có bất kỳ trao đổi nào lên trên, nên một giả định chỉ giữ trong đầu sẽ không sống sót qua cú bất ngờ đầu tiên. Hãy giữ thiết kế đã công bố và đường đi quan sát được ở hai cột riêng của cùng một ghi chú; khi hai thứ đó không khớp, bạn đã tìm ra câu hỏi đáng theo đuổi.
Kiểm tra tiến trình nào thực sự đã gửi truy vấn
Bắt đầu từ máy khách: ghi lại địa chỉ resolver, tên truy vấn và thời điểm, rồi xác nhận tiến trình nào đã gửi nó. Dòng đầu tiên bên dưới nêu tên tiến trình đang giữ socket UDP, và đó chính là phép kiểm tra mà tiêu đề này hứa hẹn. Nếu tiến trình đó là trợ lý trình duyệt hay môi trường chạy container thay vì resolver của hệ thống, phần còn lại của dấu vết mô tả một đường đi mà không ai yêu cầu.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Trên một máy có nhiều giao diện, hãy tìm ra địa chỉ nguồn mà nhân chọn cho đích đó trước khi nhìn sang chỗ khác. Đó là điểm cuối cùng mà đường đi hoàn toàn nằm trong tầm kiểm soát của bạn, và đó là giá trị bạn sẽ so với điều resolver báo cáo. Sự không khớp là dấu hiệu rằng có thứ gì ở giữa đã viết lại gói tin, hoặc đã có hai truy vấn khác nhau được gửi đi.
Giữ các tên thử nghiệm ở dạng nội bộ, vì một tên nội bộ gửi tới resolver công cộng không chứng minh được gì về đường đi nội bộ và lại công bố một cái tên mà bạn không cần công bố. Trình duyệt có bật DNS an toàn sẽ không xuất hiện trong danh sách socket đó, và chính sự vắng mặt ấy là câu trả lời.
Bộ chuyển tiếp thực hiện một truy vấn thứ hai, riêng biệt
Bộ chuyển tiếp biến một lần trao đổi thành hai. Yêu cầu từ phía dưới đến, rồi bộ chuyển tiếp gửi truy vấn của chính nó lên trên từ địa chỉ mà nó chọn. Cấu hình của nó, chứ không phải máy khách, quyết định điều resolver phía trên nhìn thấy.
tài liệu dnsmasq đáng đọc vì lý do đó: nó ghi lại cách bộ chuyển tiếp chọn máy chủ phía trên và ràng buộc phía lắng nghe của mình, và không có gì trong cách bố trí đó mang nguồn của máy khách lên trên. Vì thế nhật ký resolver hiển thị địa chỉ cổng là bình thường, không phải bằng chứng của lỗi. Sự vắng mặt cũng dễ bị đọc sai như vậy, vì một lần trúng bộ nhớ đệm không tạo ra truy vấn nào lên trên và trông y hệt một truy vấn chưa bao giờ đến. Hãy đọc cấu hình của bộ chuyển tiếp và trạng thái bộ nhớ đệm của nó trước khi đưa ra một trong hai kết luận. Hai câu hỏi, hai nơi để nhìn.
Đọc nguồn tại resolver nhận
Quan sát duy nhất giải quyết được việc này được thực hiện ở phía máy chủ. Mọi điều suy ra từ danh sách giao diện của máy khách vẫn chỉ là giả thuyết cho tới khi resolver báo cáo điều thực sự đã đến.
tcpdump -ni any port 53 and host 10.20.30.53Bắt gói trên máy resolver, giữ bản bắt ngắn và có giới hạn, và lưu ở nơi chính sách cho phép. Nếu nguồn quan sát được là một địa chỉ đã dịch, câu hỏi tiếp theo là thiết bị nào đã thực hiện việc dịch và chính sách của nó có phải là chính sách dự kiến hay không. Bản bắt trả lời điều gì đã đến; nó không giải thích vì sao chính sách cho phép. Hãy nêu tên bên quan sát và bước trong ghi chú, vì một khẳng định về quyền riêng tư đối với cổng là khẳng định về bước đó chứ không phải về toàn bộ đường đi.
Viết phát hiện như một đường đi, không phải một địa chỉ
Ghi lại máy khách, resolver, bất kỳ bộ chuyển tiếp nào, nguồn quan sát được ở mỗi bước và chính sách chi phối nó. Bản ghi như vậy trả lời phần lớn câu hỏi về sau mà không cần bắt gói lần nữa. Hãy vẽ nó như một chuỗi, vì danh sách địa chỉ che mất bước nào sinh ra cái nào.
Gắn ngày tháng, phiên bản máy khách và bản sửa cấu hình vào bản vẽ, để người đọc sau biết nó còn áp dụng hay không. Tách nguồn vận chuyển khỏi mọi thứ khác mà dịch vụ xử lý, vì thấy một địa chỉ cổng không nói gì về những gì còn được lưu. Vị trí resolver cũng không nói gì về việc máy khách nào đã hỏi. Chính việc tách các khẳng định đó ra là điều làm cho kết luận đứng vững khi bị rà soát.