draft-ietf-dnsop-no-response-issue-19.txt   draft-ietf-dnsop-no-response-issue-20.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 7, 2020 April 5, 2020 Expires: October 9, 2020 April 7, 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-19 draft-ietf-dnsop-no-response-issue-20
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 7, 2020. This Internet-Draft will expire on October 9, 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 2, line 36 skipping to change at page 2, line 36
3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7 3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7
3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8 3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8
3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8 3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8
3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8 3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8
4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8 4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8
5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9 5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9
6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10
7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10 7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10
8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11 8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11
8.1.1. Is The Server Configured For The Zone? . . . . . . . 11 8.1.1. Is The Server Configured For The Zone? . . . . . . . 12
8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12 8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12
8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13 8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13
8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15 8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15
8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15 8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15
8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16 8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16
8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16
8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17
8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17
8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18
8.2.5. Testing EDNS Version Negotiation With Unknown EDNS 8.2.5. Testing EDNS Version Negotiation With Unknown EDNS
skipping to change at page 4, line 18 skipping to change at page 4, line 18
servers which fail to respond to well-formed queries drops to near servers which fail to respond to well-formed queries 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]. Doing this regularly should reduce the they are not [RFC1034], Section 4.4.2, Paragraph 3. Doing this
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 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
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:
o The AD flag bit in a response cannot be trusted to mean anything o The AD flag bit in a response cannot be trusted to mean anything
as some servers incorrectly copy the flag bit from the request to as some servers incorrectly copy the flag bit from the request to
the response [RFC1035], [RFC4035]. the response [RFC1035], [RFC4035]. The use of the AD flag bit in
requests is defined in [RFC6840].
o Widespread non-response to EDNS queries has lead to recursive o Widespread non-response to EDNS queries has lead 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 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
skipping to change at page 8, line 23 skipping to change at page 8, line 23
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 DO
bit [RFC3225] is 1 in the query. Servers that support EDNS should bit [RFC3225] is 1 in the query. Servers that support EDNS should
always respond to EDNS requests with EDNS responses. 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. queries with DO=1. Nameservers that support DNSSEC are expected to
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.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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. from the nameserver vendor. Returning FORMERR or REFUSED are two
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
skipping to change at page 11, line 20 skipping to change at page 11, line 23
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. EDNS it should still respond to all the tests, albeit with error
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.
 End of changes. 9 change blocks. 
10 lines changed or deleted 14 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/