Subject: DNS AAAA for free

From: [email-masked]
Date: Fri, 8 Apr 2016 08:27:46 -0300

Here is an interesting draft being presented in dnsop today.
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1

The proposal is to allow AAAA records in response to A queries.

Best regards,
Ole

---

From: Geordie Guy <[email-masked]>
Date: Sat, 9 Apr 2016 17:55:30 +1000

This is genuinely awesome. 

Geordie

Sent from my mobile. Please excuse any unusual brevity or typos while I'm on the go. 

> On 8 Apr 2016, at 9:27 PM, [email-masked] wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Sander Steffann <[email-masked]>
Date: Sat, 9 Apr 2016 12:55:05 +0200

Hi,

> On 08 Apr 2016, at 13:27, [email-masked] wrote:
> 

One question: if clients send requests for both A and AAAA records simultaneously, how will including the AAAA answer in the A request help? The client will just get the AAAA answer twice: once on the A request and once on the AAAA request. If lookups were serialised and the A request/response was completed before starting the AAAA request it would make the second request unnecessary, but that's not what I see in practice...

It looks like good intentions, I'm just trying to figure out how this would work in practice :)

Cheers!
Sander

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Apr 2016 23:11:11 +1000

> One question: if clients send requests for both A and AAAA records
simultaneously, how will including the AAAA answer in the A request help?
The client will just get the AAAA answer twice: once on the A request and
once on the AAAA request. If lookups were serialised and the A
request/response was completed before starting the AAAA request it would
make the second request unnecessary, but that's not what I see in
practice...
> It looks like good intentions, I'm just trying to figure out how this
would work in practice :)

Having briefly looked at it, it seems there is an efficiency benefit.
However, answering an A query with both an A and AAAA response might
incentivise just sending A queries.

Perhaps the opposite would be better - sending an AAAA query would result
in an AAAA and A answer. That might create a small and subtle incentive to
use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures.

Regards,
Mark.

---

From: James R Cutler <[email-masked]>
Date: Sat, 9 Apr 2016 10:32:38 -0400

On 08 Apr 2016, at 13:27, [email-masked] <mailto:[email-masked]> wrote:
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 <https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1>
> 

In most conversations it is considered polite to answer the question asked and not to provide confusing extra data. This proposal violates that.

James R. Cutler
[email-masked]
PGP keys at http://pgp.mit.edu

---

From: Erik Nygren <[email-masked]>
Date: Sat, 9 Apr 2016 12:03:24 -0300

On Sat, Apr 9, 2016 at 10:11 AM, Mark Smith <[email-masked]> wrote:

> > Perhaps the opposite would be better - sending an AAAA query would
> result in an AAAA and A answer. That might create a small and subtle
> incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6
> failures.
>

+1

Motivations to do this alongside AAAA query responses rather than A queries:

   - Encourage sending AAAA queries first (generally a good practice)
   - Don't penalize devices that receive dual-stacked connectivity and do
   both AAAA and A lookups in cases when the A lookup gets dropped.
   - Helps DNS64 in the case of a NOERROR for the AAAA if the corresponding
   A record can be carried alongside.  Although... Pros: helps for
   dual-stacked clients with IPv4-only content.  Cons: removes a tiny
   motivation to dual-stack (in cases where clients behind DNS64 only do a
   AAAA lookup having a AAAA record improves DNS lookup time during DNS cache
   misses).

If we also look at something like this for stubs to resolvers, once enough
resolvers implement this it could let stubs do AAAA lookups serially and
only kick off a A lookup if no AAAA (or an empty AAAA with no A additional)
is returned.  (Although it would be undesirable for servers to wait for a A
record before returning a AAAA record, so they'd only want to tag on the A
if they already have one in-cache.)

             Erik

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Apr 2016 11:18:24 +0000

On 9 Apr 2016, at 14:11, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Apr 2016 8:55 PM, "Sander Steffann" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> > On 08 Apr 2016, at 13:27, [email-masked]<mailto:[email-masked]> wrote:
> >

Having briefly looked at it, it seems there is an efficiency benefit. However, answering an A query with both an A and AAAA response might incentivise just sending A queries.

Perhaps the opposite would be better - sending an AAAA query would result in an AAAA and A answer. That might create a small and subtle incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures.

I am aware of ISPs who have deployed IPv6 to their customers, knowing they needed to scale their DNS provision, but have still had to hold further deployment until this was achieved.  It’s not a huge issue, but any measures to help address scalability as you add IPv6 are likely to be welcomed.

But as others have pointed out, there are practicalities with the proposal.

Tim