Re: BIND 9.7.2-P2 is now available.
* Mark Andrews: * If BIND, acting as a DNSSEC validating server, has two or more trust anchors configured in named.conf for the same zone (such as example.com) and the response for a record in that zone from the authoritative server includes a bad signature, the validating server will crash while trying to validate that query. Does this change need backporting to 9.6-ESV? Is an isolated patch available? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc.key vs. rndc.conf
| Hi All: One more conf issue on bind 9.7.1-P2
| After running rndc-confgen and reloading BIND I?m getting this error:
| WARNING: key file (/etc/namedb/rndc.key) exists, but using default
| configuration file (/etc/namedb/rndc.conf)
| rndc: connection to remote host closed
| This may indicate that
| * the remote server is using an older version of the command protocol,
| * this host is not authorized to connect,
| * the clocks are not synchronized, or
| * the key is invalid.
| It seems like I have a valid key in both files...what do I need to
change?
I'm guessing from the /etc/namedb path above that you're using FreeBSD.
In that case there is no reason to use rndc.conf, as FreeBSD generates
an rndc.key file for you.
1. Stop named ('service named stop' or '/etc/rc.d/named stop')
2. rm /etc/rndc.conf
3. Start named ('service named start' or '/etc/rc.d/named start')
4. rndc status
Thanks again...removing the rndc.conf file worked! I think where I became
confused was after installing 9.7.1-P2 from the ports collection on FreeBSD
8.1, it installed an rndc.conf.sample file in /etc/namedb/...I tried
renaming that file and using it, saw some errors, and then ran rndc-confgen,
which created the rndc.key file instead.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple slave zones pointing to same file?
The slave files do not carry the @ I presume you are using on the master -- the zone-transfer data includes the specific domain names -- so the slave files can't be shared even if they could be shared. Maybe you can write a program that translates the slave data into the sharable format, and every time there is a zone transfer, you can run the program to generate a sharable file, and then have all the rest of your zone set up as masters, and have your program do an rndc reload after generatign the shared file ;-) or just use separate files. -- Gordon Lang - Original Message - From: online-reg online-...@enigmedia.com To: bind-users@lists.isc.org Sent: Sunday, October 03, 2010 9:47 AM Subject: Re: multiple slave zones pointing to same file? IME the best way to do this on a Unix'y system is to use hard links. That way if you ever need to change one of them to be its own file it's trivial to do so. Also IME, BIND doesn't react well to having multiple slave zones sharing the same file, but that may have improved in more recent versions, I haven't tried it for a couple of years now. Thanks Doug, but I'm not entirely clear on what you're recommending? It seems like you're saying it's OK, but then you're saying BIND doesn't like it? I'm guessing then that you're not running BIND on a Unix system. In any case, Mark is in a much better position than I to state categorically, Don't do that so I am happy to defer to his wisdom. Just use different files for each zone. Yes, it's a bit of duplication on the file system, but that's not the end of the world. Disk is cheap, DNS failure i Thanks Doug/Mark...I ended up just doing it the right way ;) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys-zone file not found
On Fri, Oct 01, 2010 at 10:29:34PM +, Jack Tavares wrote: Hello While starting up bind I get the following 2 messages 01-Oct-2010 15:13:15.304 set up managed keys zone for view external, file '3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys' and 01-Oct-2010 15:13:15.309 managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found The expected behavior is, the first time you start BIND with managed-keys configured in a view, it will try to load the keys from an existing managed-keys file. If the file isn't found, it logs this warning, and then if the directory is writable, it goes ahead and creates the file. So you should only be seeing this the first time, and not thereafter. Which is why I'm concerned about this: I have tried using managed-keys-directory option, but I cannot get rid of this message. BIND hasn't created the file yet? Is your working directory or managed-keys-directory writable? -- 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: multiple slave zones pointing to same file?
The slave files do not carry the @ I presume you are using on the master -- the zone-transfer data includes the specific domain names -- so the slave files can't be shared even if they could be shared. Maybe you can write a program that translates the slave data into the sharable format, and every time there is a zone transfer, you can run the program to generate a sharable file, and then have all the rest of your zone set up as masters, and have your program do an rndc reload after generatign the shared file ;-) or just use separate files. Thanks Gordon...I didn't think about the origin issues until I opened up one of the secondary zone files and saw that! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys-zone file not found
On Sun, 3 Oct 2010, Evan Hunt wrote: On Fri, Oct 01, 2010 at 10:29:34PM +, Jack Tavares wrote: Hello While starting up bind I get the following 2 messages 01-Oct-2010 15:13:15.304 set up managed keys zone for view external, file '3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys' and 01-Oct-2010 15:13:15.309 managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found The expected behavior is, the first time you start BIND with managed-keys configured in a view, it will try to load the keys from an existing managed-keys file. If the file isn't found, it logs this warning, and then if the directory is writable, it goes ahead and creates the file. So you should only be seeing this the first time, and not thereafter. Which is why I'm concerned about this: I have tried using managed-keys-directory option, but I cannot get rid of this message. BIND hasn't created the file yet? Is your working directory or managed-keys-directory writable? Evan, I had this same message and it continued on every start. But it went ahead and loaded the zone (in memory I surmised) and everything worked OK. I just tried creating an empty file (via touch) in my working directory and, viola! No more messages except for the set up managed keys zone for view external and it still works as it should. My working directory is owned by named and I run as -u named so I don't know why it does not write the file. I had a similar problem with the internal view and removed the annoying message in the same manner; touching the file with the name in the message in the working directory. So I now have two empty files; No biggie. I searched in the source code for the message and found it in ./bin/named/server.c but didn't go any further as my invocation hack worked for me and it just seemed to be a log info message. YMMV. Dave -- David Forrest e-mail d...@maplepark.com Maple Park Development Corporation http://xen.maplepark.com St. Louis, Missouri(Sent by ALPINE 2.01 FEDORA 11 LINUX) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys-zone file not found
Evan, I had this same message and it continued on every start. That's a bug, then. Thank you. -- 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
managed-keys.bind sometimes stops being updated
With a managed-keys statement including keys for . and for dlv.isc.org, the managed-keys.bind file is normally updated every hour for dlv.isc.org and every day for . (the respective TTLs of their DNSKEY RRsets, presumably). But sometimes this updating simply stops completely, until BIND is restarted. The trust anchors go on being used OK, and rndc secroots still shows them as managed. The effect seems to be associated with having used rndc reconfig, and I have observed it with both 9.7.1-P2 and 9.7.2-P2. Is this a known problem? Has anyone else observed it? -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
can't validate existing negative responses (not a zone cut) messages
Since upgrading our main recursive nameservers to BIND 9.7.2-P2 (and using a trust anchor for the root and lookaside via dlv.isc.org) I am seeing a scatter of warning messages like this: Oct 1 19:47:19 dnssec: warning: validating @1c29d580: 115.197.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) Oct 1 19:47:19 dnssec: warning: validating @8d34550: 115.197.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) Oct 2 11:25:28 dnssec: warning: validating @11d37f18: 32.197.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) Oct 3 01:39:21 dnssec: warning: validating @160f4260: 205.205.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) Oct 3 08:40:14 dnssec: warning: validating @12cd35c0: 20.204.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) Oct 3 16:53:10 dnssec: warning: validating @14c9cd70: 98.206.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) What do they mean, exactly? And should I be worrying about them? They all seem to refer to PTR records (not all of them for IP addresses in 95.101/16, but many of them are). -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
