Subject: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs

From: <[email-masked]>
Date: Thu, 4 Aug 2011 18:31:53 +0000

Hi,

RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA RRs in the response if real AAAA records are available.

Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA RRs when real AAAA records are available, the host would then be able to fall back using IPv4 in case real IPv6 connectivity on the path to dual-stack enabled destination is broken/not-good...

I.e. as of now DNS64 by default completely hides dual-stack destinations' IPv4 addresses and hence makes it impossible for hosts to fallback to IPv4.. right?

Of course returning synthetic AAAA RRs could make hosts accidentally communicate through NAT64s.. but we have the tools under work that would help hosts to prefer non-synthetic addresses during address selection functions:)

If IPv6 and IPv4 path characteristics would be different enough, it might make sense for hosts to do happy eyeballs even when in IPv6-only connection by triggering both native IPv6 and NAT64-traversing transport sessions.. but hosts can't if DNS64 hides the IPv4 address... except by performing WKP/NSP discovery as documented and then starting local IPv6 address synthesis procedures for happy eyeballs purposes:)

Just some thoughts:)

Best regards,

Teemu

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 4 Aug 2011 14:37:47 -0400

Le 2011-08-04 à 14:31, <[email-masked]> a écrit :

> Hi,
>  
> RFC6147 section 5.1.1 says DNS64 “SHOULD NOT” include synthetic AAAA RRs in the response if real AAAA records are available.
>  
> Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA RRs when real AAAA records are available, the host would then be able to fall back using IPv4

I'm not sure I get your point. If we are in a DNS64 scenario, the network between host and the NAT64, as well as the host itself,  is IPv6-only. Therefore, there is no such "fall back using IPv4".  

Unless I don't understand your point.

Marc.

> in case real IPv6 connectivity on the path to dual-stack enabled destination is broken/not-good…
>  
> I.e. as of now DNS64 by default completely hides dual-stack destinations’ IPv4 addresses and hence makes it impossible for hosts to fallback to IPv4.. right?
>  
> Of course returning synthetic AAAA RRs could make hosts accidentally communicate through NAT64s.. but we have the tools under work that would help hosts to prefer non-synthetic addresses during address selection functionsJ
>  
> If IPv6 and IPv4 path characteristics would be different enough, it might make sense for hosts to do happy eyeballs even when in IPv6-only connection by triggering both native IPv6 and NAT64-traversing transport sessions.. but hosts can’t if DNS64 hides the IPv4 address… except by performing WKP/NSP discovery as documented and then starting local IPv6 address synthesis procedures for happy eyeballs purposesJ
>  
> Just some thoughtsJ
>  
> Best regards,
>  
> Teemu
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Thu, 4 Aug 2011 18:47:03 +0000

> > RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA
> RRs in the response if real AAAA records are available.
> >
> > Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA
> RRs when real AAAA records are available, the host would then be able to fall
> back using IPv4
> 
> I'm not sure I get your point. If we are in a DNS64 scenario, the network
> between host and the NAT64, as well as the host itself,  is IPv6-only. Therefore,
> there is no such "fall back using IPv4".
> 

The address family related issues can occur in the access network or elsewhere in the Internet, right? 

If the IPv6 problem is outside of the IPv6-only access network, the eyeballs might in theory be happier if data would traverse through NAT64 and to the IPv4 Internet path to the destination..

I wrote "just some thoughts" because this is theoretical thinking, not some real life IPv6 transport network problems I would've seen:)

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 4 Aug 2011 12:02:27 -0700

> I wrote "just some thoughts" because this is theoretical thinking, not some real life IPv6 transport network problems I would've seen:)

To answer your question, no. NAT64 is here to help the transition to
all-ipv6, not to compensate and mask issues where IPv4 is faster than
IPv6.

Cameron

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Aug 2011 15:06:32 -0400

> I'm not sure I get your point. If we are in a DNS64 scenario, the network between host and the NAT64, as well as the host itself,  is IPv6-only. Therefore, there is no such "fall back using IPv4".  

Right.  Every now and then someone talks about what happens when you
use DNS64 in a dual stack environment.  The answer is, "Doctor, it
hurts when I do this."

