Là đào + theo dõi luôn luôn chính xác?

Khi độ chính xác của bộ đệm DNS bị nghi ngờ, dig +tracecó xu hướng là cách được đề xuất để xác định câu trả lời có thẩm quyền cho bản ghi DNS đối mặt với internet. Điều này dường như đặc biệt hữu ích khi cũng được ghép nối với +additional, cũng hiển thị các bản ghi keo.

Đôi khi dường như có một số bất đồng về điểm này - một số người nói rằng nó dựa vào trình phân giải cục bộ để tra cứu địa chỉ IP của các máy chủ tên trung gian, nhưng đầu ra lệnh không đưa ra dấu hiệu nào cho thấy điều này xảy ra ngoài danh sách gốc ban đầu máy chủ tên. Có vẻ hợp lý khi cho rằng điều này sẽ không xảy ra nếu mục đích +tracelà bắt đầu từ các máy chủ gốc và theo dõi bạn. (ít nhất nếu bạn có đúng danh sách máy chủ tên gốc)

Có dig +tracethực sự sử dụng trình phân giải cục bộ cho bất cứ điều gì qua máy chủ tên gốc không?

Đây rõ ràng là một câu hỏi và trả lời được dàn dựng, nhưng điều này có xu hướng gây nhầm lẫn cho mọi người thường xuyên và tôi không thể tìm thấy một câu hỏi kinh điển về chủ đề này.

dig +tracelà một công cụ chẩn đoán tuyệt vời, nhưng một khía cạnh trong thiết kế của nó bị hiểu lầm rộng rãi: IP của mọi máy chủ sẽ được truy vấn được lấy từ thư viện trình phân giải của bạn . Điều này rất dễ bị bỏ qua và thường chỉ trở thành một vấn đề khi bộ đệm cục bộ của bạn có câu trả lời sai cho một máy chủ lưu trữ tên.

Phân tích chi tiết

Điều này dễ dàng hơn để phá vỡ với một mẫu đầu ra; Tôi sẽ bỏ qua mọi thứ qua phái đoàn NS đầu tiên.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• Truy vấn ban đầu cho . IN NS(máy chủ tên gốc) đánh vào trình phân giải cục bộ, trong trường hợp này là Comcast. ( 75.75.75.75) Điều này rất dễ nhận ra.
• Truy vấn tiếp theo là cho serverfault.com. IN Avà chạy ngược lại e.root-servers.net., được chọn ngẫu nhiên từ danh sách các máy chủ tên gốc mà chúng ta vừa có. Nó có một địa chỉ IP 192.203.230.10và vì chúng tôi đã +additionalkích hoạt nên nó xuất hiện từ keo.
• Vì nó không có thẩm quyền cho serverfault.com, nên điều này được ủy quyền cho các com.máy chủ tên TLD.
• Điều không rõ ràng từ đầu ra ở đây là digkhông lấy được địa chỉ IP e.root-servers.net.từ keo.

Trong nền, đây là những gì thực sự đã xảy ra:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+tracelừa và tham khảo bộ giải quyết cục bộ để lấy địa chỉ IP của máy chủ tên hop tiếp theo thay vì tư vấn keo. Lén lút!

Điều này thường là "đủ tốt" và sẽ không gây ra vấn đề cho hầu hết mọi người. Thật không may, có trường hợp cạnh. Nếu vì bất kỳ lý do gì, bộ đệm DNS ngược dòng của bạn cung cấp câu trả lời sai cho máy chủ tên, mô hình này bị hỏng hoàn toàn.

Ví dụ thế giới thực:

• tên miền hết hạn
• keo được bổ sung tại máy chủ tên chuyển hướng đăng ký
• IP không có thật được lưu trữ cho ns1 và ns2.yourdomain.com
• tên miền được làm mới với keo phục hồi
• bất kỳ bộ nhớ cache nào có IP máy chủ tên không có thật tiếp tục gửi mọi người đến một trang web cho biết tên miền được rao bán

Trong trường hợp trên, +tracesẽ đề xuất rằng máy chủ tên riêng của chủ sở hữu tên miền là nguồn gốc của vấn đề và bạn chỉ cần gọi một câu không chính xác cho khách hàng rằng máy chủ của họ bị định cấu hình sai. Cho dù đó là điều gì đó bạn có thể (hoặc sẵn sàng) làm điều gì đó là một câu chuyện khác, nhưng điều quan trọng là phải có thông tin chính xác.

dig +trace là một công cụ tuyệt vời, nhưng giống như bất kỳ công cụ nào, bạn cần biết nó làm gì và không làm gì, và làm thế nào để khắc phục sự cố một cách thủ công khi nó không đủ.

Chỉnh sửa:

