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

From: Marek Vavruša <[email-masked]>
Date: Mon, 21 Mar 2016 16:45:51 -0700

Hi,

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).

Comments, feedback and snarky remarks would be great!
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/

Marek

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Mar 2016 10:58:00 +1100

Well we really want to get rid of A lookups.   Why don't we just
recommend that we publish mapped A records in AAAA RRsets and have
master servers update AAAA RRsets if they are inconsitent with the
A RRsets.

We also need a way to signal that there are no A records in the
AAAA RRset.  ::ffff:255.255.255.255 or ::ffff:0.0.0.0 would be
sensible records to indicate this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2016 20:14:50 -0400 (EDT)

On Mon, 21 Mar 2016, Marek Vavruša 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 authoritati
> ve. 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).
> 

I think this draft is a good idea. It does need some more writing out of
the use case and the possible interaction with some of the answer
sections. And some additional guidance with CNAME's with and without
DNSSEC.

Some comments/questions:

What happens with the Answer Count for QTYPE=A when there are no A
records and only AAAA records? And can the examples also clarify this?

What is the logic behind:

    However, if there is a direct answer to the original question, but no
    records for other address protocols, the authoritative DNS server
    SHOULD NOT prove their non-existence.  In this respect, they are
    treated as additional data.

Are you just afraid of packet size to include the proofs? Because now
a client cannot distinguish between an old auth server not supporting
this draft and a new server supporting this draft (when no additional
A/AAAA exist to add). So if it wants to know about the other QTYPE,
it will need to make another query, even for auth servers implementing
this draft. Which is exactly what this draft is trying to prevent.

What is SNAME? Did you mean QNAME?

I'm also a little confused that section 3 auth servers only talks about A
and section 4 recursive servers only talks about AAAA. I like short
documents but I think you need to write this out a bit more :)

    and it MUST reject any such records if the validation
    fails, and the zone is not provably secure.

That's awkwardly written. If the zone is not provably secure (which is a
term you should not use, and instead use Bogus, Indeterminate. Insecure
or Secure) then there is nothing to validate - if you meant Insecure. If
you meant Indeterminate or Bogus, other text is warranted.

I think you mean to say if the zone _is_ secure, then any records in it
must be proven secure too.

    other IP address records

You mean other QTYPE's for IP addresses :P

I don't think the Security Considerations use case mentioned is worth
mentioning. What is worth mentioning is if this involves CNAMEs,
because that leads to out of bailiwick data. And complications with
DNSSEC (chains to other zones?) and without (free Kaminsky attack)

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2016 17:15:43 -0700

Marek Vavruša wrote:
> ...

+1. we ought to have done this from the get-go.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2016 20:16:48 -0400 (EDT)

> sensible records to indicate this.

That's a terrible hack and error prone to implement.

Paul

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 21 Mar 2016 17:21:24 -0700

Who wants to get rid of A lookups? "A" is going to be here for a while and
using it as a generic mean to get all addresses of given protocol
(regardless of version) gives servers a way to smoothly transition over
versions.
If the A was updated to have a variable address length, then it could be
used to hand out any address with different RDLEN instead of making new
type. I'm dreading of a day when somebody implements A,AAAA, and AAAAAAAA
lookup in glibc stub in parallel.

> sensible records to indicate this.

Do we need that? I'd be happy if clients use just A for IP lookups, and
then use
AAAA if only AAAA falls out of cache. Can't think of a good use case.

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 21 Mar 2016 17:33:55 -0700

On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters <[email-masked]> 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 authoritati
>> ve. 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).
>>

Agreed, thanks for taking time commenting.

> records and only AAAA records? And can the examples also clarify this?
That's an example 5.3

> this draft. Which is exactly what this draft is trying to prevent.

The proposal is opt-in, if the authoritative decides to throw in AAAA
addresses
then client should accept them. If it doesn't then it should requery. This
is of course
going to reduce the effectiveness in the transition period for names that
have A, but don't have AAAA
which is something I expect to change.

The rationale is not to carry unnecessary payload when most authoritatives
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and
amend the draft later.

> What is SNAME? Did you mean QNAME?

SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

> must be proven secure too.

Fair enough!

   other IP address records
> DNSSEC (chains to other zones?) and without (free Kaminsky attack)

The CNAMEs should be covered by the SNAME part, owner has to either match
QNAME or terminal of CNAME chain just as a direct answer would. Maybe it
needs a clarification.

