Subject: Re: [BEHAVE] TTL in reply for DNS64 -- should be 1.

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Apr 2011 11:32:13 -0400

Hi,

On Tue, Mar 29, 2011 at 05:28:23PM +0200, Michael Richardson wrote:

> It wasn't until I started filling out they survey that I realized I
> should flush my DNS cache, that I'd have to.  So, this needs to be
> addressed somewhere --- we really need some signal in the RA that there
> is a NAT64 available, and therefore if you have a local recursive
> resolver, you should either do DNS64, or you should pay more serious
> attention to the DNS value you get from the RA (or the DHCPv6).

I think the draft actually points out that a local, DNS64-unaware
recursive resolver is going to be hosed in a NAT64 (that's what
section 6 is about), although if it's not clear enough I'd be
delighted to receive suggestions so that when we return to this
specification in the next iteration, we can make it better.  

There is some current work going on to try to detect DNS64 (IMO,
we are going to pick the ugliest and worst answer for this, but I
don't have a better solution given the constraints we're facing).

> The TTL in the reply is way too high.   I can easily imagine wandering
> in and out of IPv6 only networks (with suspends in between).   I
> shouldn't have to flush my DNS cache each time.
> 
> I'd like to suggest that the TTL be 1.

I very strongly disagree.

It is certainly true that you should not have to flush your DNS cache
each time you move between one DNS realm and another, when you're
going to get different answers from the DNS for the same qtuple.  But
this is not a reason to make the TTL of answers be 1.  It is instead a
reason for your network manager to do the right thing rather than
ignoring this problem.

Making the TTL 1 will mean that local caches cannot work effectively,
which will increase load on the DNS64 in the non-unusual case when you
remain in the same network.

> I can see that this is trying to find a heuristic that tries to find a
> reasonable upper bound so that if a AAAA does appear then it won't take
> too long to discover this.
> 
> Unfortunately, it fails, I think, for mobile nodes that can be on
> different networks in series without restarting.  I.e. laptops and
> smartphones.

