[dns-operations] Using all the addresses of every name server? (Was: ANY efforts at taking additional responses more compact?

[Viktor Dukhovni]

> On Sep 12, 2016, at 3:47 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
>> Really? I read RFC 1035, section 4.2.1, and specially 7.2, as saying
>> that a resolver must (not RFC 2119 MUST, RFC 1035 was written before)
>> try all IP addresses of an authoritative name server. RFC 1034,
>> section 5.3.3 is even clearer "The strategy is to cycle around all of
>> the addresses for all of the servers with a timeout between each
>> transmission.  In practice it is important to use all addresses of a
>> multihomed host [...]"
> 
> It's a bad idea.  A few resolvers implement this, but it leads to a problem: If there is a query which leads to an unexpected response from the upstream servers, the query will be *sent* to all of them.  This can lead to service availability problems.

The issue of *how many* nameserver addresses to try is quite separate
from the issue of whether to try multiple IP addresses of a notionally
multi-homed host.  The days when multiple addresses under a single name
really meant a single machine are long gone (or perhaps never were).
These days a name with a single address is often multiple machines, and
conversely multiple addresses under a single name are often in fact
multiple machines.

I would not recommend imputing any shared state across multiple
addresses associated with a given name.  All that one learns is
that all the addresses are associated with the same logical
service.

In Postfix (an example with which I happen to be familiar), there
is no distinction between 20 (equal preference) MX hosts with a
single address each, and one MX host with twenty addresses.  However,
by default at most 10 connection attempts and at most 2 SMTP sessions
(SMTP transactions over completed TCP connections) are made per delivery.
Postfix does not waste scarce resources to try every address of snowshoe
spammer domains with large pools of MX hosts.

-- 
	Viktor.