Date: Thu, 13 Jan 2022 08:06:01 -0600 From: Tim Daneliuk <tundra@tundraware.com> To: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: FreeBSD Trust Chain Message-ID: <48f535f9-649f-d28c-9684-a4807eef5729@tundraware.com> In-Reply-To: <CAM8r67B%2BBQC1j1TUHOebjrS56xh-DYKRE952xUO96fC4_dgRug@mail.gmail.com> References: <20220113034748.8646A34B2207@ary.qy> <76433042-3807-4d9a-fca6-7c394e602866@tundraware.com> <CAM8r67B%2BBQC1j1TUHOebjrS56xh-DYKRE952xUO96fC4_dgRug@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/13/22 3:42 AM, Tomasz CEDRO wrote: <SNIP> > Do you use local_unbound? Some people (including me) recently noticed > resolve problems with local_unbound when using local LAN dns servers > (i.e. 192.168.0.1) on a desktop machine, when using external dns only > for local_unbound all seems to work fine, when using that local LAN > resolver directly without local_unbound also all seems to work fine. > Looks a bit similar issue somewhere out there maybe? :-) > Nope, we're not using local_unbound. The machine in question is a public facing DNS server behind a static IP on the Comcast Business network. It also acts as a nating firewall to one of our LANs. The bind instance there properly resolves queries for our zone. But when it is asked to lookup something outside our own domain, it intermittently fails to do so with no predictable pattern. Adding a forwarder - either Cloudflare's or one of our other master DNS servers not on the same network, everything resolves just fine. This configuration has been in place and working for years so we surmise that either something got broken by a recent bind update, or Comcast is doing evil things with DNS queries. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48f535f9-649f-d28c-9684-a4807eef5729>