Thanks!

Marek

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2016 21:14:00 -0400 (EDT)

>       records and only AAAA records? And can the examples also clarify this?

The use case is, but I still have no idea what the ANCOUNT should
be. Neither the text nor the example list the ANCOUNT. I can only assume
based on the fact that the AAAA is placed in the answer section, that
you would have ANCOUNT=1. I think that is wrong. I think ANCOUNT should
be 0, and the AAAA record should be in the additional section.

> The proposal is opt-in, if the authoritative decides to throw in AAAA addresses
> then client should accept them. If it doesn't then it should requery. This is of course
> going to reduce the effectiveness in the transition period for names that have A, but don't have AAAA

And I would assume QTYPE=AAAA with additional A records would become the
more common query. At least I hope we are still trying to transition to
IPv6 :)

> The rationale is not to carry unnecessary payload when most authoritatives support it, but you make a good point
> that it might be better to mandate denial of non-existence proof now, and amend the draft later.

If you want to do it your way, you need to add some signalling so the
client knows what happened and it can decide whether or not to query
again. I think it is important for the client to know whether the
answer that came back came from a server supporting this document,
as opposed to a server not supporting this document.

> SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

Oh thanks. a quick google didnt give me much :)

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Mar 2016 11:41:37 +0000

> 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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Cromarty, Forth, Tyne, West Dogger: Variable, mainly northwesterly, 3 or 4.
Slight. Mainly fair. Good.

---

From: Bob Harold <[email-masked]>
Date: Tue, 22 Mar 2016 11:12:36 -0400

> > already cached by the time client comes asking for it).

I think the reverse should also be done: add "A" answers to AAAA queries.

Some possible reasons, although these might not be the best reasons:
I thought that most dual-stack computers prefer IPv6 to connect, and thus I
assumed that they would do an AAAA query first, in which case it would be
good to return an "A" record if the AAAA query finds no answer, assuming
that the client is likely to fall back to "A".
There are probably also many clients where the stack thinks it might have
IPv6 connectivity, but it really does not, so it will have to fall back to
"A", even if an AAAA answer exists.

I am almost certain someone will explain why I am wrong, but I at least
wanted this discussed.

-- 
Bob Harold

---

From: Shumon Huque <[email-masked]>
Date: Tue, 22 Mar 2016 11:55:19 -0400

> 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

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 22 Mar 2016 12:12:08 -0700

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Mar 2016 07:20:40 +1100

> resolver will remember it and act accordingly next time.

So shove it in the answer and hope the client can do something
useful with it verses add it when the client tells us it can handle
it.  We went this path with DNSSEC records and got DO.  Listen to
history.

Having to remember capabilities is much worse than just having the
capability signaled on a per query basis.  You don't have to upgrade
all the servers behind a load balancer at once,  Note this include
CPEs which proxy queries to multiple servers.  Sometimes you have
no choice like with DNS COOKIE, but here there is zero need other
than unwillingness to include signaling.

> and work only over local or trusted network, hence no latency issues.

It updates clients so it updates stubs.  Stubs should be doing
DNSSEC for validation, so yes that means EDNS.  There is lots of
FUD about CPE routers.

> truncated or answered from different node. On the contrary, waiting for

Yet, you say it is not for stub resolvers which is the piece of
code that could really benefit from it.  Nameservers are dealing
with lots of parallel lookups all the time.

> we ever have a newer address record) and more code exceptions.

Well we don't have a time machine.  We also have the potential to add
signaling so adding A to AAAA responses doesn't need to drag backwards
compatibility.
 
