Date: Sat, 14 Oct 2017 18:08:27 -0500 From: CyberLeo Kitsana <cyberleo@cyberleo.net> To: RW <rwmaillists@googlemail.com>, freebsd-questions@freebsd.org Subject: Re: Unbound(8) caching resolver no workie on fresh install :-( Message-ID: <64e5525d-fd1c-6e9b-526c-0d9c4e8f788c@cyberleo.net> In-Reply-To: <20171014224323.1ed35da3@gumby.homeunix.com> References: <4172.1507827505@segfault.tristatelogic.com> <b1f2d83e-d09f-42ad-f03d-26b6995c141f@columbus.rr.com> <20171014224323.1ed35da3@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/14/2017 04:43 PM, RW via freebsd-questions wrote: > On Thu, 12 Oct 2017 17:31:32 -0400 > Baho Utot wrote: > >> On 10/12/2017 12:58 PM, Ronald F. Guilmette wrote: > >>> During this (fresh) install, I -never- explicitly selected any >>> option that would obcviously hav the effect of telling unbound to >>> forward/route all of its DNS queries through any other specific >>> name servers). So why on earth would it be doing so? >> >> Because the base system uses unbound as the resolver. > > That doesn't explain why it forwards by default. FreeBSD's local_unbound setup will, by default, forward to the nameservers provided by DHCP or hardcoded in the config files, rather than doing full lookups by itself. See below for why this is safe. > Is ISP cache poisoning entirely a thing of the past? IIRC there are > also attacks where a DSL router is hacked and reconfigured to give bogus > DNS servers via DHCP. Properly implemented DNSSEC mitigates cache-poisoning or DNS redirection attacks, as any answers not properly signed by the authority for the name you're looking up (and every parent up to the root zone) will be rejected. The name will simply fail to resolve, rather than returning corrupt, forged, or tampered results. FreeBSD implemented local_unbound specifically to add DNSSEC validation to machines that rely on external recursing nameservers, like those provided by your ISP. DNSSEC is slow, as any given validation requires many lookups and cryptographic operations to chain the signature to a trusted root, so any local caching is beneficial. Offloading the validation to a single local caching daemon is much easier and less error-prone than dealing with the complexities of adding validation and cache management to a library that is loaded into pretty much every process on your machine. > There's also the issue that mail servers should avoid using shared > caches because of per IP address limits on blocklists. Linux resolver > packages that set-up forwarding without making it clear have been a > problem for a while now. -- Fuzzy love, -CyberLeo <CyberLeo@CyberLeo.Net> Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Element9 Communications http://www.Element9.net Furry Peace! - http://www.fur.com/peace/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64e5525d-fd1c-6e9b-526c-0d9c4e8f788c>