[dns-operations] BIND 9.7 in-band signalling for automatic signing

[João Damas]

Interesting...

On 15 Dec 2009, at 17:00, João Damas wrote:

> 
>> From the instructions bundled with BIND 9.7, it seems that the dynamic update way of initiating automatic signing with this new version (it's a new, nice, feature) is by sending a dynamic update to create an NSEC3PARAM RR. So far so good.
> Now, if you also want to tell it to use opt-out the chosen approach seems to be to set the opt-out flag in that new NSEC3PARAM RR. Currently, the RFC says:
> 
>> 4.1.2.  Flag Fields
>> 
>> 
>> The Opt-Out flag is not used and is set to zero.
>> 
>> All other flags are reserved for future use, and must be zero.
>> 
>> NSEC3PARAM RRs with a Flags field value other than zero MUST be
>> ignored.
> 
> the first sentence is not a must, not sure what sort of declaration it is, really.
> The third sentence, however, is quite damning.
> 
> Question is: Is this NSEC3PARAM going to cause interoperability problem with secondary servers not running BIND that discard it because it is not conformant? What other surprises will this trigger? Are others taking the liberal approach of just ignoring the flags since sw is not meant to do anything with them right now?

a zone signed with BIND's named-signzone does show an NSEC3PARAM with opt-out cleared even if the input file had it set (cool!)
a zone served by BIND where the source file (or a zone that had the record added via dynupd) had an NSEC3PARAM with opt-put set (which you need to trigger opt-out signing using the new auto-dnssec option) is published with the opt-out flag set.

Same source, two tools, two outputs :)

Good news is that my main concern, that this would cause problems with other servers, is not so, at least for NSD which is happy to compile a zone and serve it with the NSEC3PARAM opt-out flag set.

In any case, it would be good, given the wording of the RFC, if BIND where to clear that flag any time the NSEC3PARAM gets exposed to the outside.

Joao