NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

Wolfgang Nagele wolfgang.nagele at ausregistry.com.au
Wed Mar 7 02:00:50 UTC 2012

Hi Evan,

That's true there is a case here. This way around it makes sense to have that rndc call. Thanks for clearing this one up.


Wolfgang Nagele
Senior Systems and Network Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne, Victoria, Australia, 3004
Phone +61 3 9090 1756
Email: wolfgang.nagele at ausregistry.com.au
Web: www.ausregistry.com.au

The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.

On Mar 7, 2012, at 12:49 PM, Evan Hunt wrote:

> On Wed, Mar 07, 2012 at 10:33:24AM +1100, Wolfgang Nagele wrote:
>> Nothing says so in the specs: http://tools.ietf.org/html/rfc5155#section-4
> It does, actually:  "The presence of an NSEC3PARAM RR at a zone apex
> indicates that the specified parameters may be used by authoritative
> servers to choose an appropriate set of NSEC3 RRs for negative responses."
> In other words, by putting NSEC3PARAM in place, you're telling your
> slaves that they can rely on the existence of a full and complete NSEC3
> chain matching those parameters.  If the zone isn't signed yet, or the
> NSEC3 chain isn't fully generated yet, then that could cause breakage.
> The way we work around this is by using a special private-type record
> (TYPE65534, by default) into the zone, which contains your intended NSEC3
> parameters.  After named has finished generating the chain, it removes
> the private record.  (You could insert this record into the unsigned
> zone if you wanted to, and it would work, but using rndc is a lot
> easier.)
> -- 
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.

More information about the bind-users mailing list