Re: [mif] Last Call for MIF DNS server selection document

[<[e-mail]>]

About DNS64.

I agree DNS64 does not damage the logical structure of the namespace itself.

The main DNS64 related issue there is, I think, is just that the synthetic
responses should not be retained in possible host local cache over movement
from one network interface to another (oh well, WKP using synthetic
addresses can work in different points of network attachment, if there just
is WKP using NAT64 present:-). 

In the case of multiple parallel interfaces the NSP-using synthetic
addresses of course are usable only on the interface learned on, but I
believe the routing should take care of that with longest matching prefix
rules and so. But once a point of attachment changes, records using NSP of
course should be cleared (and also WKP using prefixes as those cannot be
guaranteed to work on new IPv6-enabled point of attachment, and may actually
be source of delays (ref happy eyeballs and non-working IPv6 paths)).

Best regards,

	Teemu

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Brian E Carpenter
> Sent: 09. syyskuuta 2011 04:32
> To: Andrew Sullivan
> Cc: [e-mail]
> Subject: Re: [mif] Last Call for MIF DNS server selection document
> 
> On 2011-09-09 12:11, Andrew Sullivan wrote:
> > On Thu, Sep 08, 2011 at 06:22:17PM -0400, Keith Moore wrote:
> >> I'm quite surprised that MIF was able to get this far with the document
> without the issue being raised.
> >
> > Have I really been so polite that this qualifies as "not raised"?  I
> > apologise to everyone, then.  But I've been uneasy about this since
> > early in my work on the DNS64 drafts.  I'm getting perhaps too adept
> > at nose-holding.
> 
> DNS64 doesn't damage the logical structure of the namespace itself.
> As soon as you admit that not all DNS servers serve the exact same
> namespace, and that a host may be able to see more than one DNS server,
> the total namespace cannot be guaranteed unique.
> There could be two totally unrelated entries for host.example.com.
> Introducing ambiguity in the DNS namespace, having already done so in the
> IPv4 address space, is a very serious step indeed.
> 
> If you want a citation, see clause 4.2 in RFC 1958.
> 
> This could be fixed by a BCP describing appropriate constraints on names
> that only resolve within a limited scope, I think, but it should not be
just a by-
> product of the draft under review.
> 
>    Brian
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif