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