Don't do it.  

I get why people want to make DNS64/NAT64 more robust than it may be
as defined.  But this is an attractive nuisance: it's never really
going to work all the way anyway.  (The twisty problems of detecting
the DNS64 are already illustrating this.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 4 Aug 2011 13:24:50 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Sullivan
> Sent: Thursday, August 04, 2011 12:07 PM
> To: [email-masked]
> Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic
> AAAA RRs
> 
> > I'm not sure I get your point. If we are in a DNS64 scenario, the
> network between host and the NAT64, as well as the host itself,  is
> IPv6-only. Therefore, there is no such "fall back using IPv4".
> >
> 

A nuance to this problem is that some networks will have a mix
of hosts:

  (a) IPv4-only, which use a 'normal' DNS server
  (b) dual stack hosts, which use a 'normal' DNS server
  (c) IPv6-only hosts, which use a DNS64 server so they
      can use a NAT64 to visit IPv4-only servers.

http://tools.ietf.org/html/draft-wing-behave-dns64-config-03 discusses
the pros/cons of a bunch of mechanisms to provide the correct DNS
server to all three of those host types.

I don't know if there is interest in this problem.  (But I find it
an interesting problem.)

-d

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 4 Aug 2011 15:47:14 -0600

> server to all three of those host types.

The technique outlined in the draft doesn't work. Clients will not strictly
stick to the "ordered" list:
		::ffff:192.0.2.1       # 'normal' DNS server
		2001:db8:dddd::1234    # DNS64 server

If for example a client is trying to resolve
www.dns-will-timeout-for-this-domain.com then the client will switch to the
second DNS server in the list. In practice you will have about 50% traffic
to each server after a day or so. 

There are plenty of examples of domains that bind and other nameservers
never return an answer for. 

The right thing to do is to have different policies for the different
networks, potentially using views or other similar DNS mechanism.

/Stephan Lagerholm

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 4 Aug 2011 16:56:09 -0700

> From: Stephan Lagerholm [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 2:47 PM
> To: Dan Wing; Andrew Sullivan; [email-masked]
> Subject: RE: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic
> AAAA RRs
> 

Can you write up how to accomplish that?

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 09:10:10 -0400

> Can you write up how to accomplish that?

People might want to have a look at
http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-03,
which is full of bad ideas that are just slightly less bad than all
the other alternatives.  

Andrew "like democracy" Sullivan

-- 
Andrew Sullivan
[email-masked]

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Fri, 5 Aug 2011 07:30:12 -0600

> which is full of bad ideas that are just slightly less bad than all

Yes those two drafts should probably "merge" into one, however there is a
difference in what they want to accomplish.

mif-dns-server-selection assumes additional logic on the host to make an
intelligent decision on what DNS server to use when several are available.
wing-behave-dns64-config assumes that you only provision the appropriate DNS
server to each host so that they can't use the wrong server.

Something like wing-behave-dns64-config is needed until all hosts supports
mif-dns-server-selection.

/Stephan Lagerholm

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 09:53:15 -0400

> mif-dns-server-selection.

Well, yes, except as you point out it's still at best going to be
heuristic, because the technique in draft-wing-behave-dns64-config is
quite likely to end up hitting the dns64 anyway.

On a slightly different note, Dan, I wonder whether you want to
include discussion of a DNSSEC wrinkle.  Suppose someone uses the
techniques in draft-wing-behave-dns64-config.  If they want the
upstream resolver to do DNSSEC for them, then there will be yet
another problem.  When a resolver sets DO=1 and CD=0 and the upstream
resolver is validating, then a vaidation failure returns SERVFAIL.  A
host might reasonably query the next DNS server it has under those
circumstances (there's a nasty attack here, of course, if your host
has both validating and non-validating upstreams.  Don't Do That).  In
this case, the upstream validation failure will cause the client to
start asking the DNS64.  Of course, as long as the DNS64 is also
validating, it'll return SERVFAIL too, so it might not matter, but it
might be worth noting.

A

-- 
Andrew Sullivan
[email-masked]