dnssec-lookaside != auto
Hello everyone, I've recently updated bind to version 9.7.2_p3. I've been using DLV before that, specifically dlv.isc.org, with two entries in named.conf options { dnssec-lookaside . trust-anchor dlv.isc.org.; }; trusted-keys{ [sometext] }; and it was working fine. However, on update I've wanted to try managed-keys. so changed trusted-keys to managed-keys (and added initial key of course) so the relevant part of config file now looks like this: managed-keys { dlv.isc.org. initial-key 257 3 5 "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; }; this has caused problem, every query caused error, no answers and these log entries: Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org DNSKEY: must be secure failure, . is under DLV (startfinddlvsep) Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53 After some googling and finding http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html and even better http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html I've changed to dnssec-lookaside auto. Lo and behold, everything works fine. However, this presents the following problems to me: - managed keys does not work as advertised: In bind manual (PDF downloaded from http://www.bind9.net/manuals), it's said that managed-keys is similar to trusted-keys, but where key in trusted-keys is static and trusted as long as it's in config file, key in managed-keys is trusted only once, to download this key and store it in trusted database. This proves to be wrong, as it's not trusted even that one time. - I don't seem to be able to switch to another DLV registry. dnssec-lookaside accepts only auto, so I have no choice but to use built-in DLV. But, e.g. secspider.cs.ucla.edu looks interesting. Can anyone shed some light if this is my mistake, not having something in configuration, or a general bind error? Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
On Dec 19 2010, Torinthiel wrote: Hello everyone, I've recently updated bind to version 9.7.2_p3. I've been using DLV before that, specifically dlv.isc.org, with two entries in named.conf options { dnssec-lookaside . trust-anchor dlv.isc.org.; }; trusted-keys{ [sometext] }; and it was working fine. However, on update I've wanted to try managed-keys. so changed trusted-keys to managed-keys (and added initial key of course) so the relevant part of config file now looks like this: managed-keys { dlv.isc.org. initial-key 257 3 5 "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; }; this has caused problem, every query caused error, no answers and these log entries: Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org DNSKEY: must be secure failure, . is under DLV (startfinddlvsep) Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53 One suspects some transcription error in the trust anchor, but I admit I can't find one in the copy above. After some googling and finding http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html and even better http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html I've changed to dnssec-lookaside auto. Lo and behold, everything works fine. "dnssec-lookaside auto" just imports the managed-keys statement from [source-tree]/bind.keys. Compare that carefully with your explicit managed-keys statement. We are using managed-keys with explicit entries (not auto) for dlv.isc.org and for the root zone (it's strange that you don't mention a trust anchor for the root zone), and it works fine (modulo the remarks at the end: just as well as a trusted-keys statement would, anyway). However, this presents the following problems to me: - managed keys does not work as advertised: In bind manual (PDF downloaded from http://www.bind9.net/manuals), it's said that managed-keys is similar to trusted-keys, but where key in trusted-keys is static and trusted as long as it's in config file, key in managed-keys is trusted only once, to download this key and store it in trusted database. This proves to be wrong, as it's not trusted even that one time. - I don't seem to be able to switch to another DLV registry. dnssec-lookaside accepts only auto, so I have no choice but to use built-in DLV. But, e.g. secspider.cs.ucla.edu looks interesting. Can anyone shed some light if this is my mistake, not having something in configuration, or a general bind error? You are doing something wrong, as it works for the rest of us. However ... when all is said and done, using managed-keys rather than trusted-keys has very limited value at the moment, if you are only going to it for dlv.isc.org and the root (and of course you should *not* use it for any trust anchor for which RFC 5011 compatible rollovers have not been promised). Neither is likely to be rolled over without a lot of publicity, and the managed-keys code still has the bug described at https://lists.isc.org/pipermail/bind-users/2010-October/081399.html -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
In message <4d0e8340.9060...@data.pl>, Torinthiel writes: > Hello everyone, > > I've recently updated bind to version 9.7.2_p3. Upgraded from what? > I've been using DLV before that, specifically dlv.isc.org, with two > entries in named.conf > > options { > dnssec-lookaside . trust-anchor dlv.isc.org.; > }; > trusted-keys{ > [sometext] > }; > > and it was working fine. > However, on update I've wanted to try managed-keys. so changed > trusted-keys to managed-keys (and added initial key of course) > > so the relevant part of config file now looks like this: > > managed-keys { > dlv.isc.org. initial-key 257 3 5 > "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 > brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ > 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 > ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk > Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM > QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; > }; > > > this has caused problem, every query caused error, no answers and these > log entries: > > Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org > DNSKEY: must be secure failure, . is under DLV (startfinddlvsep) > Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving > 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53 And what other errors were logged by named when it started? > After some googling and finding > http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html > and even better > http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html > > I've changed to dnssec-lookaside auto. Lo and behold, everything works fine. And the contents of /etc/bind.key are? Also the contents in the chroot area if you are using chroot. > However, this presents the following problems to me: > - managed keys does not work as advertised: > In bind manual (PDF downloaded from http://www.bind9.net/manuals), it's > said that managed-keys is similar to trusted-keys, but where key in > trusted-keys is static and trusted as long as it's in config file, key > in managed-keys is trusted only once, to download this key and store it > in trusted database. This proves to be wrong, as it's not trusted even > that one time. > > - I don't seem to be able to switch to another DLV registry. > dnssec-lookaside accepts only auto, so I have no choice but to use > built-in DLV. But, e.g. secspider.cs.ucla.edu looks interesting. > > Can anyone shed some light if this is my mistake, not having something > in configuration, or a general bind error? > > Regards, > Torinthiel > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
On 12/20/10 01:32, Mark Andrews wrote: > In message <4d0e8340.9060...@data.pl>, Torinthiel writes: > >> Hello everyone, >> >> I've recently updated bind to version 9.7.2_p3. >> > Upgraded from what? > >From 9.4.3_p5 > > >> I've been using DLV before that, specifically dlv.isc.org, with two >> entries in named.conf >> >> options { >> dnssec-lookaside . trust-anchor dlv.isc.org.; >> }; >> trusted-keys{ >> [sometext] >> }; >> >> and it was working fine. >> However, on update I've wanted to try managed-keys. so changed >> trusted-keys to managed-keys (and added initial key of course) >> >> so the relevant part of config file now looks like this: >> >> managed-keys { >> dlv.isc.org. initial-key 257 3 5 >> "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 >> brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ >> 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 >> ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk >> Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM >> QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; >> }; >> >> >> this has caused problem, every query caused error, no answers and these >> log entries: >> >> Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org >> DNSKEY: must be secure failure, . is under DLV (startfinddlvsep) >> Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving >> 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53 >> > And what other errors were logged by named when it started? > None. Complete startup log sequence: Dec 20 07:49:14 sarlac named[4137]: loading configuration from '/etc/bind/named.conf' Dec 20 07:49:14 sarlac named[4137]: reading built-in trusted keys from file '/etc/bind/bind.keys' Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv4 port range: [1024, 65535] Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv6 port range: [1024, 65535] Dec 20 07:49:14 sarlac named[4137]: set up managed keys zone for view _default, file 'managed-keys.bind' Dec 20 07:49:14 sarlac named[4137]: reloading configuration succeeded Dec 20 07:49:15 sarlac named[4137]: managed-keys-zone ./IN: loaded serial 16 Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: loaded serial 2010110801 Dec 20 07:49:15 sarlac named[4137]: reloading zones succeeded Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: sending notifies (serial 2010110801) > > >> After some googling and finding >> http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html >> and even better >> http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html >> >> I've changed to dnssec-lookaside auto. Lo and behold, everything works fine. >> > And the contents of /etc/bind.key are? Also the contents in the > chroot area if you are using chroot. > Changed /etc/bind.keys to /etc/bind/bind.keys, via config (and it reeds it, you can see in logs). Contents were given in first post, only I haven't mentioned it was in /etc/bind/bind.keys. The managed-keys statement is the sole statement in /etc/bind/bind.keys and is not present in main config file. Ok, this was the problem. Having included the file as well as specified it at bindkeys-file seems to have solved the problem. Ok, now the documentation seems a bit unclear about it. It never states that the file is included nor that it's not. But having information that it loads the given file (in dnssec-lookaside description) and information that file is loaded in logs has given me a false sense of security in this case. Is this double-include (sort of) configuration what I was supposed to do? Will it work correctly after a key rollover? Also, another question arises: can one include more than one bindkeys-file and/or dnssec-lookaside in config? The documentation hints that at least the latter is possigble, but does not state so. And having multiple bindkeys-file is useful if you have locally-configured keys, for which using the main file is not recommended. Skipping rest of answers, as problem is (mostly) solved. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
In message <4d0f00dd.9060...@data.pl>, Torinthiel writes: > On 12/20/10 01:32, Mark Andrews wrote: > > In message <4d0e8340.9060...@data.pl>, Torinthiel writes: > > > >> Hello everyone, > >> > >> I've recently updated bind to version 9.7.2_p3. > >> > > Upgraded from what? > > > > >From 9.4.3_p5 > > > > > > >> I've been using DLV before that, specifically dlv.isc.org, with two > >> entries in named.conf > >> > >> options { > >> dnssec-lookaside . trust-anchor dlv.isc.org.; > >> }; > >> trusted-keys{ > >> [sometext] > >> }; > >> > >> and it was working fine. > >> However, on update I've wanted to try managed-keys. so changed > >> trusted-keys to managed-keys (and added initial key of course) > >> > >> so the relevant part of config file now looks like this: > >> > >> managed-keys { > >> dlv.isc.org. initial-key 257 3 5 > >> "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 > >> brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ > >> 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 > >> ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk > >> Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM > >> QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; > >> }; > >> > >> > >> this has caused problem, every query caused error, no answers and these > >> log entries: > >> > >> Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org > >> DNSKEY: must be secure failure, . is under DLV (startfinddlvsep) > >> Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving > >> 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53 > >> > > And what other errors were logged by named when it started? > > > None. Complete startup log sequence: > Dec 20 07:49:14 sarlac named[4137]: loading configuration from > '/etc/bind/named.conf' > Dec 20 07:49:14 sarlac named[4137]: reading built-in trusted keys from > file '/etc/bind/bind.keys' > Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv4 port range: > [1024, 65535] > Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv6 port range: > [1024, 65535] > Dec 20 07:49:14 sarlac named[4137]: set up managed keys zone for view > _default, file 'managed-keys.bind' > Dec 20 07:49:14 sarlac named[4137]: reloading configuration succeeded > Dec 20 07:49:15 sarlac named[4137]: managed-keys-zone ./IN: loaded serial 16 > Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: loaded serial > 2010110801 > Dec 20 07:49:15 sarlac named[4137]: reloading zones succeeded > Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: sending > notifies (serial 2010110801) > > > > > > > > >> After some googling and finding > >> http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html > >> and even better > >> http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html > >> > >> I've changed to dnssec-lookaside auto. Lo and behold, everything works > >> fine. > >> > > And the contents of /etc/bind.key are? Also the contents in the > > chroot area if you are using chroot. > > > Changed /etc/bind.keys to /etc/bind/bind.keys, via config (and it reeds > it, you can see in logs). Contents were given in first post, only I > haven't mentioned it was in /etc/bind/bind.keys. > The managed-keys statement is the sole statement in /etc/bind/bind.keys > and is not present in main config file. > Ok, this was the problem. Having included the file as well as specified > it at bindkeys-file seems to have solved the problem. Ok, now the > documentation seems a bit unclear about it. It never states that the > file is included nor that it's not. But having information that it loads > the given file (in dnssec-lookaside description) and information that > file is loaded in logs has given me a false sense of security in this > case. Is this double-include (sort of) configuration what I was supposed > to do? Will it work correctly after a key rollover? Including a trusted/managed-key multiple times won't hurt. It should work correctly after key rollover. > Also, another question arises: can one include more than one > bindkeys-file and/or dnssec-lookaside in config? The documentation hints > that at least the latter is possigble, but does not state so. And having > mul
Re: dnssec-lookaside != auto
Dnia 2010-12-28 09:26 Eivind Olsen napisał(a): >> >> trying to resolve www.microsoft.com or microsoft.com results in a >> >> "connection timed out; no servers could be reached" >> > > > >Well, for what it's worth - it's not just you having that issue. When > >testing from home and from work I get the same. > > > >Of course, I could be doing something wrong, but whenever I see an error I > >like to imagine it's somebody elses fault :D > > > >One of the nameservers for microsoft.com is ns1.msft.net with an IP > >address of 65.55.37.62. For some reason the response I get from it is > >truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't > >seem to work, I get FORMERR back: > [cut long listing of DNS tries] Same here, I cannot reach this server with TCP or EDNS, nor get longer replies (al with dig), nor can bind resolve it locally (although it works with simple A query) Confirmed, I can get TCP and EDNS replies from a.ns.se Gentoo, bind version 9.7.2_p3, server located somewhere in France, in OVH network. > >So, to recap: at the risk of showing what a fool I am by doing something > >completely wrong here, I'm betting Microsoft has messed up their DNS - I > >would have expected queries over TCP to work, and I would not have > >expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement > >EDNS, giving a FORMERR is apparantly the right thing to do). > Not being a bind expert myself (but having read and hopefully understood the RFC's) I have to agree with it. And, having other issues with Microsoft DNS server myself (althoug this could be the lameness of it's admins as well), I don't have a hard time believing this. Although, if it works when VM is duplicated but has no traffic, it looks like something else to me (maybe two completely different errors, but with similar apperance) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-lookaside auto key expiration
Hello, I unfortunately got hit by the key expiration or whatever just happened about an hour ago that caused the "dnssec-lookaside auto" command to crush all of our DNS queries. I realize that it wasn't doing anything but we left the command in there because it had been in there and in the documentation it said it was harmless. It wasn't harmless. Anyway, I can't go back and time and make it harmless but are there any other timebombs coming up in the near future that people might not know about that they need to address? Thanks, -Drew ___ 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: dnssec-lookaside auto key expiration
We apparently let our signatures on dlv.isc.org expire. We are fixing it now. We apologize for this. This was an accident - we did *not* do this on purpose - but infact, this is a good time for anyone who still has dlv.isc.org configured to REMOVE it from your BIND configuration. The zone is empty, lookups to the zone do nothing beneficial, and as has just been demonstrated, when the zone is bogus, it can have a negative impact. I expect we will have some message here or on Twitter when the issue is finally resolved, but I don’t want to interrupt the person who is currently working on fixing it. As we are removing other obsolete features, we are tracking them along with the newly added features on the BIND Significant Features Matrix. https://kb.isc.org/docs/aa-01310 The DLV was actually removed from 9.16 so as later versions are adopted, it will no longer even be possible to run named with the dlv configured. Vicky Risk Victoria Risk Product Manager Internet Systems Consortium vi...@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: dnssec-lookaside auto key expiration
> This was an accident - we did *not* do this on purpose - but infact, > this is a good time for anyone who still has dlv.isc.org configured > to REMOVE it from your BIND configuration. This advice may be misunderstood. Use of dlv.isc.org is usually implied, not explicitly stated in named.conf, typically via dnssec-lookaside auto; (or "yes"). This should (most probably) be changed to dnssec-lookaside no; I don't have the cross-reference of what the default value has been for this option up through the history of BIND, so explicitly setting it to "no" is for now the safe thing to do. Best regards, - Håvard ___ 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: dnssec-lookaside auto key expiration
> On 26 Mar 2020, at 08:04, Havard Eidnes via bind-users > wrote: > >> This was an accident - we did *not* do this on purpose - but infact, >> this is a good time for anyone who still has dlv.isc.org configured >> to REMOVE it from your BIND configuration. > > This advice may be misunderstood. Use of dlv.isc.org is usually > implied, not explicitly stated in named.conf, typically via > > dnssec-lookaside auto; > > (or "yes"). This should (most probably) be changed to > > dnssec-lookaside no; > > I don't have the cross-reference of what the default value has been > for this option up through the history of BIND, so explicitly setting > it to "no" is for now the safe thing to do. DLV is off by default is all versions ISC shipped (from memory). Various distributions have enabled DLV in named.conf files they have shipped. We have tried hard to get DLV queries stopped but DNS has a long tail. We try to only introduce breaking changes in .0 releases which for DLV was 9.12.0. BIND 9.9.10, 9.10.5 May 2016 4352. [cleanup] The ISC DNSSEC Lookaside Validation (DLV) service is scheduled to be disabled in 2017. A warning is now logged when named is configured to use it, either explicitly or via "dnssec-lookaside auto;" [RT #42207] Formal announcement of operations ceasing apart from a empty zone. https://kb.isc.org/docs/iscs-dnssec-look-aside-validation-registry Sep 2017 BIND 9.9.12, 9.10.7, 9.11.3, 9.12.1, 9.13.0 had the following in them Feb 2018. 4889. [func] Warn about the use of old root keys without the new root key being present. Warn about dlv.isc.org's key being present. Warn about both managed and trusted root keys being present. [RT #43670] BIND 9.9.12, 9.10.7, 9.11.3 4749. [func] The ISC DLV service has been shut down, and all DLV records have been removed from dlv.isc.org. - Removed references to ISC DLV in documentation - Removed DLV key from bind.keys - No longer use ISC DLV by default in delv [RT #46155] BIND 9.12.0 4749. [func] The ISC DLV service has been shut down, and all DLV records have been removed from dlv.isc.org. - Removed references to ISC DLV in documentation - Removed DLV key from bind.keys - No longer use ISC DLV by default in delv - "dnssec-lookaside auto" and configuration of "dnssec-lookaide" with dlv.isc.org as the trust anchor are both now fatal errors. [RT #46155] BIND 9.15.3 (development) / 9.16.0 5276. [func] DNSSEC Lookaside Validation (DLV) is now obsolete; all code enabling its use has been removed from the validator, "delv", and the DNSSEC tools. [GL #7] > Best regards, > > - Håvard > ___ > 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 -- 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
dnssec-lookaside auto and managed-keys-zone problem with certain views
n only from the TLDs root-delegation-only exclude { "ad"; "af"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "fr"; "id"; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "re"; "se"; "sr"; "tn"; "to"; "tw"; "us"; "uy"; }; allow-transfer { secondaries; }; allow-query{ trusted; }; allow-query-cache { trusted; }; allow-recursion{ none; }; allow-update { none; }; max-transfer-time-in60; dnssec-enable yes; dnssec-validation yes; dnssec-lookasideauto; blackhole { bogon; }; }; // Authentication for communicating with rndc --- only listen on the loopback // port 953 for control connections key "rndc-key" { algorithm hmac-md5; secret "MrCkB0CphF4MKmcTY5q/9Q=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; inet ::1 port 953 allow { ::1; } keys { "rndc-key"; }; }; // Zone data files. view "internal-in" in { // Internal networks -- can recurse via this server and access // its cache. They also get to query for localhost related // addresses. match-clients { trusted; }; allow-transfer { none; }; allow-recursion { trusted; }; recursion yes; additional-from-authyes; additional-from-cache yes; notify no; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"; // The traditional root hints mechanism. zone "." { type hint; file "/etc/namedb/named.root"; }; // RFC 1912 zone "localhost" { type master; file "/etc/namedb/master/localhost-forward"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse"; }; // RFC 1912-style zone for IPv6 localhost address zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse"; }; include "/etc/namedb/named.zones"; }; view "external-in" in { // Publically accessible zone data. The whole world can see this. // Recursion and access to cache not allowed for the world in // general. match-clients { any; }; recursion no; additional-from-authno; additional-from-cache no; notify yes; // The traditional root hints mechanism. zone "." { type hint; file "/etc/namedb/named.root"; }; include "/etc/namedb/named.zones"; }; view "external-chaos" chaos { match-clients { !trusted; }; allow-query { none; }; zone "."{ type hint; file "/dev/null"; }; }; // // That's All Folks! // Syslog extract: Jul 18 11:59:31 lucid-nonsense named[89734]: starting BIND 9.7.1-P2 -c /etc/namedb/named.conf -t /var/named -u bind Jul 18 11:59:31 lucid-nonsense named[89734]: built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' '--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--with-idn=/usr/local' '--with-libiconv=/usr/local' '--enable-largefile' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-ipv6' '--enable-threads' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd8.1' 'build_alias=x86_64-portbld-freebsd8.1' 'CC=/usr/local/libexec/ccache/world-cc' 'CFLAGS=-O2 -pipe -march=native -fno-strict-aliasing' 'LDFLAGS= -rpath=/usr/local/lib' 'CXX=/usr/local/libexec/ccache/world-c++' 'CXXFLAGS=-O2 -pipe -march=native -fno-strict-aliasing' Jul 18 11:59:31 lucid-nonsense named[89734]: found 2 CPUs, using 2 worker threads Jul 18 11:59:31 lucid-nonsense named[89734]: using up to 4096 sockets Jul 18 11:59:31 lucid-nonsense named[89734]: loading configuration from '/etc/namedb/named.conf' Jul 18 11:59:31 lucid-nonsense named[89734]: statistics channel listening on 0.0.0.0#8080 Jul 18 11:59:31 lucid-nonsense named[89734]: statistics channel listening on ::#8080 Jul 18 11:59:31 lucid-nonsense named[8973
Re: dnssec-lookaside auto and managed-keys-zone problem with certain views
> Is there a way of using dnssec-lookaside and forcing bind not to > maintain a managed-keys-zone for certain views? Sure, just do it the old way, without "dnssec-lookaside auto". Put these in the view statement: dnssec-lookaside . trust-anchor dlv.isc.org; trusted-keys { dlv.isc.org. 257 3 5 "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; }; (Except, you know, get the key text from a secure channel or from the signed bind9 distribution, not from email...) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside auto and managed-keys-zone problem with certain views
On 18/07/2010 17:58:15, Evan Hunt wrote: >> Is there a way of using dnssec-lookaside and forcing bind not to >> maintain a managed-keys-zone for certain views? > > Sure, just do it the old way, without "dnssec-lookaside auto". > Put these in the view statement: > > dnssec-lookaside . trust-anchor dlv.isc.org; > > trusted-keys { > dlv.isc.org. 257 3 5 > "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 > brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ > 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 > ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk > Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM > QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; > }; > > (Except, you know, get the key text from a secure channel or from the > signed bind9 distribution, not from email...) Well, it's a better work around than what I have been doing, but not having the RFC 5011 behaviour is quite a disappointment. Now I have presentiments of disaster should the DLV key have to be rolled for whatever reason. Think I'll just drop the external-chaos view. Some script kiddie working out I'm running the latest version of bind is likely to be lower risk and a lot less harmful than dealing with broken dnssec chains of trust. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside auto and managed-keys-zone problem with certain views
On Sun, Jul 18, 2010 at 3:28 PM, Matthew Seaman wrote: > Think I'll just drop the external-chaos view. Some script kiddie > working out I'm running the latest version of bind is likely to be lower > risk and a lot less harmful than dealing with broken dnssec chains of trust. version none; in global options... -- aRDy Music and Rick Dicaire present: http://www.ardynet.com http://www.ardynet.com:9000/ardymusic.ogg.m3u ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside auto and managed-keys-zone problem with certain views
On 07/18/10 12:28, Matthew Seaman wrote: > Think I'll just drop the external-chaos view. Some script kiddie > working out I'm running the latest version of bind is likely to be lower > risk and a lot less harmful than dealing with broken dnssec chains of trust. I agree, and to take it one step further most of the "attack nameservers" script kiddie things are actually suites that don't bother to determine your version, they just throw everything at you and see if they can get something to break. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside auto and managed-keys-zone problem with certain views
> Well, it's a better work around than what I have been doing, but not > having the RFC 5011 behaviour is quite a disappointment. Now I have > presentiments of disaster should the DLV key have to be rolled for > whatever reason. Sorry, I misunderstood your question--I thought you wanted to know how to use DLV without having a managed-keys zone created at all. In 9.7.1 and above, you can use "managed-keys" statements at the view level as well as globally. (This was a known limitation in 9.7.0.) You can also use "dnssec-lookaside auto" at the view level. You'll want to set a "managed-keys-directory" option. For example: options { ... managed-keys-directory "managed-keys"; }; view external { match-clients { ... }; dnssec-lookaside auto; ... }; Make sure you create the "managed-keys" directory within the working directory for the named process, and that it's writable. Each view using this feature will create a separate file to store key data, and the filenames they use are... well, let's just say "unwieldy". Best to segregate them into a directory where you don't have to look at them. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users