Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša <[e-mail]>]

Thanks everybody for comments! It's a lot so I'll try to rephrase and
answer the questions below.

1. No signalling to client when AAAA is unavailable

I didn't want to include it in the beginning but I see it has a merit.
DNSSEC has means to provide authenticated non-existence for free, so I
think it's worth for auth server to add either data or non-existence proof
for any applicable RR.
e.g. if it has AAAA, but not A, it would provide AAAA RRs and NSECX for A;
if it has A but not AAAA, it would provide A RRs and NSECX for AAAA

For legacy case of no DNSSEC, an SOA in the authority indicates that no
record matching QNAME+QTYPE exists, but can't effectively signalise
non-existence of the additional address records. Which is not great, but
I'm not in for legalising yet-another EDNS option, and it also would
require client to signalise that it can handle such option before an auth
server raises it in the answer. For this case specifically, I am okay with
client making additional AAAA query to recheck.
To defense: resolvers keep track of auth functionality (ability to do EDNS,
IPv6 availability, ...), this is not any different. If the auth shows that
it either supports this (by at least one positive case) or not (this case),
resolver will remember it and act accordingly next time.

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.

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.

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.

Marek

On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque <[e-mail]> wrote:

> On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <[e-mail]> wrote:
>
>> Marek Vavruša <[e-mail]> wrote:
>> >
>> > there was an interest in reducing latency for address record lookups.
>> > Me and Olafur wrote a draft on adding AAAA records to A answers and
>> > treating them as authoritative. This fixes latency issues with NS
>> > A/AAAA discovery in resolvers and improves caching for clients (AAAA
>> > already cached by the time client comes asking for it).
>>
>> Regarding NS discovery, you should be aware that BIND queries for name
>> server A and AAAA concurrently. So this draft would just make packets
>> bigger without helping latency.
>>
>
> It's worth noting that several "happy eyeballs" style APIs issue
> concurrent
> AAAA/A queries also, like the Apple connect-by-name APIs. Also getdns
> does this. AAAA and A go out back to back, put typically AAAA is put out
> on the wire first.
>
> --
> Shumon Huque
>
>