One document matched: draft-ietf-dnsop-edns-chain-query-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
<!ENTITY rfc4035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
<!ENTITY rfc4786 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4786.xml'>
<!ENTITY rfc6824 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6824.xml'>
<!ENTITY rfc6891 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml'>
<!ENTITY rfc6982 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml'>
<!ENTITY rfc7646 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7646.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-dnsop-edns-chain-query-05">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Chain Query requests in DNS</title>
<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
<organization>Red Hat</organization>
<address>
<email>pwouters@redhat.com</email>
</address>
</author>
<date month="November" day="17" year="2015" />
<area>ops</area>
<workgroup>dnsop</workgroup>
<abstract><t>
This document defines an EDNS0 extension that can be used
by a security-aware validating Resolver configured to use
a Forwarder to send a single query, requesting a complete
validation path along with the regular query answer. The
reduction in queries lowers the latency and reduces the need
to send multiple queries at once. This extension mandates the
use of source IP verified transport such as TCP or UDP with
EDNS-COOKIE so it cannot be abused in amplification attacks.
</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>
Traditionally, a DNS client operates in stub-mode. For each
DNS question the DNS client needs to resolve, it sends a
single query to an upstream Recursive Resolver to obtain
a single DNS answer. When DNSSEC <xref target='RFC4033'/>
is deployed on such DNS clients, validation requires that
the client obtains all the intermediate information from the
DNS root down to the queried-for hostname so it can perform
DNSSEC validation on the complete chain of trust.
</t>
<t>
Currently, applications send out many UDP requests
concurrently. This requires more resources on the DNS
client with respect to state (cpu, memory, battery) and
bandwidth. There is also no guarantee that the initial set
of UDP questions will result in all the records required
for DNSSEC validation. More round trips could be required
depending on the resulting DNS answers. This especially
affects high-latency links.
</t>
<t>
This document specifies an EDNS0 extension that allows a
validating Resolver running as a Forwarder to open a TCP
connection to another Resolver and request a DNS chain answer
using one DNS query/answer pair. This reduces the number
of round trips to two. If combined with long lived TCP
or <xref target="TCP-KEEPALIVE"/> there is only one round
trip. While the upstream Resolver still needs to perform
all the individual queries required for the complete answer,
it usually has a much bigger cache and does not experience
significant slowdown from last-mile latency.
</t>
<t>
This EDNS0 extension allows the Forwarder to indicate which
part of the DNS hierarchy it already contains in its cache.
This reduces the amount of data required to be transferred
and reduces the work the upstream Recursive Resolver has
to perform.
</t>
<t>
This EDNS0 extension is only intended to be sent by Forwarders
to Recursive Resolvers. It can (and should) be ignored by
Authoritative Servers.
</t>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology">
<t>The DNS terminology used in this document is that of
<xref target="DNS-TERMINOLOGY"/>. Additionally, the following
terms are used:</t>
<t><list style="hanging">
<t hangText="Recursive Resolver:">
A nameserver that is responsible for resolving domain names
for clients by following the domain's delegation chain,
starting at the root. Recursive Resolvers frequently use
caches to be able to respond to client queries quickly.
Described in <xref target="RFC1035"/> chapter 7.</t>
<t hangText="Validating Resolver:">
A recursive nameserver that also performs DNSSEC <xref target='RFC4033'/>
validation. Also known as "security-aware resolver".
</t>
</list></t>
</section>
<section title="Overview" anchor="overview">
<t>
When DNSSEC is deployed on a host, it can no longer delegate
all DNS work to the upstream Recursive Resolver. Obtaining just
the DNS answer itself is not enough to validate that answer
using DNSSEC. For DNSSEC validation, the DNS client requires a
locally running validating Resolver so it can confirm DNSSEC
validation of all intermediary DNS answers. It can configure
itself as a Forwarder if it obtains the IP addresses of
one or more Recursive Resolvers that are available, or as a
stand-alone Recursive Resolver if no functional Recursive
Resolvers were obtained. Generating the required queries
for validation adds a significant delay in answering the DNS
question of the locally running application. The application
must wait while the Resolver validates all intermediate
answers. Each round-trip adds to the total time waiting
on DNS resolution with validation to complete. This makes
DNSSEC resolving impractical for devices on networks with a
high latency.
</t>
<t>
This document defines the CHAIN option that allows the Resolver
to request all intermediate DNS data it requires to resolve and
validate a particular DNS answer in a single round-trip. The Resolver
could be part of the application or a Recursive Resolver running
on the host.
</t>
<t>
Servers answering with CHAIN data should ensure that the
transport is TCP or source IP address verified UDP. See <xref
target="security" />. This avoids abuse in DNS amplification
attacks.
</t>
<t>
Applications that support CHAIN internally can perform
validation without requiring the host the run a Recursive Resolver.
This is particularly useful for virtual servers in a cloud or
container based deployment where it is undesirable to run a Recursive
Resolver per virtual machine.
</t>
<t>
The format of this option is described in <xref target="format" />.
</t>
<t>
As described in <xref target="responding" />, a Recursive
Resolver could use this EDNS0 option to include additional
data required by the Resolver in the Authority Section of the DNS
answer packet when using a source IP verified transport. The
Answer Section remains unchanged from a traditional DNS answer
and contains the answer and related DNSSEC entries.
</t>
<t>An empty CHAIN EDNS0 option MAY be sent over any transport
as a discovery method. A DNS server receiving such an empty CHAIN
option SHOULD add an empty CHAIN option in its
answer to indicate that it supports CHAIN for
source IP address verified transports.
</t>
<t>
The mechanisms provided by CHAIN raise various
security related concerns, related to the additional work,
bandwidth, amplification attacks as well as privacy issues
with the cache. These concerns are described in <xref
target="security" />.
</t>
</section>
<section title="Option Format" anchor="format">
<t>This draft uses an EDNS0 <xref target="RFC6891"/> option to
include client IP information in DNS messages. The option
is structured as follows:</t>
<figure><artwork align="left"><![CDATA[
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
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
~ Closest Trust Point (FQDN) ~
+---------------------------------------------------------------+
]]></artwork></figure>
<t><list style="symbols">
<t>
OPTION-CODE, 2 octets, for CHAIN is 13.
</t>
<t>
OPTION-LENGTH, 2 octets, contains the length of the
payload (everything
after Option-length) in octets.
</t>
<t>
Closest Trust Point, a variable length Fully Qualified
Domain Name ("FQDN") in DNS wire format of the requested
start point of the chain. This entry is the 'lowest'
known entry in the DNS chain known by the recursive
server seeking a CHAIN answer for which it has a
validated DS and DNSKEY record. The end point of the
chain is obtained from the DNS Query Section itself. No
DNS name compression is allowed for this value.
</t>
</list>
</t>
</section>
<section title="Protocol Description">
<section anchor="discovery" title="Discovery of Support">
<t>A Forwarder may include a zero-length CHAIN
option in a regular query over any transport to discover the
DNS server capability for CHAIN. Recursive Resolvers that
support and are willing to accept CHAIN queries over source
IP verified transport respond to a zero-length CHAIN received
by including a zero-length CHAIN option in the answer. If not
already using a source IP verified transport, the Forwarder
MAY then switch to a source IP verified transport and start
sending queries with the CHAIN option to request a CHAIN
response from the Recursive Resolver. Examples of source
IP verification are the 3-way TCP handshake and UDP with
<xref target="EDNS-COOKIE"/>.
</t>
</section>
<section anchor="querying" title="Generate a Query">
<t>
In this option value, the Forwarder sets the Closest Trust Point
in the chain - furthest from the root - that it already
has a DNSSEC validated (secure or not) answer for in its cache.
The upstream Recursive Resolver does not need to include
any part of the chain from the root down to this option's FQDN.
A complete example is described in <xref target="example1" />.
</t>
<t>
The CHAIN option should generally be sent by system
Forwarders and Resolvers within an application that also
perform DNSSEC validation.
</t>
</section>
<section anchor="send_when" title="Send the Option">
<t>
When CHAIN is available, the downstream Recursive Resolver
can adjust its query strategy based on the desired queries
and its cache contents.
</t>
<t>
A Forwarder can request the CHAIN option with every outgoing
DNS query. However, it is RECOMMENDED that Forwarders remember
which upstream Recursive Resolvers did not return the option
(and additional data) with their response. The Forwarder
SHOULD fallback to regular DNS for subsequent queries to
those Recursive Resolvers. It MAY switch to another Recursive
Resolver that does support the CHAIN option or try again
later to see if the server has become less loaded and is
now willing to answer with Query Chains.
</t>
</section>
<section anchor="responding" title="Generate a Response">
<t>
When a query containing a non-zero CHAIN option is received
from a Forwarder, the upstream Recursive Resolver supporting
CHAIN MAY 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 the chain, with its
corresponding OPTION-LENGTH. It extends the Authority
Section in the DNS answer packet with the DNS RRsets
required for validating the answer. The DNS RRsets added
start with the first chain element below the received
Closest Trust Point up to and including the NS and DS
RRsets that represent the zone cut (authoritative servers)
of the QNAME. The added RRsets MAY be added 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 related records must be added
to their appropriate sections. This includes records
required for proof of non-existence of regular and/or
wildcard records, such as NSEC or NSEC3 records.
</t>
<t>
Recursive Resolvers that have not implemented or enabled
support for the CHAIN option, or are otherwise unwilling
to perform the 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 an CHAIN option
when sending DNS answer replies back, thus indicating it is
not able or willing to support Chain Queries at this time.
</t>
<t>
Requests with wrongly formatted options (i.e. bogus FQDN) MUST
be rejected and a FORMERR response must be returned to the
sender, as described by <xref target="RFC6891"/>.
</t>
<t>
Requests resulting in chains that the receiving resolver is
unwilling to serve can be rejected by answering the query
as a regular DNS reply but with an empty CHAIN payload.
Replying with an empty CHAIN can be used for chains that
would be too big or chains that would reveal too much
information considered private.
</t>
<t>At any time, a Recursive Resolver that has determined that
it is running low on resources can refuse CHAIN queries by
replying with a regular DNS reply with an empty CHAIN payload.
</t>
<t>
If a CHAIN answer would be bigger than the Recursive Resolver
is willing to serve, it SHOULD send a partial chain starting
with the data closest to the top of the chain. The client
MAY re-send the query with an updated Closest Trust Point
until it has received the full chain. The CHAIN response
will contain the lowest Closest Trust Point that was included
in the CHAIN answer.
</t>
<t>
If the DNS request results in an CNAME or DNAME for the
Answer Section, the Recursive Resolver MUST return these
records in the Answer Section similar to regular DNS
processing. The CNAME or DNAME target MAY be placed in the
Additional Section only if all supporting records for DNSSEC
validation of the CNAME or DNAME target are also added to
the Authority Section.
</t>
<t>
The response from a Recursive Resolver to a Resolver MUST
NOT contain the CHAIN option if none was present in the
Resolver's original request.
</t>
<t>
A DNS query that contains the CHAIN option MUST also have
the DNSSEC OK ("OK") bit set. If this bit is not set,
or if the Checking Disabled ("CD") bit is set, the CHAIN
option received MUST be ignored.
</t>
</section>
</section>
<section title="Protocol Considerations">
<section title="DNSSEC Considerations">
<t>
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 records and mechanisms used to provide
data origin authentication and data integrity to the DNS, as
described in <xref target="RFC4033" />, <xref target="RFC4034"
/> and <xref target="RFC4035" />.
</t>
</section>
<section title="NS record Considerations">
<t>
CHAIN responses SHOULD include the NS RRset from the zone itself
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.
</t>
<t>
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 via the DNSKEY and DS RRsets without
using the NS RRset. However, the Forwarder might be forced
to switch from Forwarder mode to Recursive Resolver mode due
to a network topology change. In Recursive Resolver mode,
the NS RRsets are needed to find and query Authoritative
Servers directly. It is RECOMMENDED that the DNS Forwarder
populate its cache with this information to avoid requiring
future queries to obtain any missing NS records. Therefore,
CHAIN responses MUST include the NS RRset from the child zone,
including the RRSIG records required for validation.
</t>
</section>
<section title="TCP Session Management">
<t>
It is RECOMMENDED that TCP sessions not immediately be closed
after the DNS answer to the first query is received. It is
recommended to use <xref target="TCP-KEEPALIVE"/>.
</t>
<t>
Both DNS clients and servers are subject to resource constraints
which will limit the extent to which Chain Queries can be
executed. Effective limits for the number of active sessions
that can be maintained on individual clients and servers
should be established, either as configuration options or by
interrogation of process limits imposed by the operating system.
</t>
<t>
In the event that there is greater demand for Chain Queries
than can be accommodated, DNS servers may stop advertising
the CHAIN option in successive DNS messages. This allows,
for example, clients with other candidate servers to query to
establish new sessions with different servers in expectation
that those servers might still allow Chain Queries.
</t>
</section>
<section title="Negative Trust Anchors">
<t> If a CHAIN answer would intersect with a Negative Trust Anchor
<xref target="RFC7646"/>, a partian CHAIN up to the node above the
Negative Trust Anchor should be returned.
</t>
</section>
<section title="Non-Clean Paths">
<t>
Many paths between DNS clients and Recursive Resolvers suffer
from poor hygiene, limiting the free flow of DNS messages that
include particular EDNS0 options, or messages that exceed a
particular size. A fallback strategy similar to that described
in <xref target="RFC6891"/> section 6.2.2 SHOULD be employed
to avoid persistent interference due to non-clean paths.
</t>
</section>
<section title="Anycast Considerations">
<t>Recursive Resolvers of various types are commonly deployed using
anycast <xref target="RFC4786"/>.</t>
<t>
Successive DNS transactions between a client and server using
UDP transport may involve responses generated by different
anycast nodes, and the use of anycast in the implementation of
a DNS server is effectively undetectable by the client. The
CHAIN option SHOULD NOT be included in responses using UDP
transport from servers provisioned using anycast unless all
anycast server nodes are capable of processing the CHAIN option.
</t>
<t>
Changes in network topology between clients and anycast servers
may cause disruption to TCP sessions making use of CHAIN more
often than with TCP sessions that omit it, since the TCP sessions
are expected to be longer-lived. Anycast servers MAY make use
of TCP multipath <xref target="RFC6824"/> to anchor the server
side of the TCP connection to an unambiguously-unicast address
in order to avoid disruption due to topology changes.
</t>
</section>
</section>
<section anchor="implementation" title="Implementation Status">
<t>
This section records the status of known implementations of
the protocol defined by this specification at the time of
posting of this Internet-Draft, and is based on a proposal
described in <xref target="RFC6982" />. The description of
implementations in this section is intended to assist the
IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore,
no effort has been spent to verify the information presented
here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of
available implementations or their features. Readers are
advised to note that other implementations may exist.
</t>
<t>
According to <xref target="RFC6982" />, "this will allow
reviewers and working groups to assign due consideration to
documents that have the benefit of running code, which may
serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is
up to the individual working groups to use this information
as they see fit".
</t>
<t>
[While there is some interest, no work has started yet]
</t>
</section>
<section anchor="security" title="Security Considerations">
<section title="Amplification Attacks">
<t>
Chain Queries can potentially send very large DNS
answers. Attackers could abuse this using spoofed source IP
addresses to inflict large Distributed Denial of Service
attacks using query-chains as an amplification vector in
their attack. While TCP is not vulnerable for this type of
abuse, the UDP protocol is vulnerable to this.
</t>
<t>
A Recursive Resolver MUST NOT return CHAIN answers to
clients over UDP without source IP address verification.
An example of UDP based source IP address verification is
<xref target="EDNS-COOKIE"/>. A Recursive Resolver refusing
a CHAIN option MUST respond with a zero-length CHAIN option
to indicate support for CHAIN queries when a proper transport
is used. It MUST NOT send an RCODE of REFUSED.
</t>
</section>
</section>
<section anchor="example" title="Examples">
<section anchor="example1" title="Simple Query for example.com">
<t><list style="symbols">
<t>
A web browser on a client machine asks the Forwarder
running on 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.
</t>
<t>
The Resolver on the client machine checks its cache,
and notices it already has a DNSSEC validated entry of
"com." in its cache. This includes the DNSKEY RRset
with its RRSIG records. In other words, according to
its cache, ".com" is DNSSEC validated as "secure" and
can be used to continue a DNSSEC validated chain.
</t>
<t>
The Resolver on the client opens a TCP connection to
its upstream Recursive Resolver on port 53. It adds the
CHAIN option as follows:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x04</t>
<t>Closest Trust Point set to "com."</t>
</list>
</t>
<t>
The upstream Recursive Resolver receives a DNS query
over TCP with the CHAIN Closest Trust Point set to
"com.". After accepting the query it starts constructing
a DNS reply packet.
</t>
<t>
The upstream Recursive Resolver performs all the regular work to
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 - unless it is also configured as a Forwarder. The answer
to the original DNS question could be the actual A record,
the DNSSEC proof of non-existence, or an insecure NXDOMAIN response.
</t>
<t>
The upstream Recursive Resolver adds the CHAIN option
to the DNS response as follows:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x04</t>
<t>The Closest Trust Point is set to "com.".</t>
</list>
</t>
<t>
The upstream Recursive Resolver constructs the DNS
Authority Section and fills it (in any order) with:
<list style="symbols">
<t>The DS RRset for "example.com." and its corresponding
RRSIGs (made by the "com." DNSKEY(s))</t>
<t>The DNSKEY RRset for "example.com." and its
corresponding RRSIGs (made by the "example.com"
DNSKEY(s))</t>
<t>The authoritative NS RRset for "example.com." and
its corresponding RRSIGs (from the child zone)</t>
</list>
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 the Authority Section.
</t>
<t>
The upstream Recursive Resolver constructs the DNS Answer
Section and fills it with:
<list style="symbols">
<t>The A record of "www.example.com." and its corresponding RRSIGs</t>
</list>
If the answer does not exist (NODATA or NXDOMAIN),
the Answer Section remains empty. For the NXDOMAIN
case, the RCode of the DNS answer packet is set to
NXDOMAIN. Otherwise it remains NOERROR.
</t>
<t>
The upstream Recursive Resolver returns the DNS answer
over the existing TCP connection. When all data is sent,
it SHOULD keep the TCP connection open to allow for additional
incoming DNS queries - provided it has enough resources to do so.
</t>
<t>
The Resolver on the client receives the DNS answer. It
processes the Authority Section and the Answer Section
and places the information in its local cache. It ensures
that no data is accepted into the cache without having
proper DNSSEC validation. It MAY do so by looping over
the entries in the Authority and Answer Sections. When an
entry is validated for its cache, it is removed from the
processing list. If an entry cannot be validated it is left
in the process list. When the end of the list is reached,
the list is processed again until either all entries
are placed in the cache, or the remaining items cannot
be placed in the cache due to lack of validation. Those
entries are then discarded.
</t>
<t>
If the cache contains a valid answer to the application's
query, this answer is returned to the application via a
regular DNS answer packet. This packet MUST NOT contain an
CHAIN option. If no valid answer can be returned,
normal error processing is done. For example, an NXDOMAIN
or an empty Answer Section could be returned depending
on the error condition.
</t>
</list></t>
</section>
<section anchor="example2" title="Out-of-path Query for example.com">
<t>A Recursive Resolver receives a query for the A record for
example.com. It includes the CHAIN option with
the following parameters:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x0D</t>
<t>The Closest Trust Point set to 'unrelated.ca.'</t>
</list>
As there is no chain that leads from "unrelated.ca." to
"example.com", the Resolving Nameserver answers with an
empty CHAIN specified using:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x00</t>
<t>The Closest Trust Point is omitted (zero length)</t>
</list>
Note that the regular answer is still present just as it would be for a query
that did not specify the CHAIN option.
</t>
</section>
<section anchor="example3" title="Non-existent data">
<t>
A Recursive Resolver receives a query for the A record for
"ipv6.toronto.redhat.ca". It includes the CHAIN option
with the following parameters:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x03</t>
<t>The Closest Trust Point set to 'ca.'</t>
</list>
Using regular UDP queries towards Authoritative Nameservers,
it 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 Section. The Authority Section contains NSEC3
and RRSIG records proving there is no A RRtype for the QNAME
"ipv6.toronto.redhat.ca".
</t>
<t>
The Recursive Resolver constructs a DNS reply with the
following CHAIN option parameters:
<list style="symbols">
<t>Option-code, set to 13</t>
<t>Option-length, set to 0x00 0x00</t>
<t>The Closest Trust Point is ommited (zero length)</t>
</list>
The RCODE is set to "NoError". The Authority Section is filled in with:
<list style="symbols">
<t>The DS RRset for "redhat.ca." plus RRSIGs</t>
<t>The DNSKEY RRset for "redhat.ca." plus RRSIGs</t>
<t>The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca)</t>
<t>The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs</t>
<t>The DS RRset for "toronto.redhat.ca." plus RRSIGs</t>
<t>The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg ns[01].toronto.redhat.ca)</t>
<t>The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs</t>
<t>The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and "ns1.toronto.redhat.ca." plus RRSIGs</t>
<t>The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs do exist, does not include A)</t>
<t>The NSEC record for "toronto.redhat.ca." (proves no wildcard exists)</t>
</list>
The Answer Section is empty. The RCode is set to NOERROR.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="EDNS0 option code for CHAIN" anchor="iana_opt">
<t>IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
(OPT)" registry to CHAIN.</t>
</section>
</section>
<section title="Acknowledgements">
<t>
Andrew Sullivan pointed out that we do not need any new data
formats to support DNS chains. Olafur Gudmundsson ensured the
RRsets are returned in the proper Sections. Thanks to Tim Wicinski
for his thorough review.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc1034;
&rfc1035;
&rfc2119;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4786;
&rfc6824;
&rfc6891;
&rfc6982;
&rfc7646;
<reference anchor='DNS-TERMINOLOGY'>
<front>
<title>DNS Terminology</title>
<author initials='P' surname='Hoffman' fullname='P. Hoffman'>
<organization>VPN Consortium</organization>
</author>
<author initials='A' surname='Sullivan' fullname='A. Sullivan'>
<organization>Dyn</organization>
</author>
<author initials='K' surname='Fujiwara' fullname='K. Fujiwara'>
<organization>JPRS</organization>
</author>
<date month='September' day='24' year='2015' />
<abstract><t>
The DNS is defined in literally dozens of different RFCs. The
terminology used in by implementers and developers of DNS protocols,
and by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single
document.
</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-dns-terminology-05' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-dnsop-dns-terminology-05.txt' />
</reference>
<reference anchor='TCP-KEEPALIVE'>
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author initials='P' surname='Wouters' fullname='P. Wouters'>
<organization>Red Hat</organization>
</author>
<author initials='J' surname='Abley' fullname='J. Abley'>
<organization>Dyn, Inc.</organization>
</author>
<author initials='S' surname='Dickinson' fullname='S. Dickinson'>
<organization>Sinodun</organization>
</author>
<author initials='R' surname='Bellis' fullname='R. Bellis'>
<organization>ISC</organization>
</author>
<date month='October' day='20' year='2015' />
<abstract><t>
This document defines an EDNS0 option ("edns-tcp-keepalive") that
allows DNS servers to signal a variable idle timeout. This
signalling facilitates a better balance of UDP and TCP transport
between individual clients and servers, reducing the impact of
problems associated with UDP transport and allowing the state
associated with TCP transport to be managed effectively with minimal
impact on the DNS transaction time.
</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-edns-tcp-keepalive-04' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-dnsop-edns-tcp-keepalive-04.txt' />
</reference>
<reference anchor='EDNS-COOKIE'>
<front>
<title>Domain Name System (DNS) Cookies</title>
<author initials='Donald' surname='Eastlake' fullname='Donald Eastlake'>
<organization>Huawei</organization>
</author>
<date month='November' day='2' year='2015' />
<abstract><t>
DNS cookies are a lightweight DNS transaction security mechanism that
provides limited protection to DNS servers and clients against a
variety of increasingly common denial-of-service and amplification /
forgery or cache poisoning attacks by off-path attackers. DNS Cookies
are tolerant of NAT, NAT-PT, and anycast and can be incrementally
deployed.
</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-cookies' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-cookies-07.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:30:22 |