Copyright (C) 2004, 2015 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.

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

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.