Introduction
BIND 9.9.0 is the first production release of BIND 9.9.
This document summarizes changes from BIND 9.8 to BIND 9.9.
Please see the CHANGES file in the source code release for a
complete list of all changes.
Download
The latest versions of BIND 9 software can always b
On 29.02.12 17:53, Michael McNally wrote:
NXDOMAIN redirection is now possible. This enables a resolver
to respond to a client with locally-configured information
when a query would otherwise have gotten an answer of "no
such domain". This allows a recursive nameserver to provide
altern
On 02/03/12 10:13, Matus UHLAR - fantomas wrote:
On 29.02.12 17:53, Michael McNally wrote:
NXDOMAIN redirection is now possible. This enables a resolver
to respond to a client with locally-configured information
when a query would otherwise have gotten an answer of "no
such domain". This allows
On Fri, Mar 02, 2012 at 11:13:06AM +0100, Matus UHLAR - fantomas wrote:
> On 29.02.12 17:53, Michael McNally wrote:
> > NXDOMAIN redirection is now possible. This enables a resolver
> > to respond to a client with locally-configured information
> > when a query would otherwise have gotten an ans
On Fri, Mar 02, 2012 at 11:13:06AM +0100, Matus UHLAR - fantomas wrote:
> > NXDOMAIN redirection is now possible. This enables a resolver
> > to respond to a client with locally-configured information
> > when a query would otherwise have gotten an answer of "no
> > such domain". This allows a
Hi,
> "auto-dnssec" zones can now have NSEC3 parameters set prior
> to signing. [RT #23684]
According to the docs it should be possible to set NSEC3PARAM on the unsigned
version when using inline-signer mode. The signing BIND 9.9 should then decide
to use NSEC3, which salt, opt-out, etc. bas
> According to the docs it should be possible to set NSEC3PARAM on the
> unsigned version when using inline-signer mode. The signing BIND 9.9
> should then decide to use NSEC3, which salt, opt-out, etc. based on this.
> I have tried this and could not get it to work. The only way to use NSEC3
> wit
Am 06.03.2012 um 08:55 schrieb Evan Hunt:
> You should be able to use 'rndc signing -nsec3param' before the zone
> is signed. It's working for me:
>
>zone "example.nil" {
>type master;
>inline-signing yes;
>auto-dnssec maintain;
>file "example
> So, I have to do this again, if the NSEC3PARAM changes (e.g. with a
> different salt during ZSK rollover)? Or does auto-dnssec maintain take
> care on the changed NSEC3PARAM?
I'm not sure I understand the question; there's no requirement that
you change the NSEC3 parameters during a key roll.
Am 06.03.2012 um 17:28 schrieb Evan Hunt:
> However, whenever you do wish to change them,
Yes.
> you can do so with
> 'rndc signing -nsec3param', and the chain will be updated automatically.
I see.
As named is looking periodically for appearing/disappearing or changed keys in
the key directory,
On Tue, Mar 06, 2012 at 05:52:05PM +0100, Axel Rau wrote:
> As named is looking periodically for appearing/disappearing or changed
> keys in the key directory, I supposed it would notice changes of
> $INCLUDEd DS or NSEC3PARAM RR automagically and act upon.
>
> So my script has to do these 3 steps
Hi,
Ok that is already a bit better - at least saves a full sign with NSEC first.
Wondering though, from a user perspective sending in NSEC3PARAM from the
unsigned end seems like the most natural thing to do. Why complicate matters by
having to use rndc here?
Cheers,
--
Wolfgang Nagele
Senior
In message , Axel Rau writes:
>
> Am 06.03.2012 um 17:28 schrieb Evan Hunt:
>
> > However, whenever you do wish to change them,
> Yes.
> > you can do so with
> > 'rndc signing -nsec3param', and the chain will be updated automatically.
> I see.
> As named is looking periodically for appearing/dis
Hi,
> NSEC3PARAM records should be generated by the signing software and
> not just be added to the zone.
Who says that? :) I think that is a matter of implementation and preference.
> Their presence/absence changes how
> the zone is served. In particular how negative and wildcard responses
> ar
In message , Wolfgang
Nagele writes:
> Hi,
>
> Ok that is already a bit better - at least saves a full sign with NSEC first.
> Wondering though, from a user perspective sending in NSEC3PARAM from the uns
> igned end seems like the most natural thing to do. Why complicate matters by
> having to
In message <32660394-6c37-4268-9f36-1e73996dc...@ausregistry.com.au>, Wolfgang
Nagele writes:
> Hi,
>
> > NSEC3PARAM records should be generated by the signing software and
> > not just be added to the zone.
> Who says that? :) I think that is a matter of implementation and preference=
> .
>
>
Hi,
> NSEC3PARM is not supposed to be present in a unsigned zone. rndc doesn't
> add them to the zone. It tells the signing component to generate a NSEC3
> chain and when that is complete to add the NSEC3PARAM record.
Nothing says so in the specs: http://tools.ietf.org/html/rfc5155#section-4
Yo
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
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.
Cheers,
--
Wolfgang Nagele
Senior Systems and Network Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne, Victoria, Australia, 3004
Phone +61 3 909
Switch from NSEC to NSEC3 !!!
This is a statement with potentially huge consequences, IMHO.
Only valid where DNSSEC algorithms allow either method
(like algo #8 and algo #10, unsure about others).
For algorithm like #5, NSEC is implied.
So suggesting that it is easy to switch (between NSEC and N
Hi,
It is not possible to configure NSEC3 as a default in named.conf (on a
per zone basis), is it? I would welcome such a feature.
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
Thanks.
--
Marco
On 03/0
On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
AS I understand it, NSEC3 incurs overhead at validating resolvers. That
being the case, it is unfriendl
Phil,
On 03/07/12 10:27, Phil Mayers wrote:
> On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:
>
>> I also find it a bit strange that BIND decides to go for NSEC, even when
>> the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
>>
> AS I understand it, NSEC3 incurs overhead at vali
On 03/07/2012 09:38 AM, Marco Davids (SIDN) wrote:
AS I understand it, NSEC3 incurs overhead at validating resolvers. That
being the case, it is unfriendly to use it unless you really need it
I don't have a problem with that. It's just that I find the current way
BIND works a bit tricky. I wou
On Wed, Mar 07, 2012 at 09:30:06AM +0100, Marc Lampo wrote:
> Switch from NSEC to NSEC3 !!!
> This is a statement with potentially huge consequences, IMHO.
I said "NSEC3 to NSEC", actually.
As you noted, switching from NSEC to NSEC3 requires planning: if your
domain uses a DNSKEY algorithm less t
> It is not possible to configure NSEC3 as a default in named.conf (on a
> per zone basis), is it? I would welcome such a feature.
I considered it, but bogged down on issues like what to do if you have
nsec3 parameters set a certain way in named.conf, then change them in the
running zone, then res
On 03-07-12 18:08, Evan Hunt wrote:
>> I also find it a bit strange that BIND decides to go for NSEC, even when
>> the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
>
> There's no difference between algorithm 7 and algorithm 5 (RSASHA1).
> The use of a new algorithm number for a pre
> - use algo 7 with NSEC allows you to move to NSEC3 without much hassle
> (but older resolvers won't validate your replies meanwhile)
>
> - use algo 5 with NSEC and you have to do a algorithm rollover first
> when you want to move to NSEC3 (but meanwhile, older resolvers will
> validate your repl
28 matches
Mail list logo