BIND 9 is striving for strict compliance with IETF standards. We
believe this release of BIND 9 complies with the following RFCs, with
the caveats and exceptions listed in the numbered notes below. Note
that a number of these RFCs do not have the status of Internet
standards but are proposed or draft standards, experimental RFCs,
or Best Current Practice (BCP) documents. The list is non exhaustive.
RFC3491 (Obsoleted by 5890, 5891) [7]
RFC4294 - Section 5.1 [8]
The following DNS related RFC have been obsoleted
RFC2535 (Obsoleted by 4034, 4035) [3] [4]
RFC2537 (Obsoleted by 3110)
RFC2538 (Obsoleted by 4398)
RFC2671 (Obsoleted by 6891)
RFC2672 (Obsoleted by 6672)
RFC2673 (Obsoleted by 6891)
RFC3008 (Obsoleted by 4034, 4035)
RFC3152 (Obsoleted by 3596)
RFC3445 (Obsoleted by 4034, 4035)
RFC3655 (Obsoleted by 4034, 4035)
RFC3658 (Obsoleted by 4034, 4035)
RFC3755 (Obsoleted by 4034, 4035)
RFC3757 (Obsoleted by 4034, 4035)
RFC3845 (Obsoleted by 4034, 4035)
[1] Queries to zones that have failed to load return SERVFAIL rather
than a non-authoritative response. This is considered a feature.
[2] CLASS ANY queries are not supported. This is considered a
[3] Wildcard records are not supported in DNSSEC secure zones.
[4] Servers authoritative for secure zones being resolved by BIND
9 must support EDNS0 (RFC2671), and must return all relevant SIGs
and NXTs in responses rather than relying on the resolving server
to perform separate queries for missing SIGs and NXTs.
[5] When receiving a query signed with a SIG(0), the server will
only be able to verify the signature if it has the key in its local
authoritative data; it will not do recursion or validation to
[6] Section 4 is ignored.
[7] Requires --with-idn to enable entry of IDN labels within dig,
host and nslookup at compile time. ACE labels are supported
everywhere with or without --with-idn.
[8] Section 5.1 - DNAME records are fully supported.
[9] Minimally Covering NSEC Record are accepted but not generated.
[10] Will interoperate with correctly designed experiments.
[11] Named only uses ports to extend the id space, address are not
[12] Conditional on the OpenSSL library being linked against
[13] Section 5.5 does not match reality. Named uses the presence
of DO=1 to detect if validation may be occuring. CD has no bearing
on whether validation is occuring or not.
[14] Conditional on the OpenSSL library being linked against
[15] Section 5.9 - Always set CD=1 on queries. This is *not* done as
it prevents DNSSEC working correctly through another recursive server.
When talking to a recurive server the best algorithm to do is send
CD=0 and then send CD=1 iff SERVFAIL is returned in case the recurive
server has a bad clock
and/or bad trust anchor. Alternatively one
can send CD=1 then CD=0 on validation failure in case the recursive
server is under attack or there is stale / bogus authoritative data.
[16] Named doesn't currently encrypt DNS requests so the PAD option
is accepted but not returned in responses.