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.
> 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.
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
pgpAiQL5xBuXR.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
