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

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Mar 2016 11:26:47 +1100

Or we could defined the "aaa" (A and AAAA) {E}DNS bit where the
server guarantees that the response contains both the A and AAAA
answers for A or AAAA queries if aaa=1 in the response.

Recursive servers would lookup A/AAAA records if cache is missing
them before returning a response.

If the A / AAAA does not fit into the additional section then TC=1
is set.

NOERROR NODATA is valid for both types if aaa=1 in the response.

This way you could signal that you want both A and AAAA records and
if you don't want both then the response does not have the other
type added.

Yes, we would have to nuke the stupid servers that reflect back
{E}DNS flags.  We would also have nuke the stupid firewalls that
block {E}DNS queries with a unknown flag bit set.

Mark

Mark Andrews writes:
> 
> 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]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

I see the point but I don't really want to go down the EDNS route.
So presuming that this draft catches on and Alexa 1M NSs publish at least
one AAAA record,
there would be no need for two queries in most cases and no need for
additional signalisation.
If they don't publish AAAA records, then the resolver will still have to do
the same thing as today,
however that also means that IPv6 adoption is stalled and possibly
irrelevant.

TL;DR the draft optimises first case, if the second case proves to be valid
then we can always amend the draft but I don't want to overengineer it from
the start and it's always much easier to add than to remove.

Marek

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Mar 2016 12:05:33 +1100

> I see the point but I don't really want to go down the EDNS route.

Why not?  It is cleaner as it deals with A-only, A and AAAA, and
AAAA-only sites without a second lookup once support is deployed.
It is supportable on a hop by hop basis.

Just adding records w/o signalling is a waste of effort and bandwidth
if the server does not support the extra records.

https://ednscomp.isc.org/compliance/summary.html show current unknown
EDNS flags behaviour.  It also shows that you can change behaviour
with a little education.

Signaling also allows you to put both answers in the answer section.

> one AAAA record,  there would be no need for two queries in most cases
> and no need for additional signalisation. If they don't publish AAAA
> records, then the resolver will still have to do the same thing as today,

IPv6 is here to stay.  IPv4 is very much in its death throws at the moment.
 
> TL;DR the draft optimises first case, if the second case proves to be
> valid then we can always amend the draft but I don't want to overengineer
> it from the start and it's always much easier to add than to remove.

You can also under engineer.  There is no way to measure client
support as it currently is.  A flag provides you with the ability
to measure client support.

