A Common Operational Problem in DNS Servers: Failure to Communicate
RFC 8906

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23



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 query