The following section describe some of the common operational problems that one can encounter with the DNS.
Mutual gluelessness is where two domains use each other for name service rather than providing "in-zone" nameservers, the anti-poisoning rules cause no glue for those domains to be obtainable from trusted sources, and thus the domains are unreachable in a secure and trustworthy fashion.
For example:
Posit:
example.isp..
The corp. DNS servers provide a referral for example.corp. directing
resolving proxies to the content server named corp.ns.example.isp., and
supplying an additional A record for that name as "glue"
giving its IP address as 10.1.2.3 .
The isp. DNS servers provide a referral for
example.isp. directing resolving proxies to the content
server named isp.ns.example.corp., and supplying an
additional A record for that name as "glue" giving its IP
address as 10.4.5.6 .
A resolving proxy wanting to find www.example.corp..
The resolving proxy will query the corp. servers at some
point, and be told to go to corp.ns.example.isp.. However,
because the glue supplied for that name is not within the bailiwick of the
corp. servers, and is indistinguishable from poison, it will
be discarded. The resolving proxy will have to look up the A
record for corp.ns.example.isp. starting from the roots to
find the server to use before it can look up any names in
example.corp..
During that process the resolving proxy will query the isp. servers, and
be told to go to isp.ns.example.corp.. However, once again, because the
glue supplied for that name is not within the bailiwick of the isp.
servers, and is indistinguishable from poison, it will be discarded. The
resolving proxy now has to look up the A record for
isp.ns.example.corp..
But the proxy cannot look up names ending in example.corp.
until it has found corp.ns.example.isp.. However, it also
cannot look up names ending in example.isp. until it has
found isp.ns.example.corp..
Both parent servers are obeying the rules for supplying glue, yet neither
example.corp. nor example.isp. are reachable
because of a mutual dependence.
It is strongly recommended, for this and other reasons, that the intermediate names of all name servers be within the same parent domain as the domain that they are serving. "Glue" supplied by parent servers will then not be discarded and the problem of mutual gluelessness will not arise.
Sometimes, the
Forwarding Caching Proxy Server
and the
Resolving Caching Proxy Server
will return A-type resource record sets that contain the same
IP address listed twice. This is not a problem with the proxy servers.
They have cached and passed on exactly what they received.
The problem is with the original content servers, and is caused by a bug
in BIND. Most, if not all, versions of BIND will, when asked for the
addresses of the content servers themselves, return the A
records twice, once in the "answer" section of a response and a second
time in the "additional" section.
Here is an example of this repetition taken directly from the DNS servers of the company that writes BIND:
[C:\]dnsqry /serverip:204.152.184.64 a ns-ext.vix.com. [0.0.0.0:0000] -> [204.152.184.64:0035] Header: d8c2 1+0+0+0, Q, , query, no_error Question: ns-ext.vix.com. IN A [204.152.184.64:0035] -> [0.0.0.0:0000] Header: d8c2 1+1+2+2, R, AUTH, query, no_error Question: ns-ext.vix.com. IN A Answer: ns-ext.vix.com. IN A 3600 204.152.184.64 Authority: vix.com. IN NS 3600 ns-ext.vix.com. Authority: vix.com. IN NS 3600 ns1.gnac.com. Additional: ns-ext.vix.com. IN A 3600 204.152.184.64 Additional: ns1.gnac.com. IN A 1800 209.182.195.77 [C:\]
In response to a query, the content server has returned the A
record for ns-ext.vix.com. twice. Therefore the caching
proxy servers will also return that IP address twice.
In theory, a delegation from a parent content server will always be to a content server that is "closer" to the required domain. In practice, administration errors and downright incompetence result in this not being the case. Incompetent administrators, for example, have been known to list their ISP's DNS servers as content servers for their own domains when registering those domains with registrars, without the consent of or even the knowledge of their ISP, resulting in the ISP's content servers receiving queries for domains that they do not in fact serve.
The content servers in the Internet Utilities return "no such domain" responses to queries for names in a part of the namespace that they do not serve. They do this because it is the correct response to give to such queries. The name is not in their database, so the response is "no such domain".
One of the consequences of this behaviour is that incorrect delegations will be rapidly brought to the attention of admininstrators and domain name registrars.
For example:
Posit that the administrator for example.corp., when
registering that subdomain with the registrar for the corp.
domain, in order to obey the requirement imposed by the registrar that the
domain be served by two independent content servers, listed both his own
content server srv1.ns.example.corp. and the content server
of his ISP srv1.ns.example.isp. on the application form,
without obtaining the agreement of the ISP and without arranging for the
ISP's server to possess a copy of the database for the
example.corp. domain.
The corp. servers will refer clients to both servers for all
names in the domain example.corp.. Half of the time the
clients will choose to contact the administrator's own server, and half of
the time they will choose to contact the ISP's server. In the latter
case, they will receive a "no such domain" error. This will result in the
configuration error being rapidly drawn to the attention of the
example.corp. administrator.
Moreover, if the registrar happens to be thorough and demands as a condition for registration that all servers listed for a domain return an SOA record for that domain, the registrar will refuse to list the domain in the first place, because it will discover that the second server listed on the application form is returning "no such domain" errors.
Other DNS softwares choose strategies that result in DNS clients timing out, excessive DNS traffic as those clients retry their queries, and consequent delays to end users. Unfortunately, these strategies also hide the actual problem, and can cause it to remain uncorrected for months, with DNS clients generating extra traffic and users experiencing delays all of the while that it does so.
It is possible for some of the CNAME record sets in the DNS
to form a loop. In order to detect this, the
Forwarding Caching Proxy Server
and the
Resolving Caching Proxy Server
limit the number of aliases in any single response to 100, and return
a "server failure" response if that number is exceeded.
Some other DNS softwares limit the number of aliases to just 4.