doc: Add RFC documents

1 files changed, 1205 insertions, 0 deletions

diff --git a/doc/rfc/rfc8906.txt b/doc/rfc/rfc8906.txt
new file mode 100644
index 0000000..6b8b311
--- /dev/null
+++ b/doc/rfc/rfc8906.txt
@@ -0,0 +1,1205 @@
+
+
+
+
+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
+   response.  A nameserver should be able to respond to any conceivable
+   query using them.  There should be no need to drop queries because a
+   nameserver does not understand them.
+
+   Unless a nameserver is under attack, it should respond to all DNS
+   requests directed to it.  When a nameserver is under attack, it may
+   wish to drop packets.  A common attack is to use a nameserver as an
+   amplifier by sending spoofed packets.  This is done because response
+   packets are bigger than the queries and large amplification factors
+   are available, especially if EDNS is supported.  Limiting the rate of
+   responses is reasonable when this is occurring, and the client should
+   retry.  However, this only works if legitimate clients are not being
+   forced to guess whether or not EDNS queries are accepted.  As long as
+   there is still a pool of servers that don't respond to EDNS requests,
+   clients have no way to know if the lack of response is due to packet
+   loss, EDNS packets not being supported, or rate limiting due to the
+   server being under attack.  Misclassification of server behaviour is
+   unavoidable when rate limiting is used until the population of
+   servers that fail to respond to well-formed queries drops to near
+   zero.
+
+   Nameservers should respond to queries even if the queried name is not
+   for any name the server is configured to answer for.  Misconfigured
+   nameservers are a common occurrence in the DNS, and receiving queries
+   for zones that the server is not configured for is not necessarily an
+   indication that the server is under attack.  Parent zone operators
+   are advised to regularly check that the delegating NS records are
+   consistent with those of the delegated zone and to correct them when
+   they are not (Section 4.2.2 of [RFC1034], Paragraph 3).  Doing this
+   regularly should reduce the instances of broken delegations.
+
+   This document does not try to identify all possible errors nor does
+   it supply an exhaustive list of tests.
+
+2.  Consequences
+
+   Failure to follow the guidance in relevant DNS RFCs has multiple
+   adverse consequences.  Some are caused directly by the non-compliant
+   behaviour and others as a result of workarounds forced on recursive
+   servers.  Addressing known issues now will reduce future
+   interoperability issues as the DNS protocol continues to evolve and
+   clients make use of newly introduced DNS features.  In particular,
+   the base DNS specification [RFC1034] [RFC1035] and the EDNS
+   specification [RFC6891], when implemented, need to be followed.
+
+   Some examples of known consequences include the following:
+
+   *  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].
+
+   *  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.
+
+   *  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.
+
+   *  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 if it
+      doesn't support EDNS at all.
+
+   *  Mishandling of unknown query types has contributed to the
+      abandonment of the transition of the SPF type.
+
+   *  Mishandling of unknown query types has slowed up the development
+      of DNS-Based Authentication of Named Entities (DANE) and resulted
+      in additional rules being specified to reduce the probability of
+      interacting with a broken server when making TLSA queries.
+
+   The consequences of servers not following the RFCs will only grow if
+   measures are not put in place to remove non-compliant servers from
+   the ecosystem.  Working around issues due to non-compliance with RFCs
+   is not sustainable.
+
+   Most (if not all) of these consequences could have been avoided if
+   action had been taken to remove non-compliant servers as soon as
+   people were aware of them, i.e., to actively seek out broken
+   implementations and servers and inform their developers and operators
+   that they need to fix their servers.
+
+3.  Common Kinds of Queries That Result in No or Bad Responses
+
+   This section is broken down into Basic DNS requests and EDNS
+   requests.
+
+3.1.  Basic DNS Queries
+
+3.1.1.  Zone Existence
+
+   If a zone is delegated to a server, that server should respond to a
+   SOA query for that zone with an SOA record.  Failing to respond at
+   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, i.e., 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
+   the meaning of a flag, it must not copy it to the response
+   (Section 4.1.1 of [RFC1035]).  If the server does not understand the
+   meaning of a request, it should reply with a FORMERR response with
+   unknown flags set to zero.
+
+3.1.3.1.  Recursive Queries
+
+   A non-recursive server is supposed to respond to recursive queries as
+   if the Recursion Desired (RD) bit is not set [RFC1034].
+
+3.1.4.  Unknown DNS Opcodes
+
+   The use of previously undefined opcodes is to be expected.  Since the
+   DNS was first defined, two new opcodes have been added, UPDATE and
+   NOTIFY.
+
+   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,
+   those that do 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
+
+   Identifying servers that fail to respond to EDNS queries can be done
+   by first confirming that the server responds to regular DNS queries,
+   followed by a series of otherwise identical queries using EDNS, then
+   making the original query again.  A series of EDNS queries is needed,
+   as at least one DNS implementation responds to the first EDNS query
+   with FORMERR but fails to respond to subsequent queries from the same
+   address for a period until a regular DNS query is made.  The EDNS
+   query should specify a UDP buffer size of 512 bytes to avoid false
+   classification of not supporting EDNS due to response packet size.
+
+   If the server responds to the first and last queries but fails to
+   respond to most or all of the EDNS queries, it is probably faulty.
+   The test should be repeated a number of times to eliminate the
+   likelihood of a false positive due to packet loss.
+
+   Firewalls may also block larger EDNS responses, but there is no easy
+   way to check authoritative servers to see if the firewall is
+   misconfigured.
+
+3.2.2.  EDNS Queries: Version Specific
+
+   Some servers respond correctly to EDNS version 0 queries but fail to
+   respond to EDNS queries with version numbers that are higher than
+   zero.  Servers should respond with BADVERS to EDNS queries with
+   version numbers that they do not support.
+
+   Some servers respond correctly to EDNS version 0 queries but fail to
+   set QR=1 when responding to EDNS versions they do not support.  Such
+   responses may be discarded as invalid (as QR is not 1) or treated as
+   requests (when the source port of the original request was port 53).
+
+3.2.3.  EDNS Options
+
+   Some servers fail to respond to EDNS queries with EDNS options set.
+   The original EDNS specification left this behaviour undefined
+   [RFC2671], but the correct behaviour was clarified in [RFC6891].
+   Unknown EDNS options are supposed to be ignored by the server.
+
+3.2.4.  EDNS Flags
+
+   Some servers fail to respond to EDNS queries with EDNS flags set.
+   Servers should ignore EDNS flags they do not understand and must not
+   add them to the response [RFC6891].
+
+3.2.5.  Truncated EDNS Responses
+
+   Some EDNS-aware servers fail to include an OPT record when a
+   truncated response is sent.  An OPT record is supposed to be included
+   in a truncated response [RFC6891].
+
+   Some EDNS-aware servers fail to honour the advertised EDNS UDP buffer
+   size and send oversized responses [RFC6891].  Servers must send UDP
+   responses no larger than the advertised EDNS UDP buffer size.
+
+3.2.6.  DO=1 Handling
+
+   Some nameservers incorrectly only return an EDNS response when the
+   DNSSEC OK (DO) bit [RFC3225] is 1 in the query.  Servers that support
+   EDNS should always respond to EDNS requests with EDNS responses.
+
+   Some nameservers fail to copy the DO bit to the response despite
+   clearly supporting DNSSEC by returning an RRSIG records to EDNS
+   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
+
+   Some EDNS-aware servers incorrectly limit the TCP response sizes to
+   the advertised UDP response size.  This breaks DNS resolution to
+   clients where the response sizes exceed the advertised UDP response
+   size despite the server and the client being capable of sending and
+   receiving larger TCP responses, respectively.  It effectively defeats
+   setting TC=1 in UDP responses.
+
+4.  Firewalls and Load Balancers
+
+   Firewalls and load balancers can affect the externally visible
+   behaviour of a nameserver.  Tests for conformance should to be done
+   from outside of any firewall so that the system is tested as a whole.
+
+   Firewalls and load balancers should not drop DNS packets that they
+   don't understand.  They should either pass the packets or generate an
+   appropriate error response.
+
+   Requests for unknown query types are normal client behaviour and
+   should not be construed as an attack.  Nameservers have always been
+   expected to be able to handle such queries.
+
+   Requests for unknown query classes are normal client behaviour and
+   should not be construed as an attack.  Nameservers have always been
+   expected to be able to handle such queries.
+
+   Requests with unknown opcodes are normal client behaviour and should
+   not be construed as an attack.  Nameservers have always been expected
+   to be able to handle such queries.
+
+   Requests with unassigned flags set (DNS or EDNS) are expected client
+   behaviour and should not be construed as an attack.  The behaviour
+   for unassigned flags is to ignore them in the request and to not set
+   them in the response.  Dropping DNS/EDNS packets with unassigned
+   flags makes it difficult to deploy extensions that make use of them
+   due to the need to reconfigure and update firewalls.
+
+   Requests with unknown EDNS options are expected client behaviour and
+   should not be construed as an attack.  The correct behaviour for
+   unknown EDNS options is to ignore their presence when constructing a
+   reply.
+
+   Requests with unknown EDNS versions are expected client behaviour and
+   should not be construed as an attack.  The correct behaviour for
+   unknown EDNS versions is to return BADVERS along with the highest
+   EDNS version the server supports.  Dropping EDNS packets breaks EDNS
+   version negotiation.
+
+   Firewalls should not assume that there will only be a single response
+   message to a request.  There have been proposals to use EDNS to
+   signal that multiple DNS messages be returned rather than a single
+   UDP message that is fragmented at the IP layer.
+
+   DNS, and EDNS in particular, are designed to allow clients to be able
+   to use new features against older servers without having to validate
+   every option.  Indiscriminate blocking of messages breaks that
+   design.
+
+   However, there may be times when a nameserver mishandles messages
+   with a particular flag, EDNS option, EDNS version field, opcode, type
+   or class field, or combination thereof to the point where the
+   integrity of the nameserver is compromised.  Firewalls should offer
+   the ability to selectively reject messages using an appropriately
+   constructed response based on all these fields while awaiting a fix
+   from the nameserver vendor.  Returning FORMERR or REFUSED are two
+   potential error codes to return.
+
+5.  Packet Scrubbing Services
+
+   Packet scrubbing services are used to filter out undesired traffic,
+   including but not limited to denial-of-service traffic.  This is
+   often done using heuristic analysis of the traffic.
+
+   Packet scrubbing services can affect the externally visible behaviour
+   of a nameserver in a similar way to firewalls.  If an operator uses a
+   packet scrubbing service, they should check that legitimate queries
+   are not being blocked.
+
+   Packet scrubbing services, unlike firewalls, are also turned on and
+   off in response to denial-of-service attacks.  One needs to take care
+   when choosing a scrubbing service.
+
+   Ideally, operators should run these tests against a packet scrubbing
+   service to ensure that these tests are not seen as attack vectors.
+
+6.  Whole Answer Caches
+
+   Whole answer caches take a previously constructed answer and return
+   it to a subsequent query for the same question.  However, they can
+   return the wrong response if they do not take all of the relevant
+   attributes of the query into account.
+
+   In addition to the standard tuple of <qname,qtype,qclass>, a non-
+   exhaustive set of attributes that must be considered include: RD, AD,
+   CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and
+   transport.
+
+7.  Response Code Selection
+
+   Choosing the correct response code when responding to DNS queries is
+   important.  Response codes should be chosen considering how clients
+   will handle them.
+
+   For unimplemented opcodes, NOTIMP is the expected response code.
+   Note: newly implemented opcodes may change the message format by
+   extending the header, changing the structure of the records, etc.
+   Servers are not expected to be able to parse these and should respond
+   with a response code of NOTIMP rather than FORMERR (which would be
+   expected if there was a parse error with a known opcode).
+
+   For unimplemented type codes, and in the absence of other errors, the
+   only valid response is NOERROR if the qname exists and NXDOMAIN
+   otherwise.  For Meta-RRs, NOTIMP may be returned instead.
+
+   If a zone cannot be loaded because it contains unimplemented type
+   codes that are not encoded as unknown record types according to
+   [RFC3597], then the expected response is SERVFAIL, as the whole zone
+   should be rejected (Section 5.2 of [RFC1035]).  If a zone loads, then
+   Section 4.3.2 of [RFC1034] applies.
+
+   If the server supports EDNS and receives a query with an unsupported
+   EDNS version, the correct response is BADVERS [RFC6891].
+
+   If the server does not support EDNS at all, FORMERR is the expected
+   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
+   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.
+
+   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
+   respond.  There are 16 queries directed to each nameserver (assuming
+   no packet loss) testing different aspects of Basic DNS and Extended
+   DNS.
+
+   The tests below use dig from BIND 9.11.0 [ISC].  Replace $zone with
+   the name of the zone being used for testing.  Replace $server with
+   the name or address of the server being tested.
+
+   When testing, recursive servers set RD=1 and choose a zone name that
+   is known to exist and is not being served by the recursive server.
+   The root zone (".") is often a good candidate, as it is DNSSEC
+   signed.  RD=1, rather than RD=0, should be present in the responses
+   for all test involving the opcode QUERY.  Non-authoritative answers
+   (AA=0) are expected when talking to a recursive server.  AD=1 is only
+   expected if the server is validating responses and one or both AD=1
+   or DO=1 is set in the request, otherwise AD=0 is expected.
+
+8.1.  Testing: Basic DNS
+
+   This first set of tests cover Basic DNS server behaviour and all
+   servers should pass these tests.
+
+8.1.1.  Is the server configured for the zone?
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set and without EDNS.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the Authoritative Answer
+   (AA) and Query/Response (QR) bits to be set in the header; the
+   Recursion Available (RA) bits may also be set [RFC1034].  We do not
+   expect an OPT record to be returned [RFC6891].
+
+   Verify the server is configured for the zone:
+
+   dig +noedns +noad +norec soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+8.1.2.  Testing Unknown Types
+
+   Identifying servers that fail to respond to unknown or unsupported
+   types can be done by making an initial DNS query for an A record,
+   making a number of queries for an unallocated type, then making a
+   query for an A record again.  IANA maintains a registry of allocated
+   types [IANA-DNS].
+
+   If the server responds to the first and last queries but fails to
+   respond to the queries for the unallocated type, it is probably
+   faulty.  The test should be repeated a number of times to eliminate
+   the likelihood of a false positive due to packet loss.
+
+   Ask for the TYPE1000 RRset at the configured zone's name.  This query
+   is made with no DNS flag bits set and without EDNS.  TYPE1000 has
+   been chosen for this purpose, as IANA is unlikely to allocate this
+   type in the near future and it is not in a range reserved for private
+   use [RFC6895].  Any unallocated type code could be chosen for this
+   test.
+
+   We expect no records to be returned in the answer section, the rcode
+   to be set to NOERROR, and the AA and QR bits to be set in the header;
+   RA may also be set [RFC1034].  We do not expect an OPT record to be
+   returned [RFC6891].
+
+   Check that queries for an unknown type work:
+
+   dig +noedns +noad +norec type1000 $zone @$server
+
+   expect: status: NOERROR
+   expect: an empty answer section.
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+8.1.3.  Testing Header Bits
+
+8.1.3.1.  Testing CD=1 Queries
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with only the CD DNS flag bit set, with all other DNS bits clear, and
+   without EDNS.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header.  We do not expect an OPT record to be returned.
+
+   If the server supports DNSSEC, CD should be set in the response
+   [RFC4035]; otherwise, CD should be clear [RFC1034].
+
+   Check that queries with CD=1 work:
+
+   dig +noedns +noad +norec +cd soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+8.1.3.2.  Testing AD=1 Queries
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with only the AD DNS flag bit set, with all other DNS bits clear, and
+   without EDNS.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header.  We do not expect an OPT record to be returned.
+   The purpose of this query is to detect blocking of queries with the
+   AD bit present, not the specific value of AD in the response.
+
+   Check that queries with AD=1 work:
+
+   dig +noedns +norec +ad soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: the OPT record to NOT be present
+
+   AD use in queries is defined in [RFC6840].
+
+8.1.3.3.  Testing Reserved Bit
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with only the final reserved DNS flag bit set, with all other DNS
+   bits clear, and without EDNS.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may be set.  The final reserved bit must not be
+   set [RFC1034].  We do not expect an OPT record to be returned
+   [RFC6891].
+
+   Check that queries with the last unassigned DNS header flag work and
+   that the flag bit is not copied to the response:
+
+   dig +noedns +noad +norec +zflag soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: MBZ to NOT be in the response (see below)
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+   MBZ (Must Be Zero) is a dig-specific indication that the flag bit has
+   been incorrectly copied.  See Section 4.1.1 of [RFC1035]:
+
+   "Z  Reserved for future use.  Must be zero in all queries and
+      responses."
+
+8.1.3.4.  Testing Recursive Queries
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with only the RD DNS flag bit set and without EDNS.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA, QR and RD bits
+   to be set in the header; RA may also be set [RFC1034].  We do not
+   expect an OPT record to be returned [RFC6891].
+
+   Check that recursive queries work:
+
+   dig +noedns +noad +rec soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: flag: aa to be present
+   expect: flag: rd to be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+8.1.4.  Testing Unknown Opcodes
+
+   Construct a DNS message that consists of only a DNS header with
+   opcode set to 15 (currently not allocated), no DNS header bits set,
+   and empty question, answer, authority, and additional sections.
+
+   Check that new opcodes are handled:
+
+   dig +noedns +noad +opcode=15 +norec +header-only @$server
+
+   expect: status: NOTIMP
+   expect: opcode: 15
+   expect: all sections to be empty
+   expect: flag: aa to NOT be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+8.1.5.  Testing TCP
+
+   Whether a server accepts TCP connections can be tested by first
+   checking that it responds to UDP queries to confirm that it is up and
+   operating, then attempting the same query over TCP.  An additional
+   query should be made over UDP if the TCP connection attempt fails to
+   confirm that the server under test is still operating.
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set and without EDNS.  This query is to be sent
+   using TCP.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may also be set [RFC1034].  We do not expect an
+   OPT record to be returned [RFC6891].
+
+   Check that TCP queries work:
+
+   dig +noedns +noad +norec +tcp soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: flag: aa to be present
+   expect: flag: rd to NOT be present
+   expect: flag: ad to NOT be present
+   expect: the OPT record to NOT be present
+
+   The requirement that TCP be supported is defined in [RFC7766].
+
+8.2.  Testing: Extended DNS
+
+   The next set of tests cover various aspects of EDNS behaviour.  If
+   any of these tests succeed (indicating at least some EDNS support),
+   then all of them should succeed.  There are servers that support EDNS
+   but fail to handle plain EDNS queries correctly, so a plain EDNS
+   query is not a good indicator of lack of EDNS support.
+
+8.2.1.  Testing Minimal EDNS
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 0 is used without any EDNS
+   options or EDNS flags set.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may also be set [RFC1034].  We expect an OPT
+   record to be returned.  There should be no EDNS flags present in the
+   response.  The EDNS version field should be 0, and there should be no
+   EDNS options present [RFC6891].
+
+   Check that plain EDNS queries work:
+
+   dig +nocookie +edns=0 +noad +norec soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: EDNS Version 0 in response
+   expect: flag: aa to be present
+   expect: flag: ad to NOT be present
+
+   +nocookie disables sending an EDNS COOKIE option, which is otherwise
+   enabled by default in BIND 9.11.0 (and later).
+
+8.2.2.  Testing EDNS Version Negotiation
+
+   Ask for the SOA record of a zone the server is nominally configured
+   to serve.  This query is made with no DNS flag bits set.  EDNS
+   version 1 is used without any EDNS options or EDNS flags set.
+
+   We expect the SOA record for the zone to NOT be returned in the
+   answer section with the extended rcode set to BADVERS and the QR bit
+   to be set in the header; RA may also be set [RFC1034].  We expect an
+   OPT record to be returned.  There should be no EDNS flags present in
+   the response.  The EDNS version field should be 0 in the response, as
+   no other EDNS version has as yet been specified [RFC6891].
+
+   Check that EDNS version 1 queries work (EDNS supported):
+
+   dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server
+
+   expect: status: BADVERS
+   expect: the SOA record to NOT be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: EDNS Version 0 in response
+   expect: flag: aa to NOT be present
+   expect: flag: ad to NOT be present
+
+   +noednsneg has been set, as dig supports EDNS version negotiation,
+   and we want to see only the response to the initial EDNS version 1
+   query.
+
+8.2.3.  Testing Unknown EDNS Options
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 0 is used without any EDNS
+   flags.  An EDNS option is present with a value that has not yet been
+   assigned by IANA.  We have picked an unassigned code of 100 for the
+   example below.  Any unassigned EDNS option code could have been
+   chosen for this test.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may also be set [RFC1034].  We expect an OPT
+   record to be returned.  There should be no EDNS flags present in the
+   response.  The EDNS version field should be 0, as EDNS versions other
+   than 0 are yet to be specified, and there should be no EDNS options
+   present, as unknown EDNS options are supposed to be ignored by the
+   server (Section 6.1.1 of [RFC6891]).
+
+   Check that EDNS queries with an unknown option work (EDNS supported):
+
+   dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: OPT=100 to NOT be present
+   expect: EDNS Version 0 in response
+   expect: flag: aa to be present
+   expect: flag: ad to NOT be present
+
+8.2.4.  Testing Unknown EDNS Flags
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 0 is used without any EDNS
+   options.  An unassigned EDNS flag bit is set (0x40 in this case).
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may also be set [RFC1034].  We expect an OPT
+   record to be returned.  There should be no EDNS flags present in the
+   response, as unknown EDNS flags are supposed to be ignored.  The EDNS
+   version field should be 0, and there should be no EDNS options
+   present [RFC6891].
+
+   Check that EDNS queries with unknown flags work (EDNS supported):
+
+   dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: MBZ not to be present
+   expect: EDNS Version 0 in response
+   expect: flag: aa to be present
+   expect: flag: ad to NOT be present
+
+   MBZ (Must Be Zero) is a dig-specific indication that a flag bit has
+   been incorrectly copied, as per Section 6.1.4 of [RFC6891].
+
+8.2.5.  Testing EDNS Version Negotiation with Unknown EDNS Flags
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 1 is used without any EDNS
+   options.  An unassigned EDNS flag bit is set (0x40 in this case).
+
+   We expect the SOA record for the zone to NOT be returned in the
+   answer section with the extended rcode set to BADVERS and the QR bit
+   to be set in the header; RA may also be set [RFC1034].  We expect an
+   OPT record to be returned.  There should be no EDNS flags present in
+   the response, as unknown EDNS flags are supposed to be ignored.  The
+   EDNS version field should be 0, as EDNS versions other than 0 are yet
+   to be specified, and there should be no EDNS options present
+   [RFC6891].
+
+   Check that EDNS version 1 queries with unknown flags work (EDNS
+   supported):
+
+   dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \
+       $zone @$server
+
+   expect: status: BADVERS
+   expect: SOA record to NOT be present
+   expect: an OPT record to be present in the additional section
+   expect: MBZ not to be present
+   expect: EDNS Version 0 in response
+   expect: flag: aa to NOT be present
+   expect: flag: ad to NOT be present
+
+8.2.6.  Testing EDNS Version Negotiation with Unknown EDNS Options
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 1 is used.  An unknown EDNS
+   option is present.  We have picked an unassigned code of 100 for the
+   example below.  Any unassigned EDNS option code could have been
+   chosen for this test.
+
+   We expect the SOA record for the zone to NOT be returned in the
+   answer section with the extended rcode set to BADVERS and the QR bit
+   to be set in the header; RA may also be set [RFC1034].  We expect an
+   OPT record to be returned.  There should be no EDNS flags present in
+   the response.  The EDNS version field should be 0, as EDNS versions
+   other than 0 are yet to be specified, and there should be no EDNS
+   options present [RFC6891].
+
+   Check that EDNS version 1 queries with unknown options work (EDNS
+   supported):
+
+   dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \
+       $zone @$server
+
+   expect: status: BADVERS
+   expect: SOA record to NOT be present
+   expect: an OPT record to be present in the additional section
+   expect: OPT=100 to NOT be present
+   expect: EDNS Version 0 in response
+   expect: flag: aa to NOT be present
+   expect: flag: ad to NOT be present
+
+8.2.7.  Testing Truncated Responses
+
+   Ask for the DNSKEY records of the configured zone, which must be a
+   DNSSEC signed zone.  This query is made with no DNS flag bits set.
+   EDNS version 0 is used without any EDNS options.  The only EDNS flag
+   set is DO.  The EDNS UDP buffer size is set to 512.  The intention of
+   this query is to elicit a truncated response from the server.  Most
+   signed DNSKEY responses are bigger than 512 bytes.  This test will
+   not give a valid result if the zone is not signed.
+
+   We expect a response, the rcode to be set to NOERROR, and the AA and
+   QR bits to be set.  AD may be set in the response if the server
+   supports DNSSEC; otherwise it should be clear; TC and RA may also be
+   set [RFC1035] [RFC4035].  We expect an OPT record to be present in
+   the response.  There should be no EDNS flags other than DO present in
+   the response.  The EDNS version field should be 0, and there should
+   be no EDNS options present [RFC6891].
+
+   If TC is not set, it is not possible to confirm that the server
+   correctly adds the OPT record to the truncated responses or not.
+
+   dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server
+   expect: NOERROR
+   expect: OPT record with version set to 0
+
+8.2.8.  Testing DO=1 Handling
+
+   Ask for the SOA record of the configured zone, which does not need to
+   be DNSSEC signed.  This query is made with no DNS flag bits set.
+   EDNS version 0 is used without any EDNS options.  The only EDNS flag
+   set is DO.
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the response.  AD may be set in the response if the server
+   supports DNSSEC, otherwise it should be clear; RA may also be set
+   [RFC1034].  We expect an OPT record to be returned.  There should be
+   no EDNS flags other than DO present in the response, which should be
+   present if the server supports DNSSEC.  The EDNS version field should
+   be 0, and there should be no EDNS options present [RFC6891].
+
+   Check that DO=1 queries work (EDNS supported):
+
+   dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: DO=1 to be present if an RRSIG is in the response
+   expect: EDNS Version 0 in response
+   expect: flag: aa to be present
+
+8.2.9.  Testing EDNS Version Negotiation with DO=1
+
+   Ask for the SOA record of the configured zone, which does not need to
+   be DNSSEC signed.  This query is made with no DNS flag bits set.
+   EDNS version 1 is used without any EDNS options.  The only EDNS flag
+   set is DO.
+
+   We expect the SOA record for the zone NOT to be returned in the
+   answer section, the extended rcode to be set to BADVERS, and the QR
+   bit to be set in the header; RA may also be set [RFC1034].  We expect
+   an OPT record to be returned.  There should be no EDNS flags other
+   than DO present in the response, which should be there if the server
+   supports DNSSEC.  The EDNS version field should be 0, and there
+   should be no EDNS options present [RFC6891].
+
+   Check that EDNS version 1, DO=1 queries work (EDNS supported):
+
+   dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \
+       $zone @$server
+
+   expect: status: BADVERS
+   expect: SOA record to NOT be present
+   expect: an OPT record to be present in the additional section
+   expect: DO=1 to be present if the EDNS version 0 DNSSEC query test
+           returned DO=1
+   expect: EDNS Version 0 in response
+   expect: flag: aa to NOT be present
+
+8.2.10.  Testing with Multiple Defined EDNS Options
+
+   Ask for the SOA record of the configured zone.  This query is made
+   with no DNS flag bits set.  EDNS version 0 is used.  A number of
+   defined EDNS options are present (NSID [RFC5001], DNS COOKIE
+   [RFC7873], EDNS Client Subnet [RFC7871], and EDNS Expire [RFC7314]).
+
+   We expect the SOA record for the zone to be returned in the answer
+   section, the rcode to be set to NOERROR, and the AA and QR bits to be
+   set in the header; RA may also be set [RFC1034].  We expect an OPT
+   record to be returned.  There should be no EDNS flags present in the
+   response.  The EDNS version field should be 0.  Any of the requested
+   EDNS options supported by the server and permitted server
+   configuration may be returned [RFC6891].
+
+   Check that EDNS queries with multiple defined EDNS options work:
+
+   dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \
+       soa $zone @$server
+
+   expect: status: NOERROR
+   expect: the SOA record to be present in the answer section
+   expect: an OPT record to be present in the additional section
+   expect: EDNS Version 0 in response
+   expect: flag: aa to be present
+   expect: flag: ad to NOT be present
+
+8.3.  When EDNS Is Not Supported
+
+   If EDNS is not supported by the nameserver, we expect a response to
+   each of the above queries.  That response may be a FORMERR error
+   response, or the OPT record may just be ignored.
+
+   Some nameservers only return an EDNS response when a particular EDNS
+   option or flag (e.g., DO=1) is present in the request.  This
+   behaviour is not compliant behaviour and may hide other incorrect
+   behaviour from the above tests.  Retesting with the triggering
+   option/flag present will expose this misbehaviour.
+
+9.  Remediation
+
+   Nameserver operators are generally expected to test their own
+   infrastructure for compliance to standards.  The above tests should
+   be run when new systems are brought online and should be repeated
+   periodically to ensure continued interoperability.
+
+   Domain registrants who do not maintain their own DNS infrastructure
+   are entitled to a DNS service that conforms to standards and
+   interoperates well.  Registrants who become aware that their DNS
+   operator does not have a well-maintained or compliant infrastructure
+   should insist that their service provider correct issues and switch
+   providers if they do not.
+
+   In the event that an operator experiences problems due to the
+   behaviour of nameservers outside their control, the above tests will
+   help in narrowing down the precise issue(s), which can then be
+   reported to the relevant party.
+
+   If contact information for the operator of a misbehaving nameserver
+   is not already known, the following methods of communication could be
+   considered:
+
+   *  the RNAME of the zone authoritative for the name of the
+      misbehaving server
+
+   *  the RNAME of zones for which the offending server is authoritative
+
+   *  administrative or technical contacts listed in the registration
+      information for the parent domain of the name of the misbehaving
+      server or for zones for which the nameserver is authoritative
+
+   *  the registrar or registry for such zones
+
+   *  DNS-specific, operational fora (e.g., mailing lists)
+
+   Operators of parent zones may wish to regularly test the
+   authoritative nameservers 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 Top-Level Domain (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 nameservers of their registrants,
+   since they have a direct relationship.
+
+   When notification is not effective at correcting problems with a
+   misbehaving nameserver, 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
+   to occur.
+
+10.  Security Considerations
+
+   Testing protocol compliance can potentially result in false reports
+   of attempts to attack services from Intrusion Detection Services and
+   firewalls.  All of the tests are well-formed (though not necessarily
+   common) DNS queries.  None of the tests listed above should cause any
+   harm to a protocol-compliant server.
+
+   Relaxing firewall settings to ensure EDNS compliance could
+   potentially expose a critical implementation flaw in the nameserver.
+   Nameservers should be tested for conformance before relaxing firewall
+   settings.
+
+   When removing delegations for non-compliant servers, there can be a
+   knock-on effect on other zones that require these zones to be
+   operational for the nameservers addresses to be resolved.
+
+11.  IANA Considerations
+
+   This document has no IANA actions.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, DOI 10.17487/RFC3225, December 2001,
+              <https://www.rfc-editor.org/info/rfc3225>.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+              <https://www.rfc-editor.org/info/rfc4035>.
+
+   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
+              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
+              DOI 10.17487/RFC6840, February 2013,
+              <https://www.rfc-editor.org/info/rfc6840>.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891,
+              DOI 10.17487/RFC6891, April 2013,
+              <https://www.rfc-editor.org/info/rfc6891>.
+
+   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
+              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
+              April 2013, <https://www.rfc-editor.org/info/rfc6895>.
+
+   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
+              D. Wessels, "DNS Transport over TCP - Implementation
+              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
+              <https://www.rfc-editor.org/info/rfc7766>.
+
+12.2.  Informative References
+
+   [IANA-DNS] IANA, "Domain Name System (DNS) Parameters",
+              <https://www.iana.org/assignments/dns-parameters/>.
+
+   [ISC]      "Internet Systems Consortuim", <https://www.isc.org/>.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, DOI 10.17487/RFC2671, August 1999,
+              <https://www.rfc-editor.org/info/rfc2671>.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
+              2003, <https://www.rfc-editor.org/info/rfc3597>.
+
+   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
+              RFC 5001, DOI 10.17487/RFC5001, August 2007,
+              <https://www.rfc-editor.org/info/rfc5001>.
+
+   [RFC7314]  Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE
+              Option", RFC 7314, DOI 10.17487/RFC7314, July 2014,
+              <https://www.rfc-editor.org/info/rfc7314>.
+
+   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
+              Kumari, "Client Subnet in DNS Queries", RFC 7871,
+              DOI 10.17487/RFC7871, May 2016,
+              <https://www.rfc-editor.org/info/rfc7871>.
+
+   [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
+              Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
+              <https://www.rfc-editor.org/info/rfc7873>.
+
+Acknowledgements
+
+   The contributions of Matthew Pounsett and Tim Wicinski are gratefully
+   acknowledged.
+
+Authors' Addresses
+
+   M. Andrews
+   Internet Systems Consortium
+   PO Box 360
+   Newmarket, NH 03857
+   United States of America
+
+   Email: marka@isc.org
+
+
+   Ray Bellis
+   Internet Systems Consortium
+   PO Box 360
+   Newmarket, NH 03857
+   United States of America
+
+   Email: ray@isc.org