[getdns-api] SRV, concurrent lookups, Happy Eyeballs-style issues (but DNS)

[Phil Pennock]

On 2013-02-05 at 10:05 -0500, Phillip Hallam-Baker wrote:
> The one part of DNS lookup that I think departs from this model is the fact
> that it is often desirable to throw out multiple DNS queries at the same
> time.

That's a good call which is indicative of a deeper issue, which came to
mind because of RFC6555 (Happy Eyeballs); that doesn't directly address
the point below, but does speak to general dual-stack delay issues and
how to retry sensibly.

There are authoritative name-servers out there which fail to respond to
requests for AAAA records.  Normally, I think these are on
load-balancers which aren't exactly protocol compliant at the best of
times.

So a query for an SRV record which returns hostnames that can need both
IPv4 and IPv6 results can result in any IPv6 query hanging, if the
results aren't returned in AUTHORITY as in-bailiwick answers.

Arguably, that's inherently broken and anything trying to resolve
against it is screwed, but if the only dual-stack entry is at the
highest (last-chosen) priority, it won't affect APIs that take names in
turn and try to resolve them and won't affect IPv4-only clients, so
those problems can persist.

So while I like GetDNS having SRV support, I've just now realised that
there is a severe limitation to the API model I endorsed just last week.
Sorry.  (The ordering issue that was the subject of debate remains the
same, but just having the API might not be, Phillip was right to raise
the issue of segregating to a different library).

Do we declare "if you're serving up records this broken, you should
expect client hangs, we're keeping the simple API interface as being
less likely to introduce buggy code"?

Otherwise, it seems like SRV resolution is something that should be
running in a fiber sending responses down a thread-safe pipe, with the
other side trying to connect and signalling when done, and in the
mean-time the fiber tries more and more resolutions, as and when needed.
(In Go, that's a go-routine and a channel for results and a channel for
signalling).

A lot of complexity, when the "give an ordered list of probably results"
is sufficient for every non-broken setup, when these broken sites are
going to have to fix anyway as the world moves slowly towards IPv6, and
when the simpler API is less likely to lead to programming mistakes by
the API user that drive them away from this API in the first place.

Tough call as a trade-off.  Paul?

-Phil