problem with latest BIND9 9.11 from git
Hi,
(I'm not sure this is the right list for this, but I'm not sure where to
send it, or if it should go to the bug tracker, or if I should just shut up
because it's the bleading edge and I'm going to cut myself.)
Today, I updated the FreeBSD ports, so 9.9.9 and 9.10.4 went without a
hitch, but the bind9-devel port less so. I updated to the current head,
which is a27dc50, this is after dnssec-keymgr was added.
If I try to build with python, I first get this error:
making all in
/wrkdirs/usr/ports/dns/bind9-devel/work/bind9-a27dc50/bin/python/isc/tests
/usr/local/bin/python2.7 policy.py parse /dev/null > /dev/null
Generating LALR tables
/usr/local/bin/python2.7 -m parsetab
/usr/local/bin/python2.7 policy.py parse /dev/null > /dev/null
/usr/local/bin/python2.7 -m parsetab
make[5]: don't know how to make __init__.pyc. Stop
This is because the Makefile uses a GNUism, which is:
%.pyc: %.py
$(PYTHON) -m compileall .
So, I resisted the urge to ask a dependency on GNU make and I patched this
to:
.SUFFIXES: .py .pyc
.py.pyc:
$(PYTHON) -m compileall .
Which got me going a bit further, and then, it died on:
install -m 0644 ./dnssec-keymgr.8
/wrkdirs/usr/ports/dns/bind9-devel/work/stage/usr/local/man/man8
install: ./dnssec-keymgr.8: No such file or directory
It seems that man page was not generated and committed. I could add all
the docbook suite as a dependency but it seems overkill... :-/
So, to fix the build, I'm going to comment out the missing man page.
Also, right now, it installs all the .py{,c} files ${libdir} which is
/usr/local/lib, and I don't think it is a good thing.
--
Mathieu Arnold
pgpc0qEL2nh4k.pgp
Description: PGP signature
___
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
bind 9.10.3-P4 listener exits unceremoniously - bug?
We're in the process of standing up new anycast name servers. They are running BIND 9.10.3-P4 on FreeBSD 10.2-RELEASE-p9. We've only got one in service so far, but we've run into a very difficult issue. We are episodically seeing the BIND port 53 listener that is bound to the loopback (anycast) address exit. Sometimes both TCP and UDP listeners quit, in other instances just the TCP listener quits. Note that this is a recursive server. Here's an example of what I find in the BIND logs: 29-Apr-2016 12:38:06.849 network: no longer listening on 192.168.1.1#53 29-Apr-2016 12:38:06.861 network: listening on IPv4 interface lo1, 192.168.1.1#53 29-Apr-2016 12:38:06.863 network: binding TCP socket: permission denied lo1 is the anycast address for this box. BIND is still happily listening for TCP:53 on the interface address. The permission denied complaint is because BIND is running chroot. We could fix that, but it won't do anything to help explain why BIND stops listening on the loopback interface. No sign of trouble in the system logs. No evidence that there is an issue with the loopback interface disappearing. I've got lots of logging enabled in BIND, and the best I can tell is that it appears the unbind might be happening around the time when a zone transfer from the RPZ master occurs, but there is nothing helpful in the logs beyond the above announcement of 'no longer listening' (that message doesn't get written into the debug log file, so it is hard to correlate time between debug messages and the unbind). No obvious evidence of malfeasance is present. We've seen this happen three times over the past seven days. Twice it was just the TCP listener that dropped, once it was both TCP and UDP. Any thoughts on what rocks to turn over to find some clue on what might be causing this would be greatly appreciated. I can't tell if this has the smell of a bug or not at this point. thank you, mark --- Mark Boolootian UC Santa Cruz ___ 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 9.10.3-P4 listener exits unceremoniously - bug?
In message , Mark Boolootian writes: > We're in the process of standing up new anycast > name servers. They are running BIND 9.10.3-P4 > on FreeBSD 10.2-RELEASE-p9. > > We've only got one in service so far, but we've > run into a very difficult issue. We are episodically > seeing the BIND port 53 listener that is bound to the > loopback (anycast) address exit. Sometimes both > TCP and UDP listeners quit, in other instances just > the TCP listener quits. Note that this is a recursive > server. > > Here's an example of what I find in the BIND logs: > > 29-Apr-2016 12:38:06.849 network: no longer listening on 192.168.1.1#53 > 29-Apr-2016 12:38:06.861 network: listening on IPv4 interface lo1, > 192.168.1.1#53 > 29-Apr-2016 12:38:06.863 network: binding TCP socket: permission denied > > lo1 is the anycast address for this box. BIND is still happily > listening for TCP:53 on the interface address. The permission > denied complaint is because BIND is running chroot. Chroot has zero impact on this. running with -u will but you can configure FreeBSD to allow the user named is running as to bind to port 53. https://deepthought.isc.org/article/AA-00621/50/How-to-bind-to-port-53-when-using-named-u-bind-with-FreeBSD.html > We could > fix that, but it won't do anything to help explain why BIND stops > listening on the loopback interface. It's because the interface goes away. named listens to the routing socket and rescans the interfaces on changes. The interface is going away and returning. > No sign of trouble in the system logs. No evidence that there is > an issue with the loopback interface disappearing. > > I've got lots of logging enabled in BIND, and the best I > can tell is that it appears the unbind might be happening > around the time when a zone transfer from the RPZ master > occurs, but there is nothing helpful in the logs beyond the > above announcement of 'no longer listening' (that message doesn't > get written into the debug log file, so it is hard to correlate > time between debug messages and the unbind). No obvious > evidence of malfeasance is present. > > We've seen this happen three times over the past seven days. > Twice it was just the TCP listener that dropped, once it was > both TCP and UDP. > > Any thoughts on what rocks to turn over to find some clue > on what might be causing this would be greatly appreciated. > I can't tell if this has the smell of a bug or not at this point. > > thank you, > mark > --- > Mark Boolootian > UC Santa Cruz > ___ > 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
Re: bind 9.10.3-P4 listener exits unceremoniously - bug?
Hi Mark, Thanks very much for the response on this. > Chroot has zero impact on this. running with -u will but you can > configure FreeBSD to allow the user named is running as to bind to > port 53. Yes, sorry about that. That's what I meant to say :-) >> explain why BIND stops listening on the loopback interface. > > It's because the interface goes away. named listens to the routing > socket and rescans the interfaces on changes. The interface is > going away and returning. In poking at code (without a great deal of comprehension), it seemed like that was certainly a reasonable explanation. But if that was the case, why would we lose only the TCP listener with the UDP listener still bound to the loopback address? It looked to me like the rescan code would dump any listener bound to the interface. Something I didn't mention in the earlier email is that we also have an IPv6 anycast address assigned to the same loopback interface. We don't ever see any indication in the logs about the TCP/UDP ports associated with the IPv6 address being dropped (though I have just realized that I never even thought to look at these bindings when the IPv4 failures occurred). Thanks again for the ack - much appreciated. best regards, mark ___ 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, Apr 25, 2016, at 11:44 AM, jaso...@mail-central.com wrote: > Now back to figuring this^ out :-/ I started from scratch, now on bind 9.10.4. After update, I'm preserving my jnl files, but they're sill not getting written to zone files on nameserver restart. With this update file cat ~/nsupdate.txt server ns01.example.com local 10.0.0.17 debug yes zone example.com. update add test.example.com. 300 in TXT "YY" show send I exec the nsupdate $NSUPDATE ~/nsupdate.txt In my nameserver log I get Apr 29 20:03:24 ns01 named[3440]: 29-Apr-2016 20:03:24.810 update-security: info: client 10.0.0.17#17687/key jason-key: view external: signer "jason-key" approved Apr 29 20:03:24 ns01 named[3440]: 29-Apr-2016 20:03:24.810 update: info: client 10.0.0.17#17687/key jason-key: view external: updating zone 'example.com/IN': adding an RR at 'test.example.com' TXT "YY" I can see the change dig TXT test.example.com @ns01.example.com +short "YY" Checking at this time in the nameserver's chroot & init dirs, ls -altr /var/chroot/named/namedb/master/example.com* && \ ls -altr /etc/named/namedb/master/example.com* I see the .jnl only in the chroot -rw-r- 1 named named 1.2K Apr 29 20:01 /var/chroot/named/namedb/master/example.com.zone !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /var/chroot/named/namedb/master/example.com.zone.jnl -rw-r- 1 named named 1.2K Apr 29 20:01 /etc/named/namedb/master/example.com.zone It's got the update in it named-journalprint /var/chroot/named/namedb/master/example.com.zone.jnl | grep TXT add test.example.com. 300 IN TXT "YY" I then restart the nameserver systemctl stop named systemctl start named Checking again, since my chroot explicitly copies the journals, I now see the jnl in BOTH the chroot dir and the init dir ls -altr /var/chroot/named/namedb/master/example.com* && \ ls -altr /etc/named/namedb/master/example.com* -rw-r- 1 named named 1.2K Apr 29 20:01 /var/chroot/named/namedb/master/example.com.zone !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /var/chroot/named/namedb/master/example.com.zone.jnl -rw-r- 1 named named 1.2K Apr 29 20:01 /etc/named/namedb/master/example.com.zone !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /etc/named/namedb/master/example.com.zone.jnl with the update correct named-journalprint /var/chroot/named/namedb/master/example.com.zone.jnl | grep TXT && \ named-journalprint /etc/named/namedb/master/example.com.zone.jnl | grep TXT add test.example.com. 300 IN TXT "YY" add test.example.com. 300 IN TXT "YY" But obviously, the named re-start did NOT write the zone files -- the data's still, just in the jnl's, not in the zone files grep Y \ /var/chroot/named/namedb/master/example.com.zone \ /etc/named/namedb/master/example.com.zone (empty) It's official. This is driving me nuts. Jason ___ 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?
In message <1461987372.2397618.593994601.3d357...@webmail.messagingengine.com>, jaso...@mail-central.com writes: > On Mon, Apr 25, 2016, at 11:44 AM, jaso...@mail-central.com wrote: > > Now back to figuring this^ out :-/ > > I started from scratch, now on bind 9.10.4. > > After update, I'm preserving my jnl files, but they're sill not getting writt > en to zone files on nameserver restart. Just give it time. The zone contents are the masterfile + journal. The masterfile only gets written periodically as it can be a expensive operation. > With this update file > > cat ~/nsupdate.txt > server ns01.example.com > local 10.0.0.17 > debug yes > zone example.com. > update add test.example.com. 300 in TXT "YY" > show > send > > I exec the nsupdate > > $NSUPDATE ~/nsupdate.txt > > In my nameserver log I get > > Apr 29 20:03:24 ns01 named[3440]: 29-Apr-2016 20:03:24.810 update-secur > ity: info: client 10.0.0.17#17687/key jason-key: view external: signer "jason > -key" approved > Apr 29 20:03:24 ns01 named[3440]: 29-Apr-2016 20:03:24.810 update: info > : client 10.0.0.17#17687/key jason-key: view external: updating zone 'example > .com/IN': adding an RR at 'test.example.com' TXT "YY" > > I can see the change > > dig TXT test.example.com @ns01.example.com +short > "YY" > > Checking at this time in the nameserver's chroot & init dirs, > > ls -altr /var/chroot/named/namedb/master/example.com* && \ > ls -altr /etc/named/namedb/master/example.com* > > I see the .jnl only in the chroot > > -rw-r- 1 named named 1.2K Apr 29 20:01 /var/chroot/named/na > medb/master/example.com.zone > !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /var/chroot/named/na > medb/master/example.com.zone.jnl > -rw-r- 1 named named 1.2K Apr 29 20:01 /etc/named/namedb/ma > ster/example.com.zone > > It's got the update in it > > named-journalprint /var/chroot/named/namedb/master/example.com.zone.jnl > | grep TXT > add test.example.com. 300 IN TXT "YY" > > I then restart the nameserver > > systemctl stop named > systemctl start named > > Checking again, since my chroot explicitly copies the journals, I now see the > jnl in BOTH the chroot dir and the init dir > > ls -altr /var/chroot/named/namedb/master/example.com* && \ > ls -altr /etc/named/namedb/master/example.com* > -rw-r- 1 named named 1.2K Apr 29 20:01 /var/chroot/named/na > medb/master/example.com.zone > !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /var/chroot/named/na > medb/master/example.com.zone.jnl > -rw-r- 1 named named 1.2K Apr 29 20:01 /etc/named/namedb/ma > ster/example.com.zone > !!! -rw-r--r-- 1 named named 789 Apr 29 20:03 /etc/named/namedb/ma > ster/example.com.zone.jnl > > with the update correct > > named-journalprint /var/chroot/named/namedb/master/example.com.zone.jnl > | grep TXT && \ > named-journalprint /etc/named/namedb/master/example.com.zone.jnl | grep > TXT > add test.example.com. 300 IN TXT "YY" > add test.example.com. 300 IN TXT "YY" > > But obviously, the named re-start did NOT write the zone files -- the data's > still, just in the jnl's, not in the zone files > > grep Y \ >/var/chroot/named/namedb/master/example.com.zone \ >/etc/named/namedb/master/example.com.zone > (empty) > > It's official. This is driving me nuts. > > Jason > ___ > 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
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
Hi On Fri, Apr 29, 2016, at 08:42 PM, Mark Andrews wrote: > Just give it time. The zone contents are the masterfile + journal. > The masterfile only gets written periodically as it can be a expensive > operation. Sure, under normal operation, as I understand it. IIUC, though, a nameserver restart is supposed to force the write-to-journal immediately, right? But it doesn't appear to be doing it on my setup. ___ 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?
Oops, s/write-to-journal /write-journal-to-masterfile / ___ 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
