Subject: Re: DNSEXT WGLC for LLMNR

From: Stuart Cheshire <[email-masked]>
Date: Mon, 25 Aug 2003 16:40:16 -0700

>This is a last call for the DNSEXT document
>	Linklocal Multicast Name Resolution (LLMNR)
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt

This is a busy time at Apple, working towards our next OS release,
but I managed to make time to read draft-ietf-dnsext-mdns-22.txt.

>The IPv4 link-scope multicast address a given responder listens
>to, and to which a sender sends queries, is 224.0.0.251.

If your intention is to make LLMNR interoperable with Rendezvous, I fully 
support that, and would be willing to do the necessary work. For example, 
Rendezvous does not currently support TCP queries, but we would be 
willing to add that support, and things like it, if the WG wanted to 
pursue that direction.

Otherwise, if the intention is not to make LLMNR interoperable with 
Rendezvous, then it should not use the same multicast address. Using the 
same multicast address, and then using a different UDP port number so as 
to demultiplex the traffic in the kernel, would be the height of folly. 
The whole point of multicast (as opposed to good old-fashioned broadcast) 
is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce 
the interrupt burden on the host CPU (and/or reduce the traffic on that 
link). Using the UDP port number as the filtering mechanism means that 
you pay all the cost of delivering a packet to a host that doesn't want 
it, only to have the packet discarded in the kernel because no one is 
listening on that port. The whole point of multicast is to prevent that 
waste.

>Today, with the rise of home networking, there are an increasing number
>of ad-hoc networks operating without a Domain Name System (DNS) server.

I think this is side-stepping the real issue. The real issue is:

>Today, with the rise of home networking, there are an increasing number
>of home users who do not have ownership of any part of the name space
>in which they can assign names.

The whole section talking about "unqualified names" seems to be skirting 
around this issue without being willing to face it head-on and tackle it. 
Section 3.1 says:

>3.1.  Unqualified names
>
>The same host MAY use LLMNR queries for the resolution of unqualified
>host names, and conventional DNS queries for resolution of other DNS
>names.
>
>If a name is not qualified and does not end in a trailing dot, for the
>purposes of LLMNR, the implicit search order is as follows:
>
>[1]  Request the name with the current domain appended.
>[2]  Request just the name.

You can't "request just the name". There is no way to represent an 
unqualified name ("no trailing dot") in the DNS packet format. What you 
mean is:

>[1]  Request the name with the current domain appended.
>[2]  Request the name with the root domain (".") appended.

What this means is that if a home user calls their TV "tv", and their FM 
radio receiver "fm", and their CD player "cd", their computer is going to 
be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal 
State of Micronesia, and Democratic Republic of the Congo, respectively.)

This seems like it invites chaotic uncontrolled pollution of the 
top-level name space.

Furthermore, because there is no way to represent an unqualified name in 
the DNS packet format, there is also no way to represent an unqualified 
name on the right-hand-side of a PTR, CNAME or SRV record. This means 
that if you do a LLMNR query for an SRV record with an "unqualified" 
name, what you get back is an SRV record containing a target host name 
that you can't use with LLMNR because it's not an "unqualified" name.

>Unicast queries SHOULD be sent when:
>
>  b.  The sender queries for a [reverse mapping] PTR RR.

Rendezvous has something called sleep proxy service, where a device can 
transfer its RRs to a sleep proxy server on the local LAN and then go 
into low-power sleep mode. The sleep proxy server answers queries on the 
device's behalf, and wakes the device with a magic packet when an A or 
SRV query is detected that indicates the device needs to wake up to 
provide some active service. Sending queries via unicast means the sleep 
proxy server may not get to see them, and may be unable to answer and/or 
wake the device.

>The source address of LLMNR queries and responses MUST be "on link".

Is this "MUST" a requirement imposed on senders, or a checking 
requirement imposed on receivers?

>it is possible that some routers may not properly implement
>link-scope multicast

This is far fetched. How many routers *DO* implement multicast 
forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible 
scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for 
over a year (longer if you count OS 9) and there have been no problems 
reported.

>The responder should use a pre-configured TTL value

Pre-configured by whom?

>[3] A responder with both link-local and routable addresses
>    MUST respond to LLMNR queries for A/AAAA RRs only with
>    routable address(es).  This encourages use of routable
>    address(es) for establishment of new connections.

This creates failures where failures were not necessary. Just put all 
answers in the response, and let the client use them intelligently: If 
the routable address works, great, otherwise, the client can try the LL 
to see if that works. Omitting the LL from the response does not help the 
client work better: it prevents the client from connecting in situations 
where it should be able to. (In some cases of network problems, omitting 
the LL addresses may prevent you from connecting to the some piece of 
network infrastructure to correct the misconfiguration that led to the 
problem in the first place.)

>3.1.  Unqualified names
>
>The same host MAY use LLMNR queries for the resolution of unqualified
>host names

Who makes the choice offered by that "MAY"? User? OS vendor? Application 
writer?

>If a name is not qualified and does not end in a trailing dot,

What does that mean? Do "fully qualified" and "ends in a trailing dot" 
mean the same thing, or is there a difference?

>Where there is
>no DNS server authoritative for the names of hosts on the local network

What does that mean?

What is the area code for mobile phones at an IETF meeting?

The statement doesn't have well-defined meaning.

My laptop computer has a name, and its name is not determined by its 
geographic location at any given time.

DNS servers are authoritative for pieces of the name space, not for 
physical networks.

Perhaps the text should say, "Where there is no DNS server authoritative 
for the name of at least *one* of the hosts *currently* on the local 
network..."

>Where a host is configured to respond to LLMNR queries on more than one
>interface, each interface should have its own independent LLMNR cache.

Perhaps you mean "configured to *issue* LLMNR queries on more than one 
interface"

>For each UNIQUE resource record in a given interface's configuration,
>the host MUST verify resource record uniqueness on that interface.  To
>accomplish this, the host MUST send an LLMNR query for each UNIQUE
>resource record.

How many LLMNR queries? What interval?

How long after the query (or queries) may it start issuing responses for 
that name?

What about tie-breaking in the event of simultaneous startup (e.g. when 
power is restored after an outage)?

>For example, the hostname could be chosen randomly from a large pool of
>potential names

Doesn't this miss the point of hostnames? The whole point of using names 
instead of dotted-decimal IP addresses is that names are supposed to be 
more memorable, and easier for humans to type. If we're going to use 
randomly chosen names, then we already have a mechanism for randomly 
choosing from a pool of potential identifiers: it's called a DHCP server. 
Isn't the point of LLMNR to let people pick a name for their machine 
that's a little more convenient and friendly than 
"dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>