Added new compatibility notes and information about key ID collisions.

diff --git a/README b/README
index c32776316f12568bbacff3cf492b1d86d1a8a813..3e0124104b10fc88cd68f67301f0650a67a3d130 100644 (file)
--- a/README
+++ b/README
@@ -73,10 +73,30 @@ BIND 9.7.0
         - Improved PKCS#11 support, including Keyper support and explicit
           OpenSSL engine selection (see README.pkcs11 for additional details).
 
-       Warning: If you had built BIND 9.6 with any of ALLOW_NSEC3PARAM_UPDATE,
-       ALLOW_SECURE_TO_INSECURE or ALLOW_INSECURE_TO_SECURE defined then
-       you should ensure that all changes that are in progress have completed
-       prior to upgrading to BIND 9.7.  BIND 9.7 is not backwards compatible.
+        COMPATIBILITY NOTES:
+
+        - If you had built BIND 9.6 with any of ALLOW_NSEC3PARAM_UPDATE,
+          ALLOW_SECURE_TO_INSECURE or ALLOW_INSECURE_TO_SECURE defined, then
+          you should ensure that all changes that are in progress have
+          completed prior to upgrading to BIND 9.7.  BIND 9.7 implements
+          those features in a way which is not backwards compatible.
+
+        - Prior releases had a bug which caused HMAC-SHA* keys with long
+          secrets to be used incorrectly.  Fixing this bug means that older
+          versions of BIND 9 may fail to interoperate with this version
+          when using TSIG keys.  If this occurs, the new "isc-hmac-fixup"
+          tool will convert a key with a long secret into a form that works
+          correctly with all versions of BIND 9.  See the "isc-hmac-fixup"
+          man page for additional details.
+
+        - Revoking a DNSSEC key with "dnssec-revoke" changes its key ID.
+          It is possible for the new key ID to collide with that of a
+          different key.  Newly generated keys will not have this problem,
+          as "dnssec-keygen" looks for potential collisions before
+          generating keys, but exercise caution if using key revokation
+          with keys that were generated by older versions of BIND 9.
+          See README.rfc5011 for more details.
+          
 
 BIND 9.6.0
 

diff --git a/README.rfc5011 b/README.rfc5011
index fd941fb93b7ef8452524e8ad86cb3b9fa5f01142..7cf34912958d9e972279a892eaf2ffa9e8fc5dd0 100644 (file)
--- a/README.rfc5011
+++ b/README.rfc5011
@@ -54,3 +54,21 @@ the resolver.  However, validation can proceed using the new active key
 (which had been accepted by the resolver when it was a stand-by key).
 
 See RFC 5011 for more details on key rollover scenarios.
+
+When a key has been revoked, its key ID changes, increasing by
+128, and wrapping around at 65535.  So, for example, the key
+"Kexample.com.+005+10000" becomes "Kexample.com.+005+10128".
+
+If two keys have ID's exactly 128 apart, and one is revoked, then the
+two key ID's will collide, causing several problems.  To prevent this,
+dnssec-keygen will not generate a new key if another key is present which
+may collide.  This checking will only occur if the new keys are written
+to the same directory which holds all other keys in use for that zone.
+
+Older versions of BIND 9 did not have this precaution.  Exercise caution if
+using key revocation on keys that were generated by previous releases, or
+if using keys stored in multiple directories or on multiple machines.
+
+It is expected that a future release of BIND 9 will address this problem
+in a different way, by storing revoked keys with their original unrevoked
+key ID's.