> >> Marek Vavru=C5=A1a <[email-masked]> wrote:
> >> >
> --94eb2c035cd8596a8c052ea7fd8f
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Thanks everybody for comments! It&#39;s a lot so I&#39;ll =
> try to rephrase and answer the questions below.<div><br></div><div>1. No si=
> gnalling to client when AAAA is unavailable</div><div><br></div><div>I didn=
> &#39;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&#=
> 39;s worth for auth server to add either data or non-existence proof for an=
> y applicable RR.</div><div>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</div><div><br></div><div>For legacy case of no DNSSEC, =
> an SOA in the authority indicates that no record matching QNAME+QTYPE exist=
> s, but can&#39;t effectively signalise non-existence of the additional addr=
> ess records. Which is not great, but I&#39;m not in for legalising yet-anot=
> her 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 re=
> check.</div><div>To defense: resolvers keep track of auth functionality (ab=
> ility to do EDNS, IPv6 availability, ...), this is not any different. If th=
> e auth shows that it either supports this (by at least one positive case) o=
> r not (this case), resolver will remember it and act accordingly next time.=
> </div><div><br></div><div>2. Behavior of stubs is not explicit in the draft=
> </div><div><br></div><div>I should have stated this explicitly, the draft d=
> oesn&#39;t update behaviour of stub resolvers. In my opinion, they should u=
> se the most basic form of DNS and work only over local or trusted network, =
> hence no latency issues.</div><div><br></div><div>2. Stubs and recursors du=
> ring NS resolution issue parallel queries</div><div><br></div><div>That is =
> correct, the draft expects software changes if accepted. Saying that it doe=
> sn&#39;t have any effect is not entirely true though. The latency is max(rt=
> t_a, rtt_aaaa) in the best case and one of the queries time out or is block=
> ed in the worst case. In addition, this doubles query rate on authoritative=
> s and requires more logic on clients (which is error prone - see latest gli=
> bc bug), especially when one of the replies gets ratelimited, truncated or =
> answered from different node. On the contrary, waiting for single answer is=
>  simple.</div><div><br></div><div>3. AAAA query doesn&#39;t offer A records=
> </div><div><br></div><div>That is a valid point. Long answer: I think the l=
> ogic of clients asking for IPv6 is flawed from the get-go. For a smooth pro=
> tocol 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 unfortu=
> nately defined as a 32-bit Internet address. I think it should be redefined=
>  as &quot;Internet address&quot;. This way, if a client wants to ask a serv=
> er 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&#39;s discretion =
> to pick an address version that it understands. The benefit of this is that=
>  it doesn&#39;t require additional queries or major client-side changes. So=
> mebody has said IPv6 is here to stay, I&#39;d like to share this certainty.=
>  Meta-types (sort of what I want an A to become) are considered bad, but DN=
> S 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 c=
> ode exceptions.</div><div><br></div><div>Marek</div></div><div class=3D"gma=
> il_extra"><br><div class=3D"gmail_quote">On Tue, Mar 22, 2016 at 8:55 AM, S=
> humon Huque <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targe=
> t=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D=
> "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
> -left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
> quote"><span class=3D"">On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <span d=
> ir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">dot@dotat.=
> at</a>&gt;</span> wrote:<br></span><span class=3D""><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
> ft:1ex"><span>Marek Vavru=C5=A1a &lt;<a href=3D"mailto:mvavrusa@cloudflare.=
> com" target=3D"_blank">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; there was an interest in reducing latency for address record lookups.<=
> br>
> &gt; Me and Olafur wrote a draft on adding AAAA records to A answers and<br=
> >
> </span>&gt; treating them as authoritative. This fixes latency issues with =
> NS<br>
> <span>&gt; A/AAAA discovery in resolvers and improves caching for clients (=
> AAAA<br>
> &gt; already cached by the time client comes asking for it).<br>
> <br>
> </span>Regarding NS discovery, you should be aware that BIND queries for na=
> me<br>
> server A and AAAA concurrently. So this draft would just make packets<br>
> bigger without helping latency.<br></blockquote><div><br></div></span><div>=
> It&#39;s worth noting that several &quot;happy eyeballs&quot; style APIs is=
> sue concurrent=C2=A0</div><div>AAAA/A queries also, like the Apple connect-=
> by-name APIs. Also getdns</div><div>does this. AAAA and A go out back to ba=
> ck, put typically AAAA is put out=C2=A0</div><div>on the wire first.</div><=
> span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>--=C2=A0<=
> /div><div>Shumon Huque</div><div><br></div></font></span></div></div></div>
> </blockquote></div><br></div>
> 
> --94eb2c035cd8596a8c052ea7fd8f--
> 
> 
> --===============3282002912730061508==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============3282002912730061508==--
>

---

From: Shane Kerr <[email-masked]>
Date: Tue, 22 Mar 2016 22:03:45 +0100

Marek,

At 2016-03-22 12:12:08 -0700

> 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.

> truncated or answered from different node. On the contrary, waiting for

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).

> 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

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 22 Mar 2016 14:47:25 -0700

On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <CAC=
> [email-masked]>,
> =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
> >

