mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

add rfc7477 and rfc8020

Browse Source
This commit is contained in:
Mark Andrews
2016-11-16 19:12:09 +11:00
parent 28f344c18a
commit cbd3082c62
3 changed files with 1407 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/rfc/index
View File

@@ -167,3 +167,4 @@
IPv4 Locally-Served DNS Zones Registry IPv4 Locally-Served DNS Zones Registry
7830: The EDNS(0) Padding Option 7830: The EDNS(0) Padding Option
7873: Domain Name System (DNS) Cookies 7873: Domain Name System (DNS) Cookies
8020: NXDOMAIN: There Really Is Nothing Underneath

843
doc/rfc/rfc7477.txt Normal file
View File

@@ -0,0 +1,843 @@
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 7477 Parsons, Inc.
Category: Standards Track March 2015
ISSN: 2070-1721
Child-to-Parent Synchronization in DNS
Abstract
This document specifies how a child zone in the DNS can publish a
record to indicate to a parental agent that the parental agent may
copy and process certain records from the child zone. The existence
of the record and any change in its value can be monitored by a
parental agent and acted on depending on local policy.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7477.
Copyright Notice
Copyright (c) 2015 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hardaker Standards Track [Page 1]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
Table of Contents
1. Introduction ....................................................2
1.1. Terminology Used in This Document ..........................3
2. Definition of the CSYNC RRType ..................................3
2.1. The CSYNC Resource Record Format ...........................4
2.1.1. The CSYNC Resource Record Wire Format ...............4
2.1.2. The CSYNC Presentation Format .......................6
2.1.3. CSYNC RR Example ....................................6
3. CSYNC Data Processing ...........................................6
3.1. Processing Procedure .......................................7
3.2. CSYNC Record Types .........................................8
3.2.1. The NS type .........................................8
3.2.2. The A and AAAA Types ................................9
4. Operational Considerations ......................................9
4.1. Error Reporting ...........................................10
4.2. Child Nameserver Selection ................................10
4.3. Out-of-Bailiwick NS Records ...............................10
4.4. Documented Parental Agent Type Support ....................11
4.5. Removal of the CSYNC Records ..............................11
4.6. Parent/Child/Grandchild Glue Synchronization ..............12
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgments ...................................................15
Author's Address ..................................................15
1. Introduction
This document specifies how a child zone in the DNS ([RFC1034]
[RFC1035]) can publish a record to indicate to a parental agent (see
Section 1.1 for a definition of "parental agent") that it can copy
and process certain records from the child zone. The existence of
the record and any change in its value can be monitored by a parental
agent and acted on depending on local policy.
Currently, some resource records (RRs) in a parent zone are typically
expected to be in sync with the source data in the child's zone. The
most common records that should match are the nameserver (NS) records
and any necessary associated address records (A and AAAA), also known
as "glue records". These records are referred to as "delegation
records".
It has been challenging for operators of child DNS zones to update
their delegation records within the parent's set in a timely fashion.
These difficulties may stem from operator laziness as well as from
Hardaker Standards Track [Page 2]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
the complexities of maintaining a large number of DNS zones. Having
an automated mechanism for signaling updates will greatly ease the
child zone operator's maintenance burden and improve the robustness
of the DNS as a whole.
This document introduces a new Resource Record Type (RRType) named
"CSYNC" that indicates which delegation records published by a child
DNS operator should be processed by a parental agent and used to
update the parent zone's DNS data.
This specification was not designed to synchronize DNSSEC security
records, such as DS RRsets. For a solution to this problem, see the
complementary solution [RFC7344], which is designed to maintain
security delegation information. In addition, this specification
does not address how to perform bootstrapping operations, including
to get the required initial DNSSEC-secured operating environment in
place.
1.1. Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Terminology describing relationships between the interacting roles
involved in this document are defined in the following list:
Child: The entity on record that has the delegation of the domain
from the parent
Parent: The domain in which the child is registered
Child DNS operator: The entity that maintains and publishes the zone
information for the child DNS
Parental agent: The entity that the child has relationship with, to
change its delegation information
2. Definition of the CSYNC RRType
The CSYNC RRType contains, in its RDATA component, these parts: an
SOA serial number, a set of flags, and a simple bit-list indicating
the DNS RRTypes in the child that should be processed by the parental
agent in order to modify the DNS delegation records within the
parent's zone for the child DNS operator. Child DNS operators
wanting a parental agent to perform the synchronization steps
outlined in this document MUST publish a CSYNC record at the apex of
the child zone. Parental agent implementations MAY choose to query
Hardaker Standards Track [Page 3]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
child zones for this record and process DNS record data as indicated
by the Type Bit Map field in the RDATA of the CSYNC record. How the
data is processed is described in Section 3.
Parental agents MUST process the entire set of child data indicated
by the Type Bit Map field (i.e., all record types indicated along
with all of the necessary records to support processing of that type)
or else parental agents MUST NOT make any changes to parental records
at all. Errors due to unsupported Type Bit Map bits, or otherwise
nonpunishable data, SHALL result in no change to the parent zone's
delegation information for the child. Parental agents MUST ignore a
child's CSYNC RDATA set if multiple CSYNC resource records are found;
only a single CSYNC record should ever be present.
The parental agent MUST perform DNSSEC validation ([RFC4033]
[RFC4034] [RFC4035]), of the CSYNC RRType data and MUST perform
DNSSEC validation of any data to be copied from the child to the
parent. Parents MUST NOT process any data from any of these records
if any of the validation results indicate anything other than
"Secure" [RFC4034] or if any the required data cannot be successfully
retrieved.
2.1. The CSYNC Resource Record Format
2.1.1. The CSYNC Resource Record Wire Format
The CSYNC RDATA consists of the following fields:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOA Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map (continued) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1.1. The SOA Serial Field
The SOA Serial field contains a copy of the 32-bit SOA serial number
from the child zone. If the soaminimum flag is set, parental agents
querying children's authoritative servers MUST NOT act on data from
zones advertising an SOA serial number less than this value. See
[RFC1982] for properly implementing "less than" logic. If the
soaminimum flag is not set, parental agents MUST ignore the value in
the SOA Serial field. Clients can set the field to any value if the
soaminimum flag is unset, such as the number zero.
Hardaker Standards Track [Page 4]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
Note that a child zone's current SOA serial number may be greater
than the number indicated by the CSYNC record. A child SHOULD update
the SOA Serial field in the CSYNC record every time the data being
referenced by the CSYNC record is changed (e.g., an NS record or
associated address record is changed). A child MAY choose to update
the SOA Serial field to always match the current SOA Serial field.
Parental agents MAY cache SOA serial numbers from data they use and
refuse to process data from zones older than the last instance from
which they pulled data.
Although Section 3.2 of [RFC1982] describes how to properly implement
a less-than comparison operation with SOA serial numbers that may
wrap beyond the 32-bit value in both the SOA record and the CSYNC
record, it is important that a child using the soaminimum flag must
not increment its SOA serial number value more than 2^16 within the
period of time that a parent might wait between polling the child for
the CSYNC record.
2.1.1.2. The Flags Field
The Flags field contains 16 bits of boolean flags that define
operations that affect the processing of the CSYNC record. The flags
defined in this document are as follows:
0x00 0x01: "immediate"
0x00 0x02: "soaminimum"
The definitions for how the flags are to be used can be found in
Section 3.
The remaining flags are reserved for use by future specifications.
Undefined flags MUST be set to 0 by CSYNC publishers. Parental
agents MUST NOT process a CSYNC record if it contains a 1 value for a
flag that is unknown to or unsupported by the parental agent.
2.1.1.2.1. The Type Bit Map Field
The Type Bit Map field indicates the record types to be processed by
the parental agent, according to the procedures in Section 3. The
Type Bit Map field is encoded in the same way as the Type Bit Map
field of the NSEC record, described in [RFC4034], Section 4.1.2. If
a bit has been set that a parental agent implementation does not
understand, the parental agent MUST NOT act upon the record.
Specifically, a parental agent must not simply copy the data, and it
must understand the semantics associated with a bit in the Type Bit
Map field that has been set to 1.
Hardaker Standards Track [Page 5]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
2.1.2. The CSYNC Presentation Format
The CSYNC presentation format is as follows:
The SOA Serial field is represented as an integer.
The Flags field is represented as an integer.
The Type Bit Map field is represented as a sequence of RRType
mnemonics. When the mnemonic is not known, the TYPE
representation described in [RFC3597], Section 5, MUST be used.
Implementations that support parsing of presentation format
records SHOULD be able to read and understand these TYPE
representations as well.
2.1.3. CSYNC RR Example
The following CSYNC RR shows an example entry for "example.com" that
indicates the NS, A, and AAAA bits are set and should be processed by
the parental agent for example.com. The parental agent should pull
data only from a zone using a minimum SOA serial number of 66 (0x42
in hexadecimal).
example.com. 3600 IN CSYNC 66 3 A NS AAAA
The RDATA component of the example CSYNC RR would be encoded on the
wire as follows:
0x00 0x00 0x00 0x42 (SOA Serial)
0x00 0x03 (Flags = immediate | soaminimum)
0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)
3. CSYNC Data Processing
The CSYNC record and associated data must be processed as an "all or
nothing" operation set. If a parental agent fails to successfully
query for any of the required records, the whole operation MUST be
aborted. (Note that a query resulting in "no records exist" as
proven by NSEC or NSEC3 is to be considered successful).
Parental agents MAY:
Process the CSYNC record immediately if the "immediate" flag is
set. If the "immediate" flag is not set, the parental agent MUST
NOT act until the zone administrator approves the operation
through an out-of-band mechanism (such as through pushing a button
via a web interface).
Hardaker Standards Track [Page 6]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
Choose not to process the CSYNC record immediately, even if the
"immediate" flag is set. That is, a parental agent might require
the child zone administrator approve the operation through an out-
of-band mechanism (such as through pushing a button via a web
interface).
Note: how the approval is done out of band is outside the scope of
this document and is implementation specific to parental agents.
3.1. Processing Procedure
The following shows a sequence of steps that SHOULD be used when
collecting and processing CSYNC records from a child zone. Because
DNS queries are not allowed to contain more than one "question" at a
time, a sequence of requests is needed. When processing a CSYNC
transaction request, all DNS queries should be sent to a single
authoritative name server for the child zone. To ensure a single
host is being addressed, DNS over TCP SHOULD be used to avoid
conversing with multiple nodes at an anycast address.
1. Query for the child zone's SOA record
2. Query for the child zone's CSYNC record
3. Query for the child zone's data records, as required by the CSYNC
record's Type Bit Map field
* Note: if any of the resulting records being queried are not
authoritative within the child zone but rather in a grandchild
or deeper, SOA record queries must be made for the
grandchildren. This will require the parental agent to
determine where the child/grandchild zone cuts occur. Because
of the additional operational complexity, parental agents MAY
choose not to support this protocol with children making use
of records that are authoritative in the grandchildren.
4. Query for the collected SOA records again, starting with the
deepest and ending with the SOA of the child's.
If the SOA records from the first, middle, and last steps for a given
zone have different serial numbers (for example, because the zone was
edited and republished during the interval between steps 1 and 4),
then the CSYNC record obtained in the second set SHOULD NOT be
processed (rapidly changing child zones may need special
consideration or processing). The operation MAY be restarted or
retried in the future.
Hardaker Standards Track [Page 7]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
If the soaminimum flag is set and the SOA serial numbers are equal
but less than the CSYNC record's SOA Serial field [RFC1982], the
record MUST NOT be processed. If state is being kept by the parental
agent and the SOA serial number is less than the last time a CSYNC
record was processed, this CSYNC record SHOULD NOT be processed.
Similarly, if state is being kept by the parental agent and the SOA
Serial field of the CSYNC record is less than the SOA Serial field of
the CSYNC record from last time, then this CSYNC record SHOULD NOT be
processed.
If a failure of any kind occurs while trying to obtain any of the
required data, or if DNSSEC fails to validate all of the data
returned for these queries as "secure", then this CSYNC record MUST
NOT be processed.
See the "Operational Consideration" section (Section 4) for
additional guidance about processing.
3.2. CSYNC Record Types
This document defines how the following record types may be processed
if the CSYNC Type Bit Map field indicates they are to be processed.
3.2.1. The NS type
The NS type flag indicates that the NS records from the child zone
should be copied into the parent's delegation information records for
the child.
NS records found within the child's zone should be copied verbatim
(with the exception of the Time to Live (TTL) field, for which the
parent MAY want to select a different value) and the result published
within the parent zone should be a set of NS records that match
exactly. If the child has published a new NS record within their
set, this record should be added to the parent zone. Similarly, if
NS records in the parent's delegation records for the child contain
records that have been removed in the child's NS set, then they
should be removed in the parent's set as well.
Parental agents MAY refuse to perform NS updates if the replacement
records fail to meet NS record policies required by the parent zone
(e.g., "every child zone must have at least two NS records").
Parental agents MUST NOT perform NS updates if there are no NS
records returned in a query, as verified by DNSSEC denial-of-
existence protection. This situation should never happen unless the
child nameservers are misconfigured.
Hardaker Standards Track [Page 8]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
Note that it is permissible for a child's nameserver to return a
CSYNC record that removes the queried nameserver itself from the
future NS or address set.
3.2.2. The A and AAAA Types
The A and AAAA type flags indicates that the A and AAAA address glue
records for in-bailiwick NS records within the child zone should be
copied verbatim (with the exception of the TTL field, for which the
parent MAY want to select a different value) into the parent's
delegation information.
Queries should be sent by the parental agent to determine the A and
AAAA record addresses for each NS record within a NS set for the
child that are in bailiwick.
Note: only the matching types should be queried. For example, if the
AAAA bit has not been set, then the AAAA records (if any) in the
parent's delegation should remain as is. If a given address type is
set and the child's zone contains no data for that type (as proven by
appropriate NSEC or NSEC3 records), then the result in the parent's
delegation records for the child should be an empty set. However, if
the end result of processing would leave no glue records present in
the parent zone for any of the of the in-bailiwick NS records, then
the parent MUST NOT update the glue address records. That is, if the
result of the processing would leave no in-bailiwick A or AAAA
records when there are in-bailiwick NS records, then processing of
the address records cannot happen as it would leave the parent/child
relationship without any address linkage.
The procedure for querying for A and AAAA records MUST occur after
the procedure, if required, for querying for NS records as defined in
Section 3.2.1. This ensures that the right set of NS records is used
as provided by the current NS set of the child. That is, for CSYNC
records that have the NS bit set, the NS set used should be the one
pulled from the child while processing the CSYNC record. For CSYNC
records without the NS bit set, the existing NS records within the
parent should be used to determine which A and/or AAAA records to
update.
4. Operational Considerations
There are a number of important operational aspects to consider when
deploying a CSYNC RRType.
Hardaker Standards Track [Page 9]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
4.1. Error Reporting
There is no inline mechanism for a parental agent to report errors to
operators of child zones. Thus, the only error reporting mechanisms
must be out of band, such as through a web console or over email.
Parental agents should, at a minimum, at least log errors encountered
when processing CSYNC records. Child operators utilizing the
"immediate" flag that fail to see an update within the parental
agent's specified operational window should access the parental
agent's error logging interface to determine why an update failed to
be processed.
4.2. Child Nameserver Selection
Parental agents will need to poll child nameservers in search of
CSYNC records and related data records.
Parental agents MAY perform best-possible verification by querying
all NS records for available data to determine which has the most
recent SOA and CSYNC version (in an ideal world, they would all be
equal, but this is not possible in practice due to synchronization
delays and transfer failures).
Parental agents may offer a configuration interface to allow child
operators to specify which nameserver should be considered the master
to send data queries, too. Note that this master could be a
different nameserver than the publicly listed nameservers in the NS
set (i.e., it may be a "hidden master").
Parental agents with a large number of clients may choose to offer a
programmatic interface to let their children indicate that new CSYNC
records and data are available for polling rather than polling every
child on a frequent basis.
Children that wish to phase out a nameserver will need to publish the
CSYNC record to remove the nameserver and then wait for the parental
agent to process the published record before turning off the service.
This is required because the child cannot control which nameserver in
the existing NS set the parental agent may choose to query when
performing CSYNC processing.
4.3. Out-of-Bailiwick NS Records
When a zone contains NS records where the domain name pointed at does
not fall within the zone itself, there is no way for the parent to
safely update the associated glue records. Thus, the child DNS
operator MAY indicate that the NS records should be synchronized, and
Hardaker Standards Track [Page 10]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
MAY set any glue record flags (A, AAAA) as well, but the parent will
only update those glue records that are below the child's delegation
point.
Children deploying NS records pointing to domain names within their
own children (the "grandchildren") SHOULD ensure the grandchildren's
associated glue records are properly set before publishing the CSYNC
record. That is, it is imperative that proper communication and
synchronization exist between the child and the grandchild.
4.4. Documented Parental Agent Type Support
Parental agents that support processing CSYNC records SHOULD publicly
document the following minimum processing characteristics:
The fact that they support CSYNC processing
The Type Bit Map bits they support
The frequency with which they poll clients (which may also be
configurable by the client)
If they support the "immediate" flag
If they poll a child's single nameserver, a configured list of
nameservers, or all of the advertised nameservers when querying
records
If they support SOA serial number caching to avoid issues with
regression and/or replay
Where errors for CSYNC processing are published
If they support sending queries to a "hidden master"
4.5. Removal of the CSYNC Records
Children MAY remove the CSYNC record upon noticing that the parent
zone has published the required records, thus eliminating the need
for the parent to continually query for the CSYNC record and all
corresponding records. By removing the CSYNC record from the child
zone, the parental agent will only need to perform the query for the
CSYNC record and can stop processing when it finds it missing. This
will reduce resource usage by both the child and the parental agent.
Hardaker Standards Track [Page 11]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
4.6. Parent/Child/Grandchild Glue Synchronization
When a child needs to publish a CSYNC record that synchronizes NS and
A/AAAA glue records and the NS record is actually pointing to a child
of the child (a grandchild of the parent), then it is critical that
the glue records in the child point to the proper real addresses
records published by the grandchild. It is assumed that if a child
is using a grandchild's nameserver that they must be in careful
synchronization. Specifically, this specification requires this to
be the case.
5. Security Considerations
This specification requires the use of DNSSEC in order to determine
that the data being updated was unmodified by third parties.
Parental agents implementing CSYNC processing MUST ensure all DNS
transactions are validated by DNSSEC as "secure". Clients deploying
CSYNC MUST ensure their zones are signed, current and properly linked
to the parent zone with a DS record that points to an appropriate
DNSKEY of the child's zone.
This specification does not address how to perform bootstrapping
operations to get the required initial DNSSEC-secured operating
environment in place. Additionally, this specification was not
designed to synchronize DNSSEC security records, such as DS pointers,
or the CSYNC record itself. Thus, implementations of this protocol
MUST NOT use it to synchronize DS records, DNSKEY materials, CDS
records, CDNSKEY records, or CSYNC records. Similarly, future
documents extending this protocol MUST NOT offer the ability to
synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or
CSYNC records. For such a solution, please see the complimentary
solution [RFC7344] for maintaining security delegation information.
To ensure that an older CSYNC record making use of the soaminimum
flag cannot be replayed to revert values, the SOA serial number MUST
NOT be incremented by more than 2^16 during the lifetime of the
signature window of the associated RRSIGs signing the SOA and CSYNC
records. Note that this is independent of whether or not the
increment causes the 2^32 bit serial number field to wrap.
6. IANA Considerations
This document defines a new DNS Resource Record Type, named "CSYNC".
The IANA has assigned a code point from the "Resource Record (RR)
TYPEs" sub-registry of the "Domain Name System (DNS) Parameters"
registry (http://www.iana.org/assignments/dns-parameters) for this
record.
Hardaker Standards Track [Page 12]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
TYPE Value Meaning Reference
----- ------ -------------------------- -----------
CSYNC 62 Child-to-Parent Synchronization [RFC7477]
The IANA has created and maintains a sub-registry (the "Child
Synchronization (CSYNC) Flags" registry) of the "Domain Name System
(DNS) Parameters" registry. The initial values for this registry are
below.
A "Standards Action" [RFC5226] is required for the assignment of new
flag value.
This registry holds a set of single-bit "Flags" for use in the CSYNC
record within the 16-bit Flags field. Thus, a maximum of 16 flags
may be defined.
The initial assignments in this registry are:
Bit Flag Description Reference
---- ------ ------------- -----------
Bit 0 immediate Immediately process this [RFC7477],
CSYNC record. Section 3
Bit 1 soaminimum Require a SOA serial [RFC7477],
number greater than the Section 2.1.1.1
one specified.
7. References
7.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996, <http://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003,
<http://www.rfc-editor.org/info/rfc3597>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
Hardaker Standards Track [Page 13]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
7.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987,
<http://www.rfc-editor.org/info/rfc1035>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, September
2014, <http://www.rfc-editor.org/info/rfc7344>.
Hardaker Standards Track [Page 14]
RFC 7477 Child-to-Parent Synchronization in DNS March 2015
Acknowledgments
A thank you goes out to Warren Kumari and Olafur Gudmundsson, whose
work on the CDS record type helped inspire the work in this document,
as well as the definition for the "parental agent" definition and
significant contributions to the text. A thank you also goes out to
Ed Lewis, with whom the author held many conversations about the
issues surrounding parent/child relationships and synchronization.
Much of the work in this document is derived from the careful
existing analysis of these three esteemed colleagues. Thank you to
the following people who have contributed text or detailed reviews to
the document (in no particular order): Matthijs Mekking, Petr Spacek,
JINMEI Tatuya, Pete Resnick, Joel Jaeggli, Brian Haberman, Warren
Kumari, Adrian Farrel, Alia Atlas, Barry Leiba, Richard Barnes,
Stephen Farrell, and Ted Lemon. Lastly, the DNSOP WG chairs Tim
Wicinski and Suzanne Woolf have been a tremendous help in getting
this document moving forward to publication.
A special thanks goes to Roy Arends, for taking the "bite out of that
hamburger" challenge while discussing this document.
A similar project, independently designed and developed, was
conducted by ep.net called "Child Activated DNS Refresh".
Author's Address
Wes Hardaker
Parsons, Inc.
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net
Hardaker Standards Track [Page 15]

563
doc/rfc/rfc8020.txt Normal file
View File

@@ -0,0 +1,563 @@
Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 8020 AFNIC
Updates: 1034, 2308 S. Huque
Category: Standards Track Verisign Labs
ISSN: 2070-1721 November 2016
NXDOMAIN: There Really Is Nothing Underneath
Abstract
This document states clearly that when a DNS resolver receives a
response with a response code of NXDOMAIN, it means that the domain
name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
This document clarifies RFC 1034 and modifies a portion of RFC 2308:
it updates both of them.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8020.
Copyright Notice
Copyright (c) 2016 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bortzmeyer & Huque Standards Track [Page 1]
RFC 8020 NXDOMAIN Cut November 2016
Table of Contents
1. Introduction and Background .....................................2
1.1. Terminology ................................................3
2. Rules ...........................................................3
3. Updates to RFCs .................................................5
3.1. Updates to RFC 1034 ........................................5
3.2. Updates to RFC 2308 ........................................5
4. Benefits ........................................................5
5. Possible Issues .................................................6
6. Implementation Considerations ...................................6
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Why can't we just use the owner name of the returned
SOA? ...................................................9
Appendix B. Related Approaches .....................................9
Acknowledgments ....................................................9
Authors' Addresses ................................................10
1. Introduction and Background
The DNS protocol [RFC1035] defines response code 3 as "Name Error",
or "NXDOMAIN" [RFC2308], which means that the queried domain name
does not exist in the DNS. Since domain names are represented as a
tree of labels ([RFC1034], Section 3.1), nonexistence of a node
implies nonexistence of the entire subtree rooted at this node.
The DNS iterative resolution algorithm precisely interprets the
NXDOMAIN signal in this manner. If it encounters an NXDOMAIN
response code from an authoritative server, it immediately stops
iteration and returns the NXDOMAIN response to the querier.
However, in most known existing resolvers today, a cached
nonexistence for a domain is not considered "proof" that there can be
no child domains underneath. This is due to an ambiguity in
[RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names
([RFC7719]) from nonexistent names (Section 3.1). The distinction
became especially important for the development of DNSSEC, which
provides proof of nonexistence. [RFC4035], Section 3.1.3.2,
describes how security-aware authoritative name servers make the
distinction, but no existing RFCs describe the behavior for recursive
name servers.
Bortzmeyer & Huque Standards Track [Page 2]
RFC 8020 NXDOMAIN Cut November 2016
This document specifies that an NXDOMAIN response for a domain name
means that no child domains underneath the queried name exist either;
furthermore, it means that DNS resolvers should interpret cached
nonexistence in this manner. Since the domain names are organized in
a tree, it is a simple consequence of the tree structure:
nonexistence of a node implies nonexistence of the entire subtree
rooted at this node.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
"QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but,
because [RFC2308] provides a different definition, we repeat the
original one here: the QNAME is the domain name in the question
section.
"Denied name": the domain name whose existence has been denied by a
response RCODE of NXDOMAIN. In most cases, it is the QNAME but,
because of [RFC6604], it is not always the case.
Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN
itself) in the more recent [RFC7719].
The domain name space is conceptually defined in terms of a tree
structure. The implementation of a DNS resolver/cache MAY use a tree
or other data structures. The cache being a subset of the data in
the domain name space, it is much easier to reason about it in terms
of that tree structure and to describe things in those terms (names
under/above, descendant names, subtrees, etc.). In fact, the DNS
algorithm description in [RFC1034] even states an assumption that the
cache is a tree structure, so the precedent is already well
established: see its Section 4.3.2, which says "The following
algorithm assumes that the RRs are organized in several tree
structures, one for each zone, and another for the cache..." So, in
this document, each time we talk about a tree or tree operations,
we're referring to the model, not to the actual implementation.
2. Rules
When an iterative caching DNS resolver receives an NXDOMAIN response,
it SHOULD store it in its cache and then all names and resource
record sets (RRsets) at or below that node SHOULD be considered
unreachable. Subsequent queries for such names SHOULD elicit an
NXDOMAIN response.
Bortzmeyer & Huque Standards Track [Page 3]
RFC 8020 NXDOMAIN Cut November 2016
But, if a resolver has cached data under the NXDOMAIN cut, it MAY
continue to send it as a reply (until the TTL of this cached data
expires), since this may avoid additional processing when a query is
received. Section 6 provides more information about this.
Another exception is that a validating resolver MAY decide to
implement the "NXDOMAIN cut" behavior (described in the first
paragraph of this section) only when the NXDOMAIN response has been
validated with DNSSEC. See Section 7 for the rationale.
The fact that a subtree does not exist is not forever: [RFC2308],
Section 3, already describes the amount of time that an NXDOMAIN
response may be cached (the "negative TTL").
If the NXDOMAIN response due to a cached nonexistence is from a
DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3
records that authenticate the nonexistence of the name. For a
descendant name of the original NXDOMAIN name, the same set of NSEC
or NSEC3 records proves the nonexistence of the descendant name. The
iterative, caching resolver MUST return these NSEC or NSEC3 records
in the response to the triggering query if the query had the DNSSEC
OK (DO) bit set.
Warning: if there is a chain of CNAME (or DNAME), the name that does
not exist is the last of the chain ([RFC6604]) and not the QNAME.
The NXDOMAIN stored in the cache is for the denied name, not always
for the QNAME.
As an example of the consequence of these rules, consider two
successive queries to a resolver with a nonexisting domain
'foo.example': the first is for 'foo.example' (which results in an
NXDOMAIN) and the second for 'bar.foo.example' (which also results in
an NXDOMAIN). Many resolvers today will forward both queries.
However, following the rules in this document ("NXDOMAIN cut"), a
resolver would cache the first NXDOMAIN response, as a sign of
nonexistence, and then immediately return an NXDOMAIN response for
the second query, without transmitting it to an authoritative server.
If the first request is for 'bar.foo.example' and the second for
'baz.foo.example', then the first NXDOMAIN response won't tell
anything about 'baz.foo.example'; therefore, the second query will be
transmitted as it was before the use of "NXDOMAIN cut" optimization
(see Appendix A).
Bortzmeyer & Huque Standards Track [Page 4]
RFC 8020 NXDOMAIN Cut November 2016
3. Updates to RFCs
3.1. Updates to RFC 1034
This document clarifies possible ambiguities in [RFC1034] that did
not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])
from nonexistent names, and it refers to subsequent documents that
do. ENTs are nodes in the DNS that do not have resource record sets
associated with them but have descendant nodes that do. The correct
response to ENTs is NODATA (i.e., a response code of NOERROR and an
empty answer section). Additional clarifying language on these
points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2
and 2.2.3 of [RFC4592].
3.2. Updates to RFC 2308
The second paragraph of Section 5 in [RFC2308] states the following:
A negative answer that resulted from a name error (NXDOMAIN)
should be cached such that it can be retrieved and returned in
response to another query for the same <QNAME, QCLASS> that
resulted in the cached negative response.
This document revises that paragraph to the following:
A negative answer that resulted from a name error (NXDOMAIN)
should be cached such that it can be retrieved and returned in
response to another query for the same <QNAME, QCLASS> that
resulted in the cached negative response, or where the QNAME is a
descendant of the original QNAME and the QCLASS is the same.
Section 2 above elaborates on the revised rule and specifies when it
may be reasonable to relax or ignore it.
4. Benefits
The main benefit is a better efficiency of the caches. In the
example above, the resolver sends only one query instead of two, the
second one being answered from the cache. This will benefit the
entire DNS ecosystem, since the authoritative name servers will have
less unnecessary traffic to process.
The correct behavior (in [RFC1034] and made clearer in this document)
is especially useful when combined with QNAME minimization [RFC7816]
since it will allow a resolver to stop searching as soon as an
NXDOMAIN is encountered.
Bortzmeyer & Huque Standards Track [Page 5]
RFC 8020 NXDOMAIN Cut November 2016
"NXDOMAIN cut" may also help mitigate certain types of random QNAME
attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is
a fixed suffix that does not exist. In these attacks against the
authoritative name server, queries are sent to resolvers for a QNAME
composed of a fixed suffix ("dafa888.wf" in one of the articles
above), which is typically nonexistent, and a random prefix,
different for each request. A resolver receiving these requests has
to forward them to the authoritative servers. With "NXDOMAIN cut", a
system administrator would just have to send to the resolver a query
for the fixed suffix, the resolver would get a NXDOMAIN and then
would stop forwarding the queries. (It would be better if the SOA
record in the NXDOMAIN response were sufficient to find the
nonexisting domain, but this is not the case, see Appendix A.)
5. Possible Issues
Let's assume that the Top-Level Domain (TLD) example exists, but
foobar.example is not delegated (so the example's name servers will
reply NXDOMAIN for a query about anything.foobar.example). A system
administrator decides to name the internal machines of his
organization under office.foobar.example and uses a trick of his
resolver to forward requests about this zone to his local
authoritative name servers. "NXDOMAIN cut" would create problems
here; depending on the order of requests to the resolver, it may have
cached the nonexistence from example and therefore "deleted"
everything under it. This document assumes that such a setup is rare
and does not need to be supported.
Today, another possible issue exists; we see authoritative name
servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN
instead of the normal NODATA ([RFC7719], Section 3).
Such name servers are definitely wrong and have always been. Their
behaviour is incompatible with DNSSEC. Given the advantages of
"NXDOMAIN cut", there is little reason to support this behavior.
6. Implementation Considerations
This section is non-normative and is composed only of various things
that may be useful for implementors. A recursive resolver may
implement its cache in many ways. The most obvious one is a tree
data structure, because it fits the data model of domain names. But,
in practice, other implementations are possible, as well as various
optimizations (such as a tree, augmented by an index of some common
domain names).
Bortzmeyer & Huque Standards Track [Page 6]
RFC 8020 NXDOMAIN Cut November 2016
If a resolver implements its cache as a tree (without any
optimization), one way to follow the rules in Section 2 is as
follows: when receiving the NXDOMAIN, prune the subtree of positive
cache entries at that node or delete all individual cache entries for
names below that node. Then, when searching downward in its cache,
this iterative caching DNS resolver will stop searching if it
encounters a cached nonexistence.
Some resolvers may have a cache that is NOT organized as a tree (but,
for instance, as a dictionary); therefore, they have a reason to
ignore the rules of Section 2. So these rules use SHOULD and not
MUST.
7. Security Considerations
The technique described in this document may help against a denial-
of-service attack named "random qnames" described in Section 4.
If a resolver does not validate the answers with DNSSEC, or if the
zone is not signed, the resolver can of course be poisoned with a
false NXDOMAIN, thus, "deleting" a part of the domain name tree.
This denial-of-service attack is already possible without the rules
of this document (but "NXDOMAIN cut" may increase its effects). The
only solution is to use DNSSEC.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
Bortzmeyer & Huque Standards Track [Page 7]
RFC 8020 NXDOMAIN Cut November 2016
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<http://www.rfc-editor.org/info/rfc4592>.
[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits
Clarification", RFC 6604, DOI 10.17487/RFC6604, April
2012, <http://www.rfc-editor.org/info/rfc6604>.
8.2. Informative References
[RFC4035] 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,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<http://www.rfc-editor.org/info/rfc7816>.
[DNSRRR] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
Resolvers for Resiliency, Robustness, and Responsiveness",
Work in Progress, draft-vixie-dnsext-resimprove-00, June
2010.
[NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-
aggressiveuse-04, September 2016.
[joost-dnsterror]
Joost, M., "About DNS Attacks and ICMP Destination
Unreachable Reports", December 2014,
<http://www.michael-joost.de/dnsterror.html>.
[balakrichenan-dafa888]
Balakrichenan, S., "Disturbance in the DNS - "Random
qnames", the dafa888 DoS attack"", October 2014,
<https://indico.dns-oarc.net/event/20/session/3/
contribution/3>.
Bortzmeyer & Huque Standards Track [Page 8]
RFC 8020 NXDOMAIN Cut November 2016
Appendix A. Why can't we just use the owner name of the returned SOA?
In this document, we deduce the nonexistence of a domain only for
NXDOMAIN answers where the denied name was the exact domain. If a
resolver sends a query to the name servers of the TLD example, asking
for the mail exchange (MX) record for www.foobar.example, and
subsequently receives a NXDOMAIN, it can only register the fact that
www.foobar.example (and everything underneath) does not exist. This
is true regardless of whether or not the accompanying SOA record is
for the domain example only. One cannot infer that foobar.example is
nonexistent. The accompanying SOA record indicates the apex of the
zone, not the closest existing domain name. So, using the owner name
of the SOA record in the authority section to deduce "NXDOMAIN cuts"
is currently definitely not OK.
Deducing the nonexistence of a node from the SOA in the NXDOMAIN
reply may certainly help with random qnames attacks, but this is out-
of-scope for this document. It would require addressing the problems
mentioned in the first paragraph of this section. A possible
solution is, when receiving a NXDOMAIN with a SOA that is more than
one label up in the tree, to send requests for the domains that are
between the QNAME and the owner name of the SOA. (A resolver that
does DNSSEC validation or QNAME minimization will need to do it
anyway.)
Appendix B. Related Approaches
The document [NSEC] describes another way to address some of the same
concerns (decreasing the traffic for nonexisting domain names).
Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful
since it can synthesize NXDOMAINs for domains that were not queried.
Acknowledgments
The main idea in this document is taken from [DNSRRR], Section 3,
"Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors,
Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony
Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane
Wessels provided valuable feedback and suggestions.
Bortzmeyer & Huque Standards Track [Page 9]
RFC 8020 NXDOMAIN Cut November 2016
Authors' Addresses
Stephane Bortzmeyer
AFNIC
1, rue Stephenson
Montigny-le-Bretonneux 78180
France
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: https://www.afnic.fr/
Shumon Huque
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: shuque@verisign.com
URI: http://www.verisignlabs.com/
Bortzmeyer & Huque Standards Track [Page 10]