Also see thread starting at: http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
In a discussion between Olaf and Ed, Ed was the last to reply: > > >> #3.6 Private Key Storage > >> # > >> # It is recommended that, where possible, zone private keys and the > >> # zone file master copy be kept and used in off-line, non-network > >> # connected, physically secure machines only. Periodically an > >> # application can be run to add authentication to a zone by adding > >> # RRSIG and NSEC RRs. Then the augmented file can be transferred, > >> > >> The problem with this recommendation is that a lot of the upper > >> (sensitive) > >> zones have a "response time" pressure that pushes them to use > >>dynamic update. > >> Currently, dynamic update (tools) don't allow the inclusion of signatures, > >> this might have to be fixed. Left in limbo is the recommendation to > >> keep keys entirely off-line. > > > >I understand your observation but I find it difficult to turn this > >into document text. Do you have a suggestion? > > Maybe... > > When relying on dynamic update to manage a signed zone, be aware that > at least one zone's private key will have to reside on the master > server. This key is only as secure as the amount of exposure the > server receives to unknown clients and the security of the host. > Although not mandatory, administering DNS in this manner benefits if > the master is unavailable to the Internet, not listed in the NS > RRSet, an approach known as a "hidden master." > > (Don't know if we've ever defined "hidden master." > > >> # perhaps by sneaker-net, to the networked zone primary server machine. > >> > >> It's ironic that this basic tenet of the DNSSEC world is somewhat out of > >> whack with what are labeled as the most sensitive zones. > > > >The irony is not intentional. How can we improve? > > I think it's a case of time passing the technology by. When we > started this process registries ran much slower. We've added dynamic > update, IXFR, etc., and there has been a demand for immediate > gratification when registering domain names. > > The only way around this was to have DNSSECbis happen years ago. ;) -- I added the paragraph, although I made it a little more verbose. 3.6 Private Key Storage It is recommended that, where possible, zone private keys and the zone file master copy be kept and used in off-line, non-network connected, physically secure machines only. Periodically an application can be run to add authentication to a zone by adding and NSEC RRs. Then the augmented file can be transferred, When relying on dynamic update to manage a signed zone, be aware that at least one zone's private key will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set although it's name appears in the SOA RRs MNAME field. The nameservers in the NS RR set are able to receive zone updates through NOTIFY, IXFR, AXFR or out-of-band distribution mechanisms. This approach is known as the "hidden master" setup. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
