A Common Operational Problem in DNS Servers: Failure to Communicate
RFC 8906
Document | Type |
RFC - Best Current Practice
(September 2020; No errata)
Also known as BCP 231
|
|
---|---|---|---|
Authors | Mark Andrews , Ray Bellis | ||
Last updated | 2020-09-22 | ||
Replaces | draft-andrews-dns-no-response-issue | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Tim Wicinski | ||
Shepherd write-up | Show (last changed 2019-11-17) | ||
IESG | IESG state | RFC 8906 (Best Current Practice) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Warren Kumari | ||
Send notices to | "Tim Wicinski" <tjw.ietf@gmail.com> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) M. Andrews Request for Comments: 8906 R. Bellis BCP: 231 ISC Category: Best Current Practice September 2020 ISSN: 2070-1721 A Common Operational Problem in DNS Servers: Failure to Communicate 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 respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. The document does not look at the DNS data itself, just the structure of the responses. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. 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 (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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Consequences 3. Common Kinds of Queries That Result in No or Bad Responses 3.1. Basic DNS Queries 3.1.1. Zone Existence 3.1.2. Unknown/Unsupported Type Queries 3.1.3. DNS Flags 3.1.4. Unknown DNS Opcodes 3.1.5. TCP Queries 3.2. EDNS Queries 3.2.1. EDNS Queries: Version Independent 3.2.2. EDNS Queries: Version Specific 3.2.3. EDNS Options 3.2.4. EDNS Flags 3.2.5. Truncated EDNS Responses 3.2.6. DO=1 Handling 3.2.7. EDNS over TCP 4. Firewalls and Load Balancers 5. Packet Scrubbing Services 6. Whole Answer Caches 7. Response Code Selection 8. Testing 8.1. Testing: Basic DNS 8.1.1. Is the server configured for the zone? 8.1.2. Testing Unknown Types 8.1.3. Testing Header Bits 8.1.4. Testing Unknown Opcodes 8.1.5. Testing TCP 8.2. Testing: Extended DNS 8.2.1. Testing Minimal EDNS 8.2.2. Testing EDNS Version Negotiation 8.2.3. Testing Unknown EDNS Options 8.2.4. Testing Unknown EDNS Flags 8.2.5. Testing EDNS Version Negotiation with Unknown EDNS Flags 8.2.6. Testing EDNS Version Negotiation with Unknown EDNS Options 8.2.7. Testing Truncated Responses 8.2.8. Testing DO=1 Handling 8.2.9. Testing EDNS Version Negotiation with DO=1 8.2.10. Testing with Multiple Defined EDNS Options 8.3. When EDNS Is Not Supported 9. Remediation 10. Security Considerations 11. IANA Considerations 12. References 12.1. Normative References 12.2. Informative References Acknowledgements Authors' Addresses 1. Introduction The DNS [RFC1034] [RFC1035] 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. Failure to respond to a query is indistinguishable from packet loss without doing an analysis of query-response patterns. Additionally, failure to respond results in unnecessary queries being made by DNS clients and introduces delays to the resolution process. Due to the inability to distinguish between packet loss and nameservers or middleboxes dropping Extension Mechanisms for DNS (EDNS) [RFC6891] queries, packet loss is sometimes misclassified as lack of EDNS support, which can lead to DNSSEC validation failures. The existence of servers that fail to respond to queries results in developers being hesitant to deploy new standards. Such servers need to be identified and remediated. The DNS has response codes that cover almost any conceivable queryShow full document text