Domain-Name-System
dig +trace 總是準確的嗎？
當 DNS 記憶體的準確性存在問題時，
dig +trace往往是推薦的方法來確定面向 Internet 的 DNS 記錄的權威答案。+additional這在與也顯示膠水記錄的同時配對時似乎特別有用。有時在這一點上似乎存在一些分歧——有人說它依賴於本地解析器來查找中間名稱伺服器的 IP 地址，但是命令輸出沒有提供任何跡象表明這種情況發生在根的初始列表之外名稱伺服器。
+trace如果 的目的是從根伺服器開始並向下追踪，那麼假設情況並非如此似乎是合乎邏輯的。（至少如果您有正確的根名稱伺服器列表）是否
dig +trace真的將本地解析器用於根名稱伺服器之外的任何內容？
這顯然是一個分階段的問答，但這往往會使人們感到困惑，我找不到涵蓋該主題的規範問題。
dig +trace是一個很好的診斷工具，但它的設計的一個方面被廣泛誤解：將要查詢的每台伺服器的 IP 都是從您的解析器庫中獲得的。這很容易被忽視，並且通常只會在您的本地記憶體對記憶體的名稱伺服器有錯誤答案時才會成為問題。詳細分析
這更容易通過輸出樣本分解；我將省略第一個 NS 代表團之後的所有內容。
; <<>> 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
- （根名稱伺服器）的初始查詢
. IN NS命中本地解析器，在本例中為 Comcast。(75.75.75.75) 這很容易發現。- 下一個查詢是 for
serverfault.com. IN A並針對 執行e.root-servers.net.，從我們剛剛獲得的根名稱伺服器列表中隨機選擇。它的 IP 地址為192.203.230.10，並且由於我們已+additional啟用它，因此它似乎來自膠水。- 由於它對 serverfault.com 不具有權威性，因此它被委託給
com.TLD 名稱伺服器。- 從這裡的輸出中不明顯的是，它
dig沒有e.root-servers.net.從膠水中獲得 IP 地址。在後台，這就是真正發生的事情：
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)
+trace欺騙並諮詢本地解析器以獲取下一跳名稱伺服器的IP地址，而不是諮詢膠水。偷偷摸摸！這通常“足夠好”，不會對大多數人造成問題。不幸的是，有邊緣情況。如果出於某種原因，您的上游 DNS 記憶體為名稱伺服器提供了錯誤的答案，則此模型將完全崩潰。
現實世界的例子：
- 域名過期
- 膠水被重新指向註冊商重定向名稱伺服器
- ns1 和 ns2.yourdomain.com 的假 IP 被記憶體
- 域用恢復的膠水更新
- 任何帶有虛假域名伺服器 IP 的記憶體都會繼續將人們發送到顯示該域名正在出售的網站
在上述情況下，
+trace將表明域所有者自己的名稱伺服器是問題的根源，而您只需一個電話就可以避免錯誤地告訴客戶他們的伺服器配置錯誤。是否可以（或願意）做某事是另一回事，但擁有正確的資訊很重要。
dig +trace是一個很棒的工具，但是像任何工具一樣，您需要知道它做什麼和不做什麼，以及當它證明不足時如何手動解決問題。編輯：
還應該注意的是，它
dig +trace不會警告您NS指向CNAME別名的記錄。這是 ISC BIND（可能還有其他人）不會嘗試糾正的 RFC 違規。+trace將非常樂意接受A它從本地配置的名稱伺服器獲得的記錄，而如果 BIND 要執行完全遞歸，它將拒絕整個區域並使用 SERVFAIL。如果存在膠水，這可能很難解決；這會正常工作，直到刷新 NS 記錄，然後突然中斷。當記錄指向別名時，無膠委託總是會破壞 BIND 的遞歸。
NS