Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

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

 



Harald Tveit Alvestrand wrote:

>We're probably rehashing the DNSEXT discussion here, but I wasn't part of 
>the DNSEXT discussion.....
>
>LLMNR allows me to treat names in a different way than mDNS does.
>If I have a name that I'm certain I own (this box is, with high certainty, 
>the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR 
>allows me to assert that name on a LAN even when the DNS is not available, 
>or when that name is not currently asserted in the DNS.
>
>mDNS, as I understand it, doesn't allow me to do that - I would have to 
>assert "HALVESTR-W2K02.local", or "HALVESTR-W2K02.emea.cisco.com.local".

No, this is completely wrong.

There are *two* important goals of mDNS:

Goal 1: I have a legitimate FQDN, and connectivity with my peers, but no 
connectivity to the greater Internet right now. In this mode, mDNS (like 
LLMNR) is providing "fail-over" for unicast DNS. Even on Mac OS 9, five 
years ago, if you looked up "www.ietf.org" and had no unicast DNS servers 
configured, it would look it up via mDNS instead.

Goal 2: I have no legitimate FQDN. I just need a temporary no-frills name 
I can use for the time being. This is so that, for example, every HP 
printer can ship from the factory with the name "hp-printer.local", which 
is at least good enough for bootstrapping until the customer has assigned 
a legitimate FQDN for the printer. This is what mDNS uses the ".local" 
namespace for. It's a free-for-all sand box where all names are up for 
grabs and no names are quite trustworthy.

LLMNR seeks to solve the first goal but not the second, but in failing to 
provide a sand box for ad hoc names, it makes the entire DNS namespace a 
sand box for ad hoc names.

mDNS seeks to address both problems, but we're aware that looking up 
general DNS names via unauthenticated local multicast queries has 
horrible security implications, and we're aware that today we're not 
confident that we know how to solve that problem, so the mDNS draft 
recommends:

   (14. Enabling and Disabling Multicast DNS)

   The option to fail-over to Multicast DNS for names not ending
   in ".local." SHOULD be a user-configured option, and SHOULD
   be disabled by default because of the possible security issues
   related to unintended local resolution of apparently global names.

   (24. Security Considerations)

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name.

>The difference between LLMNR and mDNS here seems to be that mDNS
>*requires* me to use two different names in the two different cases;
>LLMNR, while it certainly *permits* me to do so, does not *require* it.

Absolutely not.

mDNS allows you to have a single FQDN, and answer those queries via 
multicast, but recognizes that we need solid security mechanisms before 
we can honestly recommend that.

LLMNR allows you to have a single FQDN, and ignores the security risks.

Stuart Cheshire <cheshire@xxxxxxxxx>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]