Tôi tự hỏi liệu có cách nào để truy vấn máy chủ DNS và bỏ qua bộ đệm ẩn (với dig). Thường thì tôi thay đổi một vùng trên máy chủ DNS và tôi muốn kiểm tra xem nó có giải quyết chính xác từ máy trạm của tôi không. Nhưng vì máy chủ lưu trữ các yêu cầu đã giải quyết, tôi thường nhận được các yêu cầu cũ. Khởi động lại hoặc tải máy chủ không thực sự là một cái gì đó tốt đẹp.
Câu trả lời:
Bạn có thể sử dụng @cú pháp để tra cứu tên miền từ một máy chủ cụ thể. Nếu máy chủ DNS có thẩm quyền cho tên miền đó, phản hồi sẽ không phải là kết quả được lưu trong bộ nhớ cache.
dig @ns1.example.com example.com
Bạn có thể tìm thấy các máy chủ có thẩm quyền bằng cách yêu cầu các NSbản ghi cho một tên miền:
dig example.com NS
+norecurseđược khuyến nghị. +recurseđược bật theo mặc định đôi khi sẽ thay đổi cách máy chủ DNS diễn giải hoàn toàn câu hỏi của bạn.
+tracenhưng hãy cẩn thận của bộ nhớ đệm. Andrew B đã viết lên một lời giải thích tốt về cách bộ nhớ đệm có thể lừa bạn khi chờ máy chủ tên thay đổi.
dig @8.8.8.8 example.com. các hồ sơ xuất hiện nhanh hơn nhiều ở đó.
Không có cơ chế trong giao thức DNS để buộc một máy chủ tên phản hồi mà không sử dụng bộ đệm của nó. Bản thân Dig không phải là một máy chủ tên, nó chỉ đơn giản là một công cụ chuyển truy vấn của bạn tới bất kỳ máy chủ tên nào bạn đã cấu hình, sử dụng các yêu cầu DNS tiêu chuẩn. DNS không bao gồm một cách để nói với một máy chủ không sử dụng đệ quy, nhưng đây không phải là những gì bạn muốn. Điều đó chỉ hữu ích khi bạn muốn truy vấn trực tiếp một máy chủ tên có thẩm quyền.
Nếu bạn muốn ngăn máy chủ tên phản hồi từ bộ đệm của nó, bạn chỉ có thể làm điều đó bằng cách thay đổi cấu hình trên máy chủ tên , nhưng nếu bạn không kiểm soát máy chủ tên thì điều này là không thể.
Tuy nhiên, bạn có thể được đào để bỏ qua các máy chủ tên được cấu hình và thực hiện yêu cầu đệ quy riêng của nó quay lại máy chủ gốc. Để làm điều này, sử dụng +tracetùy chọn.
dig example.com +trace
Trong thực tế vì điều này sẽ chỉ truy vấn các máy chủ có thẩm quyền thay vì bộ giải quyết bộ đệm ẩn cục bộ của bạn, kết quả sẽ không bị cũ ngay cả khi các máy chủ đó sử dụng bộ đệm ẩn nội bộ. Lợi ích bổ sung của việc sử dụng +tracelà bạn có thể thấy tất cả các yêu cầu riêng biệt được thực hiện dọc theo đường dẫn.
+norecursechỉ yêu cầu máy chủ tên trả về bất kỳ thông tin nào nó có (bao gồm thông tin được lưu trong bộ nhớ cache, nếu có), vì vậy điều đó không chính xác. +tracesẽ hoạt động vì nó sẽ theo chuỗi đệ quy đến một máy chủ có thẩm quyền.
+norecurseđề xuất vì nó gây nhầm lẫn vấn đề.
Một điều quan trọng cần lưu ý ở đây, điều mà tôi nhận thấy nhiều người không bao giờ nói đến +tracelà sử dụng +tracephương tiện máy khách đào sẽ thực hiện theo dõi chứ không phải máy chủ DNS được chỉ định trong cấu hình của bạn (/etc/resolv.conf). Vì vậy, nói cách khác, máy khách đào của bạn sẽ hoạt động giống như một máy chủ DNS đệ quy, nếu bạn hỏi nó. Nhưng - quan trọng là bạn chưa có bộ đệm.
Chi tiết hơn - vì vậy nếu bạn đã yêu cầu một mxbản ghi bằng cách sử dụng dig -t mx example.comvà /etc/resolv.conf của bạn là 8.8.8.8 thì làm bất cứ điều gì trong TTL của vùng sẽ trả về kết quả được lưu trong bộ nhớ cache. Theo một cách nào đó, nếu bạn đang tìm kiếm một cái gì đó về khu vực của riêng bạn và cách Google nhìn thấy nó, bạn đã đầu độc kết quả DNS của mình với Google cho TTL của Khu vực của bạn. Không tệ nếu bạn có một đoạn ngắn, hơi rác nếu bạn có 1 giờ.
Vì vậy, trong khi +tracesẽ giúp bạn thấy những gì bạn sẽ thấy nếu bạn hỏi Google lần đầu tiên và nó không có mục được lưu trong bộ nhớ cache, nó có thể cho bạn một ý tưởng sai lầm rằng Google sẽ nói với mọi người giống như +tracekết quả của bạn , đó là Sẽ không có nếu bạn đã hỏi trước đó và có một TTL dài, vì nó sẽ phục vụ điều đó từ bộ đệm cho đến khi hết hạn - THÌ nó sẽ phục vụ giống như những gì bạn +traceđã tiết lộ.
Không thể có quá nhiều chi tiết IMO.
dig mydomain.com +tracechỉ trả lại cho tôi các resolvdkết quả còn sơ khai từ 127.0.0.53. Xem github.com/systemd/systemd/issues/5897
+traceđào bắt đầu theo dõi bằng cách sử dụng máy chủ tên được chỉ định (ví dụ: 8.8.8.8 nếu đó là những gì bạn đã cấu hình) cho lần tra cứu đầu tiên (vùng gốc), nhưng sau đó, nó sử dụng máy chủ tên được trả về cho các truy vấn tiếp theo. Vì vậy, nếu máy chủ tên được cấu hình của bạn không hoạt động hoặc không phản hồi đúng với truy vấn cho máy chủ tên gốc, bạn có thể gặp sự cố (như trong nhận xét trên).
Bash này sẽ đào các mục DNS của example.com từ máy chủ tên được liệt kê đầu tiên của nó:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
Đây giống như một bí danh cho một .zshrc (và có lẽ .bashrc):
# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }
Đây là đầu ra cho /.:
☀ checkdns slashdot.org dev
-->Server DNS Query
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org. 21600 IN SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org. 86400 IN NS ns3.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns4.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns0.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns2.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns1.dnsmadeeasy.com.
slashdot.org. 3600 IN MX 10 mx.sourceforge.net.
slashdot.org. 3600 IN TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org. 3600 IN TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org. 300 IN A 216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms
--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms
Giải pháp này đủ phức tạp để không thực tế để ghi nhớ, nhưng đủ đơn giản để vấn đề không được khắc phục. digkhông phải là chuyên môn của tôi - cải thiện chào mừng :-)