On Tue, Mar 22, 2016 at 2:03 PM, Shane Kerr <sh...@time-travellers.org>
wrote:
> Marek,
>
> At 2016-03-22 12:12:08 -0700
> Marek Vavruša <mvavr...@cloudflare.com> wrote:
>
> > 2. Behavior of stubs is not explicit in the draft
> >
> > I should have stated this explicitly, the draft doesn't update behaviour
> of
> > stub resolvers. In my opinion, they should use the most basic form of DNS
> > and work only over local or trusted network, hence no latency issues.
>
> 8.8.8.8 isn't local or trusted, and is the largest resolver in the
> world. ;)
>
> One other important issue is that that the resolver main bottleneck is
> in packets/second, so reducing the total number of queries - potentially
> by half, but conservatively by a quarter - seems like too big of a win
> to ignore.
>
> Specifying resolver behavior when answering queries would be more
> difficult. Not impossibly so, but more complex.
Fair enough. As I wrote in the previous email, I meant stub as in
getaddrinfo() not forwarders, so hopefully that answers the question.
Public resolvers in 2016 are bizarre but that's what we got.
>
> > 2. Stubs and recursors during NS resolution issue parallel queries
> >
> > That is correct, the draft expects software changes if accepted. Saying
> > that it doesn't have any effect is not entirely true though. The latency
> is
> > max(rtt_a, rtt_aaaa) in the best case and one of the queries time out or
> is
> > blocked in the worst case. In addition, this doubles query rate on
> > authoritatives and requires more logic on clients (which is error prone -
> > see latest glibc bug), especially when one of the replies gets
> ratelimited,
> > truncated or answered from different node. On the contrary, waiting for
> > single answer is simple.
>
> I don't think this makes things too much more complicated on the
> client, especially with happy eyeballs being best practice these days.
> We kind of expect clients to do all kinds of crazy asynchronous shit,
> both with DNS and other network traffic.
>
It's all dandy until the resolution path diverges :)
> Anyway, this (parallel A and AAAA) is the main reason that people have
> always argued against combined A and AAAA queries, and it seemed to
> make sense. However, since a resolver can remember which authoritative
> servers combine A and AAAA answers, there should be a gain here (I mean,
> resolvers have to remember all kinds of stuff about authoritative
> servers anyway).
>
> > 3. AAAA query doesn't offer A records
> >
> > That is a valid point. Long answer: I think the logic of clients asking
> for
> > IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
> > authoritatives should have had a way to push IPv6 on clients instead of
> > waiting for them to ask for it. The A record is unfortunately defined as
> a
> > 32-bit Internet address. I think it should be redefined as "Internet
> > address". This way, if a client wants to ask a server about IP address,
> it
> > would _always_ use an A query and get a list of A, AAAA and possibly
> > something new. It would be up to client's discretion to pick an address
> > version that it understands. The benefit of this is that it doesn't
> require
> > additional queries or major client-side changes. Somebody has said IPv6
> is
> > here to stay, I'd like to share this certainty. Meta-types (sort of what
> I
> > want an A to become) are considered bad, but DNS was built around name to
> > address translation so optimising for this case might be worth it.
> Offering
> > A records for AAAA drags the need for backward compatibility (even more
> if
> > we ever have a newer address record) and more code exceptions.
>
> Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> killed ANY and then gave us ANYA ("any address"). ;)
>
> Cheers,
>
> --
> Shane
>
Right, it sounds a bit ironic doesn't it? Semantics of ANY isn't really
great a differs per type of server,
more so it is expensive as DNS gravitates towards key-value type storage. I
was hoping to get away
with a simple semantic change for A as it keeps the original meaning (get
an IPv4 address) untouched, while
extending it with harmless "throw in any other IP addresses as well". I
could be wrong though.
Marek
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
