draft-ietf-dnsop-no-response-issue-21.txt   draft-ietf-dnsop-no-response-issue-22.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: October 15, 2020 April 13, 2020 Expires: October 16, 2020 April 14, 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-21 draft-ietf-dnsop-no-response-issue-22
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 October 15, 2020. This Internet-Draft will expire on October 16, 2020.
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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
o The AD (Authenticated Data) bit in a response cannot be trusted to o 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 o 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 o Widespread non-response to EDNS options requires recursive servers
servers to have to decide whether to probe to see if it is the to decide whether to probe to see if it is the specific EDNS
specific EDNS option or the use of EDNS in general that is causing option or the use of EDNS in general that is causing the non
the non response. In the limited amount of time required to response. In the limited amount of time required to resolve a
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, 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 50 skipping to change at page 5, line 50
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 exception to this are queries type: either NOERROR, or NXDOMAIN. The exceptions to this are
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 queries
with the AD flag set to 1 and servers that fail to respond to queries with the AD flag set to 1 and servers that fail to respond to queries
with the last reserved flag set. 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 layout
structure for the rest of the message there is no requirement that structure for the rest of the message there is no requirement that
anything other than the DNS header match. 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,
if they do they should cleanly terminate the connection by sending those that do they should cleanly terminate the connection by sending
TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited
messages. Dropping TCP connections introduces excessive delays to messages. Dropping TCP connections introduces excessive delays to
the resolution process. the 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
skipping to change at page 11, line 19 skipping to change at page 11, line 19
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 be
ignored. The only part of the OPT record that needs to be examined ignored. The only part of the OPT record that needs to be examined
is the version field to determine if BADVERS needs to be sent or not. 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.
skipping to change at page 23, line 10 skipping to change at page 23, line 10
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 a 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. Re-testing with the triggering
option / flag present will expose this misbehaviour. option / flag present will expose this misbehaviour.
9. Remediation 9. Remediation
Name server 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 name servers 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 name server 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 o 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 o the RNAME of zones for which the offending server is authoritative
o administrative or technical contacts listed in the registration o 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 name server is authoritative server, or for zones for which the nameserver is authoritative
o the registrar or registry for such zones o the registrar or registry for such zones
o DNS-specific operational fora (e.g. mailing lists) o 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 name servers 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 TLD registries, for
example, cannot directly contact their registrants and may instead example, cannot directly contact their registrants and may instead
need to communicate through the relevant registrar. In such cases need to communicate through the relevant registrar. In such cases
it may be most efficient for registrars to take on the responsibility it may be most efficient for registrars to take on the responsibility
for testing the name servers of their registrants, since they have a for testing the name ervers of their registrants, since they have a
direct relationship. direct relationship.
When notification is not effective at correcting problems with a When notification is not effective at correcting problems with a
misbehaving name server, 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.
10. Security Considerations 10. Security Considerations
 End of changes. 15 change blocks. 
21 lines changed or deleted 21 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/