Re: unbound on ~ last 2-3 snapshots - i386
On 2014-07-26, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann toddo.zimmerm...@gmail.com wrote: Have name resolution failure after an upgrade ( rebooting into the the new system) on my crusty i386 server. A # kill -9 'unbound pid' plus starting unbound from rc.d after and everything is fine. Might have been going on for awhile, but usually it works itself out. -- Z I had sent message about unbound (subject unbound reverse DNS problem to local stub zone) on May 17, also on i386. But I have only problems with reverse DNS lookups on a local zone, hosted by nsd on the same host. Restarting unbound, makes the lookup work again for a given IP, but then might make reverse lookup fail for others :( This is still the case for me with more recent snapshots, the last I have running on that box is from June 15. Didn't this go away when you changed to the correct zone names? In unbound, I only had the 10.in-addr.arpa and in nsd I have 0.0.10.in-addr.arpa. I only had to change unbound configuration as suggested, which up to now seems to work reliable.
Re: unbound on ~ last 2-3 snapshots - i386
On Monday, July 28, 2014 12:46 CEST, Stuart Henderson s...@spacehopper.org wrote: On 2014-07-26, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann toddo.zimmerm...@gmail.com wrote: Have name resolution failure after an upgrade ( rebooting into the the new system) on my crusty i386 server. A # kill -9 'unbound pid' plus starting unbound from rc.d after and everything is fine. Might have been going on for awhile, but usually it works itself out. -- Z I had sent message about unbound (subject unbound reverse DNS problem to local stub zone) on May 17, also on i386. But I have only problems with reverse DNS lookups on a local zone, hosted by nsd on the same host. Restarting unbound, makes the lookup work again for a given IP, but then might make reverse lookup fail for others :( This is still the case for me with more recent snapshots, the last I have running on that box is from June 15. Didn't this go away when you changed to the correct zone names? In unbound, I only had the 10.in-addr.arpa and in nsd I have 0.0.10.in-addr.arpa. I only had to change unbound configuration as suggested, which up to now seems to work reliable. That comment was from me, with the problem I had. Sebastian
Re: unbound on ~ last 2-3 snapshots - i386
On 2014/07/28 13:14, Sebastian Reitenbach wrote:
On Monday, July 28, 2014 12:46 CEST, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-07-26, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann
toddo.zimmerm...@gmail.com wrote:
Have name resolution failure after an upgrade ( rebooting into the the
new system) on my crusty i386 server. A # kill -9 'unbound pid' plus
starting unbound from rc.d after and everything is fine. Might have
been going on for awhile, but usually it works itself out.
-- Z
I had sent message about unbound (subject unbound reverse DNS problem to
local stub zone)
on May 17, also on i386.
But I have only problems with reverse DNS lookups on a local zone, hosted
by
nsd on the same host. Restarting unbound, makes the lookup work again for
a given
IP, but then might make reverse lookup fail for others :(
This is still the case for me with more recent snapshots, the last I have
running
on that box is from June 15.
Didn't this go away when you changed to the correct zone names?
In unbound, I only had the 10.in-addr.arpa and in nsd I have
0.0.10.in-addr.arpa. I only had to change unbound configuration as
suggested, which up to now seems to work reliable.
That comment was from me, with the problem I had.
Sebastian
Yes the comment was from you and said that you only had to change
unbound configuration .. which up to now seems to work reliable.
I read that as you changed the configuration and that fixed it.
If that didn't fix it I would suggest serving a 10.in-addr.arpa.
zone with NS pointing in the right place to override the external
NS blackhole-{1,2}.iana.org.
If this still doesn't help, maybe turn on query logging or use
tcpdump and work out what it's actually doing..
Re: unbound on ~ last 2-3 snapshots - i386
On Sun, Jul 27, 2014 at 12:22:52AM -0400, Todd Zimmermann wrote: The home LAN setup here is a humble /29 on IPv4: unbound listens on the internal and loopback interfaces, forwarded to dnscrypt-proxy on localhost, and then out to OpenDNS. So you are basically daisy chaining three different resolvers? This seems a bit scary to me from a maintenence standpoint :). If nothing else I guess you need to verify all pieces of the puzzle are working as intended when problems occur. I do have snort (inline mode) running, so there is the expected temp loss of remote connectivity until snort is running. Normally it works itself out, but this is likely the point where this issue appears. Guess it's possible, not sure how it would affect unbound. @Patrick - I see /etc/rc.d/unbound already has daemon_flags=-c /var/unbound/unbound.conf. My rc.conf.local just has unbound_flags= Yeah, sorry about the confusion. Your way is the proper one, I was just doing things a bit too fast when trying to recreate your problem. # dig yahoo.com returns a SERVFAIL After a # kill -9 and starting unbound from /etc/rc things are fine. I'll turn up logging/verbosity and poke around more if/when it happens again. Will try to figure out ktrace and/or turn on debugging (-d) for unbound. Have run into this once in a blue moon when the system has been running for days/weeks. From your initial message I was under the impression the SERVFAIL occurs after every reboot. Seems it is more complex then :). Regards, Patrik Lundin
Re: unbound on ~ last 2-3 snapshots - i386
On Sun, Jul 27, 2014 at 3:12 AM, Patrik Lundin patrik.lundin@gmail.com wrote: So you are basically daisy chaining three different resolvers? This seems a bit scary to me from a maintenence standpoint :). If nothing else I guess you need to verify all pieces of the puzzle are working as intended when problems occur. Well it's actually only two, dnscrypt-proxy isn't a resolver. It just encrypts/decrypts DNS queries. Originally I wanted unbound listening only on localhost with divert-to rules in pf, like the ftp-proxy anchor example, but could never get that working. May be worth a revisit to simplify things. I do have snort (inline mode) running, so there is the expected temp loss of remote connectivity until snort is running. Normally it works itself out, but this is likely the point where this issue appears. Guess it's possible, not sure how it would affect unbound. It's one of the biggest bottlenecks on this box during boot, might be the wrong assumption on my part. From your initial message I was under the impression the SERVFAIL occurs after every reboot. Seems it is more complex then :). No, sorry if I implied it was after every reboot. ~ the last few snapshots, it would appear upon rebooting after sysmerge. It has also occurred intermittently/rarely after the box being up for awhile, but still enough over time that # kill -9 'unbound pid' is the reflex response. Simply restarting unbound doesn't fix it. Always assumed it was due to unbound's strict chroot under obsd. Definitely need to examine some configs on my end, always a better way to do things. Haven't been able to recreate it, but if it happens again hopefully have some more useful output. Even if it shows I fell out of the idiot tree and hit all the branches on the way down :) Appreciate your feedback and trying to recreate it. Hopefully wasn't a time waster. - Z
unbound on ~ last 2-3 snapshots - i386
Have name resolution failure after an upgrade ( rebooting into the the new system) on my crusty i386 server. A # kill -9 'unbound pid' plus starting unbound from rc.d after and everything is fine. Might have been going on for awhile, but usually it works itself out. -- Z
Re: unbound on ~ last 2-3 snapshots - i386
On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann toddo.zimmerm...@gmail.com wrote: Have name resolution failure after an upgrade ( rebooting into the the new system) on my crusty i386 server. A # kill -9 'unbound pid' plus starting unbound from rc.d after and everything is fine. Might have been going on for awhile, but usually it works itself out. -- Z I had sent message about unbound (subject unbound reverse DNS problem to local stub zone) on May 17, also on i386. But I have only problems with reverse DNS lookups on a local zone, hosted by nsd on the same host. Restarting unbound, makes the lookup work again for a given IP, but then might make reverse lookup fail for others :( This is still the case for me with more recent snapshots, the last I have running on that box is from June 15. Sebastian
Re: unbound on ~ last 2-3 snapshots - i386
On Sat, Jul 26, 2014 at 04:04:32AM -0400, Todd Zimmermann wrote: Have name resolution failure after an upgrade ( rebooting into the the new system) on my crusty i386 server. A # kill -9 'unbound pid' plus starting unbound from rc.d after and everything is fine. Might have been going on for awhile, but usually it works itself out. Trying to look into this i installed an i386 system from a freshly downloaded snapshot bsd.rd and the only thing i did on the resulting machine was add unbound_flags=-c /var/unbound/etc/unbound.conf to rc.conf.local and reboot the machine. This seems to work just fine for me: == # dig @127.0.0.1 www.openbsd.org ; DiG 9.4.2-P2 @127.0.0.1 www.openbsd.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25223 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.openbsd.org. IN A ;; ANSWER SECTION: www.openbsd.org.86400 IN A 129.128.5.194 ;; AUTHORITY SECTION: openbsd.org.86400 IN NS ns1.telstra.net. openbsd.org.86400 IN NS a.ns.bsws.de. openbsd.org.86400 IN NS ns2.superblock.net. openbsd.org.86400 IN NS c.ns.bsws.de. openbsd.org.86400 IN NS ns1.superblock.net. openbsd.org.86400 IN NS ns.sigmasoft.com. openbsd.org.86400 IN NS zeus.theos.com. ;; Query time: 684 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jul 26 12:47:26 2014 ;; MSG SIZE rcvd: 222 == Is it possible you could share some more information like the output of dig(1), any changes made to the unbound configuration etc? I guess recording what unbound is doing during a bad lookup with ktrace(1) and sharing the resulting log could be helpful as well if there is nothing interesting in the system logs. Regards, Patrik Lundin
Re: unbound on ~ last 2-3 snapshots - i386
Hey Sebastian and Patrik, Thanks for the replies and sorry for the vagueness. Should have been sleeping rather than upgrading/posting. By some minor miracle, a reboot after sysmerge was done too :) Started using unbound from ports on 5.4-stable last winter and once it was working really haven't messed with the config since. It was transferred to the -current config in ~ April with no issues. Forward and reverse for both local and remote work fine. The home LAN setup here is a humble /29 on IPv4: unbound listens on the internal and loopback interfaces, forwarded to dnscrypt-proxy on localhost, and then out to OpenDNS. I do have snort (inline mode) running, so there is the expected temp loss of remote connectivity until snort is running. Normally it works itself out, but this is likely the point where this issue appears. OpenBSD 5.6-beta (GENERIC) #245: Fri Jul 25 11:46:12 MDT 2014 If memory serves, also on the July 22 23 snapshots. @Sebastian, I can send you my unbound.conf if that helps your situation any. My server is a circa 1998 box that is starting to develop some quirks :\ @Patrick - I see /etc/rc.d/unbound already has daemon_flags=-c /var/unbound/unbound.conf. My rc.conf.local just has unbound_flags= # dig yahoo.com returns a SERVFAIL After a # kill -9 and starting unbound from /etc/rc things are fine. I'll turn up logging/verbosity and poke around more if/when it happens again. Will try to figure out ktrace and/or turn on debugging (-d) for unbound. Have run into this once in a blue moon when the system has been running for days/weeks. Thanks and Regards, Z
