draft-ietf-dnsop-no-response-issue-23.txt   rfc8906.txt 
Network Working Group M. Andrews Internet Engineering Task Force (IETF) M. Andrews
Internet-Draft R. Bellis Request for Comments: 8906 R. Bellis
Intended status: Best Current Practice ISC BCP: 231 ISC
Expires: October 18, 2020 April 16, 2020 Category: Best Current Practice September 2020
ISSN: 2070-1721
A Common Operational Problem in DNS Servers - Failure To Communicate A Common Operational Problem in DNS Servers: Failure to Communicate
draft-ietf-dnsop-no-response-issue-23
Abstract Abstract
The DNS is a query / response protocol. Failing to respond to The DNS is a query/response protocol. Failing to respond to queries,
queries, or responding incorrectly, causes both immediate operational or responding incorrectly, causes both immediate operational problems
problems and long term problems with protocol development. and long-term problems with protocol development.
This document identifies a number of common kinds of queries to which This document identifies a number of common kinds of queries to which
some servers either fail to respond or else respond incorrectly. some servers either fail to respond or respond incorrectly. This
This document also suggests procedures for zone operators to apply to document also suggests procedures for zone operators to apply to
identify and remediate the problem. identify and remediate the problem.
The document does not look at the DNS data itself, just the structure The document does not look at the DNS data itself, just the structure
of the responses. of the responses.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 18, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8906.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Consequences . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Consequences
3. Common kinds of queries that result in no or bad responses. . 5 3. Common Kinds of Queries That Result in No or Bad Responses
3.1. Basic DNS Queries . . . . . . . . . . . . . . . . . . . . 5 3.1. Basic DNS Queries
3.1.1. Zone Existence . . . . . . . . . . . . . . . . . . . 5 3.1.1. Zone Existence
3.1.2. Unknown / Unsupported Type Queries . . . . . . . . . 5 3.1.2. Unknown/Unsupported Type Queries
3.1.3. DNS Flags . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. DNS Flags
3.1.4. Unknown DNS opcodes . . . . . . . . . . . . . . . . . 6 3.1.4. Unknown DNS Opcodes
3.1.5. TCP Queries . . . . . . . . . . . . . . . . . . . . . 6 3.1.5. TCP Queries
3.2. EDNS Queries . . . . . . . . . . . . . . . . . . . . . . 6 3.2. EDNS Queries
3.2.1. EDNS Queries - Version Independent . . . . . . . . . 7 3.2.1. EDNS Queries: Version Independent
3.2.2. EDNS Queries - Version Specific . . . . . . . . . . . 7 3.2.2. EDNS Queries: Version Specific
3.2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . 7 3.2.3. EDNS Options
3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7 3.2.4. EDNS Flags
3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8 3.2.5. Truncated EDNS Responses
3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8 3.2.6. DO=1 Handling
3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8 3.2.7. EDNS over TCP
4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8 4. Firewalls and Load Balancers
5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9 5. Packet Scrubbing Services
6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10 6. Whole Answer Caches
7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10 7. Response Code Selection
8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Testing
8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 12 8.1. Testing: Basic DNS
8.1.1. Is The Server Configured For The Zone? . . . . . . . 12 8.1.1. Is the server configured for the zone?
8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12 8.1.2. Testing Unknown Types
8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13 8.1.3. Testing Header Bits
8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15 8.1.4. Testing Unknown Opcodes
8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15 8.1.5. Testing TCP
8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16 8.2. Testing: Extended DNS
8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 8.2.1. Testing Minimal EDNS
8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 8.2.2. Testing EDNS Version Negotiation
8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 8.2.3. Testing Unknown EDNS Options
8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 8.2.4. Testing Unknown EDNS Flags
8.2.5. Testing EDNS Version Negotiation With Unknown EDNS 8.2.5. Testing EDNS Version Negotiation with Unknown EDNS
Flags . . . . . . . . . . . . . . . . . . . . . . . . 19 Flags
8.2.6. Testing EDNS Version Negotiation With Unknown EDNS 8.2.6. Testing EDNS Version Negotiation with Unknown EDNS
Options . . . . . . . . . . . . . . . . . . . . . . . 20 Options
8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20 8.2.7. Testing Truncated Responses
8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 21 8.2.8. Testing DO=1 Handling
8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21 8.2.9. Testing EDNS Version Negotiation with DO=1
8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22 8.2.10. Testing with Multiple Defined EDNS Options
8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22 8.3. When EDNS Is Not Supported
9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Remediation
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 12. References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References
13.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References
13.2. Informative References . . . . . . . . . . . . . . . . . 25 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses
1. Introduction 1. Introduction
The DNS [RFC1034], [RFC1035] is a query / response protocol. Failing The DNS [RFC1034] [RFC1035] is a query/response protocol. Failing to
to respond to queries, or responding incorrectly, causes both respond to queries or responding incorrectly causes both immediate
immediate operational problems and long term problems with protocol operational problems and long-term problems with protocol
development. development.
Failure to respond to a query is indistinguishable from packet loss Failure to respond to a query is indistinguishable from packet loss
without doing an analysis of query-response patterns. Additionally without doing an analysis of query-response patterns. Additionally,
failure to respond results in unnecessary queries being made by DNS failure to respond results in unnecessary queries being made by DNS
clients, and introduces delays to the resolution process. clients and introduces delays to the resolution process.
Due to the inability to distinguish between packet loss and Due to the inability to distinguish between packet loss and
nameservers or middle boxes dropping EDNS [RFC6891] queries, packet nameservers or middleboxes dropping Extension Mechanisms for DNS
loss is sometimes misclassified as lack of EDNS support which can (EDNS) [RFC6891] queries, packet loss is sometimes misclassified as
lead to DNSSEC validation failures. lack of EDNS support, which can lead to DNSSEC validation failures.
The existence of servers which fail to respond to queries results in The existence of servers that fail to respond to queries results in
developers being hesitant to deploy new standards. Such servers need developers being hesitant to deploy new standards. Such servers need
to be identified and remediated. to be identified and remediated.
The DNS has response codes that cover almost any conceivable query The DNS has response codes that cover almost any conceivable query
response. A nameserver should be able to respond to any conceivable response. A nameserver should be able to respond to any conceivable
query using them. There should be no need to drop queries because a query using them. There should be no need to drop queries because a
nameserver does not understand them. nameserver does not understand them.
Unless a nameserver is under attack, it should respond to all DNS Unless a nameserver is under attack, it should respond to all DNS
requests directed to it. When a nameserver is under attack it may requests directed to it. When a nameserver is under attack, it may
wish to drop packets. A common attack is to use a nameserver as an wish to drop packets. A common attack is to use a nameserver as an
amplifier by sending spoofed packets. This is done because response amplifier by sending spoofed packets. This is done because response
packets are bigger than the queries and large amplification factors packets are bigger than the queries and large amplification factors
are available especially if EDNS is supported. Limiting the rate of are available, especially if EDNS is supported. Limiting the rate of
responses is reasonable when this is occurring and the client should responses is reasonable when this is occurring, and the client should
retry. This however only works if legitimate clients are not being retry. However, this only works if legitimate clients are not being
forced to guess whether EDNS queries are accepted or not. As long as forced to guess whether or not EDNS queries are accepted. As long as
there are still a pool of servers that don't respond to EDNS there is still a pool of servers that don't respond to EDNS requests,
requests, clients have no way to know if the lack of response is due clients have no way to know if the lack of response is due to packet
to packet loss, or EDNS packets not being supported, or rate limiting loss, EDNS packets not being supported, or rate limiting due to the
due to the server being under attack. Misclassification of server server being under attack. Misclassification of server behaviour is
behaviour is unavoidable when rate limiting is used until the unavoidable when rate limiting is used until the population of
population of servers which fail to respond to well-formed queries servers that fail to respond to well-formed queries drops to near
drops to near zero. zero.
Nameservers should respond to queries even if the queried name is not Nameservers should respond to queries even if the queried name is not
for any name the server is configured to answer for. Misconfigured for any name the server is configured to answer for. Misconfigured
nameservers are a common occurrence in the DNS and receiving queries nameservers are a common occurrence in the DNS, and receiving queries
for zones that the server is not configured for is not necessarily an for zones that the server is not configured for is not necessarily an
indication that the server is under attack. Parent zone operators indication that the server is under attack. Parent zone operators
are advised to regularly check that the delegating NS records are are advised to regularly check that the delegating NS records are
consistent with those of the delegated zone and to correct them when consistent with those of the delegated zone and to correct them when
they are not [RFC1034], Section 4.4.2, Paragraph 3. Doing this they are not (Section 4.2.2 of [RFC1034], Paragraph 3). Doing this
regularly should reduce the instances of broken delegations. regularly should reduce the instances of broken delegations.
This document does not try to identify all possible errors nor does This document does not try to identify all possible errors nor does
it supply an exhaustive list of tests. it supply an exhaustive list of tests.
2. Consequences 2. Consequences
Failure to follow the relevant DNS RFCs has multiple adverse Failure to follow the guidance in relevant DNS RFCs has multiple
consequences. Some are caused directly by the non-compliant adverse consequences. Some are caused directly by the non-compliant
behaviour and others as a result of work-arounds forced on recursive behaviour and others as a result of workarounds forced on recursive
servers. Addressing known issues now will reduce future servers. Addressing known issues now will reduce future
interoperability issues as the DNS protocol continues to evolve and interoperability issues as the DNS protocol continues to evolve and
clients make use of newly-introduced DNS features. In particular the clients make use of newly introduced DNS features. In particular,
base DNS specification [RFC1034], [RFC1035] and the EDNS the base DNS specification [RFC1034] [RFC1035] and the EDNS
specification [RFC6891], when implemented, need to be followed. specification [RFC6891], when implemented, need to be followed.
Some examples of known consequences include: Some examples of known consequences include the following:
o The AD (Authenticated Data) bit in a response cannot be trusted to * The AD (Authenticated Data) bit in a response cannot be trusted to
mean anything as some servers incorrectly copy the flag bit from mean anything, as some servers incorrectly copy the flag bit from
the request to the response [RFC1035], [RFC4035]. The use of the the request to the response [RFC1035] [RFC4035]. The use of the
AD bit in requests is defined in [RFC6840]. AD bit in requests is defined in [RFC6840].
o Widespread non-response to EDNS queries has led to recursive * Widespread non-response to EDNS queries has led to recursive
servers having to assume that EDNS is not supported and that servers having to assume that EDNS is not supported and that
fallback to plain DNS is required, potentially causing DNSSEC fallback to plain DNS is required, potentially causing DNSSEC
validation failures. validation failures.
o Widespread non-response to EDNS options requires recursive servers * Widespread non-response to EDNS options requires recursive servers
to decide whether to probe to see if it is the specific EDNS to decide whether to probe to see if it is the specific EDNS
option or the use of EDNS in general that is causing the non option or the use of EDNS in general that is causing the non-
response. In the limited amount of time required to resolve a response. In the limited amount of time required to resolve a
query before the client times out this is not possible. query before the client times out, this is not possible.
o Incorrectly returning FORMERR to an EDNS option being present * Incorrectly returning FORMERR to an EDNS option being present
leads to the recursive server not being able to determine if the leads to the recursive server not being able to determine if the
server is just broken in the handling of the EDNS option or server is just broken in the handling of the EDNS option or if it
doesn't support EDNS at all. doesn't support EDNS at all.
o Mishandling of unknown query types has contributed to the * Mishandling of unknown query types has contributed to the
abandonment of the transition of the SPF type. abandonment of the transition of the SPF type.
o Mishandling of unknown query types has slowed up the development * Mishandling of unknown query types has slowed up the development
of DANE and resulted in additional rules being specified to reduce of DNS-Based Authentication of Named Entities (DANE) and resulted
the probability of interacting with a broken server when making in additional rules being specified to reduce the probability of
TLSA queries. interacting with a broken server when making TLSA queries.
The consequences of servers not following the RFCs will only grow if The consequences of servers not following the RFCs will only grow if
measures are not put in place to remove non compliant servers from measures are not put in place to remove non-compliant servers from
the ecosystem. Working around issues due to non-compliance with RFCs the ecosystem. Working around issues due to non-compliance with RFCs
is not sustainable. is not sustainable.
Most (if not all) of these consequences could have been avoided if Most (if not all) of these consequences could have been avoided if
action had been taken to remove non-compliant servers as soon as action had been taken to remove non-compliant servers as soon as
people were aware of them, i.e. to actively seek out broken people were aware of them, i.e., to actively seek out broken
implementations and servers and inform their developers and operators implementations and servers and inform their developers and operators
that they need to fix their servers. that they need to fix their servers.
3. Common kinds of queries that result in no or bad responses. 3. Common Kinds of Queries That Result in No or Bad Responses
This section is broken down into Basic DNS requests and EDNS This section is broken down into Basic DNS requests and EDNS
requests. requests.
3.1. Basic DNS Queries 3.1. Basic DNS Queries
3.1.1. Zone Existence 3.1.1. Zone Existence
If a zone is delegated to a server, that server should respond to an If a zone is delegated to a server, that server should respond to a
SOA query for that zone with an SOA record. Failing to respond at SOA query for that zone with an SOA record. Failing to respond at
all is always incorrect, regardless of the configuration of the all is always incorrect, regardless of the configuration of the
server. Responding with anything other than an SOA record in the server. Responding with anything other than an SOA record in the
Answer section indicates a bad delegation. answer section indicates a bad delegation.
3.1.2. Unknown / Unsupported Type Queries 3.1.2. Unknown/Unsupported Type Queries
Some servers fail to respond to unknown or unsupported types. If a Some servers fail to respond to unknown or unsupported types. If a
server receives a query for a type that it doesn't recognise, or server receives a query for a type that it doesn't recognise, or
doesn't implement, it is expected to return the appropriate response doesn't implement, it is expected to return the appropriate response
as if it did recognise the type but does not have any data for that as if it did recognise the type but does not have any data for that
type: either NOERROR, or NXDOMAIN. The exceptions to this are type, i.e., either NOERROR or NXDOMAIN. The exceptions to this are
queries for Meta-RR types which may return NOTIMP. queries for Meta-RR types, which may return NOTIMP.
3.1.3. DNS Flags 3.1.3. DNS Flags
Some servers fail to respond to DNS queries with various DNS flags Some servers fail to respond to DNS queries with various DNS flags
set, regardless of whether they are defined or still reserved. At set, regardless of whether they are defined or still reserved. At
the time of writing there are servers that fail to respond to queries the time of writing, there are servers that fail to respond to
with the AD flag set to 1 and servers that fail to respond to queries queries with the AD flag set to 1 and servers that fail to respond to
with the last reserved flag set. queries with the last reserved flag set.
Servers should respond to such queries. If the server does not know Servers should respond to such queries. If the server does not know
the meaning of a flag it must not copy it to the response [RFC1035] the meaning of a flag, it must not copy it to the response
Section 4.1.1. If the server does not understand the meaning of a (Section 4.1.1 of [RFC1035]). If the server does not understand the
request it should reply with a FORMERR response with unknown flags meaning of a request, it should reply with a FORMERR response with
set to zero. unknown flags set to zero.
3.1.3.1. Recursive Queries 3.1.3.1. Recursive Queries
A non-recursive server is supposed to respond to recursive queries as A non-recursive server is supposed to respond to recursive queries as
if the RD bit is not set [RFC1034]. if the Recursion Desired (RD) bit is not set [RFC1034].
3.1.4. Unknown DNS opcodes 3.1.4. Unknown DNS Opcodes
The use of previously undefined opcodes is to be expected. Since the The use of previously undefined opcodes is to be expected. Since the
DNS was first defined two new opcodes have been added, UPDATE and DNS was first defined, two new opcodes have been added, UPDATE and
NOTIFY. NOTIFY.
NOTIMP is the expected rcode to an unknown or unimplemented opcode. NOTIMP is the expected rcode to an unknown or unimplemented opcode.
Note: while new opcodes will most probably use the current layout | NOTE: while new opcodes will most probably use the current
structure for the rest of the message there is no requirement that | layout structure for the rest of the message, there is no
anything other than the DNS header match. | requirement that anything other than the DNS header match.
3.1.5. TCP Queries 3.1.5. TCP Queries
All DNS servers are supposed to respond to queries over TCP All DNS servers are supposed to respond to queries over TCP
[RFC7766]. While firewalls should not block TCP connection attempts, [RFC7766]. While firewalls should not block TCP connection attempts,
those that do they should cleanly terminate the connection by sending those that do should cleanly terminate the connection by sending TCP
TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited RESET or sending ICMP/ICMPv6 Administratively Prohibited messages.
messages. Dropping TCP connections introduces excessive delays to Dropping TCP connections introduces excessive delays to the
the resolution process. resolution process.
3.2. EDNS Queries 3.2. EDNS Queries
EDNS queries are specified in [RFC6891]. EDNS queries are specified in [RFC6891].
3.2.1. EDNS Queries - Version Independent 3.2.1. EDNS Queries: Version Independent
Identifying servers that fail to respond to EDNS queries can be done Identifying servers that fail to respond to EDNS queries can be done
by first confirming that the server responds to regular DNS queries, by first confirming that the server responds to regular DNS queries,
followed by a series of otherwise identical queries using EDNS, then followed by a series of otherwise identical queries using EDNS, then
making the original query again. A series of EDNS queries is needed making the original query again. A series of EDNS queries is needed,
as at least one DNS implementation responds to the first EDNS query as at least one DNS implementation responds to the first EDNS query
with FORMERR but fails to respond to subsequent queries from the same with FORMERR but fails to respond to subsequent queries from the same
address for a period until a regular DNS query is made. The EDNS address for a period until a regular DNS query is made. The EDNS
query should specify a UDP buffer size of 512 bytes to avoid false query should specify a UDP buffer size of 512 bytes to avoid false
classification of not supporting EDNS due to response packet size. classification of not supporting EDNS due to response packet size.
If the server responds to the first and last queries but fails to If the server responds to the first and last queries but fails to
respond to most or all of the EDNS queries, it is probably faulty. respond to most or all of the EDNS queries, it is probably faulty.
The test should be repeated a number of times to eliminate the The test should be repeated a number of times to eliminate the
likelihood of a false positive due to packet loss. likelihood of a false positive due to packet loss.
Firewalls may also block larger EDNS responses but there is no easy Firewalls may also block larger EDNS responses, but there is no easy
way to check authoritative servers to see if the firewall is mis- way to check authoritative servers to see if the firewall is
configured. misconfigured.
3.2.2. EDNS Queries - Version Specific 3.2.2. EDNS Queries: Version Specific
Some servers respond correctly to EDNS version 0 queries but fail to Some servers respond correctly to EDNS version 0 queries but fail to
respond to EDNS queries with version numbers that are higher than respond to EDNS queries with version numbers that are higher than
zero. Servers should respond with BADVERS to EDNS queries with zero. Servers should respond with BADVERS to EDNS queries with
version numbers that they do not support. version numbers that they do not support.
Some servers respond correctly to EDNS version 0 queries but fail to Some servers respond correctly to EDNS version 0 queries but fail to
set QR=1 when responding to EDNS versions they do not support. Such set QR=1 when responding to EDNS versions they do not support. Such
responses may be discarded as invalid (as QR is not 1) or treated as responses may be discarded as invalid (as QR is not 1) or treated as
requests (when the source port of the original request was port 53). requests (when the source port of the original request was port 53).
skipping to change at page 8, line 7 skipping to change at line 331
Unknown EDNS options are supposed to be ignored by the server. Unknown EDNS options are supposed to be ignored by the server.
3.2.4. EDNS Flags 3.2.4. EDNS Flags
Some servers fail to respond to EDNS queries with EDNS flags set. Some servers fail to respond to EDNS queries with EDNS flags set.
Servers should ignore EDNS flags they do not understand and must not Servers should ignore EDNS flags they do not understand and must not
add them to the response [RFC6891]. add them to the response [RFC6891].
3.2.5. Truncated EDNS Responses 3.2.5. Truncated EDNS Responses
Some EDNS aware servers fail to include an OPT record when a Some EDNS-aware servers fail to include an OPT record when a
truncated response is sent. An OPT record is supposed to be included truncated response is sent. An OPT record is supposed to be included
in a truncated response [RFC6891]. in a truncated response [RFC6891].
Some EDNS aware servers fail to honour the advertised EDNS UDP buffer Some EDNS-aware servers fail to honour the advertised EDNS UDP buffer
size and send over-sized responses [RFC6891]. Servers must send UDP size and send oversized responses [RFC6891]. Servers must send UDP
responses no larger than the advertised EDNS UDP buffer size. responses no larger than the advertised EDNS UDP buffer size.
3.2.6. DO=1 Handling 3.2.6. DO=1 Handling
Some nameservers incorrectly only return an EDNS response when the DO Some nameservers incorrectly only return an EDNS response when the
bit [RFC3225] is 1 in the query. Servers that support EDNS should DNSSEC OK (DO) bit [RFC3225] is 1 in the query. Servers that support
always respond to EDNS requests with EDNS responses. EDNS should always respond to EDNS requests with EDNS responses.
Some nameservers fail to copy the DO bit to the response despite Some nameservers fail to copy the DO bit to the response despite
clearly supporting DNSSEC by returning an RRSIG records to EDNS clearly supporting DNSSEC by returning an RRSIG records to EDNS
queries with DO=1. Nameservers that support DNSSEC are expected to queries with DO=1. Nameservers that support DNSSEC are expected to
copy the DO bit from the request to the response. copy the DO bit from the request to the response.
3.2.7. EDNS over TCP 3.2.7. EDNS over TCP
Some EDNS aware servers incorrectly limit the TCP response sizes to Some EDNS-aware servers incorrectly limit the TCP response sizes to
the advertised UDP response size. This breaks DNS resolution to the advertised UDP response size. This breaks DNS resolution to
clients where the response sizes exceed the advertised UDP response clients where the response sizes exceed the advertised UDP response
size despite the server and the client being capable of sending and size despite the server and the client being capable of sending and
receiving larger TCP responses respectively. It effectively defeats receiving larger TCP responses, respectively. It effectively defeats
setting TC=1 in UDP responses. setting TC=1 in UDP responses.
4. Firewalls and Load Balancers 4. Firewalls and Load Balancers
Firewalls and load balancers can affect the externally visible Firewalls and load balancers can affect the externally visible
behaviour of a nameserver. Tests for conformance should to be done behaviour of a nameserver. Tests for conformance should to be done
from outside of any firewall so that the system is tested as a whole. from outside of any firewall so that the system is tested as a whole.
Firewalls and load balancers should not drop DNS packets that they Firewalls and load balancers should not drop DNS packets that they
don't understand. They should either pass the packets or generate an don't understand. They should either pass the packets or generate an
skipping to change at page 9, line 12 skipping to change at line 384
should not be construed as an attack. Nameservers have always been should not be construed as an attack. Nameservers have always been
expected to be able to handle such queries. expected to be able to handle such queries.
Requests with unknown opcodes are normal client behaviour and should Requests with unknown opcodes are normal client behaviour and should
not be construed as an attack. Nameservers have always been expected not be construed as an attack. Nameservers have always been expected
to be able to handle such queries. to be able to handle such queries.
Requests with unassigned flags set (DNS or EDNS) are expected client Requests with unassigned flags set (DNS or EDNS) are expected client
behaviour and should not be construed as an attack. The behaviour behaviour and should not be construed as an attack. The behaviour
for unassigned flags is to ignore them in the request and to not set for unassigned flags is to ignore them in the request and to not set
them in the response. Dropping DNS / EDNS packets with unassigned them in the response. Dropping DNS/EDNS packets with unassigned
flags makes it difficult to deploy extensions that make use of them flags makes it difficult to deploy extensions that make use of them
due to the need to reconfigure and update firewalls. due to the need to reconfigure and update firewalls.
Requests with unknown EDNS options are expected client behaviour and Requests with unknown EDNS options are expected client behaviour and
should not be construed as an attack. The correct behaviour for should not be construed as an attack. The correct behaviour for
unknown EDNS options is to ignore their presence when constructing a unknown EDNS options is to ignore their presence when constructing a
reply. reply.
Requests with unknown EDNS versions are expected client behaviour and Requests with unknown EDNS versions are expected client behaviour and
should not be construed as an attack. The correct behaviour for should not be construed as an attack. The correct behaviour for
skipping to change at page 9, line 39 skipping to change at line 411
signal that multiple DNS messages be returned rather than a single signal that multiple DNS messages be returned rather than a single
UDP message that is fragmented at the IP layer. UDP message that is fragmented at the IP layer.
DNS, and EDNS in particular, are designed to allow clients to be able DNS, and EDNS in particular, are designed to allow clients to be able
to use new features against older servers without having to validate to use new features against older servers without having to validate
every option. Indiscriminate blocking of messages breaks that every option. Indiscriminate blocking of messages breaks that
design. design.
However, there may be times when a nameserver mishandles messages However, there may be times when a nameserver mishandles messages
with a particular flag, EDNS option, EDNS version field, opcode, type with a particular flag, EDNS option, EDNS version field, opcode, type
or class field or combination thereof to the point where the or class field, or combination thereof to the point where the
integrity of the nameserver is compromised. Firewalls should offer integrity of the nameserver is compromised. Firewalls should offer
the ability to selectively reject messages using an appropriately the ability to selectively reject messages using an appropriately
constructed response based on all these fields while awaiting a fix constructed response based on all these fields while awaiting a fix
from the nameserver vendor. Returning FORMERR or REFUSED are two from the nameserver vendor. Returning FORMERR or REFUSED are two
potential error codes to return. potential error codes to return.
5. Packet Scrubbing Services 5. Packet Scrubbing Services
Packet scrubbing services are used to filter out undesired traffic, Packet scrubbing services are used to filter out undesired traffic,
including but not limited to, denial of service traffic. This is including but not limited to denial-of-service traffic. This is
often done using heuristic analysis of the traffic. often done using heuristic analysis of the traffic.
Packet scrubbing services can affect the externally visible behaviour Packet scrubbing services can affect the externally visible behaviour
of a nameserver in a similar way to firewalls. If an operator uses a of a nameserver in a similar way to firewalls. If an operator uses a
packet scrubbing service, they should check that legitimate queries packet scrubbing service, they should check that legitimate queries
are not being blocked. are not being blocked.
Packet scrubbing services, unlike firewalls, are also turned on and Packet scrubbing services, unlike firewalls, are also turned on and
off in response to denial of service attacks. One needs to take care off in response to denial-of-service attacks. One needs to take care
when choosing a scrubbing service. when choosing a scrubbing service.
Ideally, Operators should run these tests against a packet scrubbing Ideally, operators should run these tests against a packet scrubbing
service to ensure that these tests are not seen as attack vectors. service to ensure that these tests are not seen as attack vectors.
6. Whole Answer Caches 6. Whole Answer Caches
Whole answer caches take a previously constructed answer and return Whole answer caches take a previously constructed answer and return
it to a subsequent query for the same question. However, they can it to a subsequent query for the same question. However, they can
return the wrong response if they do not take all of the relevant return the wrong response if they do not take all of the relevant
attributes of the query into account. attributes of the query into account.
In addition to the standard tuple of <qname,qtype,qclass> a non- In addition to the standard tuple of <qname,qtype,qclass>, a non-
exhaustive set of attributes that must be considered include: RD, AD, exhaustive set of attributes that must be considered include: RD, AD,
CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and
transport. transport.
7. Response Code Selection 7. Response Code Selection
Choosing the correct response code when responding to DNS queries is Choosing the correct response code when responding to DNS queries is
important. Response codes should be chosen considering how clients important. Response codes should be chosen considering how clients
will handle them. will handle them.
For unimplemented opcodes NOTIMP is the expected response code. For unimplemented opcodes, NOTIMP is the expected response code.
Note: Newly implemented opcodes may change the message format by Note: newly implemented opcodes may change the message format by
extending the header, changing the structure of the records, etc. extending the header, changing the structure of the records, etc.
Servers are not expected to be able to parse these, and should Servers are not expected to be able to parse these and should respond
respond with a response code of NOTIMP rather than FORMERR (which with a response code of NOTIMP rather than FORMERR (which would be
would be expected if there was a parse error with an known opcode). expected if there was a parse error with a known opcode).
For unimplemented type codes, and in the absence of other errors, the For unimplemented type codes, and in the absence of other errors, the
only valid response is NoError if the qname exists, and NameError only valid response is NOERROR if the qname exists and NXDOMAIN
(NXDOMAIN) otherwise. For Meta-RRs NOTIMP may be returned instead. otherwise. For Meta-RRs, NOTIMP may be returned instead.
If a zone cannot be loaded because it contains unimplemented type If a zone cannot be loaded because it contains unimplemented type
codes that are not encoded as unknown record types according to codes that are not encoded as unknown record types according to
[RFC3597] then the expected response is SERVFAIL as the whole zone [RFC3597], then the expected response is SERVFAIL, as the whole zone
should be rejected Section 5.2 [RFC1035]. If a zone loads then should be rejected (Section 5.2 of [RFC1035]). If a zone loads, then
Section 4.3.2 [RFC1034] applies. Section 4.3.2 of [RFC1034] applies.
If the server supports EDNS and receives a query with an unsupported If the server supports EDNS and receives a query with an unsupported
EDNS version, the correct response is BADVERS [RFC6891]. EDNS version, the correct response is BADVERS [RFC6891].
If the server does not support EDNS at all, FORMERR is the expected If the server does not support EDNS at all, FORMERR is the expected
error code. That said a minimal EDNS server implementation requires error code. That said, a minimal EDNS server implementation requires
parsing the OPT records and responding with an empty OPT record in parsing the OPT records and responding with an empty OPT record in
the additional section in most cases. There is no need to interpret the additional section in most cases. There is no need to interpret
any EDNS options present in the request as unsupported EDNS options any EDNS options present in the request, as unsupported EDNS options
are expected to be ignored [RFC6891]. Additionally EDNS flags can be are expected to be ignored [RFC6891]. Additionally, EDNS flags can
ignored. The only part of the OPT record that needs to be examined be ignored. The only part of the OPT record that needs to be
is the version field to determine if BADVERS needs to be sent or not. examined is the version field to determine if BADVERS needs to be
sent or not.
8. Testing 8. Testing
Testing is divided into two sections: "Basic DNS", which all servers Testing is divided into two sections: "Basic DNS", which all servers
should meet, and "Extended DNS", which should be met by all servers should meet, and "Extended DNS", which should be met by all servers
that support EDNS (a server is deemed to support EDNS if it gives a that support EDNS (a server is deemed to support EDNS if it gives a
valid EDNS response to any EDNS query). If a server does not support valid EDNS response to any EDNS query). If a server does not support
EDNS it should still respond to all the tests, albeit with error EDNS, it should still respond to all the tests, albeit with error
responses. responses.
These tests query for records at the apex of a zone that the server These tests query for records at the apex of a zone that the server
is nominally configured to serve. All tests should use the same is nominally configured to serve. All tests should use the same
zone. zone.
It is advisable to run all of the tests below in parallel so as to It is advisable to run all of the tests below in parallel so as to
minimise the delays due to multiple timeouts when the servers do not minimise the delays due to multiple timeouts when the servers do not
respond. There are 16 queries directed to each nameserver (assuming respond. There are 16 queries directed to each nameserver (assuming
no packet loss) testing different aspects of Basic DNS and Extended no packet loss) testing different aspects of Basic DNS and Extended
DNS. DNS.
The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with
the name of the zone being used for testing. Replace $server with the name of the zone being used for testing. Replace $server with
the name or address of the server being tested. the name or address of the server being tested.
When testing recursive servers set RD=1 and choose a zone name that When testing, recursive servers set RD=1 and choose a zone name that
is known to exist and is not being served by the recursive server. is known to exist and is not being served by the recursive server.
The root zone (".") is often a good candidate as it is DNSSEC signed. The root zone (".") is often a good candidate, as it is DNSSEC
RD=1, rather than RD=0, should be present in the responses for all signed. RD=1, rather than RD=0, should be present in the responses
test involving the opcode QUERY. Non-authoritative answers (AA=0) for all test involving the opcode QUERY. Non-authoritative answers
are expected when talking to a recursive server. AD=1 is only (AA=0) are expected when talking to a recursive server. AD=1 is only
expected if the server is validating responses and one or both AD=1 expected if the server is validating responses and one or both AD=1
or DO=1 is set in the request otherwise AD=0 is expected. or DO=1 is set in the request, otherwise AD=0 is expected.
8.1. Testing - Basic DNS 8.1. Testing: Basic DNS
This first set of tests cover basic DNS server behaviour and all This first set of tests cover Basic DNS server behaviour and all
servers should pass these tests. servers should pass these tests.
8.1.1. Is The Server Configured For The Zone? 8.1.1. Is the server configured for the zone?
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set and without EDNS. with no DNS flag bits set and without EDNS.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the Authoritative Answer
set in the header; RA may also be set [RFC1034]. We do not expect an (AA) and Query/Response (QR) bits to be set in the header; the
OPT record to be returned [RFC6891]. Recursion Available (RA) bits may also be set [RFC1034]. We do not
expect an OPT record to be returned [RFC6891].
Verify the server is configured for the zone: Verify the server is configured for the zone:
dig +noedns +noad +norec soa $zone @$server dig +noedns +noad +norec soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
8.1.2. Testing Unknown Types 8.1.2. Testing Unknown Types
Identifying servers that fail to respond to unknown or unsupported Identifying servers that fail to respond to unknown or unsupported
types can be done by making an initial DNS query for an A record, types can be done by making an initial DNS query for an A record,
making a number of queries for an unallocated type, then making a making a number of queries for an unallocated type, then making a
query for an A record again. IANA maintains a registry of allocated query for an A record again. IANA maintains a registry of allocated
types. types [IANA-DNS].
If the server responds to the first and last queries but fails to If the server responds to the first and last queries but fails to
respond to the queries for the unallocated type, it is probably respond to the queries for the unallocated type, it is probably
faulty. The test should be repeated a number of times to eliminate faulty. The test should be repeated a number of times to eliminate
the likelihood of a false positive due to packet loss. the likelihood of a false positive due to packet loss.
Ask for the TYPE1000 RRset at the configured zone's name. This query Ask for the TYPE1000 RRset at the configured zone's name. This query
is made with no DNS flag bits set and without EDNS. TYPE1000 has is made with no DNS flag bits set and without EDNS. TYPE1000 has
been chosen for this purpose as IANA is unlikely to allocate this been chosen for this purpose, as IANA is unlikely to allocate this
type in the near future and it is not in a range reserved for private type in the near future and it is not in a range reserved for private
use [RFC6895]. Any unallocated type code could be chosen for this use [RFC6895]. Any unallocated type code could be chosen for this
test. test.
We expect no records to be returned in the answer section, the rcode We expect no records to be returned in the answer section, the rcode
to be set to NOERROR, and the AA and QR bits to be set in the header; to be set to NOERROR, and the AA and QR bits to be set in the header;
RA may also be set [RFC1034]. We do not expect an OPT record to be RA may also be set [RFC1034]. We do not expect an OPT record to be
returned [RFC6891]. returned [RFC6891].
Check that queries for an unknown type work: Check that queries for an unknown type work:
skipping to change at page 13, line 23 skipping to change at line 584
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
8.1.3. Testing Header Bits 8.1.3. Testing Header Bits
8.1.3.1. Testing CD=1 Queries 8.1.3.1. Testing CD=1 Queries
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with only the CD DNS flag bit set, all other DNS bits clear, and with only the CD DNS flag bit set, with all other DNS bits clear, and
without EDNS. without EDNS.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header. We do not expect an OPT record to be returned. set in the header. We do not expect an OPT record to be returned.
If the server supports DNSSEC, CD should be set in the response If the server supports DNSSEC, CD should be set in the response
[RFC4035] otherwise CD should be clear [RFC1034]. [RFC4035]; otherwise, CD should be clear [RFC1034].
Check that queries with CD=1 work: Check that queries with CD=1 work:
dig +noedns +noad +norec +cd soa $zone @$server dig +noedns +noad +norec +cd soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
8.1.3.2. Testing AD=1 Queries 8.1.3.2. Testing AD=1 Queries
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with only the AD DNS flag bit set and all other DNS bits clear and with only the AD DNS flag bit set, with all other DNS bits clear, and
without EDNS. without EDNS.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header. We do not expect an OPT record to be returned. set in the header. We do not expect an OPT record to be returned.
The purpose of this query is to detect blocking of queries with the The purpose of this query is to detect blocking of queries with the
AD bit present, not the specific value of AD in the response. AD bit present, not the specific value of AD in the response.
Check that queries with AD=1 work: Check that queries with AD=1 work:
skipping to change at page 14, line 23 skipping to change at line 632
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
AD use in queries is defined in [RFC6840]. AD use in queries is defined in [RFC6840].
8.1.3.3. Testing Reserved Bit 8.1.3.3. Testing Reserved Bit
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with only the final reserved DNS flag bit set and all other DNS bits with only the final reserved DNS flag bit set, with all other DNS
clear and without EDNS. bits clear, and without EDNS.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header; RA may be set. The final reserved bit must not be set in the header; RA may be set. The final reserved bit must not be
set [RFC1034]. We do not expect an OPT record to be returned set [RFC1034]. We do not expect an OPT record to be returned
[RFC6891]. [RFC6891].
Check that queries with the last unassigned DNS header flag work and Check that queries with the last unassigned DNS header flag work and
that the flag bit is not copied to the response: that the flag bit is not copied to the response:
skipping to change at page 14, line 46 skipping to change at line 655
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: MBZ to NOT be in the response (see below) expect: MBZ to NOT be in the response (see below)
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
MBZ (Must Be Zero) is a dig-specific indication that the flag bit has MBZ (Must Be Zero) is a dig-specific indication that the flag bit has
been incorrectly copied. See Section 4.1.1, [RFC1035] "Z Reserved been incorrectly copied. See Section 4.1.1 of [RFC1035]:
for future use. Must be zero in all queries and responses."
"Z Reserved for future use. Must be zero in all queries and
responses."
8.1.3.4. Testing Recursive Queries 8.1.3.4. Testing Recursive Queries
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with only the RD DNS flag bit set and without EDNS. with only the RD DNS flag bit set and without EDNS.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA, QR and RD bits section, the rcode to be set to NOERROR, and the AA, QR and RD bits
to be set in the header; RA may also be set [RFC1034]. We do not to be set in the header; RA may also be set [RFC1034]. We do not
expect an OPT record to be returned [RFC6891]. expect an OPT record to be returned [RFC6891].
skipping to change at page 15, line 29 skipping to change at line 684
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to be present expect: flag: rd to be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
8.1.4. Testing Unknown Opcodes 8.1.4. Testing Unknown Opcodes
Construct a DNS message that consists of only a DNS header with Construct a DNS message that consists of only a DNS header with
opcode set to 15 (currently not allocated), no DNS header bits set opcode set to 15 (currently not allocated), no DNS header bits set,
and empty question, answer, authority and additional sections. and empty question, answer, authority, and additional sections.
Check that new opcodes are handled: Check that new opcodes are handled:
dig +noedns +noad +opcode=15 +norec +header-only @$server dig +noedns +noad +opcode=15 +norec +header-only @$server
expect: status: NOTIMP expect: status: NOTIMP
expect: opcode: 15 expect: opcode: 15
expect: all sections to be empty expect: all sections to be empty
expect: flag: aa to NOT be present expect: flag: aa to NOT be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
skipping to change at page 16, line 27 skipping to change at line 729
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: rd to NOT be present expect: flag: rd to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
expect: the OPT record to NOT be present expect: the OPT record to NOT be present
The requirement that TCP be supported is defined in [RFC7766]. The requirement that TCP be supported is defined in [RFC7766].
8.2. Testing - Extended DNS 8.2. Testing: Extended DNS
The next set of tests cover various aspects of EDNS behaviour. If The next set of tests cover various aspects of EDNS behaviour. If
any of these tests succeed (indicating at least some EDNS support) any of these tests succeed (indicating at least some EDNS support),
then all of them should succeed. There are servers that support EDNS then all of them should succeed. There are servers that support EDNS
but fail to handle plain EDNS queries correctly so a plain EDNS query but fail to handle plain EDNS queries correctly, so a plain EDNS
is not a good indicator of lack of EDNS support. query is not a good indicator of lack of EDNS support.
8.2.1. Testing Minimal EDNS 8.2.1. Testing Minimal EDNS
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 0 is used without any EDNS with no DNS flag bits set. EDNS version 0 is used without any EDNS
options or EDNS flags set. options or EDNS flags set.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header; RA may also be set [RFC1034]. We expect an OPT set in the header; RA may also be set [RFC1034]. We expect an OPT
record to be returned. There should be no EDNS flags present in the record to be returned. There should be no EDNS flags present in the
response. The EDNS version field should be 0 and there should be no response. The EDNS version field should be 0, and there should be no
EDNS options present [RFC6891]. EDNS options present [RFC6891].
Check that plain EDNS queries work: Check that plain EDNS queries work:
dig +nocookie +edns=0 +noad +norec soa $zone @$server dig +nocookie +edns=0 +noad +norec soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
+nocookie disables sending a EDNS COOKIE option which is otherwise +nocookie disables sending an EDNS COOKIE option, which is otherwise
enabled by default in BIND 9.11.0 (and later). enabled by default in BIND 9.11.0 (and later).
8.2.2. Testing EDNS Version Negotiation 8.2.2. Testing EDNS Version Negotiation
Ask for the SOA record of a zone the server is nominally configured Ask for the SOA record of a zone the server is nominally configured
to serve. This query is made with no DNS flag bits set. EDNS to serve. This query is made with no DNS flag bits set. EDNS
version 1 is used without any EDNS options or EDNS flags set. version 1 is used without any EDNS options or EDNS flags set.
We expect the SOA record for the zone to NOT be returned in the We expect the SOA record for the zone to NOT be returned in the
answer section with the extended rcode set to BADVERS and the QR bit answer section with the extended rcode set to BADVERS and the QR bit
to be set in the header; RA may also be set [RFC1034]. We expect an to be set in the header; RA may also be set [RFC1034]. We expect an
OPT record to be returned. There should be no EDNS flags present in OPT record to be returned. There should be no EDNS flags present in
the response. The EDNS version field should be 0 in the response as the response. The EDNS version field should be 0 in the response, as
no other EDNS version has as yet been specified [RFC6891]. no other EDNS version has as yet been specified [RFC6891].
Check that EDNS version 1 queries work (EDNS supported): Check that EDNS version 1 queries work (EDNS supported):
dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server
expect: status: BADVERS expect: status: BADVERS
expect: the SOA record to NOT be present in the answer section expect: the SOA record to NOT be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to NOT be present expect: flag: aa to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
+noednsneg has been set as dig supports EDNS version negotiation and +noednsneg has been set, as dig supports EDNS version negotiation,
we want to see only the response to the initial EDNS version 1 query. and we want to see only the response to the initial EDNS version 1
query.
8.2.3. Testing Unknown EDNS Options 8.2.3. Testing Unknown EDNS Options
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 0 is used without any EDNS with no DNS flag bits set. EDNS version 0 is used without any EDNS
flags. An EDNS option is present with a value that has not yet been flags. An EDNS option is present with a value that has not yet been
assigned by IANA. We have picked an unassigned code of 100 for the assigned by IANA. We have picked an unassigned code of 100 for the
example below. Any unassigned EDNS option code could have been example below. Any unassigned EDNS option code could have been
choosen for this test. chosen for this test.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header; RA may also be set [RFC1034]. We expect an OPT set in the header; RA may also be set [RFC1034]. We expect an OPT
record to be returned. There should be no EDNS flags present in the record to be returned. There should be no EDNS flags present in the
response. The EDNS version field should be 0 as EDNS versions other response. The EDNS version field should be 0, as EDNS versions other
than 0 are yet to be specified and there should be no EDNS options than 0 are yet to be specified, and there should be no EDNS options
present as unknown EDNS options are supposed to be ignored by the present, as unknown EDNS options are supposed to be ignored by the
server [RFC6891] Section 6.1.2. server (Section 6.1.1 of [RFC6891]).
Check that EDNS queries with an unknown option work (EDNS supported): Check that EDNS queries with an unknown option work (EDNS supported):
dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: OPT=100 to NOT be present expect: OPT=100 to NOT be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
skipping to change at page 18, line 38 skipping to change at line 832
8.2.4. Testing Unknown EDNS Flags 8.2.4. Testing Unknown EDNS Flags
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 0 is used without any EDNS with no DNS flag bits set. EDNS version 0 is used without any EDNS
options. An unassigned EDNS flag bit is set (0x40 in this case). options. An unassigned EDNS flag bit is set (0x40 in this case).
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header; RA may also be set [RFC1034]. We expect an OPT set in the header; RA may also be set [RFC1034]. We expect an OPT
record to be returned. There should be no EDNS flags present in the record to be returned. There should be no EDNS flags present in the
response as unknown EDNS flags are supposed to be ignored. The EDNS response, as unknown EDNS flags are supposed to be ignored. The EDNS
version field should be 0 and there should be no EDNS options present version field should be 0, and there should be no EDNS options
[RFC6891]. present [RFC6891].
Check that EDNS queries with unknown flags work (EDNS supported): Check that EDNS queries with unknown flags work (EDNS supported):
dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: MBZ not to be present expect: MBZ not to be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
MBZ (Must Be Zero) is a dig-specific indication that a flag bit has MBZ (Must Be Zero) is a dig-specific indication that a flag bit has
been incorrectly copied as per Section 6.1.4, [RFC6891]. been incorrectly copied, as per Section 6.1.4 of [RFC6891].
8.2.5. Testing EDNS Version Negotiation With Unknown EDNS Flags 8.2.5. Testing EDNS Version Negotiation with Unknown EDNS Flags
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 1 is used without any EDNS with no DNS flag bits set. EDNS version 1 is used without any EDNS
options. An unassigned EDNS flag bit is set (0x40 in this case). options. An unassigned EDNS flag bit is set (0x40 in this case).
We expect the SOA record for the zone to NOT be returned in the We expect the SOA record for the zone to NOT be returned in the
answer section with the extended rcode set to BADVERS and the QR bit answer section with the extended rcode set to BADVERS and the QR bit
to be set in the header; RA may also be set [RFC1034]. We expect an to be set in the header; RA may also be set [RFC1034]. We expect an
OPT record to be returned. There should be no EDNS flags present in OPT record to be returned. There should be no EDNS flags present in
the response as unknown EDNS flags are supposed to be ignored. The the response, as unknown EDNS flags are supposed to be ignored. The
EDNS version field should be 0 as EDNS versions other than 0 are yet EDNS version field should be 0, as EDNS versions other than 0 are yet
to be specified and there should be no EDNS options present to be specified, and there should be no EDNS options present
[RFC6891]. [RFC6891].
Check that EDNS version 1 queries with unknown flags work (EDNS Check that EDNS version 1 queries with unknown flags work (EDNS
supported): supported):
dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \ dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \
$zone @$server $zone @$server
expect: status: BADVERS expect: status: BADVERS
expect: SOA record to NOT be present expect: SOA record to NOT be present
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: MBZ not to be present expect: MBZ not to be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to NOT be present expect: flag: aa to NOT be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
8.2.6. Testing EDNS Version Negotiation With Unknown EDNS Options 8.2.6. Testing EDNS Version Negotiation with Unknown EDNS Options
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 1 is used. An unknown EDNS with no DNS flag bits set. EDNS version 1 is used. An unknown EDNS
option is present. We have picked an unassigned code of 100 for the option is present. We have picked an unassigned code of 100 for the
example below. Any unassigned EDNS option code could have been example below. Any unassigned EDNS option code could have been
chosen for this test. chosen for this test.
We expect the SOA record for the zone to NOT be returned in the We expect the SOA record for the zone to NOT be returned in the
answer section with the extended rcode set to BADVERS and the QR bit answer section with the extended rcode set to BADVERS and the QR bit
to be set in the header; RA may also be set [RFC1034]. We expect an to be set in the header; RA may also be set [RFC1034]. We expect an
OPT record to be returned. There should be no EDNS flags present in OPT record to be returned. There should be no EDNS flags present in
the response. The EDNS version field should be 0 as EDNS versions the response. The EDNS version field should be 0, as EDNS versions
other than 0 are yet to be specified and there should be no EDNS other than 0 are yet to be specified, and there should be no EDNS
options present [RFC6891]. options present [RFC6891].
Check that EDNS version 1 queries with unknown options work (EDNS Check that EDNS version 1 queries with unknown options work (EDNS
supported): supported):
dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \ dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \
$zone @$server $zone @$server
expect: status: BADVERS expect: status: BADVERS
expect: SOA record to NOT be present expect: SOA record to NOT be present
skipping to change at page 20, line 46 skipping to change at line 921
Ask for the DNSKEY records of the configured zone, which must be a Ask for the DNSKEY records of the configured zone, which must be a
DNSSEC signed zone. This query is made with no DNS flag bits set. DNSSEC signed zone. This query is made with no DNS flag bits set.
EDNS version 0 is used without any EDNS options. The only EDNS flag EDNS version 0 is used without any EDNS options. The only EDNS flag
set is DO. The EDNS UDP buffer size is set to 512. The intention of set is DO. The EDNS UDP buffer size is set to 512. The intention of
this query is to elicit a truncated response from the server. Most this query is to elicit a truncated response from the server. Most
signed DNSKEY responses are bigger than 512 bytes. This test will signed DNSKEY responses are bigger than 512 bytes. This test will
not give a valid result if the zone is not signed. not give a valid result if the zone is not signed.
We expect a response, the rcode to be set to NOERROR, and the AA and We expect a response, the rcode to be set to NOERROR, and the AA and
QR bits to be set, AD may be set in the response if the server QR bits to be set. AD may be set in the response if the server
supports DNSSEC otherwise it should be clear; TC and RA may also be supports DNSSEC; otherwise it should be clear; TC and RA may also be
set [RFC1035] [RFC4035]. We expect an OPT record to be present in set [RFC1035] [RFC4035]. We expect an OPT record to be present in
the response. There should be no EDNS flags other than DO present in the response. There should be no EDNS flags other than DO present in
the response. The EDNS version field should be 0 and there should be the response. The EDNS version field should be 0, and there should
no EDNS options present [RFC6891]. be no EDNS options present [RFC6891].
If TC is not set it is not possible to confirm that the server If TC is not set, it is not possible to confirm that the server
correctly adds the OPT record to the truncated responses or not. correctly adds the OPT record to the truncated responses or not.
dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server
expect: NOERROR expect: NOERROR
expect: OPT record with version set to 0 expect: OPT record with version set to 0
8.2.8. Testing DO=1 Handling 8.2.8. Testing DO=1 Handling
Ask for the SOA record of the configured zone, which does not need to Ask for the SOA record of the configured zone, which does not need to
be DNSSEC signed. This query is made with no DNS flag bits set. be DNSSEC signed. This query is made with no DNS flag bits set.
EDNS version 0 is used without any EDNS options. The only EDNS flag EDNS version 0 is used without any EDNS options. The only EDNS flag
set is DO. set is DO.
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the response, AD may be set in the response if the server set in the response. AD may be set in the response if the server
supports DNSSEC otherwise it should be clear; RA may also be set supports DNSSEC, otherwise it should be clear; RA may also be set
[RFC1034]. We expect an OPT record to be returned. There should be [RFC1034]. We expect an OPT record to be returned. There should be
no EDNS flags other than DO present in the response which should be no EDNS flags other than DO present in the response, which should be
present if the server supports DNSSEC. The EDNS version field should present if the server supports DNSSEC. The EDNS version field should
be 0 and there should be no EDNS options present [RFC6891]. be 0, and there should be no EDNS options present [RFC6891].
Check that DO=1 queries work (EDNS supported): Check that DO=1 queries work (EDNS supported):
dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: DO=1 to be present if an RRSIG is in the response expect: DO=1 to be present if an RRSIG is in the response
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to be present expect: flag: aa to be present
8.2.9. Testing EDNS Version Negotiation With DO=1 8.2.9. Testing EDNS Version Negotiation with DO=1
Ask for the SOA record of the configured zone, which does not need to Ask for the SOA record of the configured zone, which does not need to
be DNSSEC signed. This query is made with no DNS flag bits set. be DNSSEC signed. This query is made with no DNS flag bits set.
EDNS version 1 is used without any EDNS options. The only EDNS flag EDNS version 1 is used without any EDNS options. The only EDNS flag
set is DO. set is DO.
We expect the SOA record for the zone to NOT be returned in the We expect the SOA record for the zone NOT to be returned in the
answer section, the rcode to be set to NOERROR, ; the QR bit and answer section, the extended rcode to be set to BADVERS, and the QR
possibly the RA bit to be set [RFC1034]. We expect an OPT record to bit to be set in the header; RA may also be set [RFC1034]. We expect
be returned. There should be no EDNS flags other than DO present in an OPT record to be returned. There should be no EDNS flags other
the response which should be there if the server supports DNSSEC. than DO present in the response, which should be there if the server
The EDNS version field should be 0 and there should be no EDNS supports DNSSEC. The EDNS version field should be 0, and there
options present [RFC6891]. should be no EDNS options present [RFC6891].
Check that EDNS version 1, DO=1 queries work (EDNS supported): Check that EDNS version 1, DO=1 queries work (EDNS supported):
dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \ dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \
$zone @$server $zone @$server
expect: status: BADVERS expect: status: BADVERS
expect: SOA record to NOT be present expect: SOA record to NOT be present
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: DO=1 to be present if the EDNS version 0 DNSSEC query test expect: DO=1 to be present if the EDNS version 0 DNSSEC query test
returned DO=1 returned DO=1
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to NOT be present expect: flag: aa to NOT be present
8.2.10. Testing With Multiple Defined EDNS Options 8.2.10. Testing with Multiple Defined EDNS Options
Ask for the SOA record of the configured zone. This query is made Ask for the SOA record of the configured zone. This query is made
with no DNS flag bits set. EDNS version 0 is used. A number of with no DNS flag bits set. EDNS version 0 is used. A number of
defined EDNS options are present (NSID [RFC5001], DNS COOKIE defined EDNS options are present (NSID [RFC5001], DNS COOKIE
[RFC7873], EDNS Client Subnet [RFC7871] and EDNS Expire [RFC7314]). [RFC7873], EDNS Client Subnet [RFC7871], and EDNS Expire [RFC7314]).
We expect the SOA record for the zone to be returned in the answer We expect the SOA record for the zone to be returned in the answer
section, the rcode to be set to NOERROR, and the AA and QR bits to be section, the rcode to be set to NOERROR, and the AA and QR bits to be
set in the header; RA may also be set [RFC1034]. We expect an OPT set in the header; RA may also be set [RFC1034]. We expect an OPT
record to be returned. There should be no EDNS flags present in the record to be returned. There should be no EDNS flags present in the
response. The EDNS version field should be 0. Any of the requested response. The EDNS version field should be 0. Any of the requested
EDNS options supported by the server and permitted server EDNS options supported by the server and permitted server
configuration may be returned [RFC6891]. configuration may be returned [RFC6891].
Check that EDNS queries with multiple defined EDNS options work: Check that EDNS queries with multiple defined EDNS options work:
skipping to change at page 22, line 49 skipping to change at line 1021
expect: the SOA record to be present in the answer section expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
expect: flag: aa to be present expect: flag: aa to be present
expect: flag: ad to NOT be present expect: flag: ad to NOT be present
8.3. When EDNS Is Not Supported 8.3. When EDNS Is Not Supported
If EDNS is not supported by the nameserver, we expect a response to If EDNS is not supported by the nameserver, we expect a response to
each of the above queries. That response may be a FORMERR error each of the above queries. That response may be a FORMERR error
response or the OPT record may just be ignored. response, or the OPT record may just be ignored.
Some nameservers only return a EDNS response when a particular EDNS Some nameservers only return an EDNS response when a particular EDNS
option or flag (e.g. DO=1) is present in the request. This option or flag (e.g., DO=1) is present in the request. This
behaviour is not compliant behaviour and may hide other incorrect behaviour is not compliant behaviour and may hide other incorrect
behaviour from the above tests. Re-testing with the triggering behaviour from the above tests. Retesting with the triggering
option / flag present will expose this misbehaviour. option/flag present will expose this misbehaviour.
9. Remediation 9. Remediation
Nameserver operators are generally expected to test their own Nameserver operators are generally expected to test their own
infrastructure for compliance to standards. The above tests should infrastructure for compliance to standards. The above tests should
be run when new systems are brought online, and should be repeated be run when new systems are brought online and should be repeated
periodically to ensure continued interoperability. periodically to ensure continued interoperability.
Domain registrants who do not maintain their own DNS infrastructure Domain registrants who do not maintain their own DNS infrastructure
are entitled to a DNS service that conforms to standards and are entitled to a DNS service that conforms to standards and
interoperates well. Registrants who become aware that their DNS interoperates well. Registrants who become aware that their DNS
operator does not have a well maintained or compliant infrastructure operator does not have a well-maintained or compliant infrastructure
should insist that their service provider correct issues, and switch should insist that their service provider correct issues and switch
providers if they do not. providers if they do not.
In the event that an operator experiences problems due to the In the event that an operator experiences problems due to the
behaviour of nameservers outside their control, the above tests will behaviour of nameservers outside their control, the above tests will
help in narrowing down the precise issue(s) which can then be help in narrowing down the precise issue(s), which can then be
reported to the relevant party. reported to the relevant party.
If contact information for the operator of a misbehaving nameserver If contact information for the operator of a misbehaving nameserver
is not already known, the following methods of communication could be is not already known, the following methods of communication could be
considered: considered:
o the RNAME of the zone authoritative for the name of the * the RNAME of the zone authoritative for the name of the
misbehaving server misbehaving server
o the RNAME of zones for which the offending server is authoritative * the RNAME of zones for which the offending server is authoritative
o administrative or technical contacts listed in the registration * administrative or technical contacts listed in the registration
information for the parent domain of the name of the misbehaving information for the parent domain of the name of the misbehaving
server, or for zones for which the nameserver is authoritative server or for zones for which the nameserver is authoritative
o the registrar or registry for such zones * the registrar or registry for such zones
o DNS-specific operational fora (e.g. mailing lists) * DNS-specific, operational fora (e.g., mailing lists)
Operators of parent zones may wish to regularly test the Operators of parent zones may wish to regularly test the
authoritative nameservers of their child zones. However, parent authoritative nameservers of their child zones. However, parent
operators can have widely varying capabilities in terms of operators can have widely varying capabilities in terms of
notification or remediation depending on whether they have a direct notification or remediation depending on whether they have a direct
relationship with the child operator. Many TLD registries, for relationship with the child operator. Many Top-Level Domain (TLD)
example, cannot directly contact their registrants and may instead registries, for example, cannot directly contact their registrants
need to communicate through the relevant registrar. In such cases and may instead need to communicate through the relevant registrar.
it may be most efficient for registrars to take on the responsibility In such cases, it may be most efficient for registrars to take on the
for testing the name ervers of their registrants, since they have a responsibility for testing the nameservers of their registrants,
direct relationship. since they have a direct relationship.
When notification is not effective at correcting problems with a When notification is not effective at correcting problems with a
misbehaving nameserver, parent operators can choose to remove NS misbehaving nameserver, parent operators can choose to remove NS
record sets (and glue records below) that refer to the faulty server record sets (and glue records below) that refer to the faulty server
until the servers are fixed. This should only be done as a last until the servers are fixed. This should only be done as a last
resort and with due consideration, as removal of a delegation can resort and with due consideration, as removal of a delegation can
have unanticipated side effects. For example, other parts of the DNS have unanticipated side effects. For example, other parts of the DNS
tree may depend on names below the removed zone cut, and the parent tree may depend on names below the removed zone cut, and the parent
operator may find themselves responsible for causing new DNS failures operator may find themselves responsible for causing new DNS failures
to occur. to occur.
skipping to change at page 24, line 30 skipping to change at line 1099
of attempts to attack services from Intrusion Detection Services and of attempts to attack services from Intrusion Detection Services and
firewalls. All of the tests are well-formed (though not necessarily firewalls. All of the tests are well-formed (though not necessarily
common) DNS queries. None of the tests listed above should cause any common) DNS queries. None of the tests listed above should cause any
harm to a protocol-compliant server. harm to a protocol-compliant server.
Relaxing firewall settings to ensure EDNS compliance could Relaxing firewall settings to ensure EDNS compliance could
potentially expose a critical implementation flaw in the nameserver. potentially expose a critical implementation flaw in the nameserver.
Nameservers should be tested for conformance before relaxing firewall Nameservers should be tested for conformance before relaxing firewall
settings. settings.
When removing delegations for non-compliant servers there can be a When removing delegations for non-compliant servers, there can be a
knock on effect on other zones that require these zones to be knock-on effect on other zones that require these zones to be
operational for the nameservers addresses to be resolved. operational for the nameservers addresses to be resolved.
11. IANA Considerations 11. IANA Considerations
There are no actions for IANA. This document has no IANA actions.
12. Acknowledgements
The contributions of the following are gratefully acknowledged:
Matthew Pounsett, Tim Wicinski.
13. References 12. References
13.1. Normative References 12.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc1034>. <https://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, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
skipping to change at page 25, line 37 skipping to change at line 1147
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
13.2. Informative References 12.2. Informative References
[IANA-DNS] IANA, "Domain Name System (DNS) Parameters",
<https://www.iana.org/assignments/dns-parameters/>.
[ISC] "Internet Systems Consortuim", <https://www.isc.org/>. [ISC] "Internet Systems Consortuim", <https://www.isc.org/>.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, DOI 10.17487/RFC2671, August 1999, RFC 2671, DOI 10.17487/RFC2671, August 1999,
<https://www.rfc-editor.org/info/rfc2671>. <https://www.rfc-editor.org/info/rfc2671>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>. 2003, <https://www.rfc-editor.org/info/rfc3597>.
skipping to change at page 26, line 18 skipping to change at line 1179
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871, Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>. <https://www.rfc-editor.org/info/rfc7871>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
Acknowledgements
The contributions of Matthew Pounsett and Tim Wicinski are gratefully
acknowledged.
Authors' Addresses Authors' Addresses
M. Andrews M. Andrews
Internet Systems Consortium Internet Systems Consortium
PO Box 360 PO Box 360
Newmarket, NH 03857 Newmarket, NH 03857
US United States of America
Email: marka@isc.org Email: marka@isc.org
Ray Bellis Ray Bellis
Internet Systems Consortium Internet Systems Consortium
PO Box 360 PO Box 360
Newmarket, NH 03857 Newmarket, NH 03857
US United States of America
Email: ray@isc.org Email: ray@isc.org
 End of changes. 127 change blocks. 
282 lines changed or deleted 286 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/