> --001a11432b86aea53d052e98798d
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">I see the point but I don&#39;t really want to go down the=
>  EDNS route.<div>So presuming that this draft catches on and Alexa 1M NSs p=
> ublish at least one AAAA record,</div><div>there would be no need for two q=
> ueries in most cases and no need for additional signalisation.</div><div>If=
>  they don&#39;t publish AAAA records, then the resolver will still have to =
> do the same thing as today,</div><div>however that also means that IPv6 ado=
> ption is stalled and possibly irrelevant.</div><div><br></div><div>TL;DR th=
> e draft optimises first case, if the second case proves to be valid then we=
>  can always amend the draft but I don&#39;t want to overengineer it from th=
> e start and it&#39;s always much easier to add than to remove.</div><div><b=
> r></div><div>Marek</div><div><br></div></div><div class=3D"gmail_extra"><br=
> ><div class=3D"gmail_quote">On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews <=
> span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">mar=
> [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"><br>
> Or we could defined the &quot;aaa&quot; (A and AAAA) {E}DNS bit where the<b=
> r>
> server guarantees that the response contains both the A and AAAA<br>
> answers for A or AAAA queries if aaa=3D1 in the response.<br>
> <br>
> Recursive servers would lookup A/AAAA records if cache is missing<br>
> them before returning a response.<br>
> <br>
> If the A / AAAA does not fit into the additional section then TC=3D1<br>
> is set.<br>
> <br>
> NOERROR NODATA is valid for both types if aaa=3D1 in the response.<br>
> <br>
> This way you could signal that you want both A and AAAA records and<br>
> if you don&#39;t want both then the response does not have the other<br>
> type added.<br>
> <br>
> Yes, we would have to nuke the stupid servers that reflect back<br>
> {E}DNS flags.=C2=A0 We would also have nuke the stupid firewalls that<br>
> block {E}DNS queries with a unknown flag bit set.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><span class=3D"im HOEnZb"><br>
> Mark Andrews writes:<br>
> &gt;<br>
> &gt; Well we really want to get rid of A lookups.=C2=A0 =C2=A0Why don&#39;t=
>  we just<br>
> &gt; recommend that we publish mapped A records in AAAA RRsets and have<br>
> &gt; master servers update AAAA RRsets if they are inconsitent with the<br>
> &gt; A RRsets.<br>
> &gt;<br>
> &gt; We also need a way to signal that there are no A records in the<br>
> &gt; AAAA RRset.=C2=A0 ::ffff:255.255.255.255 or ::ffff:0.0.0.0 would be<br=
> >
> &gt; sensible records to indicate this.<br>
> &gt;<br>
> </span><div class=3D"HOEnZb"><div class=3D"h5">&gt; Mark<br>
> &gt;<br>
> &gt; --<br>
> &gt; Mark Andrews, ISC<br>
> &gt; 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> &gt; PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">=
> +61 2 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> =C2=A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </div></div></blockquote></div><br></div>
> 
> --001a11432b86aea53d052e98798d--

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2016 18:55:00 -0700

Mark Andrews wrote:
> In message<CAC=TB12xXJNbmexMA4w5oLU+xhQbh=tKH=[email-masked]>, =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:

i think we have to start planning for a world in which EDNS0 never 
reaches 75% penetration due to middleboxes having the high ground.

i think putting aaaa in the additional section and specifying that the 
AA bit covers all rr's matching qname or effective-qname, is likely to 
penetrate better than rrtype!=qtype in the answer section, though.

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Tue, 22 Mar 2016 12:04:05 +1000

I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.

-George

On Tue, Mar 22, 2016 at 11:55 AM, Paul Vixie <[email-masked]> wrote:
>
>
> Mark Andrews wrote:
>>
>> In
>> message<CAC=TB12xXJNbmexMA4w5oLU+xhQbh=tKH=[email-masked]>,
>> =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
>>>
> i think we have to start planning for a world in which EDNS0 never reaches
> 75% penetration due to middleboxes having the high ground.
>
> i think putting aaaa in the additional section and specifying that the AA
> bit covers all rr's matching qname or effective-qname, is likely to
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2016 19:07:00 -0700

> users, and it sees significantly more than 75% EDNS0. More like 93%.

by query volume, or by rdns ip?

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Tue, 22 Mar 2016 12:10:22 +1000

> by query volume, or by rdns ip?

By query volume. And, we're at authority where I suspect you see the edge.

Once the query is covered by a modern competent resolver, and gets
passed, it acquires. EDNS0

-George

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2016 19:20:08 -0700

> passed, it acquires. EDNS0

most middleboxes who think they know what a dns packet has to look like 
and willfully intercept or rewrite or drop them, are between the stub 
and the (desired) rdns. i am not sanguine about getting edns0-carried 
data to a stub often enough during my lifetime to say, let's solve the 
a-vs-aaaa problem using another protocol extension.

if the internet is a territory, then the dns, like bgp, is the map of 
that territory. since many commercial and government actors want to 
control access to the internet, they mostly do it by controlling access 
to the dns. and their incentives are misaligned such that they do not 
care what they break or what upgrade paths they deny.

note that solving a+aaaa with an edns0 extension may be good enough, if 
we think that getting the aaaa rrsets cached more often will mean that 
the stub's aaaa query will less often lead to a cache miss, as long as 
the largest share of RTT for a stub query that leads to a cache miss is 
still on the rdns-to-auth path and not the stub-to-rdns path.

-- 
P Vixie

---

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

> 75% penetration due to middleboxes having the high ground.

Well, you could get most of the way there for this proposal by having
just recursives do it.  End users are mostly going to do happy
eyeballs anyway, so if a recursive gets the AAAA with the A its own
load goes down because it can answer more stuff from cache.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Thu, 24 Mar 2016 14:49:20 +0100

Andrew,

At 2016-03-23 09:11:44 -0400

> load goes down because it can answer more stuff from cache.

I'd like to argue that supporting A+AAAA on the stub side is
potentially huge.

Given that 90%+ of a recursive resolver's time is spent reading stuff
out of cache, being able to get the data to clients with fewer queries
seems huge to me. This is a big, fat win for resolver operators.

It also seems not hugely complicated.

On the stub resolver side, it should be relatively simple to discover if
this functionality is supported, and use it if it is. We could add a
special query for this that a host can use for this, or any of 100
other methods.
 
On the recursive resolver side, it should not impact performance, as no
additional searches should be required to get both the A and AAAA data
for a recursive resolver. While there is additional logic to handle this
approach (because of issues of collecting A and AAAA together into a
single reply), it's not hugely complicated (at least not compared to all
of the other the crap that resolvers have to do while talking to the
authoritative world).

Cheers,

--
Shane