ietf
[Top] [All Lists]

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard

2005-09-06 07:57:28
On Mon, Sep 05, 2005 at 01:45:03AM -0700, Christian Huitema wrote:
LLMNR does not create additional DNS queries. Applications do not issue
LLMNR requests, they issue name resolution requests. When a name
resolution request is issued, the current behavior is to submit the
request to the DNS, possibly applying a "search list". LLMNR does not
change that. LLMNR adds an additional transaction at the end of the
search list, falling back to local multicast resolution if the
infrastructure could not resolve the query authoritatively.

The _protocol_ does not change that.  The _adoption_ of the protocol
changes the world in such a way that the effect appears.  Today, very
few people accidentally resolve things to TLDs like .myhome or .local
or .whydoicare or whatever.  But if LLMNR is widely adopted, then end
users will have reasons to attempt to make such resolutions as a
matter of course (maybe accidentally -- the names might be configured
for them by programs, so that they don't even know they're doing
this).  If those end users' boxes are also hooked up to the DNS
infrastructure -- an assumtion that hardly requires stretching one's
imagination -- then every such attempted resolution will send at
least one query to the DNS infrastructure.

Just because a protocol doesn't require a technical change in
behaviour does not mean that its adoption will not change the
techno-social environment.  For a somewhat recent example, consider
the phishing attacks that IDNA opened up.  They're really not much
different from other, previously-known phishing attacks, but because
the phish-space was so much bigger, what was once a managable
annoyance became a problem that needed to be addressed by those
developing IDNA-aware applications.  

At least in the IDNA case, the social problems could be worked around
with techno-social solutions.  Not so in the case of LLMNR: if we
start to have this problem, everyone will have to live with it,
because the protocol is designed that way.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew(_at_)ca(_dot_)afilias(_dot_)info>                              M2P 2A8
                                        +1 416 646 3304 x4110


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf