A Common Operational Problem in DNS Servers - Failure To Respond.
Internet Systems Consortium
950 Charter Street
Redwood City
CA
94063
US
marka@isc.org
The DNS is a query / response protocol. Failure to respond to
queries causes both immediate operational problems and long term
problems with protocol development.
This document will identify a number of common classes of
queries that some servers fail to respond too. This document
will also suggest procedures for TLD and other similar zone
operators to apply to reduce / eliminate the problem.
The DNS ,
is a query / response protocol. Failure to respond to
queries causes both immediate operational problems and long
term problems with protocol development.
Failure to respond to a query is indistinguishable from a
packet loss without doing a analysis of query response
patterns and results in unnecessary additional queries being
made by DNS clients and unnecessary delays being introduced
to the resolution process.
Allowing servers which fail to respond to queries to remain
in the DNS hierarchy for extended periods results in
developers being afraid to deploy new type codes. Such servers
need to be identified and corrected / replaced.
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.
Unless a nameserver is under attack, it should respond to
all queries directed to it as a result of following
delegations. Additionally code should not assume that there
isn't a delegation to the server even if it is not configured
to serve the zone. Broken delegation are a common occurrence
in the DNS and receiving queries for zones that you are not
configured for is not a necessarily a indication that you
are under attack.
There are two common query class that result in non responses
today. These are EDNS queries and
queries for unknown (unallocated) or unsupported types.
Identifying servers that fail to respond to EDNS queries
can be done by first identifying that the server responds
to regular DNS queries then making a series otherwise
identical responses 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.
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 likely hood of a false positive
due to packet loss.
Identifying servers that fail to respond to unknown or
unsupported types can be done by making a initial DNS
query for a A record, making a number of queries for
unallocated type, them making a query for a A record
again. IANA maintains a registry of allocated types.
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 likely hood of a false
positive due to packet loss.
While the first step in remediating this problem is to get
the offending nameserver code corrected, there is a very
long tail problem with DNS servers in that it can often
take over a decade between the code being corrected and a
nameserver being upgraded with corrected code. With that
in mind it is requested that TLD, and other similar zone
operators, take steps to identify and inform their customers,
directly or indirectly through registrars, that they are
running such servers and that the customers need to correct
the problem.
TLD operators should construct a list of servers child zones
are delegated to along with a delegated zone name. This
name shall be the query name used to test the server as it
is supposed to exist.
For each server the TLD operator shall make a SOA query the
delegated zone name. This should result in the SOA record
being returned in the answer section. If the SOA record is
not return but some other response is returned this is a
indication of a bad delegation and the TLD operator should
take whatever steps it normally takes to rectify a bad
delegation. If more that one zone is delegated to the server
it should choose another zone until it finds a zone which
responds correctly or it exhausts the list of zones delegated
to the server.
If it fails to get a response to a SOA query the TLD operator
should make a A query as some nameservers fail to respond to
SOA queries but respond to A queries. If it gets no response
to the A query another delegated zone should be queried for
as some nameservers fail to respond to zones they are not
configured for. If subsequent queries find a responding
zone all delegation to this server need to be checked and
rectified using the TLD's normal procedures.
Having identified a working <server, query name> tuple the
TLD operator should now check that the server responds to
both EDNS and unknown query type tests as described above.
If the TLD operator finds that server fails either or both
tests, the TLD operator shall take steps to inform the
operator of the server that they are running a fault
nameserver and that they need to take steps to correct the
matter. The TLD operator shall also record the <server,
query name> for followup testing.
If repeated attempts to inform and get the customer
to correct / replace the fault server are unsuccessful
the TLD operator shall remove all delegations to said
server from the zone.
DOMAIN NAMES - CONCEPTS AND FACILITIES
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
Extension Mechanisms for DNS (EDNS0)