Zeroconfig and Multicast DNS

[Brooks Davis]

On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >>> Things get a bit more complex for multi-homed hosts; especially if they
> >>> are connected to more than one local link using IPv4 Link Local
> >>> Addressing...
> >>
> >>Well, I already have a proof-of-concept of this running a multi-homed
> >>responder and hosts on both ends resolve the addresses correct.
> >>
> >>A multi-homed host with two interfaces configured in 169.254/16 will
> >>have other major problems beyond mDNS as the host would threat
> >>both interfaces as being on the same net even if they are
> >>physically separated.
> >
> >And that's one of the things that we'll have to fix if we want LLA and 
> >mDNS to work correctly. The default should probably be to assume that 
> >they are separate; but to recognize if they are in fact on the same 
> >link. That should be easy enough to do since the LLA packets sent out on 
> >one interface will be seen by the other one when they are on the same link.
> >
> 
> Um...I'm not sure if this is even possible. Let's forget mDNS and
> go back to basic IP.
> Say a multi-homed host has two interfaces both configured with an
> address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and
> it wants to initiate a connection to 169.254.3.1, how on earth should
> it be able to tell on which side 3.1 is located? There might even be
> one 3.1 on both side that could be completely different hosts.

You probably would need an extension similiar to the one for IPv6 LLAs.
i.e. the %bge0 in fe80::2e0:81ff:fe31:9f00%bge0.

> >>> As I mentioned in an earlier posting, I would really like to see it
> >>> support multiple TLDs for a single host. In particular, if I'm using
> >>> example.com, then mumble.local and mumble.example.com should both
> >>> resolve via mDNS to the IP address of host mumble. Similarly, services
> >>> advertised by host mumble should automatically be listed in both 
> >>domains.
> >>
> 
> Ok, some kind of alias that will propagate for all records. I don't
> have a good solution to it yet, I need to think about this but I do
> get your point (and I can see the benefit with it).
> 
> >>Well, $(hostname).example.com. A  $(ifaddr) :)
> >>You would have to configure the NSS module to allow .com queries too.
> >
> >The NSS module shouldn't have to know which domains mDNS is handling. It 
> >should just attempt to resolve the FQDN given, using mDNS. If it fails, 
> >resolution will fall back to the next module listed in nsswitch.conf. (I 
> >envision the default as being: files mdns dns)
> 
> This suggestion is VERY VERY dangerous. Any responder on the network
> could very well decide to respond to for example www.google.com (or to
> the address of your internet banking site). What you see in your browser
> would be www.google.com and the page might look like google but you
> won't be at the site you think. Having the responder resolve names
> with real TLDs means that it will resolve names that it does not have
> the authority over.
> 
> The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss
> module should ship with a default to only allow queries to
>   .local
>   .168.254.in-addr.arpa
>   .168.192.in-addr.arpa
>   .16.172.in-addr.arpa-31.172.in-addr.arpa
>   .10.in-addr.arpa
> 
> And whatever set of IPs that are assign as link/site-local for IPv6,
> I don't remember them at the moment.
> However it should be possible for a user to add whatever TLD he/she
> wants or disable the restriction all together. But the default should
> be restricted to prevent name spoofs.

Agreed.  In most environments a spoof will still be possible, but it
would be harder and would require traffic that is detectable by a good
IDS.

-- Brooks

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060824/89c00f5b/attachment-0001.pgp