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
pgpqhvL1v9N6b.pgp
Description: PGP signature