The DNS is loosely coherent.  If we're going to start fooling with the
answers (an admittedly dirty hack to begin with), then that loose
coherence is going to be strained when moving in and out of realms
where DNS64 is deployed.  I have my doubts that this will be quite so
common as you seem to be suggesting, but even if it is, I think that's
part of the cost of using NAT to solve this problem.  Making all
caches last a second seems to me to be at least as bad as the symptom
we're trying to cure.  Moreover, it won't work anyway, since some
applications will cleave to the first record they get even after the
TTL is expired (especially if it's that short).

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 13 Apr 2011 09:02:50 -0700

On 4/13/2011 8:32 AM, Andrew Sullivan wrote:
> common as you seem to be suggesting,...
>

This feels like it will be *very* common. We already have one mobile 
operator testing a NAT64 deployment, and when my mobile phone is at home 
it is on an 802.11 network with native IPv6. So every time I walk up and 
down the street I go in and out of a NAT64 environment (or would, if I 
was using that carrier).

Matthew Kaufman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Apr 2011 12:14:52 -0400

On Wed, Apr 13, 2011 at 09:02:50AM -0700, Matthew Kaufman wrote:
> operator testing a NAT64 deployment, and when my mobile phone is at
> home it is on an 802.11 network with native IPv6. So every time I
> walk up and down the street I go in and out of a NAT64 environment
> (or would, if I was using that carrier).

Well, yes, but is your phone caching its DNS responses?  And if so,
does it respect the TTL from the RR that it gets back?

Remember, reducing the TTL will only work in the case where your end
node has a cache, that cache is DNS64-unaware, and there is no
mechanism to tell it that it has changed upstream DNS sources.  If
your network manager notices that it has moved from one v6 network to
another, then it probably needs to flush your DNS cache.

This is already true today, even though we would like it not to be.
The DNS hasn't been a unified namespace for a long time, and your
local DNS server may well provide you with results local to your
network.  Moreover, mDNS is all but guaranteed to do so.  So your
network manager, if you are using mDNS, already needs to know how to
do some of this.

There is, moreover, the fact that some applications don't release the
address record they have even if the TTL expires.  

I don't think the way to fix this generic problem is to turn down the
TTL for one species of the problem.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Apr 2011 12:16:47 -0400

> TTL for one species of the problem.

+1

The network manager is where this should be fixed.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 13 Apr 2011 10:33:35 -0700

> TTL for one species of the problem.

I wasn't arguing for the particular solution, just that the hypothetical 
situation (of moving in/out of NAT64) seems much more likely to be 
commonplace.

Matthew Kaufman

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Apr 2011 23:48:28 +0200

On 29 mrt 2011, at 17:28, Michael Richardson wrote:

> we really need some signal in the RA that there

Adding stuff to RAs is even harder than adding stuff to DHCP. I don't think handling this corner case more gracefully is worth the trouble.

If people have IPv6 but no IPv4 and run a local recursive DNS then presumably they'll have an incentive to investigate the availability of NAT64.

But if your favorite DNS vendor wants to add a config option "forward-first-if-no-ipv4-available" nothing's stopping them.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Apr 2011 16:11:17 +0000

[...]
> It is certainly true that you should not have to flush your DNS cache each time
> you move between one DNS realm and another, when you're going to get
> different answers from the DNS for the same qtuple.  But this is not a reason to
> make the TTL of answers be 1.  It is instead a reason for your network manager
> to do the right thing rather than ignoring this problem.
[...]

I completely agree with Andrew.   If there's a cache in the host, then the
host is responsible for flushing the cache when you change networks.  This 
is not a reason to punish everyone else by making TTL=1.

-Dave

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 14 Apr 2011 09:16:07 -0700

> is not a reason to punish everyone else by making TTL=1.

Completely agree.

Cameron

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Apr 2011 09:23:39 -0400

{my appologies for late reply: I read my IETF lists in large chunks. On
the other hand, I can read the entire thread before replying}

>>>>> "Andrew" == Andrew Sullivan <[email-masked]> writes:
    Andrew> There is some current work going on to try to detect DNS64
    Andrew> (IMO, we are going to pick the ugliest and worst answer for
    Andrew> this, but I don't have a better solution given the
    Andrew> constraints we're facing).

I am in favour of heuristics, but they should be a mitigation until a
non-heuristic signal is available.  
An RA option seems like a great thing to me, and I can't see why how
long this will take to standardize should matter.  

    Andrew> It is certainly true that you should not have to flush your
    Andrew> DNS cache each time you move between one DNS realm and
    Andrew> another, when you're going to get different answers from the
    Andrew> DNS for the same qtuple.  But this is not a reason to make
    Andrew> the TTL of answers be 1.  It is instead a reason for your
    Andrew> network manager to do the right thing rather than ignoring
    Andrew> this problem.

okay, I will buy this.  My preference is really to do the AAAA synthesis
locally, where I also want to do DNSSEC.  If I have that RA signal that
I should do it, then I'm set, and I can flush as necessary.

    >> different networks in series without restarting.  I.e. laptops
    >> and smartphones.

    Andrew> The DNS is loosely coherent.  If we're going to start
    Andrew> fooling with the answers (an admittedly dirty hack to begin
    Andrew> with), then that loose coherence is going to be strained
    Andrew> when moving in and out of realms where DNS64 is deployed.  I
    Andrew> have my doubts that this will be quite so common as you seem
    Andrew> to be suggesting, but even if it is, I think that's part of
    Andrew> the cost of using NAT to solve this problem.  Making all
    Andrew> caches last a second seems to me to be at least as bad as
    Andrew> the symptom we're trying to cure.  Moreover, it won't work
    Andrew> anyway, since some applications will cleave to the first
    Andrew> record they get even after the TTL is expired (especially if
    Andrew> it's that short).

Yes, I agree that this is a problem.

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> On 29 mrt 2011, at 17:28, Michael Richardson wrote:

    >> we really need some signal in the RA that there is a NAT64
    >> available, and therefore if you have a local recursive resolver,
    >> you should either do DNS64, or you should pay more serious

    Iljitsch> Adding stuff to RAs is even harder than adding stuff to
    Iljitsch> DHCP. I don't think handling this corner case more
    Iljitsch> gracefully is worth the trouble.

okay, I find this very surprising.

    Iljitsch> If people have IPv6 but no IPv4 and run a local recursive
    Iljitsch> DNS then presumably they'll have an incentive to
    Iljitsch> investigate the availability of NAT64.

okay, so the problem is we need a signal that NAT64 is available so that
local synethesis can occur.   +1 on the network manager doing this.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Apr 2011 15:59:25 +0200

> okay, I find this very surprising.

Which part? That it's hard or that because it's hard it's not worth doing?

The problem with RAs is that you need it in hosts and in routers, and unless the user/administrator wants to do a lot of hacking, this needs to sit deep in the OS. These OSes are on fairly long update cycles, and in the case of routers, it can take REALLY long for software that's available to be deployed, typically people don't update their routers unless they really need to. Also, this needs to be configured unless the router is the NAT64 or DNS64, which makes the chance of this happening even smaller.

So you're looking at at least one, but more realistically two years before it even starts appearing. And even then you're looking at 5+ years of partial deployment. So if you can't depend on this feature being there for that long, you need to address the issue through other means anyway, and then, what's the point of doing it in RAs anyway?

> local synethesis can occur.   +1 on the network manager doing this.

A host could assume (and test for) the presence of a NAT64 on the well known prefix if it is running IPv6-only.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Apr 2011 18:16:03 -0400

>> okay, I find this very surprising.

    Iljitsch> Which part? That it's hard or that because it's hard it's
    Iljitsch> not worth doing?

    Iljitsch> The problem with RAs is that you need it in hosts and in
    Iljitsch> routers, and unless the user/administrator wants to do a
    Iljitsch> lot of hacking, this needs to sit deep in the OS. These
    Iljitsch> OSes are on fairly long update cycles, and in the case of
    Iljitsch> routers, it can take REALLY long for software that's
    Iljitsch> available to be deployed, typically people don't update
    Iljitsch> their routers unless they really need to. Also, this needs
    Iljitsch> to be configured unless the router is the NAT64 or DNS64,
    Iljitsch> which makes the chance of this happening even smaller.

    Iljitsch> So you're looking at at least one, but more realistically
    Iljitsch> two years before it even starts appearing. And even then

No, I'm in a greenfield, and the routers I care about are all open
source, and the CPE devices have SDKs.  So, I think I can do it on my
network in time for my NAT64/DNS64 deployment in June.

If only I had a code point.

    >> okay, so the problem is we need a signal that NAT64 is available
    >> so that local synethesis can occur.  +1 on the network manager
    >> doing this.

    Iljitsch> A host could assume (and test for) the presence of a NAT64
    Iljitsch> on the well known prefix if it is running IPv6-only. 

okay, that's a good heuristic.
I'll be hacking my install to return TTL=1 as well.  It's my DNS server
I'll be killing.