< draft-ietf-dnsop-edns-chain-query-04.txt   draft-ietf-dnsop-edns-chain-query-05.txt >
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track October 19, 2015 Intended status: Standards Track November 17, 2015
Expires: April 21, 2016 Expires: May 20, 2016
Chain Query requests in DNS Chain Query requests in DNS
draft-ietf-dnsop-edns-chain-query-04 draft-ietf-dnsop-edns-chain-query-05
Abstract Abstract
This document defines an EDNS0 extension that can be used by a This document defines an EDNS0 extension that can be used by a
security-aware validating Resolver configured as a Forwarder to send security-aware validating Resolver configured to use a Forwarder to
a single query, requesting a complete validation path along with the send a single query, requesting a complete validation path along with
regular query answer. The reduction in queries lowers the latency. the regular query answer. The reduction in queries lowers the
This extension requries the use of source IP verified transport such latency and reduces the need to send multiple queries at once. This
as TCP or UDP with EDNS-COOKIE so it cannot be abused in extension mandates the use of source IP verified transport such as
amplification attacks. TCP or UDP with EDNS-COOKIE so it cannot be abused in amplification
attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016. This Internet-Draft will expire on May 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5
5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5
5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6
5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6
6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7
6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8
6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8
6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 8
6.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9 6.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9
6.6. Anycast Considerations . . . . . . . . . . . . . . . . . 9 6.6. Anycast Considerations . . . . . . . . . . . . . . . . . 9
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10
9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12
9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 38 skipping to change at page 3, line 39
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The DNS terminology used in this document is that of The DNS terminology used in this document is that of
[DNS-TERMINOLOGY]. Additionally, the following terms are used: [DNS-TERMINOLOGY]. Additionally, the following terms are used:
[edit: which I hope will end up in the terminology document]
Recursive Resolver: A nameserver that is responsible for resolving Recursive Resolver: A nameserver that is responsible for resolving
domain names for clients by following the domain's delegation domain names for clients by following the domain's delegation
chain, starting at the root. Recursive Resolvers frequently use chain, starting at the root. Recursive Resolvers frequently use
caches to be able to respond to client queries quickly. Described caches to be able to respond to client queries quickly. Described
in [RFC1035] chapter 7. in [RFC1035] chapter 7.
Validating Resolver: A recursive nameserver that also performs Validating Resolver: A recursive nameserver that also performs
DNSSEC [RFC4033] validation. Also known as "security-aware DNSSEC [RFC4033] validation. Also known as "security-aware
resolver". resolver".
skipping to change at page 5, line 20 skipping to change at page 5, line 20
information in DNS messages. The option is structured as follows: information in DNS messages. The option is structured as follows:
1 2 3 1 2 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 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
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH ! ! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
~ Closest Trust Point (FQDN) ~ ~ Closest Trust Point (FQDN) ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
o OPTION-CODE, 2 octets, for CHAIN is [TBD1]. o OPTION-CODE, 2 octets, for CHAIN is 13.
o OPTION-LENGTH, 2 octets, contains the length of the payload o OPTION-LENGTH, 2 octets, contains the length of the payload
(everything after Option-length) in octets. (everything after Option-length) in octets.
o Closest Trust Point, a variable length FDQN of the requested start o Closest Trust Point, a variable length Fully Qualified Domain Name
point of the chain. This entry is the 'lowest' known entry in the ("FQDN") in DNS wire format of the requested start point of the
DNS chain known by the recursive server seeking a CHAIN answer for chain. This entry is the 'lowest' known entry in the DNS chain
which it has a validated DS and DNSKEY record. The end point of known by the recursive server seeking a CHAIN answer for which it
the chain is obtained from the DNS Query Section itself. No DNS has a validated DS and DNSKEY record. The end point of the chain
name compression is allowed for this value. is obtained from the DNS Query Section itself. No DNS name
compression is allowed for this value.
5. Protocol Description 5. Protocol Description
5.1. Discovery of Support 5.1. Discovery of Support
A Forwarder may include a zero-length CHAIN option in a regular query A Forwarder may include a zero-length CHAIN option in a regular query
over any transport to discover the DNS server capability for CHAIN. over any transport to discover the DNS server capability for CHAIN.
Recursive Resolvers that support and are willing to accept CHAIN Recursive Resolvers that support and are willing to accept CHAIN
queries over source IP verified transport respond to a zero-length queries over source IP verified transport respond to a zero-length
CHAIN received by including a zero-length CHAIN option in the answer. CHAIN received by including a zero-length CHAIN option in the answer.
skipping to change at page 6, line 40 skipping to change at page 6, line 43
When a query containing a non-zero CHAIN option is received from a When a query containing a non-zero CHAIN option is received from a
Forwarder, the upstream Recursive Resolver supporting CHAIN MAY Forwarder, the upstream Recursive Resolver supporting CHAIN MAY
respond by confirming that it is returning a CHAIN. To do so, it respond by confirming that it is returning a CHAIN. To do so, it
MUST set the CHAIN option to the lowest Trust Point sent as part of MUST set the CHAIN option to the lowest Trust Point sent as part of
the chain, with its corresponding OPTION-LENGTH. It extends the the chain, with its corresponding OPTION-LENGTH. It extends the
Authority Section in the DNS answer packet with the DNS RRsets Authority Section in the DNS answer packet with the DNS RRsets
required for validating the answer. The DNS RRsets added start with required for validating the answer. The DNS RRsets added start with
the first chain element below the received Closest Trust Point up to the first chain element below the received Closest Trust Point up to
and including the NS and DS RRsets that represent the zone cut and including the NS and DS RRsets that represent the zone cut
(authoritative servers) of the QNAME. The actual DNS answer to the (authoritative servers) of the QNAME. The added RRsets MAY be added
question in the Query Section is placed in the DNS Answer in matching hierarchical order but a DNS client MUST NOT depend on
the order of the added RRsets for validation. The actual DNS answer
to the question in the Query Section is placed in the DNS Answer
Section identical to the traditional DNS answer. All required DNSSEC Section identical to the traditional DNS answer. All required DNSSEC
related records must be added to their appropriate sections. This related records must be added to their appropriate sections. This
includes records required for proof of non-existence of regular and/ includes records required for proof of non-existence of regular and/
or wildcard records, such as NSEC or NSEC3 records. or wildcard records, such as NSEC or NSEC3 records.
Recursive Resolvers that have not implemented or enabled support for Recursive Resolvers that have not implemented or enabled support for
the CHAIN option, or are otherwise unwilling to perform the the CHAIN option, or are otherwise unwilling to perform the
additional work for a Chain Query due to work load, may safely ignore additional work for a Chain Query due to work load, may safely ignore
the option in the incoming queries. Such a server MUST NOT include the option in the incoming queries. Such a server MUST NOT include
an CHAIN option when sending DNS answer replies back, thus indicating an CHAIN option when sending DNS answer replies back, thus indicating
skipping to change at page 7, line 45 skipping to change at page 7, line 45
Answer Section similar to regular DNS processing. The CNAME or DNAME Answer Section similar to regular DNS processing. The CNAME or DNAME
target MAY be placed in the Additional Section only if all supporting target MAY be placed in the Additional Section only if all supporting
records for DNSSEC validation of the CNAME or DNAME target are also records for DNSSEC validation of the CNAME or DNAME target are also
added to the Authority Section. added to the Authority Section.
The response from a Recursive Resolver to a Resolver MUST NOT contain The response from a Recursive Resolver to a Resolver MUST NOT contain
the CHAIN option if none was present in the Resolver's original the CHAIN option if none was present in the Resolver's original
request. request.
A DNS query that contains the CHAIN option MUST also have the DNSSEC A DNS query that contains the CHAIN option MUST also have the DNSSEC
OK bit set. If this bit is not set, the CHAIN option received MUST OK ("OK") bit set. If this bit is not set, or if the Checking
be ignored. Disabled ("CD") bit is set, the CHAIN option received MUST be
ignored.
6. Protocol Considerations 6. Protocol Considerations
6.1. DNSSEC Considerations 6.1. DNSSEC Considerations
The presence or absence of an OPT resource record containing an CHAIN The presence or absence of an OPT resource record containing an CHAIN
option in a DNS query does not change the usage of those resource option in a DNS query does not change the usage of those resource
records and mechanisms used to provide data origin authentication and records and mechanisms used to provide data origin authentication and
data integrity to the DNS, as described in [RFC4033], [RFC4034] and data integrity to the DNS, as described in [RFC4033], [RFC4034] and
[RFC4035]. [RFC4035].
6.2. NS record Considerations 6.2. NS record Considerations
CHAIN responses MUST include the NS RRset from the child zone CHAIN responses SHOULD include the NS RRset from the zone itself
including the RRSIG records required for validation. including the RRSIG records required for validation. It MUST NOT
include the NS RRset from parent zone, as this RRset is not signed.
If the size of the answer is an important factor, the NS RRset MAY be
omited.
When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer
required to use the NS RRset, as it can construct the validation path required to use the NS RRset, as it can construct the validation path
via the DNSKEY and DS RRsets without using the NS RRset. However, via the DNSKEY and DS RRsets without using the NS RRset. However,
the Forwarder might be forced to switch from Forwarder mode to the Forwarder might be forced to switch from Forwarder mode to
Recursive Resolver mode due to a network topology change. In Recursive Resolver mode due to a network topology change. In
Recursive Resolver mode, the NS RRsets are needed to find and query Recursive Resolver mode, the NS RRsets are needed to find and query
Authoritative Servers directly. It is RECOMMENDED that the DNS Authoritative Servers directly. It is RECOMMENDED that the DNS
Forwarder populate its cache with this information to avoid requiring Forwarder populate its cache with this information to avoid requiring
future queries to obtain any missing NS records. Therefore, CHAIN future queries to obtain any missing NS records. Therefore, CHAIN
skipping to change at page 10, line 41 skipping to change at page 10, line 39
transport is used. It MUST NOT send an RCODE of REFUSED. transport is used. It MUST NOT send an RCODE of REFUSED.
9. Examples 9. Examples
9.1. Simple Query for example.com 9.1. Simple Query for example.com
o A web browser on a client machine asks the Forwarder running on o A web browser on a client machine asks the Forwarder running on
localhost to resolve the A record of "www.example.com." by sending localhost to resolve the A record of "www.example.com." by sending
a regular DNS UDP query on port 53 to 127.0.0.1. a regular DNS UDP query on port 53 to 127.0.0.1.
o The Forwarder on the client machine checks its cache, and notices o The Resolver on the client machine checks its cache, and notices
it already has a DNSSEC validated entry of "com." in its cache. it already has a DNSSEC validated entry of "com." in its cache.
This includes the DNSKEY RRset with its RRSIG records. In other This includes the DNSKEY RRset with its RRSIG records. In other
words, according to its cache, ".com" is DNSSEC validated as words, according to its cache, ".com" is DNSSEC validated as
"secure" and can be used to continue a DNSSEC validated chain. "secure" and can be used to continue a DNSSEC validated chain.
o The Forwarder on the client opens a TCP connection to its upstream o The Resolver on the client opens a TCP connection to its upstream
Recursive Resolver on port 53. It adds the CHAIN option as Recursive Resolver on port 53. It adds the CHAIN option as
follows: follows:
* Option-code, set to [TBD1] * Option-code, set to 13
* Option-length, set to 0x00 0x04
* Option-length, set to 0x00 0x04
* Closest Trust Point set to "com." * Closest Trust Point set to "com."
o The upstream Recursive Resolver receives a DNS query over TCP with o The upstream Recursive Resolver receives a DNS query over TCP with
the CHAIN Closest Trust Point set to "com.". After accepting the the CHAIN Closest Trust Point set to "com.". After accepting the
query it starts constructing a DNS reply packet. query it starts constructing a DNS reply packet.
o The upstream Recursive Resolver performs all the regular work to o The upstream Recursive Resolver performs all the regular work to
ensure it has all the answers to the query for the A record of ensure it has all the answers to the query for the A record of
"www.example.com.". It does so without using the CHAIN option - "www.example.com.". It does so without using the CHAIN option -
unless it is also configured as a Forwarder. The answer to the unless it is also configured as a Forwarder. The answer to the
original DNS question could be the actual A record, the DNSSEC original DNS question could be the actual A record, the DNSSEC
proof of non-existence, or an insecure NXDOMAIN response. proof of non-existence, or an insecure NXDOMAIN response.
o The upstream Recursive Resolver adds the CHAIN option to the DNS o The upstream Recursive Resolver adds the CHAIN option to the DNS
response as follows: response as follows:
* Option-code, set to [TBD1] * Option-code, set to 13
* Option-length, set to 0x00 0x00 * Option-length, set to 0x00 0x04
* The Closest Trust Point is ommited (zero length) * The Closest Trust Point is set to "com.".
o The upstream Recursive Resolver constructs the DNS Authority o The upstream Recursive Resolver constructs the DNS Authority
Section and fills it with: Section and fills it (in any order) with:
* The DS RRset for "example.com." and its corresponding RRSIGs * The DS RRset for "example.com." and its corresponding RRSIGs
(made by the "com." DNSKEY(s)) (made by the "com." DNSKEY(s))
* The DNSKEY RRset for "example.com." and its corresponding * The DNSKEY RRset for "example.com." and its corresponding
RRSIGs (made by the "example.com" DNSKEY(s)) RRSIGs (made by the "example.com" DNSKEY(s))
* The authoritative NS RRset for "example.com." and its * The authoritative NS RRset for "example.com." and its
corresponding RRSIGs (from the child zone) corresponding RRSIGs (from the child zone)
skipping to change at page 12, line 4 skipping to change at page 11, line 46
corresponding RRSIGs (from the child zone) corresponding RRSIGs (from the child zone)
If the answer does not exist, and the zone uses DNSSEC, it also If the answer does not exist, and the zone uses DNSSEC, it also
adds the proof of non-existence, such as NSEC or NSEC3 records, to adds the proof of non-existence, such as NSEC or NSEC3 records, to
the Authority Section. the Authority Section.
o The upstream Recursive Resolver constructs the DNS Answer o The upstream Recursive Resolver constructs the DNS Answer
Section and fills it with: Section and fills it with:
* The A record of "www.example.com." and its corresponding RRSIGs * The A record of "www.example.com." and its corresponding RRSIGs
If the answer does not exist (NODATA or NXDOMAIN), the Answer If the answer does not exist (NODATA or NXDOMAIN), the Answer
Section remains empty. For the NXDOMAIN case, the RCode of the Section remains empty. For the NXDOMAIN case, the RCode of the
DNS answer packet is set to NXDOMAIN. Otherwise it remains DNS answer packet is set to NXDOMAIN. Otherwise it remains
NOERROR. NOERROR.
o The upstream Recursive Resolver returns the DNS answer over the o The upstream Recursive Resolver returns the DNS answer over the
existing TCP connection. When all data is sent, it SHOULD keep existing TCP connection. When all data is sent, it SHOULD keep
the TCP connection open to allow for additional incoming DNS the TCP connection open to allow for additional incoming DNS
queries - provided it has enough resources to do so. queries - provided it has enough resources to do so.
o The Forwarder receives the DNS answer. It processes the Authority o The Resolver on the client receives the DNS answer. It processes
Section and the Answer Section and places the information in its the Authority Section and the Answer Section and places the
local cache. It ensures that no data is accepted into the cache information in its local cache. It ensures that no data is
without having proper DNSSEC validation. It MAY do so by looping accepted into the cache without having proper DNSSEC validation.
over the entries in the Authority and Answer Sections. When an It MAY do so by looping over the entries in the Authority and
entry is validated for its cache, it is removed from the Answer Sections. When an entry is validated for its cache, it is
processing list. If an entry cannot be validated it is left in removed from the processing list. If an entry cannot be validated
the process list. When the end of the list is reached, the list it is left in the process list. When the end of the list is
is processed again until either all entries are placed in the reached, the list is processed again until either all entries are
cache, or the remaining items cannot be placed in the cache due to placed in the cache, or the remaining items cannot be placed in
lack of validation. Those entries are then discarded. the cache due to lack of validation. Those entries are then
discarded.
o If the cache contains a valid answer to the application's query, o If the cache contains a valid answer to the application's query,
this answer is returned to the application via a regular DNS this answer is returned to the application via a regular DNS
answer packet. This packet MUST NOT contain an CHAIN option. If answer packet. This packet MUST NOT contain an CHAIN option. If
no valid answer can be returned, normal error processing is done. no valid answer can be returned, normal error processing is done.
For example, an NXDOMAIN or an empty Answer Section could be For example, an NXDOMAIN or an empty Answer Section could be
returned depending on the error condition. returned depending on the error condition.
9.2. Out-of-path Query for example.com 9.2. Out-of-path Query for example.com
A Recursive Resolver receives a query for the A record for A Recursive Resolver receives a query for the A record for
example.com. It includes the CHAIN option with the following example.com. It includes the CHAIN option with the following
parameters: parameters:
o Option-code, set to [TBD1] o Option-code, set to 13
o Option-length, set to 0x00 0x0D o Option-length, set to 0x00 0x0D
o The Closest Trust Point set to 'unrelated.ca.' o The Closest Trust Point set to 'unrelated.ca.'
As there is no chain that leads from "unrelated.ca." to As there is no chain that leads from "unrelated.ca." to
"example.com", the Resolving Nameserver answers with an empty CHAIN "example.com", the Resolving Nameserver answers with an empty CHAIN
specified using: specified using:
o Option-code, set to [TBD1] o Option-code, set to 13
o Option-length, set to 0x00 0x00 o Option-length, set to 0x00 0x00
o The Closest Trust Point is omitted (zero length)
o The Closest Trust Point is omitted (zero length)
Note that the regular answer is still present just as it would be for Note that the regular answer is still present just as it would be for
a query that did not specify the CHAIN option. a query that did not specify the CHAIN option.
9.3. Non-existent data 9.3. Non-existent data
A Recursive Resolver receives a query for the A record for A Recursive Resolver receives a query for the A record for
"ipv6.toronto.redhat.ca". It includes the CHAIN option with the "ipv6.toronto.redhat.ca". It includes the CHAIN option with the
following parameters: following parameters:
o Option-code, set to [TBD1] o Option-code, set to 13
o Option-length, set to 0x00 0x03 o Option-length, set to 0x00 0x03
o The Closest Trust Point set to 'ca.' o The Closest Trust Point set to 'ca.'
Using regular UDP queries towards Authoritative Nameservers, it Using regular UDP queries towards Authoritative Nameservers, it
locates the NS RRset for "toronto.redhat.ca.". When querying for the locates the NS RRset for "toronto.redhat.ca.". When querying for the
A record it receives a reply with RCODE "NoError" and an empty Answer A record it receives a reply with RCODE "NoError" and an empty Answer
Section. The Authority Section contains NSEC3 and RRSIG records Section. The Authority Section contains NSEC3 and RRSIG records
proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca".
The Recursive Resolver constructs a DNS reply with the following The Recursive Resolver constructs a DNS reply with the following
CHAIN option parameters: CHAIN option parameters:
o Option-code, set to [TBD1] o Option-code, set to 13
o Option-length, set to 0x00 0x00 o Option-length, set to 0x00 0x00
o The Closest Trust Point is ommited (zero length) o The Closest Trust Point is ommited (zero length)
The RCODE is set to "NoError". The Authority Section is filled in The RCODE is set to "NoError". The Authority Section is filled in
with: with:
o The DS RRset for "redhat.ca." plus RRSIGs o The DS RRset for "redhat.ca." plus RRSIGs
skipping to change at page 14, line 6 skipping to change at page 14, line 4
o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca)
o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
o The DS RRset for "toronto.redhat.ca." plus RRSIGs o The DS RRset for "toronto.redhat.ca." plus RRSIGs
o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg
ns[01].toronto.redhat.ca) ns[01].toronto.redhat.ca)
o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and
"ns1.toronto.redhat.ca." plus RRSIGs "ns1.toronto.redhat.ca." plus RRSIGs
o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs
do exist, does not include A) do exist, does not include A)
o The NSEC record for "toronto.redhat.ca." (proves no wildcard o The NSEC record for "toronto.redhat.ca." (proves no wildcard
exists) exists)
The Answer Section is empty. The RCode is set to NOERROR. The Answer Section is empty. The RCode is set to NOERROR.
10. IANA Considerations 10. IANA Considerations
10.1. EDNS0 option code for CHAIN 10.1. EDNS0 option code for CHAIN
IANA has assigned option code [TBD1] in the "DNS EDNS0 Option Codes IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
(OPT)" registry to CHAIN. (OPT)" registry to CHAIN.
11. Acknowledgements 11. Acknowledgements
Andrew Sullivan pointed out that we do not need any new data formats Andrew Sullivan pointed out that we do not need any new data formats
to support DNS chains. Olafur Gudmundsson ensured the RRsets are to support DNS chains. Olafur Gudmundsson ensured the RRsets are
returned in the proper Sections. Thanks to Tim Wicinski for his returned in the proper Sections. Thanks to Tim Wicinski for his
thorough review. thorough review.
12. Normative References 12. Normative References
[DNS-TERMINOLOGY] [DNS-TERMINOLOGY]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-dns-terminology-05 (work in Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
progress), September 2015. progress), September 2015.
[EDNS-COOKIE] [EDNS-COOKIE]
Eastlake, Donald., "Domain Name System (DNS) Cookies", Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-ietf-dnsop-cookies (work in progress), August 2015. draft-ietf-dnsop-cookies (work in progress), November
2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 15, line 49 skipping to change at page 15, line 52
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
and R. Weber, "Definition and Use of DNSSEC Negative Trust and R. Weber, "Definition and Use of DNSSEC Negative Trust
Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
<http://www.rfc-editor.org/info/rfc7646>. <http://www.rfc-editor.org/info/rfc7646>.
[TCP-KEEPALIVE] [TCP-KEEPALIVE]
Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
tcp-keepalive-03 (work in progress), September 2015. tcp-keepalive-04 (work in progress), October 2015.
Author's Address Author's Address
Paul Wouters Paul Wouters
Red Hat Red Hat
Email: pwouters@redhat.com Email: pwouters@redhat.com
 End of changes. 34 change blocks. 
57 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/