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
20 matches
Mail list logo
