Internet DRAFT - draft-pp-additional-contents
draft-pp-additional-contents
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, <https://www.rfc-editor.org/info/rfc1035>.
[DNS-CLARIFICATIONS]
Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[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,
<https://www.rfc-editor.org/info/rfc6891>.
[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,
<https://www.rfc-editor.org/info/rfc4035>.
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]
