Notes on type extensibility

New numbers may be assigned meanings at any time. ``The domain system is intentionally extensible,'' says RFC 1034, the first part of the DNS specification. ``New data types and experimental behavior should always be expected,'' says RFC 1035, the second part of the DNS specification. ``A name server may acquire [records] that the server doesn't know how to convert to printable format ... this data must be preserved,'' says RFC 1123, Requirements for Internet Hosts.

BIND 9.0.0 violates this fundamental requirement of the Domain Name System. BIND 9.0.0 aborts an incoming zone transfer if it sees an unrecognized record type in the zone. BIND 9.0.0 aborts a query if it sees an unrecognized record type in the answer to the query. The same comments apply to BIND 4 and BIND 8, except that, under some circumstances, BIND 4 and BIND 8 accidentally pass along unparsed answers containing unrecognized record types.

The DNS architecture was designed to allow smooth introduction of new record types. Individual servers could be extended to provide data of those types, and individual clients that wanted the data could look it up. DNS software ``SHOULD be written to minimize the trauma associated with the introduction of new well-known types and local experimentation with non-standard types,'' RFC 1123 says.

Unfortunately, thanks to BIND's behavior, every new record type is an interoperability disaster. The client's query will fail if the nearby cache is running BIND. A new type isn't safe until every BIND cache on the Internet has been upgraded to handle the type.

In contrast, let's look at djbdns:

• dnscache, which handles outgoing DNS queries, supports data of all types.
• tinydns, which handles incoming DNS queries, supports data of all types. You can feed binary data of any type to tinydns-data. (Of course, the tinydns-data input format may be extended in the future to provide nicer representations of a popular new type.)
• axfrdns, which handles outgoing zone transfers, supports data of all types.
• axfr-get, which handles incoming zone transfers, supports data of all types.
• dnsq, a replacement for dig, supports data of all types.

The BIND company claimed that BIND 9.0.0 was written for ``full RFC conformance.'' That claim is false. They didn't even get the basics right.

After I set up this web page, the BIND company changed their zone format and internal record format to support unrecognized types. They say that BIND versions 9.1.0 and above work correctly. Now I'd like to hear how they plan to get rid of all the BIND 4 and BIND 8 servers.

The authors of NSD subsequently screwed up an even more basic aspect of handling new types. Bug 2002-04-29 09:45: ``We return a NotImp error on RR types we do not implement even when the query causes a referral.''