> - 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
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
> 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 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
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
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 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
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
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 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
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,
> 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
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=
> .
>
>
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
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 , 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,
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
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
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,
> 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 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
> 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
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
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
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 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 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
27 matches
Mail list logo