Cũng cần lưu ý rằng dig +tracesẽ không cảnh báo bạn về NScác hồ sơ chỉ vào CNAMEbí danh. Đây là vi phạm RFC mà ISC BIND (và có thể cả những người khác) sẽ không cố gắng sửa. +tracesẽ hoàn toàn vui vẻ chấp nhận Abản ghi mà nó nhận được từ máy chủ tên được cấu hình cục bộ của bạn, trong khi nếu BIND được thực hiện đệ quy đầy đủ thì nó sẽ từ chối toàn bộ khu vực bằng một SERVFAIL.

Điều này có thể khó khăn để khắc phục sự cố nếu có keo; Điều này sẽ hoạt động tốt cho đến khi các bản ghi NS được làm mới , sau đó đột nhiên bị phá vỡ. Các phái đoàn không có ánh sáng sẽ luôn phá vỡ đệ quy của BIND khi một NSkỷ lục chỉ vào một bí danh.

Một cách khác để theo dõi độ phân giải DNS mà không sử dụng trình phân giải cục bộ cho bất cứ điều gì ngoại trừ tìm máy chủ tên gốc, là sử dụng dnsgraph (Tiết lộ đầy đủ: Tôi đã viết điều này). Nó có một công cụ dòng lệnh và một phiên bản web, trong đó bạn có thể tìm thấy một ví dụ tại http://ip.seveas.net/dnsgraph/

Ví dụ cho serverfault.com, hiện thực sự có vấn đề về DNS:

Rất muộn với chủ đề này, nhưng tôi nghĩ rằng một phần của câu hỏi là tại sao một dig + dấu vết sử dụng các truy vấn đệ quy cho các trình phân giải cục bộ chưa được giải thích trực tiếp và giải thích này có liên quan đến độ chính xác của kết quả của dig + dấu vết.

Sau truy vấn đệ quy ban đầu cho các bản ghi NS của vùng gốc, sau đó đào có thể đưa ra các truy vấn tiếp theo cho các trình phân giải cục bộ theo các điều kiện sau:

1. một phản hồi giới thiệu bị cắt ngắn do kích thước của phản hồi vượt quá 512 byte cho truy vấn lặp tiếp theo

2. đào chọn một bản ghi NS từ phần AUTHORITY của phản hồi giới thiệu mà bản ghi A (keo) tương ứng bị thiếu trong phần THÊM

Vì đào chỉ có một tên miền từ bản ghi NS, nên đào phải phân giải tên thành địa chỉ IP bằng cách truy vấn máy chủ DNS cục bộ. Đây là nguyên nhân gốc rễ (ý định chơi chữ, xin lỗi).

AndrewB có một ví dụ không hoàn toàn phù hợp với những gì tôi vừa mô tả, trong đó bản ghi NS vùng gốc được chọn:

. 121459 IN NS e.root-servers.net.

có một bản ghi A tương ứng:

e.root-servers.net. 354907 IN A 192.203.230.10

Tuy nhiên, xin lưu ý rằng không có bản ghi AAAA tương ứng cho root điện tử, cũng như không có bản ghi AAAA cho một số máy chủ gốc khác.

Ngoài ra, lưu ý kích thước của phản ứng:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 byte là kích thước phổ biến cho các phản hồi đã bị cắt ngắn (tức là bản ghi keo tiếp theo sẽ có> 16 byte, đặt phản hồi trên 512 byte). Nói cách khác, trong một truy vấn cho các bản ghi NS gốc, một AUTHORITY hoàn chỉnh và THÊM hoàn chỉnh (cả bản ghi A và AAAA) sẽ vượt quá 512 byte, do đó, bất kỳ truy vấn dựa trên UDP nào không chỉ định kích thước truy vấn lớn hơn thông qua các tùy chọn EDNS0 sẽ nhận được phản hồi bị cắt ở đâu đó trong phần BỔ SUNG, vì dấu vết trên cho thấy (chỉ f, h, i, j và k có hồ sơ keo A và AAAA).

Việc thiếu bản ghi AAAA cho e.root-servers.net và kích thước của phản hồi cho "NS." truy vấn mạnh mẽ đề nghị rằng truy vấn đệ quy tiếp theo được thực hiện vì lý do tôi yêu cầu. Có lẽ O / S của máy khách có khả năng IPv6 và thích các bản ghi AAAA - hoặc một số lý do khác.

Nhưng trong mọi trường hợp, sau khi đọc chủ đề này, tôi đã xem xét hiện tượng đào + theo dõi thực hiện các truy vấn đệ quy tiếp theo truy vấn ban đầu cho root. Theo kinh nghiệm của tôi, sự tương ứng giữa việc chọn một bản ghi NS mà không có bản ghi A / AAAA tương ứng và sau đó gửi một truy vấn đệ quy cho bản ghi đó đến DNS cục bộ là 100%, theo kinh nghiệm của tôi. Và điều ngược lại là đúng - Tôi chưa thấy các truy vấn đệ quy khi bản ghi NS được chọn từ giới thiệu có bản ghi keo tương ứng.