feature survey -- bind9 dnssec -- autogenerate missing signatures

Jim Reid jim at rfc1035.com
Wed Sep 3 12:11:43 UTC 2008


On Sep 3, 2008, at 12:53, Francis Dupont wrote:

> In your previous mail you wrote:
>
>   I'm not sure this is a good idea because the people who are most
>   likely to use this feature will probably be unaware of the risks of
>   having the signing key on-line and won't have taken suitable
>   precautions.
>
> => note the signing key doesn't need to be on-line, only the signing
> capability has to be available on-line (there are two common ways to
> provide this: the signing key on-line and a protected key store,
> something you can find in HSMs (Hardware Security Modules). In the
> second case it is possible to make the private key not extractable
> (and with FIPS 140-2 HSMs certified at high levels, really not  
> possible),
> i.e., you can only abuse of the signing function).

Francis, this is all very well. People with DNSSEC clue will use these  
sorts of beasts because they understand why keys need to be properly  
protected. I'm far from convinced the typical DNS admin (no DNSSEC  
clue) will understand this or deploy these sorts of measures if they  
sign their zones. They'll inevitably take the path of least  
resistance. Which would most probably mean on-the-fly background  
signing if that was available and the actual signing key on-line and  
in cleartext on the master server.

>   They're also likely to be the people that will be
>   startled by the SOA serial number magically changing as a result  
> of on
>   the fly signing.
>
> => it is already the case for dynamic updates (which is strongly  
> related
> to on-line (re-)signing).

True. but if people are using dynamic DNS, there is already an  
expectation that the SOA serial number changes "at random". This is  
unlikely to be the case for the on-the-fly background signing that  
Paul proposed.


More information about the bind-workers mailing list