The superdomain owner hall of shame

You've come to this page because you've asked a question similar to the following:

I've set up a content DNS server listening on a publically accessible IP address, to publish my DNS data, and populated its database with the correct data that I actually want published. But the registry/registrar is complaining about my content DNS server, showing me the output of some testing tools that it has run. What's all this about?

This is the Frequently Given Answer to that question. You can find an alternative hall of shame distributed across all of the "how to receive a delegation from …" pages on Dan Bernstein's djbdns site.

Foolish registries and (more usually) registrars perform all sorts of daft, pointless, and downright wrong tests on prospective content DNS servers before they will make delegations. Many of these tests are performed by rôte ("That's just what our testing tool was written to do."), based upon handed-down notions of best practice ("We were told, simply, that servers have to do this."), and with little or no actual understanding either of bailiwick or of what content DNS service actually is and how it differs from proxy DNS service

Practices that are, shamefully, made compulsory

Here is the hall of shame listing all of the well-known unnecessary and often incorrect hoops that foolish registries and registrars make subdomain owners jump through.

Requiring the deliberate publication of cache pollution

Foolish registries/registrars send NS queries for . (the DNS namespace root) to subdomain content DNS servers, and whinge if they don't receive some root delegation information back. (Sometimes they even whinge if the root delegation isn't specifically that of ICANN's . content DNS servers.) They also send queries for localhost. and 1.0.0.127.in-addr.arpa. to subdomain content DNS servers, and whinge if they don't receive particular information back.

This bespeaks a fundamental lack of understanding of the DNS on their part, with respect to the proper separation of services, bailiwick, and the nature of delegation.

The basic mistake that the foolish registries/registrars are making is that of thinking that what a content DNS server publishes about domain names that are outside of its bailiwick actually matters. It does not. The contents of the global distributed DNS database are formed by combining only the in-bailiwick data published by all of the content DNS servers around the world. All other, out-of-bailiwick, data are simply irrelevant. Tests on what a content DNS server may say about out-of-bailiwick domain names are pointless.

Requiring particular values in SOA resource records

Foolish registries/registrars send SOA queries for the delegation point to subdomain content DNS servers, study the fields of the resulting SOA resource records relating to DNS database replication, and whinge if they don't see values that they like.

Such foolish registries/registrars don't understand what the semantics of those fields actually are. They make wholly unjustified assumptions about the semantics of those fields (based upon wholly unjustified assumptions about what DNS database replication mechanism is in use), from which they derive wholly unjustified limitations on what those fields may contain.

Registries/registrars have no way to know what database replication mechanism is in use amongst the content DNS servers for the subdomain. That is an entirely private matter amongst the (administrators of the) coöoperating content DNS servers themselves. They thus have no way to know what values are reasonable in the fields, relating to DNS database replication, of subdomain SOA resource records.

Requiring class C divisions between server IP addresses

Foolish registries/registrars whinge if the IP addresses of multiple content DNS servers within a single set have the first three octets in common.

This thinking is a hang over from the days when IP addresses had classes, from which one could easily deduce whether two IP addresses were on the same network. If two IP addresses differed only in their final octet, the deduction would be that they were on the same network, behind a common connection to the rest of Internet, and thus that the good practice, of not having a single point of failure (in this case, the shared connection to the rest of Internet) for multiple content DNS servers in a set, had not been followed.

Internet addressing has not worked this way for quite some time. The foolish registries/registrars need to drag themselves kicking and screaming into the 1990s (sic!). It's no longer possible to unequivocally state that two IP addresses that differ only in their final octets are on the same network.

The mistake that the foolish registries/registrars are making is in thinking that a simple comparison of octets in two IP addresses will tell them what is in fact only discoverable by checking an actual border gateway routing table.

Requiring the availability of DNS/TCP service

Foolish registries/registrars whinge if content DNS/UDP service is provided but content DNS/TCP service is not.

The provision of DNS/TCP service is not actually a requirement, even though a few very vocal people claim that it is, or should be. RFC 1123 § 6.1.3.2 merely says that content DNS servers "should be able to service TCP queries". This is a recommendation, which there may be "valid reason in particular circumstances to ignore". And indeed there are. If the circumstances are that there is no reason for providing DNS/TCP service, then the fact that TCP services (in general) are open to denial-of-service attacks, in ways that UDP services are not, is a "valid reason in particular circumstances to ignore" that recommendation. Given that RFC 1123 § 6.1.3.2 also says that the back ends of resolving proxy DNS servers "must support UDP" and "must send a UDP query first", the circumstances in which there is no reason for providing DNS/TCP, and thus where the general weaknesses of TCP service become reasons to ignore the recommendation to provide it, are when

RFC 1123 § 6.1.3.2 also says that "truncation cannot be predicted, since it is data-dependent". The foolish registries/registrars, of course, have no access to the DNS databases of the content DNS servers. Thus what RFC 1123 § 6.1.3.2 says is true as far as the foolish registries/registrars are concerned. Moreover, the database replication mechanism that is in use is an entirely private matter amongst the coöoperating content DNS servers themselves. The foolish registries/registrars have no way of knowing whether both of the aforementioned conditions (for ignoring the recommendation to provide DNS/TCP service) actually hold.

