Copyright (C) Internet Systems Consortium, Inc. ("ISC") See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. 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. RFC1034 RFC1035 [1] [2] RFC1123 RFC1183 RFC1535 RFC1536 RFC1706 RFC1712 RFC1750 RFC1876 RFC1982 RFC1995 RFC1996 RFC2136 RFC2163 RFC2181 RFC2230 RFC2308 RFC2536 RFC2539 RFC2782 RFC2915 RFC2930 RFC2931 [5] RFC3007 RFC3110 RFC3123 RFC3225 RFC3226 RFC3363 [6] RFC3490 [7] RFC3491 (Obsoleted by 5890, 5891) [7] RFC3493 RFC3496 RFC3597 RFC3645 RFC4025 RFC4034 RFC4035 RFC4074 RFC4255 RFC4294 - Section 5.1 [8] RFC4343 RFC4398 RFC4408 RFC4431 RFC4470 [9] RFC4509 RFC4635 RFC4701 RFC4892 RFC4955 [10] RFC5001 RFC5011 RFC5155 RFC5205 RFC5452 [11] RFC5702 RFC5933 [12] RFC5936 RFC5952 RFC5966 RFC6052 RFC6147 [13] RFC6303 RFC6605 [14] RFC6672 RFC6698 RFC6742 RFC6840 [15] RFC6844 RFC6891 RFC7043 RFC7314 RFC7477 RFC7793 RFC7830 [16] 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 feature. [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 retrieve unknown keys. [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 used. [12] Conditional on the OpenSSL library being linked against supporting GOST. [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 supporting ECDSA. [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.