Subject: Re: [BEHAVE] draft-ietf-behave-dns64-00 Additional section processing

From: Simon Perreault <[email-masked]>
Date: Sun, 2 Aug 2009 07:08:43 -0400

On Friday 31 July 2009 16:10:44 Andrew Sullivan wrote:
>     1.  "We don't care.  Don't run a DNS server that offers recursion
>     and performs caching behind a DNS64, period."  I think this won't
>     really work, because we have no way of knowing how many such
>     resolvers there are out there, and the whole point of this effort
>     is to reduce the need to upgrade all the deployed systems
>     (particularly, all the customer equipment) or to know exactly what
>     equipment lies where in the network.

This is what I would prefer.

There are many cases where B is controlled by the same entity as the one who 
controls the DNS64. In this case, B's configuration can be modified so that it 
works in this context. No need to change software, just configuration.

Otherwise, there are many cases where the entity who controls the DNS64 also 
controls the network, and may then simply redirect all DNS queries to the 
DNS64. Many ISPs currently do this anyway with DNS servers that lie in 
arguably less useful fashion.

Are there significant instances of other cases (the entity who controls the 
DNS64 controls neither B nor the network) we should care about? I can't think 
of any.

Simon
-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.

---

From: Timothy Baldwin <[email-masked]>
Date: Thu, 06 Aug 2009 15:18:41 +0100

Andrew Sullivan wrote:
> On Fri, Jul 31, 2009 at 10:33:52PM +0100, Timothy Baldwin wrote:
>
>   
>> But one can be reasonably certain many of them are IPv4 only, 
>>     
>
> I think I don't understand this part of your comment, which is why the
> rest of it is opaque to me.  Many of _what_ are IPv4 only?
The recursive DNS servers that you describe as "out there".
>   Do you
> mean that the target hosts are v4 only?  If so, then yes, that's
> exactly the scenario we're trying to help, where one host is on a v6
> only network and another is on a v4 only network.
>   
I was referring to v4 hosts on the proposed v6 only network. Obviously 
one must ensure that the nodes on a v6 only network are not v4 only, it 
would not be much extra work to ensure they are not configured to use 
problematic DNS servers.

As for existing v6 only networks for which connectivity to v4 hosts is 
wanted - do many exist?

For existing v6 only hosts in a existing dual-stack network, there may 
be a problem if these are configured by RAs or DHCPv6.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Aug 2009 11:37:31 +0200

On 31 jul 2009, at 22:10, Andrew Sullivan wrote:

> Suppose one has a DNS server that offers recursion and performs
> caching, and that it is behind a DNS64.  I'll call this system "B" for
> the sake of brevity.  B can happen on a CPE box, for instance, which
> usually gets its own list of nameservers from DHCP.  What B does
> _not_ have is a root.hints file: it relies on an upstream server for
> some work, in order to make use of the existing cache at the ISP.  The
> critical ingedient here is that the nameserver is not merely
> forwarding.

So you're saying that even though this server can simply forward all  
queries to the ISP nameservers it will try to do its own recursive  
lookups sometimes and return a failure to the client if that doesn't  
work?

Such a server wouldn't work in an IPv6-only environment today, and  
probably also not in an IPv4-only environment in the future. This has  
nothing to do with DNS64, just with the fact that if you want to  
resolve information that resides on v4-only servers when you only have  
v6 there is not a lot you can do. (And NAT64 won't help you because  
you're trying to access literal IPv4 addresses.)

As such, the only reasonable way forward is saying "don't do that".  
Especially since this strange mixture of recursive/forwarding  
nameserver doesn't seem to have any useful properties.

IPv6 CPE specifications are currently being worked on so it's not too  
late to avoid this type of DNS servers from escaping into the wild.