I don't really like DO being in EDNS instead of header. I'm okay with other
address types being in additional as well.

> than unwillingness to include signaling.

It is unwillingness to include signaling because I still don't see any
practical benefit of it. This draft does not significantly change the look
of the response (not more than aliases or additional records) to warrant a
client signaling.

> DNSSEC for validation, so yes that means EDNS.  There is lots of

Almost no-one enables EDNS for stub. I mean stub as in getaddrinfo(), not
forwarders like dnsmasq (these are updated).

> signaling so adding A to AAAA responses doesn't need to drag backwards

Right, we don't have a time machine, but we can amend I-Ds.

> > bigger without helping
> latency.<br></blockquote><div><br></div></span><div>=
> > span class=3D"HOEnZb"><font
> color=3D"#888888"><div><br></div><div>--=C2=A0<=
> > /div><div>Shumon
> Huque</div><div><br></div></font></span></div></div></div>

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 22 Mar 2016 15:00:48 -0700

> 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.

> both with DNS and other network traffic.

It's all dandy until the resolution path diverges :)

> killed ANY and then gave us ANYA ("any address"). ;)

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Mar 2016 09:11:32 +1100

> killed ANY and then gave us ANYA ("any address"). ;)

You would then need to do ANYA, A and AAAA queries or you have to
have signaling to indicate if the server supports ANYA with fallback
to A and AAAA on no support.  Now for named you go from NOTIMP ->
NOERROR/NXDOMAIN introducing a meta type but for other servers you
start at NOERROR/NXDOMAIN so explicit signaling of support for a
meta type is needed.

Mark

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Mar 2016 10:32:14 +0000

> I didn't want to include it in the beginning but I see it has a merit.

Yep. Also, while improving this for direct address queries, it should also
be improved for additional data in MX, NS, SRV (etc.) queries.

> server raises it in the answer.

Another option might be to define a couple of meta-TYPEs, NOA and NOAAAA
(same RDATA format as NULL), so the server could say, "I wanted to put
AAAA records here, but there aren't any, and there isn't a DNSSEC pone
either".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties: Variable 3 or 4, becoming southwest 4 or 5 later. Slight or moderate.
Occasional drizzle. Good, occasionally poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Mar 2016 09:07:55 -0400

Hi,

On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> treating them as authoritative.

The last time this was proposed, in DNSEXT when Olafur was co-chair,
the proposal was rejected on the following grounds:

    1.  We had no idea what resolvers who weren't expecting the AAAA
    in the Answer section would do.  This draft says what is "more
    likely", but I have no way of evaluating that claim.  Without an
    EDNS0 signal, I think this proposal is pretty dangerous.

    2.  It isn't clear what a cache is supposed to do when it gets an
    A and has a AAAA already in cache, particularly if there isn't an
    A record.  This draft is far too sketchy on that case.  Can the
    AAAA satisfy queries for AAAA?  (I think section 4 says yes, but
    it's a little terse.)

    3.  This amounts to special server-side processing, and there'd
    been a traditional resistance to

    4.  The proposal had been made several times before, and always
    rejected; what's different this time?  (This argument always
    seemed the weakest to me.)

Making it optional behaviour the way this proposal does seems to
introduce quite a lot of confusion.  Is a happy-eyeballs resolver
supposed to take the non-existence of the AAAA in the answer as some
sort of evidence that the AAAA is never coming?  (I think this
proposal says, "No," but I'm sceptical that's what will happen.)  Why
doesn't happy eyeballs do what is necessary here?

I think I'd feel a lot more comfortable with anything along these
lines if there were a signal from the resolver stating that it knows
what to do, but that still brings up server-side processing.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Mar 2016 13:36:09 +0000

>     EDNS0 signal, I think this proposal is pretty dangerous.

This makes me wonder, if you put the extra records in the additional
section instead, what implications does that have wrt RFC 2181
trustworthiness ranking.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay: Northerly or northwesterly 4 or 5, becoming variable 4, then becoming
southwesterly 5 later in north. Moderate or rough, occasionally slight at
first in east. Fair. Good.

---

From: Marek Vavruša <[email-masked]>
Date: Wed, 23 Mar 2016 09:37:57 -0700

Hi Andrew, first of all - thanks for being constructive.

>     EDNS0 signal, I think this proposal is pretty dangerous.

