> > And what happens when vendors start shipping support for LLMNR? > > Will getaddrinfo() (or other API used for DNS lookup) suddenly start > > doing LLMNR queries if it thinks that DNS is unreachable? Will apps > > that were formerly using getaddrinfo to do DNS queries then get > > exposed to LL addresses even though they don't work properly with > > those apps? > > One solution may be to have a configurable switch for the behavior of > existing APIs (getaddrinfo...), like the existing nsswitch.conf ?
Aarrgh! please, no. The last thing apps need to deal with is more variation in behavior from one platform to another. If LLMNR is going to handle queries for DNS names, it needs to produce consistent results with DNS. Full stop. If it doesn't guarantee this, it has no business returning queries for DNS names, and we need to forbid getaddrinfo() APIs from using LLMNR. Part of behaving consistently with DNS means NO LL addresses in LLMNR for any DNS name which could also be queried from DNS. We really, really don't want apps using LL addresses anyway - not even on an isolated network. First because this requires apps to treat LL addresses differently depending on whether they are being run on an isolated network or not. Second because all the hosts in the app may not have a consistent view of the network - some hosts in an app may see themselves as being on an isolated network while other hosts see themselves as connected. Third because isolated newtorks can become connected and connected networks can become isolated - and you want to avoid having to change addresses across those transitions - this essentially amounts to a renumbering procedure done under severe time constraints. A lot of these problems are solved if instead of using LL, isolated networks elect a probabistically unique PI prefix (PUPI). I think it would be acceptable to advertise a PUPI in DNS or LLMNR as long as there were no PA addresses available (or maybe as long as any PA addresses were also advertised). And PUPIs are routable by private agreement between managed networks, or within a self-configuring network, so you don't have the same severely constrained use you have with LL. Ketih -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
