--- 1/draft-ietf-dnsop-no-response-issue-21.txt 2020-04-14 16:13:14.552208905 -0700 +++ 2/draft-ietf-dnsop-no-response-issue-22.txt 2020-04-14 16:13:14.680212140 -0700 @@ -1,18 +1,18 @@ Network Working Group M. Andrews Internet-Draft R. Bellis 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 - draft-ietf-dnsop-no-response-issue-21 + draft-ietf-dnsop-no-response-issue-22 Abstract The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to @@ -29,21 +29,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -178,27 +178,27 @@ o The AD (Authenticated Data) bit in a response cannot be trusted to mean anything as some servers incorrectly copy the flag bit from the request to the response [RFC1035], [RFC4035]. The use of the AD bit in requests is defined in [RFC6840]. o Widespread non-response to EDNS queries has led to recursive servers having to assume that EDNS is not supported and that fallback to plain DNS is required, potentially causing DNSSEC validation failures. - o Widespread non-response to EDNS options, requires recursive - servers to have 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 response. In the limited amount of time required to - resolve a query before the client times out this is not possible. + o Widespread non-response to EDNS options requires recursive servers + 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 + response. In the limited amount of time required to resolve a + 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 server is just broken in the handling of the EDNS option or doesn't support EDNS at all. o Mishandling of unknown query types has contributed to the abandonment of the transition of the SPF type. o Mishandling of unknown query types has slowed up the development of DANE and resulted in additional rules being specified to reduce the probability of interacting with a broken server when making @@ -229,22 +229,22 @@ 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 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 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 - type: either NOERROR, or NXDOMAIN. The exception to this are queries - for Meta-RR types which may return NOTIMP. + type: either NOERROR, or NXDOMAIN. The exceptions to this are + queries for Meta-RR types which may return NOTIMP. 3.1.3. 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 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 last reserved flag set. Servers should respond to such queries. If the server does not know @@ -266,22 +266,22 @@ NOTIMP is the expected rcode to an unknown or unimplemented opcode. Note: while new opcodes will most probably use the current layout structure for the rest of the message there is no requirement that anything other than the DNS header match. 3.1.5. TCP Queries All DNS servers are supposed to respond to queries over TCP - [RFC7766]. While firewalls should not block TCP connection attempts - if they do they should cleanly terminate the connection by sending + [RFC7766]. While firewalls should not block TCP connection attempts, + those that do they should cleanly terminate the connection by sending TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited messages. Dropping TCP connections introduces excessive delays to the resolution process. 3.2. EDNS Queries EDNS queries are specified in [RFC6891]. 3.2.1. EDNS Queries - Version Independent @@ -478,21 +478,21 @@ error code. That said a minimal EDNS server implementation requires parsing the OPT records and responding with an empty OPT record in the additional section in most cases. There is no need to interpret any EDNS options present in the request as unsupported EDNS options are expected to be ignored [RFC6891]. Additionally EDNS flags can be 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. 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 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 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 is nominally configured to serve. All tests should use the same zone. @@ -1061,21 +1061,21 @@ o DNS-specific operational fora (e.g. mailing lists) Operators of parent zones may wish to regularly test the authoritative name servers of their child zones. However, parent operators can have widely varying capabilities in terms of notification or remediation depending on whether they have a direct relationship with the child operator. Many TLD registries, for example, cannot directly contact their registrants and may instead need to communicate through the relevant registrar. In such cases 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. When notification is not effective at correcting problems with a misbehaving name server, parent operators can choose to remove NS 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 resort and with due consideration, as removal of a delegation can have unanticipated side effects. For example, other parts of the DNS tree may depend on names below the removed zone cut, and the parent operator may find themselves responsible for causing new DNS failures