We have a way of measuring DNSSEC algorithms penetration, QNAME
minimisation-enabled resolvers etc., thus also a way to evaluate this
claim. I'm setting up a special domain using this I-D and then we can use
RIPE Atlas or 1x1 test, should Google or someone be interested in testing
this.

>     AAAA satisfy queries for AAAA?  (I think section 4 says yes, but

The draft suggests following 2181 and all these records should be treated
as authoritative.
I'm comfortable with shoving the AAAA into authority/additional which would
lower their rank and
AAAA query would replace them.

>     been a traditional resistance to

I'm happy to back this with patches.

>     seemed the weakest to me.)

With all respect, I'm not in a position to be an IETF librarian.
I'm happy to discuss this draft and whether it has any merit or not.
If it's coming back then it means the idea is probably interesting,
as for me the proposition of cutting query rate for most sought-after
QTYPEs in half is too good to be ignored.

> doesn't happy eyeballs do what is necessary here?

For TTL, yes, if the authoritative provides non-existence proof.
"Happy eyeballs" means a resolver will maybe get both answers in ~ same RTT,
this I-D means it will have to send only half of the queries to get this
information.
Talking to upstream is the most expensive operation for resolver next to
signature
verification.

> what to do, but that still brings up server-side processing.

I admit I'm not a big fan of EDNS, but I'm okay with using it if I'm proven
that resolvers will panic
on a sight of different record in any of the packet sections. Shoving the
records into NS/AR and thus
degrading their 2181 trustworthiness rank would be a better compromise to
explore first.

Best,

M

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Mar 2016 17:50:29 +0100

>RIPE Atlas or 1x1 test, should Google or someone be interested in testing

The 1x1 test would be APNIC.

It should be easy to measure with RIPE Atlas. The advantage of Atlas is that
you will get the DNS reply packet, so it is possible to investigate if the
a middle box mangles the reply in one way or another. I wonder if
any existing code would already cache the AAAA.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 23 Mar 2016 14:17:58 -0400

> start at NOERROR/NXDOMAIN so explicit signaling of support for a
There are two ways to approach the address distribution problem,
a) from the client side
b) from the server side
our proposal is strictly in camp b) i.e. just servers put this out.

The OPEN question is what will resolvers do
#1 Accept but RRsets
#2 Discard non QTYPE covered set
#3 discard the answer

If it is #3 then this is a horrible idea,
if is #2 then there is no loss and resolvers will improve over time.
if it is #1 then it is a win without any resolver changes.

Tony,
Same questions apply if AAAA set is put in the additional section.

Andrew,
We need data to determine if this is feasible.

Olafur

---

From: Joao Damas <[email-masked]>
Date: Wed, 23 Mar 2016 19:24:24 +0100

In one of the experiments we are conducting we stuff the response with other QTYPE data and this seems to not interfere with resolver behaviour (unless we trigger it). So #3 doesn’t seem to be a common case (we could look in the fringes for this behaviour).

Towards the resolver’s clients, all extraneous data gets cleaned out of the response, which is quite sane behaviour in the current DNS. Have not tested what the resolver does with the data (keep it in cache, something in between #1 and #2, or discard it altogether, as in #2).

Joao

> On 23 Mar 2016, at 19:17, Ólafur Guðmundsson <[email-masked]> wrote:
> 
> 
> On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> 
> In message <[email-masked] <mailto:[email-masked]>>, Shane Kerr writes:

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Mar 2016 20:09:13 +0100

> +1. we ought to have done this from the get-go.

It did not work back then because unexpected RRsets in the answer broke
resolvers.  This is how we got the DO flag, I think.

I doubt AAAA was any different from SIG in that regard, unknown is
unknown after all.

Therefore, technically, sending AAAA along should only be done for
replies to DO=1 queries because there is a reasonable expectation that
the recipient will be able to deal with unexecpted RRsets.

Florian

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Mar 2016 20:14:33 +0100

> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/

The glibc stub resolver already implements this draft in its response
processing by accident.  I was planning to fix that.

I don't see how this proposal reduces latency or server load.  We still
have to do dual A/AAAA queries.  In the majority of cases, there is no
AAAA record, so we have to wait for the second reply to arrive.

We could reduce server load by sending the AAAA query only after the A
response, but we'd have to send it in most cases because we cannot take
absence of an AAAA RRset as proof of its non-existence.

On the server side, doing AAAA lookups for all incoming A queries, on
top of A lookups, isn't free (although it should be fairly cheap because
the server at least knows where to send the AAAA query).

