/contrib/bind9/doc/arm/managed-keys.xml

https://bitbucket.org/freebsd/freebsd-head/ · XML · 100 lines · 79 code · 2 blank · 19 comment · 0 complexity · 8bd1264f7fcd7da448a462ba596ea271 MD5 · raw file

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <!--
  3. - Copyright (C) 2010 Internet Systems Consortium, Inc. ("ISC")
  4. -
  5. - Permission to use, copy, modify, and/or distribute this software for any
  6. - purpose with or without fee is hereby granted, provided that the above
  7. - copyright notice and this permission notice appear in all copies.
  8. -
  9. - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  10. - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
  11. - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  12. - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  13. - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  14. - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  15. - PERFORMANCE OF THIS SOFTWARE.
  16. -->
  17. <!-- $Id: managed-keys.xml,v 1.3 2010/02/03 23:49:07 tbox Exp $ -->
  18. <sect1 id="rfc5011.support">
  19. <title>Dynamic Trust Anchor Management</title>
  20. <para>BIND 9.7.0 introduces support for RFC 5011, dynamic trust
  21. anchor management. Using this feature allows
  22. <command>named</command> to keep track of changes to critical
  23. DNSSEC keys without any need for the operator to make changes to
  24. configuration files.</para>
  25. <sect2>
  26. <title>Validating Resolver</title>
  27. <!-- TODO: command tag is overloaded for configuration and executables -->
  28. <para>To configure a validating resolver to use RFC 5011 to
  29. maintain a trust anchor, configure the trust anchor using a
  30. <command>managed-keys</command> statement. Information about
  31. this can be found in
  32. <xref linkend="managed-keys" />.</para>
  33. <!-- TODO: managed-keys examples
  34. also in DNSSEC section above here in ARM -->
  35. </sect2>
  36. <sect2>
  37. <title>Authoritative Server</title>
  38. <para>To set up an authoritative zone for RFC 5011 trust anchor
  39. maintenance, generate two (or more) key signing keys (KSKs) for
  40. the zone. Sign the zone with one of them; this is the "active"
  41. KSK. All KSK's which do not sign the zone are "stand-by"
  42. keys.</para>
  43. <para>Any validating resolver which is configured to use the
  44. active KSK as an RFC 5011-managed trust anchor will take note
  45. of the stand-by KSKs in the zone's DNSKEY RRset, and store them
  46. for future reference. The resolver will recheck the zone
  47. periodically, and after 30 days, if the new key is still there,
  48. then the key will be accepted by the resolver as a valid trust
  49. anchor for the zone. Any time after this 30-day acceptance
  50. timer has completed, the active KSK can be revoked, and the
  51. zone can be "rolled over" to the newly accepted key.</para>
  52. <para>The easiest way to place a stand-by key in a zone is to
  53. use the "smart signing" features of
  54. <command>dnssec-keygen</command> and
  55. <command>dnssec-signzone</command>. If a key with a publication
  56. date in the past, but an activation date which is unset or in
  57. the future, "
  58. <command>dnssec-signzone -S</command>" will include the DNSKEY
  59. record in the zone, but will not sign with it:</para>
  60. <screen>
  61. $ <userinput>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</userinput>
  62. $ <userinput>dnssec-signzone -S -K keys example.net</userinput>
  63. </screen>
  64. <para>To revoke a key, the new command
  65. <command>dnssec-revoke</command> has been added. This adds the
  66. REVOKED bit to the key flags and re-generates the
  67. <filename>K*.key</filename> and
  68. <filename>K*.private</filename> files.</para>
  69. <para>After revoking the active key, the zone must be signed
  70. with both the revoked KSK and the new active KSK. (Smart
  71. signing takes care of this automatically.)</para>
  72. <para>Once a key has been revoked and used to sign the DNSKEY
  73. RRset in which it appears, that key will never again be
  74. accepted as a valid trust anchor by the resolver. However,
  75. validation can proceed using the new active key (which had been
  76. accepted by the resolver when it was a stand-by key).</para>
  77. <para>See RFC 5011 for more details on key rollover
  78. scenarios.</para>
  79. <para>When a key has been revoked, its key ID changes,
  80. increasing by 128, and wrapping around at 65535. So, for
  81. example, the key "<filename>Kexample.com.+005+10000</filename>" becomes
  82. "<filename>Kexample.com.+005+10128</filename>".</para>
  83. <para>If two keys have ID's exactly 128 apart, and one is
  84. revoked, then the two key ID's will collide, causing several
  85. problems. To prevent this,
  86. <command>dnssec-keygen</command> will not generate a new key if
  87. another key is present which may collide. This checking will
  88. only occur if the new keys are written to the same directory
  89. which holds all other keys in use for that zone.</para>
  90. <para>Older versions of BIND 9 did not have this precaution.
  91. Exercise caution if using key revocation on keys that were
  92. generated by previous releases, or if using keys stored in
  93. multiple directories or on multiple machines.</para>
  94. <para>It is expected that a future release of BIND 9 will
  95. address this problem in a different way, by storing revoked
  96. keys with their original unrevoked key ID's.</para>
  97. </sect2>
  98. </sect1>