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
