draft-ietf-dnsop-no-response-issue-14.txt   draft-ietf-dnsop-no-response-issue-15.txt 
Network Working Group M. Andrews Network Working Group M. Andrews
Internet-Draft R. Bellis Internet-Draft R. Bellis
Intended status: Best Current Practice ISC Intended status: Best Current Practice ISC
Expires: May 7, 2020 November 4, 2019 Expires: September 9, 2020 March 8, 2020
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-14 draft-ietf-dnsop-no-response-issue-15
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, or responding incorrectly, causes both immediate operational queries, or responding incorrectly, causes both immediate operational
problems and long term problems with protocol development. problems 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 else respond incorrectly.
This document also suggests procedures for zone operators to apply to This document also suggests procedures for zone operators to apply to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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]. Doing this regularly should reduce the they are not [RFC1034]. Doing this regularly should reduce the
instances of broken delegations. 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 a 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 relevant DNS RFCs has multiple adverse
consequences. Some are caused directly from the non-compliant consequences. Some are caused directly from the non-compliant
behaviour and others as a result of work-arounds forced on recursive behaviour and others as a result of work-arounds 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 the
base DNS specification [RFC1034], [RFC1035] and the EDNS base DNS specification [RFC1034], [RFC1035] and the EDNS
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 o Widespread non-response to EDNS options, requires recursive
servers to have to decide whether to probe to see if it is the servers to have to decide whether to probe to see if it is the
EDNS option or just EDNS that is causing the non response. In the EDNS option or just EDNS that is causing the non response. In the
limited amount of time required to resolve a query before the limited amount of time required to resolve a query before the
client times out this is not possible. client times out this is not possible.
o Incorrectly returning FORMERR to a EDNS option being present, o 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
doesn't support EDNS at all. doesn't support EDNS at all.
o Mishandling of unknown query types has contributed to the o 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 o Mishandling of unknown query types has slowed up the development
of DANE and resulted in additional rules being specified to reduce of DANE and resulted in additional rules being specified to reduce
the probability of interacting with a broken server when making the probability of interacting with a broken server when making
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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
Initially, to test existence of the zone, an SOA query should be If a zone is delegated to a server, that server should respond to an
made. If the SOA record is not returned but some other response is SOA query for that zone with an SOA record. Failing to respond at
returned, this is an indication of a bad delegation. all is always incorrect, regardless of the configuration of the
server. Responding with anything other than an SOA record in the
Answer section indicates a bad delegation.
3.1.2. Unknown / Unsupported Type Queries 3.1.2. Unknown / Unsupported Type Queries
Identifying servers that fail to respond to unknown or unsupported Some servers fail to respond to unknown or unsupported types. If a
types can be done by making an initial DNS query for an A record, server receives a query for a type that it doesn't recognize, or
making a number of queries for an unallocated type, then making a doesn't implement, it is expected to return the appropriate response
query for an A record again. IANA maintains a registry of allocated as if it did recognize the type but does not have any data for that
types. type: either NOERROR, or NXDOMAIN. The exception to this are queries
for Meta-RR types which may return NOTIMP.
If the server responds to the first and last queries but fails to
respond to the queries for the unallocated type, it is probably
faulty. The test should be repeated a number of times to eliminate
the likelihood of a false positive due to packet loss.
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 queries
with the AD bit set to 1 and servers that fail to respond to queries with the AD bit set to 1 and servers that fail to respond to queries
with the last reserved flag bit set. with the last reserved flag bit set.
3.1.3.1. Recursive Queries 3.1.3.1. Recursive Queries
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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. from the nameserver vendor.
5. Scrubbing Services 5. Scrubbing Services
Scrubbing services can affect the externally visible behaviour of a Scrubbing services can affect the externally visible behaviour of a
nameserver in a similar way to firewalls. If a operator uses a nameserver in a similar way to firewalls. If an operator uses a
scrubbing service, they should check that legitimate queries are not scrubbing service, they should check that legitimate queries are not
being blocked. being blocked.
Scrubbing services, unlike firewalls, are also turned on and off in Scrubbing services, unlike firewalls, are also turned on and off in
response to denial of service attacks. One needs to take care when response to denial of service attacks. One needs to take care when
choosing a scrubbing service. choosing a scrubbing service.
Ideally, Operators should run these tests against a scrubbing service Ideally, Operators should run these tests against a scrubbing service
to ensure that these tests are not seen as attack vectors. to ensure that these tests are not seen as attack vectors.
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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
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
query for an A record again. IANA maintains a registry of allocated
types.
If the server responds to the first and last queries but fails to
respond to the queries for the unallocated type, it is probably
faulty. The test should be repeated a number of times to eliminate
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 with the We expect no records to be returned in the answer section with the
rcode set to NOERROR and the AA and QR bits to be set in the rcode set to NOERROR and the AA and QR bits to be set in the
response; RA may also be set [RFC1034]. We do not expect an OPT response; RA may also be set [RFC1034]. We do not expect an OPT
skipping to change at page 17, line 26 skipping to change at page 17, line 26
+noednsneg has been set as dig supports EDNS version negotiation and +noednsneg has been set as dig supports EDNS version negotiation and
we want to see only the response to the initial EDNS version 1 query. 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
choose for this test. choosen 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 with the rcode set to NOERROR and the AA and QR bits to be section with the rcode set to NOERROR and the AA and QR bits to be
set in the response; RA may also be set [RFC1034]. We expect an OPT set in the response; 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 [RFC6891] Section 6.1.2.
skipping to change at page 21, line 12 skipping to change at page 21, line 12
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 a 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.
 End of changes. 12 change blocks. 
22 lines changed or deleted 31 lines changed or added

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