diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance
index 0d3d74271d..ad3fb0d429 100644
--- a/doc/misc/rfc-compliance
+++ b/doc/misc/rfc-compliance
@@ -28,11 +28,7 @@ or Best Current Practice (BCP) documents.  The list is non exhaustive.
   RFC2230
   RFC2308
   RFC2536
-  RFC2538
   RFC2539
-  RFC2671
-  RFC2672
-  RFC2673
   RFC2782
   RFC2915
   RFC2930
@@ -55,11 +51,47 @@ or Best Current Practice (BCP) documents.  The list is non exhaustive.
   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
+  RFC7314
+  RFC7314
 
 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)
@@ -72,17 +104,18 @@ The following DNS related RFC have been obsoleted
 [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.
+[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.
+[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
+[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.
 
@@ -93,3 +126,29 @@ 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.