Glue 記錄是否被遞歸解析器記憶體？

Glue記錄中權威名稱伺服器的IP地址是否被遞歸解析器記憶體？

頂級域的名稱伺服器包括膠水以及域名的委託。

現在，遞歸解析器是否記憶體此“A”/“AAAA”記錄（粘合記錄）？我知道僅當響應來自“權威”名稱伺服器時才適用記憶體，但此處 TLD 名稱伺服器進一步委託並且不能被視為權威。

或者

，權威名稱伺服器是否還提供自己的 IP 地址作為 A 記錄（以及域的 A 記錄），這就是遞歸解析器記憶體的內容？

通常，膠水記錄不會作為權威答案給出，如果您查看以下查詢的標誌（是否存在aa 權威答案；RFC 1035, 4.1.1），您可能會注意到：

• 對父母的權威：

dig com NS @f.gtld-servers.net
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

• 刪除控制。兩者都在附加部分中給出了粘合記錄。

dig google.com NS @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

dig ns1.google.com A @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

• 來自權威伺服器的權威答案：

dig google.com NS @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

dig ns1.google.com A @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

RFC 1034, 5.3.3中的基本算法記憶體了大部分響應數據；只有失敗和其他奇怪的內容（d）被忽略（重點是我的）：

• 一種。如果響應回答了問題或包含名稱錯誤，則記憶體數據並將其返回給客戶端。
• 灣。如果響應包含對其他伺服器的更好委託，則記憶體委託資訊，然後轉到步驟 2。
• C。如果響應顯示 CNAME 而不是答案本身，則記憶體 CNAME，將 SNAME 更改為 CNAME RR 中的規範名稱，然後轉到步驟 1。
• d。如果響應顯示伺服器故障或其他奇怪的內容，請從 SLIST 中刪除伺服器並返回步驟 3。

RFC 還提到某些實現可以選擇強制解析器忽略記憶體的數據並諮詢權威伺服器。真正發生的事情取決於實施。根據Kudelski 安全研究的 DNS 如何殺死網際網路：

除了可能導致非故意錯誤響應的錯誤之外，還必須考慮記憶體中毒（請參閱Dan Kaminsky 的 2008 DNS 漏洞和DNS 記憶體中毒 Hitchhiker 指南）。許多 DNS 記憶體實現將粘合記錄記憶體為正常記錄，因此 DNS 伺服器可能會提供惡意響應，從而導致記憶體中的條目錯誤。

例如：

evil.com.       IN NS ns.company.com.
ns.company.com. IN A 6.6.6.6

雖然合法伺服器說

company.com.    IN NS ns.company.com.
ns.company.com. IN A 1.2.3.4

因此，在記錄的整個生命週期內，錯誤的 IP 地址最終都會在記憶體中。為了避免這個問題，大多數記憶體解析器實現不信任並忽略超出管轄範圍的 NS 記錄的可選粘合記錄，因此忽略 ns.company.com. IN A 6.6.6.6上面範例中的 。DNS 管理員須知：最好只擁有轄區內記錄。

答案是否權威本身並不是記錄是否應該被記憶體的指標：

• 上層名稱伺服器是同一權威名稱伺服器結構的一部分。因此，由於他們確實委派了對其子域的控制權，即最終可以控制誰可以權威地回答，他們應該被信任並且值得信賴。通常，粘合記錄應該與區域本身的記錄相匹配，根據 IANA對權威名稱伺服器的技術要求，其他一切都將是配置錯誤：

膠水與權威數據的一致性

對於將 IP 地址列為粘合的名稱伺服器，IP 地址必須與該主機的權威 A 和 AAAA 記錄匹配。

委託和區域之間的一致性

由權威名稱伺服器提供的 NS 記錄集必須與為父區域中的委託提議的記錄集相匹配。

• 並非每個遞歸伺服器都從根名稱伺服器開始解析名稱，但也有更複雜的遞歸基礎設施。解析器可以有轉發器，他們要求的其他遞歸名稱伺服器，而不是權威名稱伺服器。這些響應從不具有權威性，但始終被記憶體。

• 在 DNS 記憶體中毒場景中，肇事者不是任何權威名稱伺服器，而是欺騙來自可信來源的答案，無論它是權威名稱伺服器還是轉發器。因為 DNS 使用 UDP，所以欺騙響應更容易。對此有一些解決方案：

  • 最大 UDP 響應大小。如果響應大於即大於單個 UDP 數據包，則 DNS 使用 TCP。有一個附加部分，包含粘合記錄的響應很容易越過該邊界。TCP 連接並不是那麼容易被欺騙，因為它需要一個中間人位置。
  • DNSSEC 驗證。欺騙性響應的記錄不能具有匹配的 DNSSEC 簽名，因此不會被記憶體。
  • 加密的 DNS。有兩個標準：基於 TLS 的 DNS ( RFC 7858 ) 和基於 HTTPS 的 DNS ( RFC 8484 )。

引用自：https://serverfault.com/questions/1019332