ICANN

paul.hoffman@icann.org

PowerDNS

peter.van.dijk@powerdns.com

Internet-Draft 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.

RFC 1034 , RFC 1035 , and RFC 2181 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 , , , or any other document.

When describing what each section holds, Section 3.7 of 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 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 says: Additional – RRs holding additional information and that it: contains RRs which relate to the query, but are not strictly answers for the question.

Section 4.2.1 of 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 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.

RFC 4035 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.

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 would not be possible. 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.

This document does not create any new IANA considerations.

This document does not create any new security considerations.

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]