1 files changed, 160 insertions, 0 deletions
diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance
new file mode 100644
index 0000000..0dbc9d4
--- /dev/null
+++ b/doc/misc/rfc-compliance
@@ -0,0 +1,160 @@
+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.