Mailing List Archive

1 2  View All
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, 13 May 2021 09:41:25 -0400
Daniel J. Luke wrote:

> On May 13, 2021, at 12:14 AM, Michael B Allen <ioplex@gmail.com>
> wrote:
> > It is not completely trivial setup a caching name server. I
> > literally have two accounts so it's at least a serious nuisance.
>
> It's pretty simple to install unbound and set it up on most systems.

Actually I found "local-unbound" quite confusing on FreeBSD.

It turned-out that all you need to do is set:

local_unbound_enable=YES
local_unbound_forwarders=none

but the second line was undocumented. I had to read through 2 shell
scripts to work it out. If you miss it out unbound will get
automatically configured for forwarding on first run.

What made it doubly confusing is that it got set up with resolvconf
which I'd never given any thought to before.

Forwarding is right for almost all cases, so it wouldn't surprise me if
some Linux distributions have a similar pitfall.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On 2021-05-14 at 10:10:31 UTC-0400 (Fri, 14 May 2021 15:10:31 +0100)
RW <rwmaillists@googlemail.com>
is rumored to have said:

> Forwarding is right for almost all cases,

True, but forwarding to any of the free public resolvers is not suitable
for systems intentionally exposed to connections from unknown random
outsiders. It is especially important for systems doing MX or spam
filtering service to use a resolver under common administrative control
and on the same LAN if not the same machine. Beyond the issues of answer
legitimacy, excess latency or UDP packet loss can cause performance and
reliability problems, particularly on high-traffic MTAs.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Fri, May 14, 2021 at 11:14:50AM -0400, Bill Cole wrote:
>
> True, but forwarding to any of the free public resolvers is not suitable for
> systems intentionally exposed to connections from unknown random outsiders.
> It is especially important for systems doing MX or spam filtering service to
> use a resolver under common administrative control and on the same LAN if
> not the same machine. Beyond the issues of answer legitimacy, excess latency
> or UDP packet loss can cause performance and reliability problems,
> particularly on high-traffic MTAs.

Why would there be issues of legitimacy or latency if my local resolver
forwards everything to 1.1.1.1 or 8.8.8.8? Never had any problems and I'm
pretty sure the large caches answer most generic lookups faster. Obviously
specific DNSBLs are configured to bypass forwarding.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On 2021-05-14 at 11:35:05 UTC-0400 (Fri, 14 May 2021 18:35:05 +0300)
Henrik K <users@spamassassin.apache.org>
is rumored to have said:

> On Fri, May 14, 2021 at 11:14:50AM -0400, Bill Cole wrote:
>>
>> True, but forwarding to any of the free public resolvers is not
>> suitable for
>> systems intentionally exposed to connections from unknown random
>> outsiders.
>> It is especially important for systems doing MX or spam filtering
>> service to
>> use a resolver under common administrative control and on the same
>> LAN if
>> not the same machine. Beyond the issues of answer legitimacy, excess
>> latency
>> or UDP packet loss can cause performance and reliability problems,
>> particularly on high-traffic MTAs.
>
> Why would there be issues of legitimacy or latency if my local
> resolver
> forwards everything to 1.1.1.1 or 8.8.8.8?

Legitimacy:

Both Google (8.8.8.8) & CloudFlare (1.1.1.1) claim not to filter DNS
results, although Google hedges that a bit in the FAQ at
https://developers.google.com/speed/public-dns/faq. If you're going to
forward anything to a public resolver, those 2 would be the best
choices.

Most other public resolvers openly tout their filtering of results as
"protection" and some have at times experimented with typo-fixing (e.g.
correcting 'yaho' to 'yahoo') and typo-squatting: replacing all NXDOMAIN
A/AAAA answers with the addresses of their own ad-laden machines.

> Never had any problems

Anecdotal.

I *have* seen a client's machines crippled for about an hour by Google's
public DNS going bad for them locally. Whether it was something wrong
with their anycasting, networking breakage at the link provider, or just
the most-local nodes failing, I and they will never know. When it
happens, there is no documented way to report a problem or get any idea
about when (if ever) it will be resolved.

I doubt that there is any way for anyone outside of Google to know how
rare such failures are. I doubt they would ever share such information
in any useful way. I suspect that their availability in a global
aggregate sense is good enough that they could call it 'five nines' or
whatever, but that's not satisfying for people who are the 0.05% of
Google's users affected for 0.05% of a year by a mystery outage.

> and I'm
> pretty sure the large caches answer most generic lookups faster.

An answer from a host-local cache will always be much faster than an
answer from a cache that is on the other side of a router hop and WAN
link. An answer from a LAN-local cache will be as well, as long as it
isn't overloaded. DNS queries by a busy MTA which are rooted in routine
'ham' handling have a very high cache hit rate on a mature local cache,
while deep misses (i.e. where the resolver must go to the root zone or a
TLD nameserver to get glue) are largely a product of spam. To the extent
that DNS slowness affects mail, it disproportionately affects spam, if
your cache is well-populated with names you see a lot of.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

1 2  View All