Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") Copyright (C) 2001 Internet Software Consortium. See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. $Id: rfc-compliance,v 1.4 2004/03/05 05:04:53 marka Exp $ 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. RFC1034 RFC1035 [1] [2] RFC1123 RFC1183 RFC1535 RFC1536 RFC1706 RFC1712 RFC1750 RFC1876 RFC1982 RFC1995 RFC1996 RFC2136 RFC2163 RFC2181 RFC2230 RFC2308 RFC2535 [3] [4] RFC2536 RFC2537 RFC2538 RFC2539 RFC2671 RFC2672 RFC2673 RFC2782 RFC2915 RFC2930 RFC2931 [5] RFC3007 [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.