But the administrator of the content DNS servers themselves does, and what RFC 1123 § 6.1.3.2 says does not hold for the administrator. The administrator can look at the contents of the DNS database and determine from them whether any response will incur truncation. (Put another way: The administrator can ensure that no data are added to the database in the first place that would cause truncation to occur.) The administrator is also privy to the DNS database replication arrangements, and knows whether the "zone transfer" database replication is in use or not. The administrator can thus (albeit not without some work in some circumstances) determine whether the conditions hold and thus whether there are reasons to ignore the recommendation to provide DNS/TCP service.

On the gripping hand, this still doesn't justify the foolish registrars/registries checking for the existence of content DNS/TCP service and whingeing if it is not provided. They are simply not in a position to determine whether that check is a valid one to be making.

Requiring the availability of "zone transfer" database replication

Foolish registries/registrars whinge if "zone transfer" database replication is not available to certain IP addresses that they designate.

This check is wrong for several reasons:

The basic mistake that the foolish registries/registrars are making is in thinking that "zone transfer" service is an integral part of content DNS service and that they have some sort of right to privileged access to the subdomain's DNS database. It isn't, and they do not. "Zone transfer" service is an extension to the core DNS protocol; and is only a database replication mechanism (not even a very good one, at that), not anything to do with content DNS service proper. Database replication is an entirely private matter for (the administrators of) a set of coöoperating content DNS servers, and not an automatic right to outsiders. And "zone transfer" database replication is just one of many database replication mechanisms, which is falling in popularity with the advent of modern DNS servers with more flexible databases.

Requiring the existence of a postmaster mailbox

Foolish registries/registrars whinge if, when asked to delegate a subdomain, no mail service for the <Postmaster@…> mailbox at that subdomain is provided.

This is just blatantly silly. Not all domain names are there for the purposes of electronic mail. Indeed, many aren't. (Just ask the owners of altavista.com., a well known "no electronic mail here" domain, for example.) Requiring that a subdomain have mail service is just daft.

It's also counterproductive. It requires that the administrators of "no electronic mail" domains set up dummy SMTP Relay servers solely for the benefit of appeasing the foolish registry/registrar, and prevents them from adopting best practice. Best practice, of course, is that if the intent is to provide no electronic mail service to Internet, one should not have a (potentially exploitable) SMTP Relay server at all.

Requiring delegation information for inner nodes

Foolish registries/registrars perform a very bizarre check, and of course whinge if it fails. They look at the intermediate domain names, that form the halfway point in the delegation information for the domain that it is intended to delegate, strip off the first label, ask the content DNS servers being delegated to for the NS resource record sets for the resulting names, and then check that those resource record sets comprise the same intermediate domain names that they started with.

One can almost see the logic in this, as long as one adopts the following erroneous premise:

For every subdomain example.it., the intermediate domain names for the content DNS servers will be of the form ns1.example.it., ns2.example.it., and so forth.

Given that premise, what happens when the check is performed is that the foolish registry/registrar looks at the proposed delegation information for example.it., sees the intermediate domain names ns1.example.it. and ns2.example.it., strips off their first label to yield example.it., looks up the NS resource record set for example.it., and finds ns1.example.it. and ns2.example.it. again.

But, of course, that premise is erroneous.

There is simply no justification at all for this bizarre check. It is based upon a very narrowminded notion, that is simply false in practice, of how delegations are constructed.

Checks that registries/registrars, ironically, miss

Here is a hall of shame listing some of the hoops that registries and registrars do not make subdomain owners jump through.

Omitting a check for EDNS0 support

Registries/registrars don't check to see whether content DNS servers respond to EDNS0 queries. But doing so would vastly improve the lot of resolving proxy DNS servers that are capable of using EDNS0.

Currently, most DNS lookups involve public content DNS servers that don't actually support EDNS0. Such servers will fail in one of a (quite large) number of ways when sent EDNS0 queries. (These can be somewhat bizarre. One DNS server software sends back "bad format" responses with empty "question" sections, for example.) Where a resolving proxy DNS server is configured to use EDNS0, most of its back-end queries involve two DNS/UDP transactions, the first attempting to use EDNS0, either receiving an error response or timing out after receiving no response, and the second not. In contrast, when configured to not use ENDS0, there is just one DNS/UDP transaction in those cases. The use of EDNS0 yields a gain from the loss of the DNS/TCP setup/teardown overhead in the subset of cases where TCP fallback would otherwise be used. But this is vastly diminished by the loss incurred by the concomitant increase in DNS/UDP traffic, and the extra timeouts talking to the the non-responsive-to-ENDS0 servers, for pretty much all lookups across the board.

The irony of this is that if content DNS servers implemented EDNS0 (even if only to the extents of recognising and parsing EDNS0 queries properly, and advertising 512 octet DNS/UDP datagram sizes), the current situation would be much improved.

Checks that content DNS servers responded non-erroneously to EDNS0 queries (not that they support extensions, such as large UDP datagram sizes, but merely that they do not yield error responses, or simply fail to respond at all, when sent EDNS0 queries) is, ironically, one of the generally beneficial checks that registries/registrars don't make.


© Copyright 2004–2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.