auto-dnssec maintain and no key: no error message?
When I run a BIND with auto-dnssec maintain and inline-signing yes, if I create no key, there is no error message and, worse, the log file says the zone is signed: Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (unsigned): loaded serial 2013073000 Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (signed): loaded serial 2013073000 Jul 30 16:31:42 u12-33673 named[1605]: all zones loaded Jul 30 16:31:42 u12-33673 named[1605]: running Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (signed): receive_secure_serial: unchanged Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (signed): reconfiguring zone keys Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (signed): next key event: 30-Jul-2013 17:31:42.009 Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (signed): sending notifies (serial 2013073000) Of course, there is no signature: % dig +multi @localhost SOA auto.rd.nic.fr ; DiG 9.9.2-P1 +multi @localhost SOA auto.rd.nic.fr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 57439 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;auto.rd.nic.fr.IN SOA ;; ANSWER SECTION: auto.rd.nic.fr. 86400 IN SOA 10.200.0.73. bortzmeyer.nic.fr. ( 2013073000 ; serial 30480 ; refresh (8 hours 28 minutes) 26400 ; retry (7 hours 20 minutes) 2419200; expire (4 weeks) 86400 ; minimum (1 day) ) ;; AUTHORITY SECTION: auto.rd.nic.fr. 86400 IN NS ns1.bortzmeyer.org. auto.rd.nic.fr. 86400 IN NS ns1.auto.rd.nic.fr. ;; ADDITIONAL SECTION: ns1.auto.rd.nic.fr. 86400 IN A 109.26.74.172 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jul 30 16:38:00 2013 ;; MSG SIZE rcvd: 167 IMHO, BIND should clearly log there is something missing. BIND 9.9.2-P1 (the version in the last Ubuntu server) ___ 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: auto-dnssec maintain and no key: no error message?
On Tue, 30 Jul 2013, Stephane Bortzmeyer wrote: Of course, there is no signature: % dig +multi @localhost SOA auto.rd.nic.fr Add +dnssec ___ 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: auto-dnssec maintain and no key: no error message?
On Tue, Jul 30, 2013 at 09:50:46AM -0500, Jeremy C. Reed jr...@isc.org wrote a message of 7 lines which said: Of course, there is no signature: % dig +multi @localhost SOA auto.rd.nic.fr Add +dnssec [I thought it was in my .digrc.] It changes nothing. Without a key, BIND could not create signatures. % dig +multi +dnssec @localhost SOA auto.rd.nic.fr ; DiG 9.9.2-P1 +multi +dnssec @localhost SOA auto.rd.nic.fr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13678 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;auto.rd.nic.fr.IN SOA ;; ANSWER SECTION: auto.rd.nic.fr. 86400 IN SOA 10.200.0.73. bortzmeyer.nic.fr. ( 2013073000 ; serial 30480 ; refresh (8 hours 28 minutes) 26400 ; retry (7 hours 20 minutes) 2419200; expire (4 weeks) 86400 ; minimum (1 day) ) ;; AUTHORITY SECTION: auto.rd.nic.fr. 86400 IN NS ns1.bortzmeyer.org. auto.rd.nic.fr. 86400 IN NS ns1.auto.rd.nic.fr. ;; ADDITIONAL SECTION: ns1.auto.rd.nic.fr. 86400 IN A 109.26.74.172 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jul 30 16:55:24 2013 ;; MSG SIZE rcvd: 167 ___ 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: auto-dnssec maintain and no key: no error message?
When I run a BIND with auto-dnssec maintain and inline-signing yes, if I create no key, there is no error message and, worse, the log file says the zone is signed: Thanks for pointing this out. It's not really an error, but the log should certainly be clearer about what's going on. An inline-signing zone is represented internally as *two* zone objects, one to hold the original unsigned data, and the other the signed. These zones are differentiated in the log file by the labels (unsigned) and (signed), regardless of whether signing in fact taken place yet. A zone that is to be signed, but can't find a key to sign with, simply waits quietly until a key is provided. Presumably you're planning to create the keys and run rndc loadkeys later. We ought to be logging this condition, but it's not an error. If you report this to bind9-b...@isc.org we'll address it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
Sorry for the bump here, but through extensive troubleshooting I've
identified a trend in this. It appears that zones hosted on the
lower-numbered masters are still updating without issue. This leads me to
believe that something is causing BIND to forget the later cluster
servers, as the logs show that it doesn't even try to query them for zone
updates. Is this known behavior? Perhaps a network failure causes a
master to be marked bad in newer versions of BIND? Restarting named on
the slave continues to correct the problem, so for now I'm (unfortunately)
restarting named frequently on this slave.
On Mon, Jul 29, 2013 at 6:41 PM, Brandon Whaley
brand...@inmotionhosting.com wrote:
Hi all, I've recently upgraded from a CentOS5 install of BIND 9
(bind-9.3.6-20.P1.el5_8.6) to a CentOS6 install
(bind-9.8.2-0.17.rc1.el6_4.4.x86_64) for one of my two nameservers. The
config I'm using is nearly identical (added rate limiting only) and the
server that has not yet been updated is still having no problems. The
upgraded server will stop receiving updates for zones after 1-3 days of
completely normal operation. Restarting named (but not reloading) corrects
the problem for another 1-3 days.
I have logs showing what happens before and after a restart of the
service. I've changed the IPs in these logs and the config file which
follows. In them, 10.0.x.1 represents a master server and 10.10.10.1 is
the slave having issues. These logs are basically tail -f named.log |
grep example.com where example.com is the test domain I'm using (it
happens with all domains). I update the zone file's serial on 10.0.4.1,
then do an rndc reload there, these are the logs that come up:
Before named restart
=
29-Jul-2013 10:17:29.567 notify: info: client 10.0.4.1#37224: received
notify for zone 'example.com'
29-Jul-2013 10:17:30.069 notify: info: client 10.0.4.1#32206: received
notify for zone 'example.com'
29-Jul-2013 10:17:30.069 general: info: zone example.com/IN: notify from
10.0.4.1#32206: refresh in progress, refresh check queued
29-Jul-2013 10:18:59.568 general: info: zone example.com/IN: refresh:
retry limit for master 10.0.1.1#53 exceeded (source 10.10.10.1#0)
29-Jul-2013 10:18:59.568 general: info: zone example.com/IN: Transfer
started.
29-Jul-2013 10:18:59.569 xfer-in: info: transfer of 'example.com/IN' from
10.0.1.1#53: connected using 10.10.10.1#55992
29-Jul-2013 10:18:59.570 xfer-in: info: transfer of 'example.com/IN' from
10.0.1.1#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs
(0 bytes/sec)
After named restart
=
29-Jul-2013 10:43:34.879 notify: info: client 10.0.4.1#42576: received
notify for zone 'example.com'
29-Jul-2013 10:43:34.890 general: info: zone example.com/IN: serial
number (2011061500) received from master 10.0.1.1#53 ours (2013022611)
29-Jul-2013 10:43:34.900 general: info: zone example.com/IN: refresh:
non-authoritative answer from master 10.0.2.1#53 (source 10.10.10.1#0)
29-Jul-2013 10:43:34.904 general: info: zone example.com/IN: refresh:
non-authoritative answer from master 10.0.3.1#53 (source 10.10.10.1#0)
29-Jul-2013 10:43:34.915 general: info: zone example.com/IN: Transfer
started.
29-Jul-2013 10:43:34.916 xfer-in: info: transfer of 'example.com/IN' from
10.0.4.1#53: connected using 10.10.10.1#44081
29-Jul-2013 10:43:34.919 general: info: zone example.com/IN: transferred
serial 2013072910
29-Jul-2013 10:43:34.919 xfer-in: info: transfer of 'example.com/IN' from
10.0.4.1#53: Transfer completed: 1 messages, 23 records, 719 bytes, 0.002
secs (359500 bytes/sec)
29-Jul-2013 10:43:35.379 notify: info: client 10.0.4.1#43038: received
notify for zone 'example.com'
29-Jul-2013 10:43:35.380 general: info: zone example.com/IN: notify from
10.0.4.1#43038: zone is up to date
In case it's necessary, here is the config for the slave where these logs
were produced:
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { rndc-key; };
};
include /etc/rndc.key;
acl notifytrusted { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
logging{
channel simple_log {
file /var/log/named.log versions 3 size 65m;
#severity warning;
severity debug 0;
print-time yes;
print-severity yes;
print-category yes;
};
category default{
simple_log;
};
};
zone . {
type hint;
file /var/named/named.ca;
};
options {
statistics-file /var/named/data/named_stats.txt;
directory /var/named;
forwarders {10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
forward only;
transfers-in 5;
transfers-per-ns 5;
serial-query-rate 1;
transfer-source 10.10.10.1;
use-alt-transfer-source no;
rate-limit {
responses-per-second 200;
window 5;
};
allow-transfer { none; };
notify no;
allow-notify
Re: BIND slave stops updating from master after 1-3 days
On 30 July 2013 20:31, Brandon Whaley brand...@inmotionhosting.com wrote: Sorry for the bump here, but through extensive troubleshooting I've identified a trend in this. It appears that zones hosted on the lower-numbered masters are still updating without issue. This leads me to believe that something is causing BIND to forget the later cluster servers, as the logs show that it doesn't even try to query them for zone updates. Is this known behavior? Perhaps a network failure causes a master to be marked bad in newer versions of BIND? Restarting named on the slave continues to correct the problem, so for now I'm (unfortunately) restarting named frequently on this slave. Can you post a snippet of one of your secondary zone config stanzas so we can see how you have the slave zone configured. From previous posts to the list I think it was identified that BIND will contact the first master server listed and failover to the second master if the first wasn't contactable, but then it would ignore any additional masters. Would be good to get some clarification on this from ISC, I've tried to trace my way through the source code and can't identify where BIND decides which master to update from, all I can find is the code where it goes to cleanup if the server isn't contactable (bind-9.9.3-P2/lib/dns/zone.c ln:13647), but can't see where it would then choose another one and try again. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
Hey Steve, thanks for the reply. Here's the top of one of the masters'
named.conf files (they're all the same, with the exception of which zones
are on them:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
include /etc/rndc.key;
logging{
channel simple_log {
file /var/log/ramlog/named.log versions 3 size 65m;
severity debug 0;
print-time yes;
print-severity yes;
print-category yes;
};
category default{
simple_log;
};
};
zone . {
type hint;
file /var/named/named.ca;
};
options {
statistics-file /var/named/data/named_stats.txt;
directory /var/named;
recursion no;
transfers-out 1;
notify explicit;
also-notify {10.10.10.1; 10.10.10.2; };
allow-transfer {10.10.10.1; 10.10.10.2; };
files 4096;
};
zone 0.0.127.in-addr.arpa {
type master;
file /var/named/named.local;
};
zone example.com {
type master;
file /var/named/example.com.db;
};
I think that's what you asked for. In case I misunderstood, here's a zone
entry from the slave's named.conf (this immediately follows the options
block in my first email:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
On Tue, Jul 30, 2013 at 4:10 PM, Steven Carr sjc...@gmail.com wrote:
On 30 July 2013 20:31, Brandon Whaley brand...@inmotionhosting.comwrote:
Sorry for the bump here, but through extensive troubleshooting I've
identified a trend in this. It appears that zones hosted on the
lower-numbered masters are still updating without issue. This leads me to
believe that something is causing BIND to forget the later cluster
servers, as the logs show that it doesn't even try to query them for zone
updates. Is this known behavior? Perhaps a network failure causes a
master to be marked bad in newer versions of BIND? Restarting named on
the slave continues to correct the problem, so for now I'm (unfortunately)
restarting named frequently on this slave.
Can you post a snippet of one of your secondary zone config stanzas so we
can see how you have the slave zone configured.
From previous posts to the list I think it was identified that BIND will
contact the first master server listed and failover to the second master if
the first wasn't contactable, but then it would ignore any additional
masters.
Would be good to get some clarification on this from ISC, I've tried to
trace my way through the source code and can't identify where BIND decides
which master to update from, all I can find is the code where it goes to
cleanup if the server isn't contactable (bind-9.9.3-P2/lib/dns/zone.c
ln:13647), but can't see where it would then choose another one and try
again.
Steve
___
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
--
Best Regards,
Brandon W.
Tier 3 System Administrator
InMotion Hosting Inc.
888-321-4678
757-416-6575 (Int'l)
NEW: 24x7 EMAIL and PHONE Technical Support
Did you know?
We'll Build, Update and Promote Your Site for You! Visit
www.inmotionhosting.com/webdesign
Answers to commonly asked questions, as well as other useful tools, can be
found at http://support.inmotionhosting.com
How am I doing? Please feel free to email my manager at
manager_feedb...@inmotion.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
- Original Message -
I think that's what you asked for. In case I misunderstood, here's a
zone entry from the slave's named.conf (this immediately follows the
options block in my first email:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
Should probably have the 10.10.10.1 master here, rather than the slave
nameservers that are configured not to allow transfers.
L ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave. The
10.0.x.1 IPs are the addresses of the masters.
On Tue, Jul 30, 2013 at 4:43 PM, Lawrence K. Chen, P.Eng. lkc...@ksu.eduwrote:
--
I think that's what you asked for. In case I misunderstood, here's a zone
entry from the slave's named.conf (this immediately follows the options
block in my first email:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
Should probably have the 10.10.10.1 master here, rather than the slave
nameservers that are configured not to allow transfers.
L
--
Best Regards,
Brandon W.
Tier 3 System Administrator
InMotion Hosting Inc.
888-321-4678
757-416-6575 (Int'l)
NEW: 24x7 EMAIL and PHONE Technical Support
Did you know?
We'll Build, Update and Promote Your Site for You! Visit
www.inmotionhosting.com/webdesign
Answers to commonly asked questions, as well as other useful tools, can be
found at http://support.inmotionhosting.com
How am I doing? Please feel free to email my manager at
manager_feedb...@inmotion.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
On 30 July 2013 21:38, Brandon Whaley brand...@inmotionhosting.com wrote:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
So given what I mentioned before I would envisage BIND contacting 10.0.1.1
and then failing to 10.0.2.1 but ignoring the rest. Is this what you are
seeing in the logs? Or is the slave not attempting to contact any of the
servers?
Just out of curiosity, what is the reason for having 5 masters? are these
multi-master? or are they effectively slaves that also allow zone transfers?
Steve
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
Oh, guess I got it mixed up because the slave is saying it got
non-authoritative answers from 10.0.x.1.. where I think of the master should at
least be authoritative for its domain.
- Original Message -
Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave.
The 10.0.x.1 IPs are the addresses of the masters.
On Tue, Jul 30, 2013 at 4:43 PM, Lawrence K. Chen, P.Eng.
lkc...@ksu.edu wrote:
I think that's what you asked for. In case I misunderstood,
here's
a
zone entry from the slave's named.conf (this immediately follows
the
options block in my first email:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
Should probably have the 10.10.10.1 master here, rather than the
slave nameservers that are configured not to allow transfers.
L
--
Best Regards,
Brandon W.
Tier 3 System Administrator
InMotion Hosting Inc.
888-321-4678
757-416-6575 (Int'l)
NEW: 24x7 EMAIL and PHONE Technical Support
Did you know?
We'll Build, Update and Promote Your Site for You! Visit
www.inmotionhosting.com/webdesign
Answers to commonly asked questions, as well as other useful tools,
can be found at http://support.inmotionhosting.com
How am I doing? Please feel free to email my manager at
manager_feedb...@inmotion.net
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
In article mailman.968.1375218342.20661.bind-us...@lists.isc.org, Lawrence K. Chen, P.Eng. lkc...@ksu.edu wrote: Oh, guess I got it mixed up because the slave is saying it got non-authoritative answers from 10.0.x.1.. where I think of the master should at least be authoritative for its domain. It *should* be. But if it gets an error loading the zone file, it will make itself non-authoritative, to avoid propagating the errors to slaves. -- Barry Margolin Arlington, MA ___ 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
Updated to bind 9.9.3-P2
From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2. All the picky messages of this version.there were the no SPF/SPF records for SPF/TXTbut I thought I already had SPF everywhere...but turned out there was one zone file the main SPF record had both types, but the rest were only of TXT kind. Not sure if I just missed it when I had adding SPF types long agoor somebody had hacked them out on me. And, I hadn't noticed because I hadn't had need to make changes to those SPF recordswhere I have had to tweak the top level SPF record now and thensuch as adding new mailservers or switching to ironport or change ~all to -all. But, it also complained about the formerly delegated subdomains that have now become include files.All I had done was remove the SOA and NS records dnssec-signzone: warning: ol$$$.ksu.edu:12: record with inherited owner (u$$$.n$$$.k-state.edu) immediately after $ORIGIN (ol$$$.k-state.edu) dnssec-signzone: warning: oe$$$.ksu.edu:9: record with inherited owner (u$$$.n$$$.k-state.edu) immediately after $ORIGIN (oe$$$.k-state.edu) Not sure how it came up with the message, but in these files (not including the extensive comments) were of the form: TXT who we are @A a.b.c.d www A a.b.c.d ... While there were plenty of other such files where it didn't complain...but the TXT line was commented out. Elsewhere we publish a template of what a zone file should look like...with SOA, NS, and the commented out TXT line, should the department/unit want something there. Putting an @ in front made the warnings go away. And, then also after all the found SPF/TXT record but no SPF/SPF record messages, there was also the message: Jul 30 15:07:00 ns-1 named[29380]: [ID 873579 daemon.warning] pri/$$.$$$.ksu.edu.signed:10: signature has expired The file timestamp was Feb 13, 2013. Yeah, I guess the signature had expired. The zone file hadn't been changed since December 5, 2012. But, the system is supposed to do periodic refresh signings It used to do it on the 1st and 15th of every month...but it was then changed to do it every two weeksor it was supposed to. But, I guess I neglected to confirm that the convoluted command sequence I had come up under bash, would work under cron and /bin/sh December 5 being when I thought I needed to jump from 9.7.6-P4 to 9.9.2-P1before taking some time off before leaving for LISA And, knowing that 9.9 was a desired upgrade given that this is a DNSSEC NSEC3 signed zone file where a wildcard recorded was desiredso it had been taken out until I did upgrade. Which is odd, because as I type this...I realize that another unit (library/ezproxy) has a wildcard DNS record also DNSSEC NSEC3 signedand they hadn't mentioned any problems to me. Though they hadn't been using a wildcard certificate for the service for some time (ipsCA certs not being widely recognized anymore being the reason wasn't enough to stay with free for .edu certs...which they had found included wildcard certs.) So they had probably had a workaround for the one external resource that was SSL, they were working on a wildcard cert now as there are now more than two external resources requiring SSL. And, that somebody that knows the cost of incommon certs has started working for them 9.9.3 also marks the switch to compiling it 64-bit instead of 32-bit for Solaris. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
The logs do seem to only check the first 1-2 servers in the forwarders
section when the problem is occurring. If named is restarted on this
slave, it will check all the servers, as expected when it receives a notify.
We have our zones distributed among 5 masters to speed updates. The
software we use that allows customers to update their zones does a direct
update of the zone file on the master server to which it is connected, then
queues a reload of named. Once every few minutes the reload occurs on the
master, which sends the notify to our slave servers, who should check
serials on all the masters and transfer from the latest. We do this
because the number of zones we have was causing the reload on the masters
to take too long and delaying updates to the slaves.
This system was working without issue until this slave was updated to BIND
9.8, and the slave that is still on BIND 9.3 continues to function normally.
One thing that just occurred to me is that in every case I've seen thus
far, an earlier master (say 10.0.1.1) had a zone with an old serial for the
domain in question (which has a newer serial on say 10.0.5.1). This occurs
because we tend to move users between servers that sync to different
masters. Could this be related to the problem?
On Tue, Jul 30, 2013 at 5:01 PM, Steven Carr sjc...@gmail.com wrote:
On 30 July 2013 21:38, Brandon Whaley brand...@inmotionhosting.comwrote:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
So given what I mentioned before I would envisage BIND contacting 10.0.1.1
and then failing to 10.0.2.1 but ignoring the rest. Is this what you are
seeing in the logs? Or is the slave not attempting to contact any of the
servers?
Just out of curiosity, what is the reason for having 5 masters? are these
multi-master? or are they effectively slaves that also allow zone transfers?
Steve
___
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
--
Best Regards,
Brandon W.
Tier 3 System Administrator
InMotion Hosting Inc.
888-321-4678
757-416-6575 (Int'l)
NEW: 24x7 EMAIL and PHONE Technical Support
Did you know?
We'll Build, Update and Promote Your Site for You! Visit
www.inmotionhosting.com/webdesign
Answers to commonly asked questions, as well as other useful tools, can be
found at http://support.inmotionhosting.com
How am I doing? Please feel free to email my manager at
manager_feedb...@inmotion.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
On 30 July 2013 22:52, Brandon Whaley brand...@inmotionhosting.com wrote: Once every few minutes the reload occurs on the master, which sends the notify to our slave servers, who should check serials on all the masters and transfer from the latest. I think this is your problem. From what I understand BIND does not do this. It will contact the last server that it received an update from and check the serial, if it's greater then it will update, but it certainly won't chase around each master server looking to see if one of them has a higher version. I think you need to fix the way you have implemented the masters, BIND doesn't support multi-master DNS which is what you are trying to implement. If you need this functionality then Microsoft does (to a point, there still is effectively a master but as it's distributed through LDAP it handles multiple updates in the background using a timestamp of the update as the decider) but then IMHO it's just not BIND. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
That's certainly disconcerting (and diverges from the behavior we continue to see with BIND 9.3). Is there any reason these updates would work without issue immediately after a restart but stop working at some point later? As you can see in the logs I provided in my initial post (relevant lines copied below) it does work as I described after a restart, for an as-yet-determined amount of time: 29-Jul-2013 10:43:34.879 notify: info: client 10.0.4.1#42576: received notify for zone 'example.com' 29-Jul-2013 10:43:34.890 general: info: zone example.com/IN: serial number (2011061500) received from master 10.0.1.1#53 ours (2013022611) 29-Jul-2013 10:43:34.900 general: info: zone example.com/IN: refresh: non-authoritative answer from master 10.0.2.1#53 (source 10.10.10.1#0) 29-Jul-2013 10:43:34.904 general: info: zone example.com/IN: refresh: non-authoritative answer from master 10.0.3.1#53 (source 10.10.10.1#0) 29-Jul-2013 10:43:34.915 general: info: zone example.com/IN: Transfer started. 29-Jul-2013 10:43:34.916 xfer-in: info: transfer of 'example.com/IN' from 10.0.4.1#53: connected using 10.10.10.1#44081 29-Jul-2013 10:43:34.919 general: info: zone example.com/IN: transferred serial 2013072910 29-Jul-2013 10:43:34.919 xfer-in: info: transfer of 'example.com/IN' from 10.0.4.1#53: Transfer completed: 1 messages, 23 records, 719 bytes, 0.002 secs (359500 bytes/sec) 29-Jul-2013 10:43:35.379 notify: info: client 10.0.4.1#43038: received notify for zone 'example.com' 29-Jul-2013 10:43:35.380 general: info: zone example.com/IN: notify from 10.0.4.1#43038: zone is up to date On Tue, Jul 30, 2013 at 6:06 PM, Steven Carr sjc...@gmail.com wrote: On 30 July 2013 22:52, Brandon Whaley brand...@inmotionhosting.comwrote: Once every few minutes the reload occurs on the master, which sends the notify to our slave servers, who should check serials on all the masters and transfer from the latest. I think this is your problem. From what I understand BIND does not do this. It will contact the last server that it received an update from and check the serial, if it's greater then it will update, but it certainly won't chase around each master server looking to see if one of them has a higher version. I think you need to fix the way you have implemented the masters, BIND doesn't support multi-master DNS which is what you are trying to implement. If you need this functionality then Microsoft does (to a point, there still is effectively a master but as it's distributed through LDAP it handles multiple updates in the background using a timestamp of the update as the decider) but then IMHO it's just not BIND. Steve ___ 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 -- Best Regards, Brandon W. Tier 3 System Administrator InMotion Hosting Inc. 888-321-4678 757-416-6575 (Int'l) NEW: 24x7 EMAIL and PHONE Technical Support Did you know? We'll Build, Update and Promote Your Site for You! Visit www.inmotionhosting.com/webdesign Answers to commonly asked questions, as well as other useful tools, can be found at http://support.inmotionhosting.com How am I doing? Please feel free to email my manager at manager_feedb...@inmotion.net ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND slave stops updating from master after 1-3 days
On 30 July 2013 23:19, Brandon Whaley brand...@inmotionhosting.com wrote: That's certainly disconcerting (and diverges from the behavior we continue to see with BIND 9.3). Is there any reason these updates would work without issue immediately after a restart but stop working at some point later? As you can see in the logs I provided in my initial post (relevant lines copied below) it does work as I described after a restart, for an as-yet-determined amount of time: 29-Jul-2013 10:43:34.879 notify: info: client 10.0.4.1#42576: received notify for zone 'example.com' 29-Jul-2013 10:43:34.890 general: info: zone example.com/IN: serial number (2011061500) received from master 10.0.1.1#53 ours (2013022611) 29-Jul-2013 10:43:34.900 general: info: zone example.com/IN: refresh: non-authoritative answer from master 10.0.2.1#53 (source 10.10.10.1#0) 29-Jul-2013 10:43:34.904 general: info: zone example.com/IN: refresh: non-authoritative answer from master 10.0.3.1#53 (source 10.10.10.1#0) 29-Jul-2013 10:43:34.915 general: info: zone example.com/IN: Transfer started. 29-Jul-2013 10:43:34.916 xfer-in: info: transfer of 'example.com/IN' from 10.0.4.1#53: connected using 10.10.10.1#44081 29-Jul-2013 10:43:34.919 general: info: zone example.com/IN: transferred serial 2013072910 29-Jul-2013 10:43:34.919 xfer-in: info: transfer of 'example.com/IN' from 10.0.4.1#53: Transfer completed: 1 messages, 23 records, 719 bytes, 0.002 secs (359500 bytes/sec) 29-Jul-2013 10:43:35.379 notify: info: client 10.0.4.1#43038: received notify for zone 'example.com' 29-Jul-2013 10:43:35.380 general: info: zone example.com/IN: notify from 10.0.4.1#43038: zone is up to date So looking at that log it would seem to indicate that on a restart it does consult masters in sequence until it finds one that has a higher serial than what it currently has. It tried 1.1 and got a very old serial, skipped 2.1 and 3.2 as there was a non-authoritative answer, then got a response from 4.1 with a higher serial and initiated transfer, it has no need to consult 5.1 as it shouldn't be any higher than the one it has just transferred (because BIND doesn't do multi-master). After receiving the notify it goes back to the first master to check for an update, which fails (as it's older) and eventually leads to the zone expiring. Steve ___ 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: Updated to bind 9.9.3-P2
On 07/30/2013 02:49 PM, Lawrence K. Chen, P.Eng. wrote: From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2. All the picky messages of this version You had a lot of issues in your message. IMO they make it clear that you can benefit from the better testing provided by the latest version (which is 9.9.3-P2, btw). You will definitely be better off fixing those errors. You can compile the latest version before installing it, and use the named-compilezone and named-checkzone from the newer version before you complete the upgrade process. Regarding your DNSSEC problems, you should really consider the auto-dnssec maintain option, which will prevent the need for your homegrown automated system (which apparently has issues), and is one of the chief benefits of the 9.9 branch. hope this helps, Doug ___ 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
