The Additional Section and Glue in DNS Responses

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 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

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¶

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.¶

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.¶

Authors' Addresses