Subject: [DNSOP] interop problems with getaddrinfo() address selection

From: Tony Finch <[email-masked]>
Date: Tue, 4 Dec 2007 21:44:51 +0000

Rule 9 of RFC 3484 specifies that the IP addresses (v4 and v6) returned by
getaddrinfo() should be sorted according to the size of their common
prefix with the local host's chosen source IP address. This defeats DNS
round robin load balancing which has led to some severe operational
problems. DNS round robin needs to be documented in an RFC, and RFC 3484
should be updated with rule 9 deleted or substantially modified for
compatibility with DNS round robin.

Ian Jackson has written a thorough description of the problem from the
perspective of a proposal that Debian's version of glibc should have the
troublesome sorting behaviour removed:

http://lists.debian.org/debian-ctte/2007/11/msg00029.html

FreeBSD's getaddrinfo() only implements Rule 9 if the kernel's address
selection policy is configured, which is not done by default so DNS round
robin is passed through.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER GERMAN BIGHT HUMBER THAMES DOVER WIGHT PORTLAND SOUTHWEST 5 TO 7,
INCREASING GALE 8 AT TIMES. MAINLY ROUGH. RAIN THEN SHOWERS. MODERATE OR POOR
BECOMING GOOD.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 14:47:20 -0800

I knew this came up before:

http://lists.oarci.net/pipermail/dns-operations/2007-September/002021.html

Note that the RFC's text says "implementation" and not "application" 
or "protocol."  There isn't a standard DNS algorithm for choosing the 
server to be queried, the algorithms are up to the implementers (as 
the algorithm isn't an inter-operability issue) of DNS instances.

I looked for a bit but can't find an excellent paper in which a 
research stood up different name servers with no connectivity to 
others and then measured the number of (unanswered) queries sent to 
each of the root servers.  One server implementation sent them all to 
A, one sent 1/13th to each of the 13 servers, others did other 
distributions.  This mostly demonstrated the spectrum of strategies.

Note that DNS has reasons not to follow what's in 3484 - namely that 
DNS servers are supposed to be far flung, finding a local one is not 
going to be advantageous (as opposed to other application data 
sources).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 14:47:20 -0800

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 16:29:41 -0800

I stumbled across this:

http://www.nanog.org/mtg-0310/pdf/wessels.pdf

Look for the (unnumbered) slide "Distribution of Queries to 
Nameservers" and the ones following it.

At 14:47 -0800 12/4/07, Edward Lewis wrote:
>or "protocol."  There isn't a standard DNS algorithm for choosing 
>the server to be queried, the algorithms are up to the implementers 
>(as the algorithm isn't an inter-operability issue) of DNS instances.
>
>each of the root servers.  One server implementation sent them all 
>to A, one sent 1/13th to each of the 13 servers, others did other

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 16:29:41 -0800

I stumbled across this:

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 16:29:41 -0800

I stumbled across this:

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2007 08:59:57 +0000

On Tue, 4 Dec 2007, Edward Lewis wrote:
>
> Note that the RFC's text says "implementation" and not "application" or
> "protocol."  There isn't a standard DNS algorithm for choosing the server to
> be queried, the algorithms are up to the implementers (as the algorithm isn't
> an inter-operability issue) of DNS instances.

This is nothing to do with choice of nameserver. This is a stub resolver
implementation problem to do with query result manipulation.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: SOUTHERLY VEERING WESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9,
PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH INCREASING VERY ROUGH OR HIGH.
OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2007 08:59:57 +0000

Tony.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 12 Dec 2007 22:28:44 +0100

> compatibility with DNS round robin.

I think this belongs to the v6ops working group.  It's a technical
mistake that RFC 3484 talks about v4 stub resolver behavior at all, and
that should be fixed.

I'm not even convinced rule 9 makes sense for IPv6 as it is about to be
deployed (with PI and routing generally as wild as in IPv4 land), but I
haven't got any strong feelings about it.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 12 Dec 2007 22:28:44 +0100

---

From: Dean Anderson <[email-masked]>
Date: Thu, 13 Dec 2007 11:48:26 -0500 (EST)

I think it is well known that Round robin DNS load balancing is not a
guaranteed behavior.  The "severe operational problems"  from its
non-support are the fault of unreasonable reliance on insufficient
testing and insufficient analysis of the requirements of DNS resolvers.  
I think the solution here is to get better engineers who read rather
than assume.

This is not a DNS operational issue.

But as a protocol/resolver specification issue, I'd have to say that I
think sorting or randomization should be site specific.  Most of the
time, giving the closest address prefix first, followed by next closest
prefix is the right choice, as it has the best chance of localizing
traffic.  I doubt this will come up on DNSEXT, given the desire to
severely restrict changes to DNS.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Thu, 13 Dec 2007 11:48:26 -0500 (EST)

--Dean

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Dec 2007 22:53:27 +0100

> I think the solution here is to get better engineers who read rather

Huh?  If I understand you correctly, you're saying that it's not worth
fixing the RFC, even if its guidelines seem to cause practical problems
-- because knowledgeable folks will ignore it anyway.

> This is not a DNS operational issue.

Maybe, but which non-IPv6 WG concerns itself with resolver behavior?

> traffic.

Doesn't seem to be the case anymore--these days, hardly any services
reside on the same network as the clients.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Dec 2007 22:53:27 +0100