Minutes of the 4/30/03 LLMNR Conference Call

[Bernard Aboba <aboba@internaut.com>]

Attendees: Erik Guttman, Randy Bush, Christian Huitema, Bernard Aboba

Bernard Aboba gave a summary of the currently open issues on the LLMNR
Issues page:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

These include Issue 36 which is purely editorial, as well as Issue 33,
which deals with sending PTR via unicast. Issue 34 deals with sending of
unicast queries via TCP. Issue 35 deals with the TTL of all queries,
multicast and unicast.

Issue 33 is the parent of Issues 34 and 35 in that prior to introducing
the concept of a unicast query, all LLMNR queries had been done via
link-scope multicast with a unicast UDP response, unless a cached NS
RR existed, in which case a unicast UDP query is feasible.  If the unicast
response had the TC bit set, then the query would be resent using TCP.
Because of this it is necessary for all responders to listen on the TCP
LLMNR port, as well as the UDP LLMNR port (in the case of cached NS RRs).
Erik Guttman suggested that the only way a responder might get away with
not implementing a TCP listener would be if it knew that it would *never*
set the TC bit. That might be hard to know in practice, given every
possible query that could be answered. But if the query support were
restricted (say, A/AAAA only) then this might be knowable.

Issue 33 proposes that PTR queries be sent via unicast. Assuming that
unicast queries are sent via UDP, this translates to a requirement for the
responder to implement a UDP unicast listener. It was felt that this
increases the level of vulnerability, and so is undesirable.

Randy Bush asked about the situations in which PTR queries would be sent
via LLMNR. Section 3 of the specification states that "LLMNR requests
SHOULD be  sent only when no manual or automatic DNS configuration has been
performed, when DNS servers do not respond, or when they respond to a
query with RCODE=3 (Authoritative Name Error) or RCODE=0 and an empty
answer section." There was a question about whether in the case where
RCODE=0 and the answer section is empty, whether it is appropriate to send
an LLMNR query. It was noted that where IPv6 hosts are concerned,
currently DNS servers respond to AAAA and IPV6 PTR RR queries with lots of
different errors, including RCODE=3 and RCODE=0. So in practice, it may be
necessary to use LLMNR in both cases.

It was noted that it is not believed that DNSSEC will be very usable with
LLMNR, although it might be possible for LLMNR responses to be validated
in situations where the proper cache entries have been built up.

It was noted that PTR RR queries are typically not required, since quite a
few applications that use PTR RR queries don't do much with the
information anyway, and in fact can handle teh failure to resolve the PTR
RR gracefully. As a result, Christian Huitema suggested that
implementation of PTR RR queries be optional. The first level of support
for LLMNR is to send and respond to A/AAAA queries; this is the most
typical use. If it was  certain that the TC bit would never be set in a
response, then in this case the responder might not need to implement TCP.
Randy Bush pointed out that TCP  support was required in RFC 1034-1035, so
that the precedent was clear: omitting this functionality because you are
*sure* it can't be used only leads to breakage when it turns out that
ooops, it can happen after all.

Beyond this, the next level of support would be SRV and other RRs. Such a
responder implementation would need to implement a TCP listener.

Overall, the recommendation was to accept Issue 33 (unicast PTR query);
and Issue 36 (editorial), as well as Issue 35 (TTL=1). On Issue 34,
possible compromise language was suggested:

a. TCP listener is required for any implementation in which the TC bit can
be set in a response.

b. All LLMNR queries and responses MUST be sent with TTL=1. (Issue 35)

c. Unicast queries SHOULD be sent via TCP. A responder with a unicast UDP
listener MAY sent back an empty response with the TC bit set automatically
in response to a unicast UDP query in order to force use of TCP. That
implies that a sender probably needs to implement TCP anyway.

d. PTR RR queries SHOULD be sent via unicast.


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