Subject: [v6ops] 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: Erik Kline <[email-masked]>
Date: Sat, 9 Apr 2016 17:07:10 +0900

So far I fail to see the benefit.

Host that think they can do IPv6 generally ask for AAAAs first, or
nearly simultaneously with As if they're doing connection racing.  So
I don't see how this helps.

On 9 April 2016 at 16:55, Geordie Guy <[email-masked]> wrote:
> 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
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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: 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: Geordie Guy <[email-masked]>
Date: Sat, 9 Apr 2016 17:55:30 +1000

Geordie

---

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: Robert <[email-masked]>
Date: Tue, 12 Apr 2016 08:08:13 -0700

> I don't see how this helps.

There's a bit of an explanation in the RFC, which I think boils down to:

a) stub resolvers on dual stack hosts issue two DNS queries, but treat
it as a single request so if either response is lost the stub resolver
will try the whole thing again
b) maybe your resolver is anycast and the two queries end up different hosts

I was a little skeptical of the impact of "a)" so I wrote up a quick
getaddrinfo program and tested it out on what I had handy by blocking
either A or AAAA queries from the client.

Linux (glibc 2.22):
 No blocking: 0.002s
 Blocking AAAA: 15.019s
 Blocking A: getaddrinfo: Temporary failure in name resolution

FreeBSD 10.3:
  No blocking: 0.002s
  Blocking AAAA: 15.036s
  Blocking A: 15.047s

MacOSX 10.11.4 (on wifi):
  No blocking: 0.008s
  Blocking AAAA: 5.016s
  Blocking A: 30.079s

So yeah, in the worst case you can really impact performance of
getaddrinfo.  Even in the normal case, getaddrinfo sends two queries
and is bounded by the worst, so the client is twice as likely to see
failure.

I'm not sold that returning AAAAs in A is the right thing, it seems
like returning As in AAAA would be a better mode of operation.  Fewer
clients that would need to be updated, encourages checking for AAAAs
first and could save you the second lookup.

As the draft is written today, I feel like in 20 years people will be
wondering why everything does a A query and only ever gets back AAAA
data.

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 12 Apr 2016 15:59:03 +0000

Thinking further on DNS64 and the compatibility (limitations) of DNSSEC with DNS64, I was wondering if the additional A record in an AAAA query could add value here?

A stub resolver that supports local synthesis of AAAA records, so does not require DNS64 from the network, could use the A record for synthesis.
In a network with security aware RDNSS then the stub resolver can request only AAAA, set the DO bit, and  can get the DNSSEC A record back (is this true?)
So it can help with compatibility of DNSSEC on stub resolvers, when local synthesis is supported and some stable equilibrium can be found between need for DNS64 and desire for DNSSEC.
Is my thinking correct?

From: v6ops [mailto:[email-masked]] On Behalf Of Erik Nygren
Sent: 09 April 2016 16:03
To: Mark Smith
Cc: 6man WG; v6ops list
Subject: Re: [v6ops] DNS AAAA for free

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

On 9 Apr 2016 8:55 PM, "Sander Steffann" <[email-masked]<mailto:[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

  *   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

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. 
If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. 
If you've received this email in error, please let me know immediately on the email address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited 
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

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.

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