Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Informational P. van Dijk Expires: 16 June 2022 PowerDNS 13 December 2021 The Additional Section and Glue in DNS Responses draft-pp-additional-contents-01 Abstract Implementers have recently expressed different views on what can appear in the Additional section in DNS responses. Proposals for adding functionality to the DNS protocol that rely on non-glue records in the Additional section rely on having a common understanding of the semantics of the Additional section. This document restates what has been said in other DNS standards, and does not update any of them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 June 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Hoffman & van Dijk Expires 16 June 2022 [Page 1] Internet-Draft Additional; Glue December 2021 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Purpose of the Additional Section . . . . . . . . . . . . . . 2 3. Glue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. Informative References . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction RFC 1034 [DNS-CONCEPTS], RFC 1035 [DNS-BASE], and RFC 2181 [DNS-CLARIFICATIONS] are the basis for understanding the DNS protocol and message format. One important part of the message format is what record types can appear in each section of DNS responses, and the semantics of the presence or absence of those record types in each section. This document focuses on the contents of the Additional section in DNS responses. This document explicitly does not update [DNS-CONCEPTS], [DNS-BASE], [DNS-CLARIFICATIONS], or any other document. 2. Purpose of the Additional Section When describing what each section holds, Section 3.7 of [DNS-CONCEPTS] says: Additional - Carries RRs which may be helpful in using the RRs in the other sections. When describing the algorithm for putting together a DNS response, Section 4.3.2 of [DNS-CONCEPTS] says: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. When describing what each section holds, Section 4.1 of [DNS-BASE] says: Additional - RRs holding additional information Hoffman & van Dijk Expires 16 June 2022 [Page 2] Internet-Draft Additional; Glue December 2021 and that it: contains RRs which relate to the query, but are not strictly answers for the question. 3. Glue Section 4.2.1 of [DNS-CONCEPTS] says: Data that allows access to name servers for subzones (sometimes called "glue" data). and To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. Section 5.4.1 of [DNS-CLARIFICATIONS] says: "Glue" above includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub- zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear. 4. DNSSEC RFC 4035 [DNSSEC] discusses the inclusion of DNSSEC signatures on data in the Additional section. Section 3.1.1 says: When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section. If space does not permit inclusion of both the RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs. If this happens, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit. 5. Conclusions The foundational documents for the DNS did not place any restriction on what additional information might appear in the Additional section of DNS replies. If they had, the widely used extension mechanism in RFC 6891 [DNS-EXTENSIONS] would not be possible. Hoffman & van Dijk Expires 16 June 2022 [Page 3] Internet-Draft Additional; Glue December 2021 Glue records are addresses for name servers. These records can (and almost always do) appear in the Additional section of responses that are delegations. Non-address records that appear in the Additional section are not considered glue as that term is used in existing RFCs. It is both acceptable and common for RRSIG RRs to appear in the Additional section of responses. New protocols can specify that non-address resource records can appear in the Additional section of responses. They can define the semantics of the presence or absence of those non-address records. 6. IANA Considerations This document does not create any new IANA considerations. 7. Security Considerations This document does not create any new security considerations. 8. Informative References [DNS-BASE] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [DNS-CLARIFICATIONS] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [DNS-EXTENSIONS] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . Hoffman & van Dijk Expires 16 June 2022 [Page 4] Internet-Draft Additional; Glue December 2021 Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Peter van Dijk PowerDNS Email: peter.van.dijk@powerdns.com Hoffman & van Dijk Expires 16 June 2022 [Page 5]