RE: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 NSEC3), without mentioning the link with the algorithm without mentioning the consequences if chain-of-trust is established (and (DNSSEC) data might be cached out there) is probably not the right thing to do. (given recent contributions in this list that DNSSEC management is not easy ...) Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- ... (Also, if you want to switch to NSEC instead of NSEC3, you can use 'rndc signing -nsec3param none'.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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/07/12 00:10, Wolfgang Nagele wrote:
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 Systems and Network Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne, Victoria, Australia, 3004
Phone +61 3 9090 1756
Email: wolfgang.nag...@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 6, 2012, at 6:55 PM, Evan Hunt wrote:
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 the inline signer atm is to run 'rndc -nsec3param' once the zone has
been configured. Any hints?
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;
};
$ rndc signing -nsec3param 1 0 10 BEEF example.nil
$ rndc signing -list example.nil
Pending NSEC3 chain 1 0 10 BEEF
$ dnssec-keygen -3 example.nil
Generating key pair.++
..++
Kexample.nil.+007+28952
$ dnssec-keygen -3fk example.nil
Generating key pair...+++
..+++
Kexample.nil.+007+04053
$ rndc loadkeys example.nil
$ sbin/rndc signing -list example.nil
Done signing with key 4053/NSEC3RSASHA1
Done signing with key 28952/NSEC3RSASHA1
$ dig @localhost +short nsec3param example.nil
1 0 10 BEEF
--
Evan Hunt -- each@isc.orggg
Internet Systema Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 unfriendly to use it unless you really need it, because you're increasing the load on everyone else. It's unclear to me how many people have genuine concerns with zone walking that NSEC3 is an appropriate response to; putting sensitive names in a private subdomain or using split DNS would seems to be safer if you're concerned about tex hax0rs getting a list of all your machines (and don't forget to remove them all from reverse DNS, which takes minutes to walk given a target /16) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 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 would feel more comfortable with an explicit configuration-option in named.conf, rather than a seperate action (being 'rndc signing -nsec3param'). (In the case I *really* want NSEC3 that is, naturally) Regards, -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 would feel more comfortable with an explicit configuration-option in named.conf, rather than a seperate action (being 'rndc signing -nsec3param'). (In the case I *really* want NSEC3 that is, naturally) Ah sorry, I misunderstood you. Can't comment on the NSEC3 usability side of things; it's not something I've ever used outside the lab, and I didn't find it particularly onerous. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 7, you'll need to roll to a new algorithm first. However, any algorithm that supports NSEC3 also supports NSEC, so if you decide you don't want NSEC3 and want to revert, you can do so quite easily. I always recommend using 'dnssec-keygen -3' when generating keys, in order to keep one's options open, even though I *don't* recommend NSEC3 for most people. (It places additional computational burdens on both the recursive and authoritative servers, for benefits that are relatively limited if you're not a TLD operator.) I expect we'll switch to using -3 as the default in some future release. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 previously-existing algorithm is sort of a signaling mechanism: it tells older resolvers that you're using a newer version of the DNSSEC specification than they're equipped to deal with . But it doesn't mean NSEC3 is required, or even expected. Interesting way of looking at it. Algo 7 is mentioned in RFC5155. It tells older resolvers your are using a newer version of DNSSEC. Sure it does, namely a version that supports NSEC3, right? Now why would you want to do that? Because either you are doing NSEC3, or you are planning to do so in the foreseeable future. It's kind of a trade-off, I suppose: - 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). Are there still any 'older' resolvers around? Maybe not... Anyway, thanks for your insights! -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
- 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). Yes, exactly. Are there still any 'older' resolvers around? Maybe not... Fewer and fewer, and they mostly aren't using DNSSEC. (They can't validate the root zone, after all.) But after some discussion last year, we still felt it was too soon to update the default algorithm in dnssec-keygen. Maybe in 9.10. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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;
};
$ rndc signing -nsec3param 1 0 10 BEEF example.nil
$ rndc signing -list example.nil
Pending NSEC3 chain 1 0 10 BEEF
$ dnssec-keygen -3 example.nil
Generating key pair.++
..++
Kexample.nil.+007+28952
$ dnssec-keygen -3fk example.nil
Generating key pair...+++
..+++
Kexample.nil.+007+04053
$ rndc loadkeys example.nil
$ sbin/rndc signing -list example.nil
Done signing with key 4053/NSEC3RSASHA1
Done signing with key 28952/NSEC3RSASHA1
$ dig @localhost +short nsec3param example.nil
1 0 10 BEEF
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?
Axel
---
PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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. However, whenever you do wish to change them, you can do so with 'rndc signing -nsec3param', and the chain will be updated automatically. (Also, if you want to switch to NSEC instead of NSEC3, you can use 'rndc signing -nsec3param none'.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 supposed it would notice changes of $INCLUDEd DS or NSEC3PARAM RR automagically and act upon. So my script has to do these 3 steps on changing NSEC3PARAM: 1. create new NSEC3PARAM (replacing $INCLUDED file) 2. increment SOA serial 3. rndc signing -nsec3param myZone? Thanks, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 Systems and Network Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne, Victoria, Australia, 3004
Phone +61 3 9090 1756
Email: wolfgang.nag...@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 6, 2012, at 6:55 PM, Evan Hunt wrote:
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 the inline signer atm is to run 'rndc -nsec3param' once the zone has
been configured. Any hints?
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;
};
$ rndc signing -nsec3param 1 0 10 BEEF example.nil
$ rndc signing -list example.nil
Pending NSEC3 chain 1 0 10 BEEF
$ dnssec-keygen -3 example.nil
Generating key pair.++
..++
Kexample.nil.+007+28952
$ dnssec-keygen -3fk example.nil
Generating key pair...+++
..+++
Kexample.nil.+007+04053
$ rndc loadkeys example.nil
$ sbin/rndc signing -list example.nil
Done signing with key 4053/NSEC3RSASHA1
Done signing with key 28952/NSEC3RSASHA1
$ dig @localhost +short nsec3param example.nil
1 0 10 BEEF
--
Evan Hunt -- each@isc.orggg
Internet Systema Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 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 on changing NSEC3PARAM: 1. create new NSEC3PARAM (replacing $INCLUDED file) 2. increment SOA serial 3. rndc signing -nsec3param myZone? Thanks, Axel NSEC3PARAM records should be generated by the signing software and not just be added to the zone. Their presence/absence changes how the zone is served. In particular how negative and wildcard responses are generated. named stages the introduction/removal of NSEC3 chains and their associated NEC3PARAM records. named also stages the introduction/removal of NSEC records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 generated. And how is that different from sending them in from a trusted source (your unsigned version, hopefully using TSIG) VS sending them in via another trusted source (rndc)? Cheers, Wolfgang ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 thing to do. Why complicate matters by having to use rndc here? Because NSEC3PARAM is in-band signaling. With NSEC you have the apex's NSEC record presence/absence as a signal. With NSEC3 you have multiple NSEC3 chains and you need to know the NSEC3 parameters to find the NSEC3 record for the apex. One could do that by tracking all the NSEC3 records on a per parameter set basis then looking for the presence/absence of the NSEC3 record for the apex or use a seperate type NSEC3PARAM. With both NSEC and NSEC3 you can have partial chains, to support incremental signing, and you don't want to use them until they are complete. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 presence/absence changes how the zone is served. In particular how negative and wildcard responses are generated. And how is that different from sending them in from a trusted source (your = unsigned version, hopefully using TSIG) VS sending them in via another trus= ted source (rndc)? 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. Cheers, Wolfgang= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 just add complexity by having the user enter the same information twice and possibly failing to do it right. Cheers, Wolfgang ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 9090 1756 Email: wolfgang.nag...@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 -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
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 the inline signer atm is to run 'rndc -nsec3param' once the zone has
been configured. Any hints?
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;
};
$ rndc signing -nsec3param 1 0 10 BEEF example.nil
$ rndc signing -list example.nil
Pending NSEC3 chain 1 0 10 BEEF
$ dnssec-keygen -3 example.nil
Generating key pair.++
..++
Kexample.nil.+007+28952
$ dnssec-keygen -3fk example.nil
Generating key pair...+++
..+++
Kexample.nil.+007+04053
$ rndc loadkeys example.nil
$ sbin/rndc signing -list example.nil
Done signing with key 4053/NSEC3RSASHA1
Done signing with key 28952/NSEC3RSASHA1
$ dig @localhost +short nsec3param example.nil
1 0 10 BEEF
--
Evan Hunt -- each@isc.orggg
Internet Systema Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.9.0 is now available
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 alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] just by signing? so I can spare all our domains from being misused by such shit just by signing them? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fucking windows! Bring Bill Gates! (Southpark the movie) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.9.0 is now available
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 recursive nameserver to provide alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] just by signing? so I can spare all our domains from being misused by such shit just by signing them? For the bind implementation, yes. For the zillions of other crappy DNS servers and providers that to NXDOMAIN redirection, probably not. (If the *clients* did DNSSEC-checking, then yes) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.9.0 is now available
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 no such domain. This allows a recursive nameserver to provide alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] just by signing? so I can spare all our domains from being misused by such shit just by signing them? That's one half of it; the queries also need to request DNSSEC (EDNS DO=1). One or the other, by itself, isn't enough. This applies to both NXDOMAIN rewriting and RPZ, as of 9.9.0 (the RPZ behavior changed during the 9.9.0 development process). Bill. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.9.0 is now available
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 nameserver to provide alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] just by signing? so I can spare all our domains from being misused by such shit just by signing them? Not entirely, but it'll help, yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.9.0 is now available
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 be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for Microsoft Windows operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features The new inline-signing option, in combination with the auto-dnssec option that was introduced in BIND 9.7, allows named to sign zones completely transparently. Previously automatic zone signing only worked on master zones that were configured to be dynamic; now, it works on any master or slave zone. In a master zone with inline signing, the zone is loaded from disk as usual, and a second copy of the zone is created to hold the signed version. The original zone file is not touched; all comments remain intact. When you edit the zone file and reload, named detects the incremental changes that have been made to the raw version of the zone, and applies those changes to the signed version, adding signatures as needed. A slave zone with inline signing works similarly, except that instead of loading the zone from disk and then signing it, the slave transfers the zone from a master server and then signs it. This enables bump in the wire signing: a dedicated signing server acting as an intermediary between a hidden master server (which provides the raw zone data) and a set of publicly accessible slave servers (which only serve the signed data). [RT #26224/23657] 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 alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] rndc flushtree name command removes the specified name and all names under it from the cache. [RT #19970] rndc sync command dumps pending changes in a dynamic zone to disk without a freeze/thaw cycle. rndc sync -clean removes the journal file after syncing. rndc freeze no longer removes journal files. [RT #22473] The new rndc signing command provides greater visibility and control of the automatic DNSSEC signing process. Options to this new command include -list zone which will show the current state of signing operations overall or per specified zone. [RT #23729] auto-dnssec zones can now have NSEC3 parameters set prior to signing. [RT #23684] Improves the startup time for an authoritative server with a large number of zones by making the zone task table of variable size rather than fixed size. This means that authoritative servers with many zones will be serving that zone data much sooner. [RT #24406] Improves scalability by using multiple threads to listen for and process queries. Previously named only listened for queries on one thread regardless of the number of overall threads used. [RT #22992] Improves startup and reconfiguration time by allowing zones to load in multiple threads. [RT #25333] Improves initial start-up and server reload time by increasing the default size of the hash table the configuration parser uses to keep track of loaded zones and allowing it to grow dynamically to better handle systems with large numbers of zones. [RT #26523] The also-notify option now takes the same syntax as masters, thus it can use named master lists and TSIG keys. [RT #23508] The dnssec-signzone -D option causes dnssec-signzone to write DNSSEC data to a separate output file. This allows you to put $INCLUDE example.com.signed into the zonefile for example.com, run dnssec-signzone -SD example.com, and the result is a fully signed zone which did *not* overwrite your original zone file. Running the same command again will incrementally re-sign the zone, replacing only those signatures that need updating, rather than signing the entire zone from scratch. [RT #22896] dnssec-signzone -R forces removal of signatures that are not expired but were created by a key which no longer exists. [RT #22471] dnssec-signzone -X option allows signatures on DNSKEY records to have a different expiration date from other signatures. This makes it
