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
> multiple bindkeys-file is useful if you have locally-configured keys,
> for which using the main file is not recommended.
Only one dnssec-lookaside clause is supported.
Multiple trusted-keys/managed keys clauses are supported.
> 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
--
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/lis
Re: DDNS fails. record allready exists
On 20.12.10 21:34, magic-b...@damage.devloop.de wrote: > I have not yet found a solution for my problem. So I came here: > > I use DDNS. Every night my server (in my local network) is shutting down. On > the next day I have the problem that DDNS is no longer working, because on > update I get the error that the DNS record allready exists. What is the > solution? why is it shutting down? -- 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. LSD will make your ECS screen display 16.7 million colors ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDNS fails. record allready exists
Hi, I forget something: I use DDNS with DHCP. Thus DDNS fails the next time the client is getting a new lease. regards Daniel Am Montag, 20. Dezember 2010, 21:34:32 schrieben Sie: > Hi List, > I have not yet found a solution for my problem. So I came here: > > I use DDNS. Every night my server (in my local network) is shutting down. > On the next day I have the problem that DDNS is no longer working, because > on update I get the error that the DNS record allready exists. What is the > solution? > > I use BIND version 9.7.2_p3-r1. > > regards > Daniel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DDNS fails. record allready exists
Hi List, I have not yet found a solution for my problem. So I came here: I use DDNS. Every night my server (in my local network) is shutting down. On the next day I have the problem that DDNS is no longer working, because on update I get the error that the DNS record allready exists. What is the solution? I use BIND version 9.7.2_p3-r1. regards Daniel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Wrong names for NS and glue records not in the child zone
On 20/12/2010 13:50, Kalman Feher wrote: >> The registry NS return an authority section like : >> > domain.tld. IN NS ns1.domain.tld. >> > domain.tld. IN NS ns2.domain.tld. >> > and an additional section with these glue records. >> > >> > The delegation should be : >> > domain.tld. IN NS ns1.domain.com. >> > domain.tld. IN NS ns2.domain.com. >> > which are also glue records, by the way, but domain.com. resolution is OK. >> > >> > Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for >> > www.domain.tld. I flushed the cache before. >> > Does it mean that bind ignores the authoritative answer for glue records >> > and the NS records ? > Glue records are not authoritative, although depending on the registry in > question they may reply as such. In any case the apex of the zone is > considered the most trustworthy by BIND so it will cache the child zone NS > records in preference to the glue records. Of course once the cache expires, > unless one of the delegation points is accessible from the parent zone (are > all NS records for the domain wrong in the parent?) the domain will no > longer be accessible. You've already proven as much with the +trace. Your > only option is to fix the glue records. Thanks for your answer. Yes, I've been trying to get the glue records fixed for several days ; actually there should be no glue record at all, as the authoritative NS for domain.tld should be ns(1|2).domain.com, not ns(1|2)domain.tld. Sorry I forgot to tell there were only those two NS, so yes, all NS records are currently wrong in the parent. But the IP addresses of the glues refer to the correct servers (copied from the correct NS names), so I was wondering if this was the reason why my cache server was still resolving some records. Laurent ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Wrong names for NS and glue records not in the child zone
On 20/12/10 11:05 AM, "Laurent Bauer" wrote: > > Hello, > > We (my company) are registrar for a domain name which is delegated to > our client NS. Our client wanted to change the NS records (just the > names, same IP addresses) but the registry put the wrong names and > created glue records instead. > Obviously the glue records are not present in the child zone, and the NS > names do not match either, as this is not what the client had configured. > > The registry NS return an authority section like : > domain.tld. IN NS ns1.domain.tld. > domain.tld. IN NS ns2.domain.tld. > and an additional section with these glue records. > > The delegation should be : > domain.tld. IN NS ns1.domain.com. > domain.tld. IN NS ns2.domain.com. > which are also glue records, by the way, but domain.com. resolution is OK. > > Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for > www.domain.tld. I flushed the cache before. > Does it mean that bind ignores the authoritative answer for glue records > and the NS records ? Glue records are not authoritative, although depending on the registry in question they may reply as such. In any case the apex of the zone is considered the most trustworthy by BIND so it will cache the child zone NS records in preference to the glue records. Of course once the cache expires, unless one of the delegation points is accessible from the parent zone (are all NS records for the domain wrong in the parent?) the domain will no longer be accessible. You've already proven as much with the +trace. Your only option is to fix the glue records. > Is it just because the IP addresses are the same, > or some kind of tolerance to this kind of configuration error ? Could > this be an implementation-dependant behaviour ? > > A "dig +trace" query fails with "connection timed out; no servers could > be reached" when trying to query the authoritative NS for domain.tld. > While I might find this is the right behaviour that dig only follows > authoritative NS, is it not supposed to connect to ns1.domain.tld. and > then return NXDOMAIN for ns1.domain.tld. ? > > My main problem is that the registry tells us there is no problem, as > the resolution is still OK for www records. > I would like to explain this, and have other arguments than "the client > does not want that" or "this will stop resolving the moment the glue > records change for ns1.domain.com." > > Thanks in advance for any answer to my questions. > > Laurent > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about nsupdate
Thanks Michael. I appreciate it much. 2010/12/20 Michael Sinatra : > On 12/19/10 23:47, Jorg W Young wrote: >> >> Hello, >> >> We primarily update the DNS records by nsupdate from a web interface. >> Under this case, if I modified the zone file directly by hand, will >> nsupdate overwrite the modification? > > If you attempt to update a dynamic zone by hand, without first "freezing" > the zone or shutting down named, you will likely corrupt the zone. You need > to use 'rndc freeze ' and then do the update by hand (don't forget to > bump the serial number!), and then do 'rndc thaw ' (assuming you're > using a recent version of BIND). While the zone is frozen, updates made > dynamically (e.g. via your web interface) will be discarded. For these > reasons, it's often good to think about whether the hand-editing is really > necessary and what impact it has on your overall process. > > michael > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Wrong names for NS and glue records not in the child zone
Hello, We (my company) are registrar for a domain name which is delegated to our client NS. Our client wanted to change the NS records (just the names, same IP addresses) but the registry put the wrong names and created glue records instead. Obviously the glue records are not present in the child zone, and the NS names do not match either, as this is not what the client had configured. The registry NS return an authority section like : domain.tld. IN NS ns1.domain.tld. domain.tld. IN NS ns2.domain.tld. and an additional section with these glue records. The delegation should be : domain.tld. IN NS ns1.domain.com. domain.tld. IN NS ns2.domain.com. which are also glue records, by the way, but domain.com. resolution is OK. Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for www.domain.tld. I flushed the cache before. Does it mean that bind ignores the authoritative answer for glue records and the NS records ? Is it just because the IP addresses are the same, or some kind of tolerance to this kind of configuration error ? Could this be an implementation-dependant behaviour ? A "dig +trace" query fails with "connection timed out; no servers could be reached" when trying to query the authoritative NS for domain.tld. While I might find this is the right behaviour that dig only follows authoritative NS, is it not supposed to connect to ns1.domain.tld. and then return NXDOMAIN for ns1.domain.tld. ? My main problem is that the registry tells us there is no problem, as the resolution is still OK for www records. I would like to explain this, and have other arguments than "the client does not want that" or "this will stop resolving the moment the glue records change for ns1.domain.com." Thanks in advance for any answer to my questions. Laurent ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about nsupdate
On 12/19/10 23:47, Jorg W Young wrote: Hello, We primarily update the DNS records by nsupdate from a web interface. Under this case, if I modified the zone file directly by hand, will nsupdate overwrite the modification? If you attempt to update a dynamic zone by hand, without first "freezing" the zone or shutting down named, you will likely corrupt the zone. You need to use 'rndc freeze ' and then do the update by hand (don't forget to bump the serial number!), and then do 'rndc thaw ' (assuming you're using a recent version of BIND). While the zone is frozen, updates made dynamically (e.g. via your web interface) will be discarded. For these reasons, it's often good to think about whether the hand-editing is really necessary and what impact it has on your overall process. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
