[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt

On 5/07/2007, at 4:29 AM, Rémi Denis-Courmont wrote:


Le mercredi 4 juillet 2007, vous avez écrit :

Anycast is good, but I think it's important that the clients are
default configured with a vendor agnostic DNS name that points to the
anycast address as well.


I have not seen any precedent of vendor-agnostic DNS name (apart from
example.TLD that is). Not only that, but who would maintain the DNS
zone that clients would run into when the ISP does not "hijack" the
name?
I've not seen precedent of vendor-default DNS names for network functions, either (or at least, that I can recall on short notice :-). I'm not sure that lack of precedent is a good reason to not do something.
That's a good question as to who would host and maintain the zone. In the document I say: "The root servers (or some other independent party) would host the DNS name". I'm not sure who that third party could be, but the root servers (or perhaps a subset of the root servers) seem well placed in terms of reliability, and trust-ability. 


There are probably millions of Windows boxes using
teredo.ipv6.microsoft.com already. It is technically possible to change this zone to point to an anycast prefix (should Microsoft be willing to 
use it...), as has seemingly been done with 6to4.ipv6.microsoft.com.
My recommendation would be for MS to change the default to a new name, and also change the A record of the existing default to point to the anycast address. 


That means that the control is entirely with
the SP, and there is no reliance on third party DNS names etc.


With anycast, the access provider has control, always. With DNS, it
assumes that the user is using the ISP recursive DNS servers (most
common, but not systematic).


With /only/ DNS, yes.
My recommendation (which isn't clear from ready the document, sorry about that!) is to use both DNS and anycast, and by default the DNS entry points to the anycast address. ISPs should use anycast where possible, but use DNS if it's not available. 


Also, if providers don't have the ability to anycast,
If they have no control over routing, I doubt they would or even should 
have control over DNS still.
Perhaps, however there are 'virtual' ISPs who run DNS, SMTP, etc. services for their customers, but who do not route their IP traffic to other parts of the Internet. However, my comment was more in regards to it being unsuitable for their network for some reason (perhaps in an enterprise network, for example), or because they want to be able to load balance things differently to how they could with anycast.
By the way, you may as well drop the SRV records idea. Some people would 
complain that it allows Teredo to run not-on-port 3544, and becomes a
mess to block at the firewall. Not *me* though.
If end users can connect out through your firewall on any address, being able to block a Teredo port doesn't gain you any security. If you want to prevent users from automatically establishing tunnelling without them realising, either a) disable Teredo on all machines, or b) put in a DNS entry pointing to an invalid server, or c) null route the anycast address. I'm sure you're aware of this, but I'll describe why it's not a problem when I document the SRV as a sub-option of the well known DNS name bit so that others get it too :-).
The only reason I can see not to do well known DNS in parallel to IPv4 anycast is the issue of who would host the name, and I suspect we could resolve that fairly easily. It seems to me that the flexibility and security that is gained is worth it.
Perhaps an alternative to having a fallback in DNS is to have the anycast address configured as the Teredo server address to use when the DNS name is un-resolvable - that would require some extra logic in the clients though, but it would be pretty trivial I'd imagine: 

address = dns_lookup(well.known.dns.name)
if (address = failed) then address = a.b.c.d

--
Nathan Ward