Florian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Mar 2016 16:03:12 -0400

Hi,

> RIPE Atlas or 1x1 test, should Google or someone be interested in testing

I don't understand how it's a way to evaluate this claim.  DNSSEC
includes a bit (DO) that says you're prepared to handle the additional
data in the answer section.  Indeed, the unpreparedness of people for
this data was just exactly the reason for the DO bit.  What isn't
clear to me is whether people implemented that as, "Take whatever
comes in the answer even if you didn't ask for it," or whether they're
looking for DNSSEC data.  The latter is what DO says one is prepared
to do.

> I'm happy to back this with patches.

That _you_ can produce the code is not the question.  The question is
whether people are comfortable adding additional server side
processing to the protocol.  It's always been a big deal before (which
is part of the reason RRTYPEs that require this aren't eligible for
allocation by expert review).  I confess I'm susprised that this
aspect of your proposal isn't getting more push back, but maybe that's
because it's supposed to be optional.

> With all respect, I'm not in a position to be an IETF librarian.

No, but I observe you're not the only author on this document, and
since I was Olafur's co-chair when we dealt with this kind of proposal
last time I sort of assumed his memory would be as good as mine.

> If it's coming back then it means the idea is probably interesting,

There was never any question that the idea has some value.  The
question was always whether it would work reliably on the Internet we
have.  Maybe what we're saying is either (1) the Internet has in fact
changed or (2) that we're going to have to abandon some of the old
functionality.  If so, ok, but we ought to say so explicitly.  (Also,
without some significant changes to the charter and maybe to the area
in which this WG lives, I'm not sure this WG is in fact the right
place for fundamental changes to assumptions about the protocol
functioning.  Minor maintenance, sure.  Note that I don't want to play
charter games -- I think they're useless and boring -- but this kind
of major change to the protocol doesn't obviously fit to me under the
provisions in 5 of the DNSOP charter, though this is the right place
to start the discussion.  The same, note, is true of the
deprecate-classes discussion.)

> Talking to upstream is the most expensive operation for resolver
> next to signature verification.

So, yes.  It strikes me, however, that if that's the real use case you
could definitely use EDNS0, on the assumption that the end client
could use happy eyeballs.  The resolver would of course get two
queries, but it would only need to send one and could re-use the
single answer it gets over and over, meaning that cache re-use ought
to be pretty good.  

> on a sight of different record in any of the packet sections.

This is putting the burden of proof in the wrong place.  You're
proposing to change the protocol behaviour in a pretty fundamental
way.  You need to be able to show that the new behaviour doesn't break
old-but-conforming implementations.  That's how standards work.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Mar 2016 22:10:36 +0100

> looking for DNSSEC data.  The latter is what DO says one is prepared

DO was used initially for SIG and kept for RRSIG.  For an early DNSSEC
implementation, RRSIG was just another unsolicited RR type because it
could only know about SIG.  This suggests (to me at least) that
practically speaking, DO isn't strongly tied to DNSSEC.

Florian

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Wed, 23 Mar 2016 21:30:17 +0000

The more generalized form, of course, is for the client to provide a bitmap and/or an enumerated list, of the RRTYPEs it wishes to receive and/or not receive.

