[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    LLMNR Issue 52: LLMNR-25 review (Ralph Droms)
From:       Ralph Droms <rdroms () cisco ! com>
Date:       2003-12-15 18:29:59
[Download RAW message or body]

See "RD>" for my comments on the responses to issue 52.

- Ralph

[BA]  1. LLMNR does indeed use the same packet format as DNS for both
requests and responses. This should be clarified.

   RD> OK; changes below look OK.

2. Names are used in LLMNR the same way that they are used in DNS,
and have the same structure. The matching rules are also identical,
including use of wildcards.

   RD> Practically speaking, because of text in section 2.2 like:

     Responders MUST NOT respond to LLMNR queries for names they are
     not authoritative for.

   I think the LLMNR names could be characterized as simple character
   strings, and that LLMNR name comparisons could be characterized as a
   simple equality check (with application of DNS case-folding rules).

LLMNR also does not change how hosts determine their names
or how they handle DHCP options 12 and 15. Some hosts accept
DHCP assignment of names, others do not.

   RD> I wasn't thinking so much of DHCP specifically, I just used
   the DHCP options as examples of how a host might be configured with
   various names that would be used in the synthesis of LLMNR names.

In terms of the examples, it is not possible to encode a query
for "foo" or "foo.example.com" or "foo.example" using the DNS
packet format; only queries for "foo.", "foo.example.com."
or "foo.example." are possible. An LLMNR responder
will only respond to a query if it is authoritative for
that name. Whether the responder is configured to respond to queries
for "foo." or "foo.example.com." is implementation dependent.

   RD> OK, so before I read your response to issue 56, I wrote the
   following text as a suggestion for a new section to be added to
   section 2.  The idea is to give a clear example of what RRs an LLMNR
   responder might own, and where those RRs might be synthesized from.

     2.1 Resource record model and naming

     Each LLMNR responder conceptually maintains a set of records for which
     it is authoritative in response to LLMNR queries.  These records are
     similar to 'nodes', as defined in DNS (RFC 1034).  Each record has a
     name that acts as a key for the record, and owns one or more resource
     records (RRs).  The RRs are typed like DNS RRs.

     The records for which an LLMNR is authoritative may be constructed
     from information configured in the responder, or may be explicitly
     configured.  For example, a Windows 2000 host configured through the
     "System Properties" control panel to have computer name "host1" and to
     be a member of the "example.com" domain, and with IPv4 address
     10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
     authoritative for the following records:

     host1.	                IN A       10.1.1.1
			    IN AAAA    2001:0DB8::1:2:3:FF:FE:4:5:6

     host1.example.com.	IN A       10.1.1.1
			    IN AAAA    2001:0DB8::1:2:3:FF:FE:4:5:6

     1.1.1.10.in-addr.arpa.  IN PTR     host1.
			    IN PTR     host1.example.com.

     6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.inv6.arpa
			    IN PTR     host1.
			    IN PTR     host1.example.com

     An LLMNR responder might be further manually configured with the name
     of a local mail server with an MX RR included in the "host1" and
     "host1.example.com" records.

     An LLMNR responder is only authoritative for records that are directly
     related to the responder itself.

     Names in LLMNR are treated as a character string, with no internal
     structure.  Thus, the LLMNR name host1 is completely unrelated to
     host1.example.com. Comparisons between LLMNR names are simple equality
     tests, with case-folding according to the rules in DNS (RFC ???).

3. The term "authoritative" is used to refer to whether a host
responds to a query for a name.  The term "owned" is used to refer to
whether an RR is present on the responder. These are different things,
so the same term cannot be used. The term "has" is used synonymously
with "owned" and so the term "owned" can be substituted to improve
clarity.

   RD> Thanks for the clarification...

Proposed fixes:

   RD> The fixes all look OK, except where noted...

In Section 1, change:

"This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from the Domain Name System (DNS),
with a distinct resolver cache, but does not change the format of DNS
packets.  LLMNR supports all current and future DNS formats, types and
classes."

To:

"This document discusses Link Local Multicast Name Resolution (LLMNR),
which utilizes the DNS packet format for both requests and responses,
and supports all current and future DNS formats, types and classes.
LLMNR operates on a separate port from the Domain Name System (DNS),
with a distinct resolver cache."

Add to Section 2:

"This document does not specify how names are
chosen or configured. This may occur via any mechanism, including
DHCPv4 [RFC2131] or DHCPv6 [RFC3315]."

   RD> Perhaps also mention local synthesis and explicit configuration?
   "including synthesis from local configuration information such as
   the host name and default domain, configuration information obtained
   through DHCPv4 [RFC2131} or DHCPv6 [RFC3315], or explicit manual
   configuration."

Add to Section 2.1:

"An LLMNR query is composed in exactly the same manner
and with the same packet format as a
DNS query as specified in [RFC1035]."

Add to Section 2.2:

"A response to an LLMNR query is composed in exactly the same manner
and with the same packet format as a response to a
DNS query as specified in [RFC1035]."

Throughout the document: Change "has" to "owns" where the term refers to RRs.

Add the following definition to the terminology section:

"Owner

A host is said to be the owner of a Resource Record (RR) if it is configured
to respond to an LLMNR query for that RR."

Proposed resolution: Accept


--
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/>
[prev in list] [next in list] [prev in thread] [next in thread]