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
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
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
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 validating
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
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 than
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
- 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 replies).
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 example1.db;
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, I
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
In message e5c102c2-758f-407e-8970-23b60dce7...@chaos1.de, 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
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
are
In message dafe4c5a-daa9-4d54-8963-a56d9cd9f...@ausregistry.com.au, 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
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=
.
Their
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
You
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
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
with
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
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 a
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 answer of
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 recursive
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
25 matches
Mail list logo