One of the sticky problems to deal with, however, is how the server should respond if it implements some, but not all of the RRTYPEs requested (spike the whole transaction with a NOTIMP? return the ones it knows about and a pseudo-RR representing the ones it doesn't?)

													- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Tony Finch
Sent: Wednesday, March 23, 2016 6:32 AM
To: Marek Vavruša
Cc: [email-masked] WG
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

> I didn't want to include it in the beginning but I see it has a merit.

Yep. Also, while improving this for direct address queries, it should also be improved for additional data in MX, NS, SRV (etc.) queries.

> 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.

Another option might be to define a couple of meta-TYPEs, NOA and NOAAAA (same RDATA format as NULL), so the server could say, "I wanted to put AAAA records here, but there aren't any, and there isn't a DNSSEC pone either".

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Mar 2016 17:47:33 -0400 (EDT)

> One of the sticky problems to deal with, however, is how the server should respond if it implements some, but not all of the RRTYPEs requested (spike the whole transaction with a NOTIMP? return the…

That has been suggested in the past as well, but it seems it was not
liked eiter. We even already have the bitmap as it is used for NSEC3.

Since at the time I wanted it for "additional crypto" records, and
that seemed to have moved to SRV style prefix records, I didn't
try harder.

Paul

---

From: George Michaelson <[email-masked]>
Date: Thu, 24 Mar 2016 08:33:28 +1000

> practically speaking, DO isn't strongly tied to DNSSEC.

Very strong +1. The % of incoming query with DO set is far, far higher
than the % of incoming query seen at authority who subsequently ask
for DS/DNSKEY at zone and parent. There is a good, strong indication
that resolvers pass DO as a compile/run flag of capability to handle
additional records in response, not as an indication of intent to
perform any function using them.

(this is with fresh unseen domains, where there is no opportunistic
cache of the DNSKEY or DS, so the absence of a fetch of them is a very
good indicator there was no intent to try and use the RRSIG sent back
as a result of DO being sent in query)

-G

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 19:01:20 -0400

> perform any function using them.

I might feel more comfortable if the proposal required DO, but AFAICT
it doesn't (I might have misread, of course.  I found the I-D a little
terse).  If it does require DO, however, we're back to requiring
EDNS0.  In that case, we could just use an EDNS0-based signal.

As I think many here know, I am not of the get-off-my-lawn persuasion
for DNS innovations.  I don't think it's a bad idea in principle.  I'm
just aware that we have this long history, and that history was based
on a certain kind of conservatism that is arguably appropriate to a
technology quite as fundamental to the Internet functioning as the DNS
is.  If we're going to abandon that conservatism, I think it needs
quite a lot more early IETF buy-in than we might get by developing
this work here in DNSOP.  The more signal we can get to suggest that
DNS actors are ok with the innovation, the lower I think that bar gets.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2016 02:51:21 -0000

>DNS actors are ok with the innovation, the lower I think that bar gets.

I'd be a lot more comfortable if we had some field test data about
what real DNS caches do with the extra AAAA records.  In theory
nothing bad should happen, in practice ...

R's,
John

---

From: Marek Vavruša <[email-masked]>
Date: Fri, 25 Mar 2016 19:56:21 -0700

> nothing bad should happen, in practice ...

I agree, working on it.

Marek

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sat, 26 Mar 2016 15:59:39 -0400

> nothing bad should happen, in practice ...
The next step is experimentation, we wanted to see if the community thought
this was a stupid idea before going forward.
There are 3 possible outcomes when a DNS querier gets an aswer like this
#1 It accepts everything from authority section
#2 It tosses the non queried RRset
#3 it Rejects the answer and tries again

If the result is #1 nothing needs to be done
For #2 that means convincing the software vendors to adopt more relaxed
approach
On the other hand if #3 is the case for a significant part of the
infrastructure we can not do this w/o signaling

Olafur

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2016 20:42:58 -0000

>this was a stupid idea before going forward.

I certainly don't think it's stupid.

>#3 it Rejects the answer and tries again

#4 it ignores the answer and doesn't try again
#5 it misinterprets the AAAA records as A records (they're not CNAME, what else could they be?)
#6 it dereferences an uninitialized pointer and gets random junk sometimes, crashes other times

I don't think any of those are particularly likely, but I've never
sent answers with extra records other than CNAME, DNAME, and (when DO
is set) DNSSEC stuff.  So I think we agree that reports of what
current code really does would be helpful.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 26 Mar 2016 16:43:32 -0400

> #3 it Rejects the answer and tries again

#4 it panics and you don't know that.

There's no way to know whether #4 cases are out there, and nothing in
any data you collect would tell the difference between 1 and 4.  I
think the chances are pretty low because of the experience with DNSSEC
deployment, but at least there we were relying on the DO bit.  What
you're proposing is to change the protocol for people who don't even
set DO.  Surely that's risky?

> For #2 that means convincing the software vendors to adopt more relaxed

No, it means making a protocol change to a well-established,
long-deployed standard and _then_ getting people to adopt it, and
doing so without any signals about the deployment.

Please don't think I'm saying no: my employer feels this pain just as
much as yours does, and I also am anxious to support ideas that move
the state of the art ahead.  But I cannot believe we are seriously
talking about deploying stuff that changes a 30 year old
connectionless protocol without any signal in the protocol that the
change is ok for the involved players in each exchange.  If that's
really the sort of thing we're going to do, then we might as well just
start uploading protocol definitions to github and tell people to try
to track them.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]