Re: LLMNR considreed harmful

[Keith Moore <moore@cs.utk.edu>]

> This seems to be a serious problem. Could you give some
> more information, at least some pointers to the relevant
> drafts and an expansion of LLMNR?

the draft is draft-ietf-dnsext-mdns-18.txt

LLMNR = Linklocal Multicast Name Resolution

problems in slightly more detail:

1. The goals and usage scope for the protocol are unclear.  It seems to
be targeted at isolated, nomadic, or intermittently connected newtorks
which need to support some form of name lookup but don't have reliable
DNS service.  Also the idea is to clearly to provide the name lookup
without requiring a central server, an approach which would be useful in
ad hoc or unmanaged networks.

The first paragraph of the Introduction says that LLMNR "cannot be
considered a substitute for DNS".  And yet the next sentence states
that a goal is to support name lookup on hosts that aren't configured
with the address of a DNS server - presumably even though one might be
available.  Similarly section 3 states that "LLMNR...is not intended as
a replacement for DNS" and then immediately suggests that LLMNR requests
should be sent under a variety of conditions when DNS is not available,
or when DNS does not respond.  In other words, the disclaimers
notwithstanding, LLMNR clearly is substituting for or replacing DNS
under some set of ill-defined conditions which vary from one host to
another.

The abstract implies that it targets home networks, but home networks
that are connected to the Internet do have DNS service.

2. It's clear that the LLMNR protocol is based on DNS, but the intended
relationship between LLMNR and DNS is not clear.  

- It appears to be assumed that the same server might respond to both
DNS queries and LLMNR queries (section 2.2)

- LLMNR claims to support all record types of DNS, but it doesn't
require the use of NS records to delegate lookups.

- All of the examples use fully-qualified DNS-style names, implying that
ordinary DNS names are used in LLMNR, and yet section 3 says that
LLMNR queries SHOULD be only for names which are either unqualified or
"in the default domain".  (never mind that domain names have nothing to
do with network topology... we're assuming that it's okay for the local
network to answer queries for a host's default domain even when the
host's domain may have nothing to do with the link.)

- section 2.2. says "Responders MUST NOT respond to LLMNR queries for
names that they're not authoritative for", thus implying some notion
of authority, but this authority is not defined.

- there is no advice on consistency between LLMNR and DNS.  for 
  instance there's no stated responsibility for a host to keep
  LLMNR and DNS consistent under any set of conditions, and in
  fact LLMNR servers are expected to use constant TTLs
  (where these might differ from those in DNS) and omit RRs from
  responses that might be provided in DNS.

3. LLMNR changes semantics of DNS lookup, and overloads semantics of 
   existing APIs

apparently it is intended that existing APIs for DNS lookup will be
overloaded to use LLMNR under some conditions which would otherwise
produce DNS lookup errors.  applications that expect the existing
behavior may break, and they are also subject to additional attacks. 
finally the additional time needed to attempt LLMNR queries will
result in additional delays for the application.

LLMNR will produce results that are inconsistent with DNS, and there's 
no way for an application to specify what kind of query to use or to
tell that it's getting LLMNR instead of DNS.

LLMNR has the potential for multiple answers from multiple sources to
the same query, DNS does not normally exhibit this (though a DNS
implementation could follow multiple NS paths and perhaps get varying
results to the same query from multiple NSes, it should find that the
serial numbers differ, and thus be able to resolve the conflict.)