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 violates this fundamental requirement of the Domain Name System. BIND 9 aborts an incoming zone transfer if it sees an unrecognized record type in the zone. BIND 9 aborts a query if it sees an unrecognized record type in the answer to the query. (The same comments apply to previous versions of BIND, except that, under some circumstances, those versions would 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:
The BIND company claims that BIND 9 was written for ``full RFC conformance.'' That claim is false. BIND doesn't even get the basics right. The BIND zone format and internal record format can't handle new types.