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

[Michael Richardson <[e-mail]>]

I'm sorry if this a repeat.
{Although I've been on the mailing list a long time, I have been
ignoring it, and actually made a decision to unsubscribe a few hours
ago... I don't think I've succeeded yet.}

Today I tried the ietf-nat64 network.  I found that I got the wrong DNS
server via RA, and I'm told that it might work.  I expected to have to
put the correct one into my local recursive resolvers' "forwarder" list,
but in fact to my surprise my /etc/resolv.conf was updated by
NetworkManager.  

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 discovered some things that did not work (mostly in my IM client),
which I reported.... aha... do I have to flush my DNS cache?  yes, I do.

marajade-[~] mcr 10005 %dig @2001:df8:0:7::1 www.credil.org aaaa
;; ANSWER SECTION:
www.credil.org.         6118    IN      AAAA    64:ff9b::adec:8254

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.
Section 5.1.7 of draft-ietf-behave-dns64-11 says:

   o  The TTL field is set to the minimum of the TTL of the original A
      RR and the SOA RR for the queried domain.  (Note that in order to
      obtain the TTL of the SOA RR, the DNS64 does not need to perform a
      new query, but it can remember the TTL from the SOA RR in the
      negative response to the AAAA query.  If the SOA RR was not
      delivered with the negative response to the AAAA query, then the
      DNS64 SHOULD use a the minimum of the TTL of the original A RR and
      600 seconds.  It is possible instead to query explicitly for the
      SOA RR and use the result of that query, but this will increase
      query load and time to resolution for little additional benefit.)
      This is in keeping with the approach used in negative caching
      ([RFC2308].

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.

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