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.