This page contains information on the Linklocal Multicast Name Resolution (LLMNR) protocol, including current status of the protocol specification and the list of open and resolved LLMNR Issues.
About the IETF DNSEXT WG
DNSEXT WG
Charter
DNSEXT Mailing
List Archives
Document status: Published as RFC 4795
LLMNR FAQ
LLMNR Frequently Asked Questions
Related work in IETF ZEROCONF WG
ZEROCONF WG
Charter
ZEROCONF WG Issues
List
ZEROCONF WG
Archives
IPv4 Linklocal
addressing specification
Open Issues List
A description in red implies that no issue has been submitted (if you are the owner of such a message, please send the LLMNR editors an issue). An asterix following an Issue number (e.g. Issue #666*) means that the issue entry is not up to date, and the author is expect to send additional text to LLMNR Editors .
To submit a new issue, send an e-mail to the DNSEXT WG Mailing list, using the following template. Please CC: the LLMNR editors list. .
Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Document: LLMNR-<version>
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem
Requested change:
Proposal
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
| IETF Last Call Comments
Issue Number |
Status | Type | Description | Owner |
Resolved Issues List
The following table contains the issues that have already been resolved, and the fix included in a revision of the specification.
The following are the long form versions of the issues:
Issue 1: Unqualified names
Submitter: Joshua
Graessley
Submitter email address: jgraessley@apple.com
Date first
submitted: November 1, 2002
Reference:
<CA805F88-EDEE-11D6-9333-000393760260@apple.com>
Document:
LLMNR-12
Comment type: T
Priority: S
Section:
6.2
Rationale/Explanation of issue:
In section 6.2, Usage
Restrictions:
> As noted in Section 3.1, LLMNR is intended for usage
in scenarios where
> a DNS server is not configured. If an interface has
been configured
> for
> a given protocol via any automatic
configuration mechanism which is
> able
> to supply DNS
configuration information, then LLMNR SHOULD NOT be used
> on that
interface for that protocol unless it has been explicitly
> enabled,
whether via that mechanism or any other. This ensures that
> upgraded
hosts do not change their default behavior, without requiring
> the source
of the configuration information to be simultaneously
> updated. This
implies that on the interface, the host will neither
> listen on the
LINKLOCAL multicast address, nor will it send queries to
> that
address.
If a multi-homed host is connected to a configured network and
an
unconfigured network, it may want to perform LLMNR to find hosts on the
unconfigured network. This conflicts with the security concerns that
suggest LLMNR should not be used. It is unclear if LLMNR could be used
in this case, but only for unqualified names. If LLMNR is supposed to
be
used only for unqualified names, how does one resolve conflicts
between an
unqualified name resolved via LLMNR and the fully qualified
name created by
appending the "current domain". This limits, in very
difficult to guess
ways, the names that could be used with LLMNR on the
unconfigured
link.
Example: My laptop has a wireless interface and an ethernet jack. I
may
have my ethernet jack connected to a network with a global IPv4 address
and a DNS server both of which I received from a DHCP server. The DHCP
server also told me that my current domain is "graessley.net". My
wireless interface may be used only to connect to an 802.11 printer
nearby. My printer may have a LLMNR name of "printer". Since I have a
configured DNS server and a current domain, my resolver library will
probably query "printer.graessley.net" before trying "printer". This
makes it impossible to find my printer by name. It is unclear what
names
I could use for the printer. Any host that connects wirelessly to
my printer
may search any number of other domains if the host is also
connected to
another network.
What am I overlooking?
-josh
[BA] I agree that the situation you present is problematic.
Below is a
proposed resolution.
Change section 3.1 to the following:
"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.
This is the behavior suggested by [RFC1536]. LLMNR
uses this technique
to resolve unqualified host names."
Proposed resolution: Accept
Issue 2: TTL=255 on Send, Check on
Receive?
Submitter: Christian Huitema
Submitter email address:
huitema@microsoft.com
Date first submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
Why is it necessary to set TTL=255 on Sending an LLMNR Response, and
then
to check this on receipt? All you really care about is that the
responder is
on the same link. That is enough.
[BA]
The issue here is how to limit LLMNR responses to hosts
on
the local link. Requests are not an issue because there
are either sent to a
linklocal multicast address or are
sent unicast.
It would appear
that Zeroconf WG is leaning toward eliminating
the TTL=255 on send, check on
receive requirement for IPv4
LL. However, LLMNR as an application can choose
to impose such
a requirement if it desires.
I do believe that
poisoning of the LLMNR cache is an issue
here, especially given the
likelihood of not receiving
a response to a DNS query and falling back to
LLMNR.
[BA] Here is the proposed resolution:
"2.4.
Addressing
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic
Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules
with respect to
source address selection, TTL settings, and
acceptable
source/destination address combinations. IPv6 is described in
[RFC2460];
IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries
and
responses MUST obey the rules laid out in these documents.
In
composing an LLMNR response, the responder MUST set the Hop Limit
field in
the IPv6 header and the TTL field in IPv4 header of the LLMNR
response to
255. The sender MUST verify that the Hop Limit field in IPv6
header and TTL
field in IPv4 header of each response to the LLMNR query
is set to 255. If it
is not, then sender MUST ignore the response.
Implementation
note:
In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL
socket
options are used to set the TTL of outgoing unicast and
multicast
packets. The IP_RECVTTL socket option is available on some
platforms
to retrieve the IPv4 TTL of received packets with
recvmsg().
[RFC2292] specifies similar options for setting and retrieving
the
IPv6 Hop Limit.
[BA] -
At IETF 56, the discussion seemed to indicate that sending with
TTL=255
and checking on receipt would "do no harm" so that it was ok. The
major
issues encountered in Zeroconf WG with IPv4LL don't seem to apply
here,
since there are no legacy LLMNR implementations out there that set TTL
to
something other than 255, so we have a clean slate. Also, even if
the
IPv4LL draft doesn't specify setting or checking of TTL, an
application
can still do so. So I'd like to recommend that we keep the
existing -14
text that mandates setting TTL=255 and checking
it.
Proposed Resolution: Accept
Issue 3: Unsafe queries
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
March 7, 2003
Reference:
Document: LLMNR-13
Comment type:
T
Priority: S
Section:
Rationale/Explanation of issue:
It seems unwise to send an LLMNR query for any name and RR if the DNS server
does not respond or
responds with NXRRSET.
In practice, no response
or NXRRSET will occur quite often, even if the DNS server is
functioning.
This is was shown by Jung, et al. "DNS Performance and
Effectiveness
of Caching", IEEE/ACM Transactions on Networking, October 2002,
Volume 10, Number 5, pp. 589-603.
For example, in the study 23 percent of
all client lookups were not answered in an MIT data set
collected in
December 2000. 13 percent of lookups result in an answer that indicates an
error.
Most of these errors indicate that the desired name does not exist
(NXDOMAIN). Inverse lookups
often cause errors, as do NS records that point
to nonexistent servers.
As a result, it seems unwise to fallback to an
LLMNR query for
any query, just because the DNS server doesn't answer, or
answers
with NXRRSET. My proposal is not to fallback to LLMNR for
any RR
query for a name that has a "." and is not in the default domain. In this
case
we aren't talking about a local machine name, or even a hostname that is
reasonably familiar.
It could be a name of an arbitrary host on the
Internet. We don't want to send LLMNR queries
for those names, since LLMNR
Responses are so easily spoofed. So only fallback to LLMNR
if the name has no
"." or is in the default domain.
Change Section 3 to the following:
"3. Usage model
LLMNR is a peer-to-peer name resolution protocol that
is not intended
as a replacement for DNS. By default, 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.
As noted in [DNSPerf], even when DNS servers are configured,
a
significant fraction of DNS queries do not receive a response, or
result
in a negative responses due to missing inverse mappings
or NS records that
point to nonexistent or inappropriate hosts.
Given this, support for LLMNR as
a secondary name resolution
mechanism has the potential to result in a large
number of
inappropriate queries without the following
additional
restrictions:
[1] If a DNS query does not receive a
response, prior to falling
back to LLMNR, the query SHOULD be retransmitted
at least
once.
[2] A sender SHOULD send LLMNR queries only for names
that are
either unqualified or exist within the default domain.
[3] A
responder with both linklocal and routable addresses
MUST respond only to
LLMNR queries for A/AAAA RRs for
the routable address. This encourages use of
the routable
address for establishment of new connections."
[Rob Austein]
This has some usability effects. What if me and my
friend are
on an airplane, with FQDNs, and want to communicate? We're
not
in the same domain and our hosts don't have unqualified names.
This
change doesn't support that scenario.
[BA]
The solution to this issue is for a host to have both an
unqualified and
qualified name. Your machine could be both "rob" and
"rob.example.com" for
the purposes of LLMNR.
[Christian Huitema]
The described restriction would still allow use of LLMNR for resolving
qualified domain
names that are not part of the local domain, in a situation
where there is no DNS server,
or where the DNS server is unreachable -- or
made unreachable by a DOS attack. OTOH, we
may debate whether this is really
an additional vulnerability; after all, it is already
possible to listen in
promiscuous mode, capture requests to the server, and send spoofed
responses
quickly. I guess we only have an additional functionality in switched
networks.
[BA]
The discussion at IETF 56 centered on how this would impact a typical
use
case: two users, one with machine bernarda.microsoft.com and another
with
randy.psg.com attempting to communicate over an adhoc network.
The
proposed change would not allow these two machines to resolve each
other's
name, since neither host exists within the other's "default
domain".
One possible solution to this would be for the two machines to
answer
queries for "bernarda" and "randy", rather than only answering queries
for
the FQDN. If this would work, then the proposed rule is ok as is.
Proposed Resolution: Accept
Issue 4: Introduction Unclear
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type:
T
Priority: S
Section:
Rationale/Explanation of issue:
The introduction is unclear that LLMNR is not a replacement for DNS.
Having the text explicitly say that LLMNR cannot be used
for
communication outside a single link would make sense.
Replace Section 1 with the following:
"1. Introduction
This document discusses Link-Local Multicast Name
Resolution (LLMNR),
which operates on a separate port from 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. However,
since
LLMNR only operates on the local link, it cannot be considered a
substitute for DNS.
The goal of LLMNR is to enable name resolution
in scenarios in which
conventional DNS name resolution is not possible. These
include
scenarios in which hosts are not configured with the address of a
DNS
server, where configured DNS servers do not reply to a query, or
where
they respond with RCODE set to NXRRSET.
LLMNR queries are sent
to and received on port TBD using a LINKLOCAL
address as specified in
"Administratively Scoped IP Multicast" [RFC2365]
for IPv4 and the "solicited
name" LINKLOCAL multicast addresses for
IPv6, and using a unicast address as
described in Section 2.3. The LLMNR
LINKLOCAL address to be used for IPv4 is
224.0.0.251. LINKLOCAL
addresses are used to prevent propagation of LLMNR
traffic across
routers, potentially flooding the network.
Propagation
of LLMNR packets on the local link is considered sufficient
to enable name
resolution in small networks. The assumption is that if a
network has a home
gateway, then the network either has a DNS server or
the home gateway can
function as a DNS proxy. By implementing DHCPv4 as
well as a DNS proxy and
dynamic DNS, home gateways can provide name
resolution for the names of hosts
over IPv4 on the local network.
For small IPv6 networks, equivalent
functionality can be provided by a
home gateway implementing DHCPv6 for DNS
configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and
dynamic DNS, providing name
resolution for the names of hosts over IPv6 on
the local network.
This should be adequate as long as home gateways
implementing DNS
configuration also support dynamic DNS in some
form.
In the future, LLMNR may be defined to support greater than
LINKLOCAL
multicast scope. This would occur if LLMNR deployment is
successful,
the assumption that LLMNR is not needed on multiple links
proves
incorrect, and multicast routing becomes ubiquitous. For example, it
is
not clear that this assumption will be valid in large adhoc
networking
scenarios.
Once we have experience in LLMNR deployment in
terms of administrative
issues, usability and impact on the network it will
be possible
reevaluate which multicast scopes are appropriate for use with
multicast
name resolution mechanisms.
Service discovery in general, as
well as discovery of DNS servers using
LLMNR in particular is outside of the
scope of this document, as is name
resolution over non-multicast capable
media."
Proposed Resolution: Accept
Issue 5: Jittering
Submitter: Christian
Huitema
Submitter email address: huitema@microsoft.com
Date first
submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type:
T
Priority: S
Section: 2
Rationale/Explanation of issue:
The specification does not require jittering of LLMNR Requests, and
is
vague on jittering of LLMNR Responses. This is can cause
synchronization
problems.
Insert the following text in Section 2:
"In order to avoid
synchronization of LLMNR queries and Responses, LLMNR
Requests and Responses
are delayed by a time uniformly distributed between
0 and 200 ms."
Proposed Resolution: Accept
Issue 6: IPv6 Multicast Groups
Submitter:
Mika Liljeberg
Submitter email address: mika.liljeberg@welho.com
Date
first submitted: March 8, 2003
Reference:
Document: LLMNR-13
Comment
type: T
Priority: S
Section:
Rationale/Explanation of issue:
Reading the draft I get the understanding that, in order to respond
to
reverse queries for IPv6 addresses, the host has to configure
the
following sixteen multicast addresses on each of its
interfaces:
FF02:0:0:0:0:2:MD5("0") .. FF02:0:0:0:0:2:MD5("F")
In
addition, a host may have multiple aliases (especially if it is
multihomed),
so the number of multicast groups that need to be
configured per inteface
could be close to twenty. This is clearly a
waste of multicast
filters.
It is unlikely (correct me if I'm wrong) that a NIC will support
this
many multicast filters in hardware, which means that the NIC will
have
to be configured to receive all multicasts and the filtering must
be
done in software. That pretty much defeats the purpose of having
the
hash based solicited name multicast addresses in the first
place.
It would seem much better to just have a single well-known
IPv6
link-local multicast address for reverse lookups. The alternative
would
seem to be to not support PTR queries at all for IPv6
addresses.
I leave it to the discretion of the editors to decide whether
this
should be formulated as an issue.
MikaL
Comment from Bill
Sommerfeld <sommerfeld@orchard.arlington.ma.us>:
I just took a look
at drivers for a few commonly used fast ethernet
chipsets, and found the
following limits:
- 80 literal multicast addresses
- 64-entry
hash.
- 128-entry hash.
- 256-entry hash.
- 512-entry hash.
The
"N-entry hash" variety maintain a N-bit vector, and run the
recieved
multicast address through a hash function with N possible
outputs; if the
corresponding bit in the vector is set, the packet is
received, so you get
more graceful degradation as the number of groups
increases at the cost of
slightly more false positives received.
MikaL: That's a pretty neat approach. The longer bit vectors sound good
enough,
although I still can't say that I like the idea of having to listen
to
16 different multicast groups just for doing PTR queries. [It would
be
possible to optimize this, of course, but that would force the
LLMNR
responder to actively monitor all changes in interface
configuration.]
One 802.11 card I looked at has a lower limits (16
literal addresses).
Another 802.11 card seems to have no multicast filtering
at all!
(though that may be an inadequate driver rather than a deficiency
in
the hardware/firmware).
MikaL: Needless to say, 802.11 and other
wireless interfaces would be a major
use case for LLMNR.
[BA] At IETF 56, the sentiment seemed to be for reducing the number
of
multicast groups used for IPv6. The proposed text uses multiple groups
for
A/AAAA queries, but a single group for all other queries. This
would
result in a host with a single name, but multiple addresses listening
on
only one multicast group for all the PTR RRs it has.
One question
is whether the scalability benefits of multiple groups is
worth the
complexity. In my mind, multiple groups do provide some scaling
benefits, but
only if the overall traffic load is low. If the problem
outlined in Issue 21
isn't addressed, I think we will have a scaling
problem for multiple groups
or a single group.
Opinions solicited.
[BA] During the LLMNR Issue Conference call of 4/16/03, it was
noted that
use of multiple multicast groups requires that
the name be canonicalized
prior to computing the hash to
determine what multicast group is to be used.
In the past,
canonicalization has been the source of issues, so
requiring
that it be done correctly is likely to result in interoperability
problems.
Also, each responder will need to listen both on
the
"node information" IPv6 multicast addresses used for
A/AAAA queries
as well as on the single multicast address
used for other queries. This
means that a sender could send to the
single multicast address that all
responders must listen on,
and it would work. Therefore, implementers
looking to simplify their
senders will choose only send to a single multicast
group.
Given that multiple multicast groups results in
interoperability
and is likely to be bypassed by implementers, the
recommended resolution is to use a single multicast group
with IPv6 as
well as IPv4.
In Section 1, Change:
"LLMNR queries are sent
to and received on port TBD using a link-scope
multicast address as specified
in "Administratively Scoped IP Multicast"
[RFC2365] for IPv4. The LLMNR
link-scope multicast address to be used
for IPv4 is 224.0.0.251. For IPv6,
the "solicited name" link-scope
multicast addresses are used for A/AAAA
queries, and a separate link-
scope multicast address TBD for all other
queries. Link-scope multicast
addresses are used to prevent propagation of
LLMNR traffic across
routers, potentially flooding the network; for details,
see Section 2.4.
In circumstances described in Section 2.3, LLMNR queries can
also be
sent to a unicast address."
To:
"LLMNR queries are sent
to and received on port TBD using a link-scope
multicast address as specified
in "Administratively Scoped IP Multicast"
[RFC2365] for IPv4. The LLMNR
link-scope multicast address to be used
for IPv4 is 224.0.0.251. For IPv6,
the LLMNR link-scope multicast
address is TBD. Link-scope multicast addresses
are used to prevent
propagation of LLMNR traffic across routers, potentially
flooding the
network; for details, see Section 2.4. In circumstances
described in
Section 2.3, LLMNR queries can also be sent to a unicast
address."
Change Section 2.4 from:
"The IPv4 link-scope multicast
address a given responder listens to, and
to which a sender sends all
queries, is 224.0.0.251. The IPv6 link-
scope multicast address a given
responder listens to, and to which a
sender sends A/AAAA queries, is formed
as follows: The name of the
resource record in question is expressed in its
canonical form (see
[RFC2535], section 8.1), which is uncompressed with all
alphabetic
characters in lower case.
The first label of the FQDN in
the query is then hashed using the MD5
algorithm, described in [RFC1321]. The
first 32 bits of the resultant
128-bit hash is then appended to the prefix
FF02:0:0:0:0:2::/96 to yield
the 128-bit "solicited name multicast address".
(Note: this procedure
is intended to be the same as that specified in section
3 of "IPv6 Node
Information Queries" [NodeInfo]). A responder that listens
for queries
for multiple names with different first labels will necessarily
listen
to multiple of these solicited name multicast
addresses.
"
To:
"The IPv4 link-scope multicast address a given
responder listens to, and
to which a sender sends all queries, is
224.0.0.251. The IPv6 link-
scope multicast address a given responder listens
to, and to which a
sender sends all queries, is TBD."
Section 6
from:
"This specification does not create any new name spaces for
IANA
administration. LLMNR requires allocation of a port TBD for both
TCP
and UDP. Assignment of the same port for both transports is
requested.
LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251)
that
has been previously allocated to LLMNR by IANA. It also
requires
allocation of a link scope multicast IPv6 address, for use with
queries
of types other than A/AAAA."
To:
"This specification
does not create any new name spaces for IANA
administration. LLMNR requires
allocation of a port TBD for both TCP
and UDP. Assignment of the same port
for both transports is requested.
LLMNR utilizes a link-scope multicast IPv4
address (224.0.0.251) that
has been previously allocated to LLMNR by IANA. It
also requires
allocation of a link-scope multicast IPv6 address."
Proposed Resolution: Accept
Issue 7: Advertisement of LL
addresses
Submitter: Erik Nordmark
Submitter email address:
erik.nordmark@eng.sun.com
Date first submitted: November 4,
2002
Reference:
<Roam.SIMC.2.0.6.1036349563.288.nordmark@bebop.france>
Document:
LLMNR-12
Comment type: T
Priority: S
Section:
Rationale/Explanation
of issue:
> Since automatic IPv6 DNS configuration mechanisms such as
[DHCPv6DNS]
> and [DNSDisc] are not yet widely deployed, and not all DNS
servers
> support IPv6, "partial configuration" may be common in the
short
> term, and LLMNR may prove useful in enabling linklocal name
resolution
> over IPv6. However, in the long term, IPv6 DNS configuration,
and DNS support
> over IPv6 will become more common so that LLMNR usage
will typically be
> restricted to adhoc networks in which neither IPv4 nor
IPv6 DNS servers are
> configured, and situations in which DNS servers do
not respond to queries."
The above doesn't speculate about a future where
names to global
addresses can be resolved using DNS, but names to
link-local
addresses can only be resolved using LLMNR.
The high-order
question is whether the LLMNR spec should speculate
about this future or
not.
[BA Comment]:
Currently, the draft doesn't state what addresses an LLMNR responder
will
include in its A/AAAA RR query response. Are you suggesting that it
should
respond *only* with a linklocal address?
[Erik Nordmark Comment]:
I'm suggesting that we don't know the answer to that question yet.
And the
draft, by saying that the applicability is likely to be
limited to adhoc
networks, says that we do know the answer to the question.
So leaving the
applicability a bit more open-ended might be useful.
Note that ideally
we'd use global addresses for all application use,
since limited scope
addresses can cause problems for applications.
But the thing I don't know is
whether this will always be sufficient
or whether there will be cases where
it makes sense to use LLMNR to
get a link-local address back even in cases
when the network is
connected to the Internet.
Erik
[BA comment]:
It seems unwise to advertise a LL address (IPv4 or IPv6) in an LLMNR Response
if a routable address is available. This will only encourage the querier to
contact the responder on the LL address.
Add the following text to section 4:
"[4] A responder with both linklocal and routable
addresses
SHOULD respond only to LLMNR queries for A/AAAA
RRs for
the routable address. This encourages use of the
routable
address for establishment of new
connections."
Proposed Resolution: Accept
Issue 8: Conflict resolution
Submitter: Mika
Liljeberg
Submitter email address: mika.liljeberg@welho.com
Date first
submitted: March 11, 2003
Document: LLMNR-13
Comment type: T
Priority:
S
Section: 5
Rationale/Explanation of issue:
Section 5
states:
Every responder that responds to a LLMNR query and/or dynamic
update
request AND includes a UNIQUE record in the
response:
1. MUST verify that there is no other host within
the scope of the
LLMNR query propagation that
can return a resource record
for the same
name, type and class.
2. MUST NOT include a UNIQUE resource
record in the
response without having verified
its uniqueness.
How does a responder know whether a particular RR that it
owns is UNIQUE
or not? Looks like this attribute has to be manually
configured for
every RR on every authoritative responder. Is this
interpretation
correct?
I suppose an implementation can simply choose
to not support cluster
names and just assert that every RR it owns is
UNIQUE.
MikaL
[BA] -
I believe that the default assumption is that the RR is
UNIQUE
unless it is configured otherwise. Add the following to
Section
4:
"By default, a host SHOULD be configured to behave as though
all
RRs are UNIQUE."
Proposed resolution: Accept
Issue 9: Dual stack implementation
issues
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type: T
Priority: S
Section:
2
Rationale/Explanation of issue:
In [this section] I see again some
confusion. Any DNS server either
over IPv6 or over IPv4 can serve BOTH IPv6
and IPv4
queries. It does not matter whether this server was
obtained
through DHCPv4 or DCHPv6 (or by any other means).
The
corollary to this is that enabling both IPv4 and IPv6
LLMNR on the same link,
means that you just have two
"nameservers" to choose, and a host (sender)
should be able
send query to either one (regardless of the query type:
A,
AAAA or PTR).
However, if it is expected that there are IPv4-only
or
IPv6-only hosts on the link, then it should send query to
both
"servers"? Does it send them in parallel or after
one
timeouts?
Proposed change: [From Bernard Aboba]
In section
2, change:
"network has a home gateway, then the network either has a DNS
server or
the home gateway can function as a DNS proxy. By implementing
DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can provide
name
resolution for the names of IPv4 hosts on the local network.
For
small IPv6 networks, equivalent functionality can be provided by a
home
gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a
DNS proxy supporting AAAA RRs and dynamic DNS, providing name
resolution for
the names of IPv6 hosts on the local network."
To:
"network has a
home gateway, then the network either has a DNS server or
the home gateway
can function as a DNS proxy. Home gateways can acquire
A records by
supporting DNS dynamic update, either by supporting
dynamic client update of
A RRs on the DNS proxy, or by supporting DHCPv4-based dynamic
DNS update
within the DNS proxy and DHCPv4 server implemented on the home gateway.
This
allows the home gateway to provide resolution of the names of IPv4
hosts
on the local network.
For small IPv6 networks, equivalent
functionality can be provided by a
home gateway acquiring AAAA records,
either by supporting dynamic client
update of AAA RRs on the DNS proxy, or by
supporting DHCPv6-based DNS update
between a DNS proxy and DHCPv6 server
implemented within the home gateway.
This allows the home gateway to provide
resolution of the names of IPv6
hosts on the local network. Hosts supporting
both IPv4
and IPv6 may send LLMNR queries over both IPv4 and IPv6 either in
serial
or in parallel, according to the
implementation."
Proposed resolution: Accept
Issue 10: Sending of NXRRSET
Submitter:
Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 2.5
Rationale/Explanation of issue:
"Since the responder MUST NOT respond to queries for names it is
not
authoritative for, a responder MUST NOT respond to an A, A6 or AAAA
RR
query with an NXRRSET. However, for other queries, such a response
is
possible; for example, if the host has a AAAA RR, but no MX RR, and
an
MX RR query is received."
Perhaps, better or additional example
would be "AAAA" and "A"
(instead of "AAAA" and "MX"): e.g. "if the host has a
AAAA RR,
but no A RR, and an A RR query is received" (or vice
versa).
Proposed change: [From Levon
Esibov]
Change:
"Since the responder MUST NOT respond to queries
for names it is not
authoritative for, a responder MUST NOT respond to an A,
A6 or AAAA RR
query with an NXRRSET. However, if the host has a AAAA RR, but
no MX RR,
and an MX RR query is received, the host would respond as
follows:
RCODE: NOERROR
Answer: <empty>
Authority: SOA for
zone.
Additional: Empty."
To:
"While the responder MUST NOT
respond to queries for names it is not
authoritative for, a responder MAY
respond to a query for the
name it is authoritative for, even if the type of
query does not
match a RR owned by the responder, with RCODE set to
NXRRSET.
For example, if the host has a AAAA RR, but no A RR,
and an A RR
query is received, the host would respond with
RCODE set to
NXRRSET."
Proposed resolution: Accept
Issue 11: Terminology
Submitter: Markku
Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 1.2
Rationale/Explanation of issue:
"1.2. Terminology
Responder A host that listens to (but not
necessarily responds to)
a LLMNR query is called "responder".
Sender A
host that sends an LLMNR query. The same host may be
configured as a
"sender", but not a "responder" and vice
versa, i.e. as a "responder", but
not a "sender"."
I thought the idea was that each host knows it's own
name and
address and is an authority on those. Thus each host must be
a
'responder'. But, if it cannot be 'sender' at same time, it
cannot query
any other names.
And if host is a 'sender', it cannot listen and respond
to
queries that match its name?
To me it seems that the most common
and useful configuration
would exactly be combined 'sender' + 'responder',
which seems
to be ruled out by above!
Proposed change [From Dave
Thaler]:
Change:
"Responder A host that listens to (but not
necessarily responds to)
a LLMNR query is called "responder".
Sender A
host that sends an LLMNR query. The same host may be
configured as a
"sender", but not a "responder" and vice
versa, i.e. as a "responder", but
not a "sender".
"
To:
"Responder A host that listens to LLMNR
queries, and responds to those
for which it is authoritative is called
"responder".
Sender A host that sends an LLMNR query. Typically a host
is
configured as both a sender and a responder, but a host may
be
configured as a "sender", but not a "responder" or a
"responder" but
not a "sender".
"
Proposed resolution: Accept
Issue 12: LLMNR Port
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
October 25, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 2, 2.2, 6.3, 7
Rationale/Explanation of
issue:
LLMNR currently operates on the same port as Apple's "Rendezvous" name
resolution
protocol. However, since these protocols are not compatible, this
is
inappropriate. The protocols also use the same multicast address for IPv4,
but
this is not an issue.
Proposal:
In section 2,
change:
"LLMNR queries are sent to and received on port 5353 using a
LINKLOCAL address..."
To:
"LLMNR queries are sent to and received
on port TBD using a LINKLOCAL address..."
In section 2.2,
change:
"A responder listens on port 5353 on the LINKLOCAL
address"
To:
"A responder listens on port TBD on the LINKLOCAL
address"
In section 6.3, change:
"LLMNR operates on a separate
port (5353) from DNS"
To:
"LLMNR operates on a separate port from
DNS"
In section 7, change:
"Since it uses a port (5353) and link
scope multicast IPv4 address (224.0.0.251)
previously allocated for use with
LLMNR,
no additional IANA allocations are required."
To:
"LLMNR
requires allocation of a port. LLMNR utilizes a link scope multicast
IPv4
address (224.0.0.251) that has been previously allocated to LLMNR
by
IANA."
Proposed resolution: Accept
Issue 13: Concatenation of
Responses
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type: T
Priority: S
Section:
2.5
Rationale/Explanation of issue:
The sender MUST anticipate
receiving multiple replies to the same LLMNR
query, in the event that several
LLMNR enabled computers receive the
query and respond with valid answers.
When this occurs, the responses
MAY first be concatenated, and then treated
in the same manner that
multiple RRs received from the same DNS server would,
ordinarily.
Concatenated? Isn't receiving multiple replies an
indication
of a conflict? Two hosts on the link use same name? At
least
for A and AAAA queries?
[Comment from Levon Esibov]:
It
is possible that there may be RRs owned by multiple responders, and
therefore
receiving multiple replies is not always evidence of a conflict.
Proposed resolution: Reject
Issue 14: LLMNR configuration
Submitter: Markku
Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 3.1
Rationale/Explanation of issue:
LLMNR
usage can be configured manually or automatically. On interfaces
where no
manual or automatic DNS configuration has been performed for a
given protocol
(IPv4 or IPv6), LLMNR SHOULD be enabled for that
protocol.
Again the
same confusion. DNS is not configured for single
interface. When a host finds
a DNS server address, it will
apply to ALL interfaces.
Thus, the
logical conclusion is: if host has "real" DNS server
address, then NONE of
the interfaces can have LLNMR. Or, you
have to accept the fact that in such
situation you have both
GLOBAL DNS and LLNMR applying to the same interface
and
specify sensible rules to deal with situation.
[NOTE: I do realise
there are such beasts as split DNS servers
or intranet local servers, but
handling these require some new
"namespace" concepts that are not present in
"standard
traditional" DNS semantics and resolver stubs.]
Proposed
change: [From Dave Thaler]
Change:
"LLMNR usage can be configured
manually or automatically. On interfaces
where no manual or automatic DNS
configuration has been performed for a
given protocol (IPv4 or IPv6), LLMNR
SHOULD be enabled for that
protocol.
For IPv6, the stateless DNS
discovery mechanisms described in "IPv6
Stateless DNS Discovery" [DNSDisc] or
"Using DHCPv6 for DNS
Configuration in Hosts" [DHCPv6DNS] can be used to
discover whether
LLMNR should be enabled or disabled on a per-interface
basis."
To:
"LLMNR usage can be configured manually or
automatically on a per interface
basis. By default, LLMNR SHOULD be enabled
as a secondary name resolution
mechanism, available for use when no manual or
automatic DNS configuration has
been performed, when configured DNS servers
do not respond, or when they
respond to a query with
NXRRSET."
Proposed Resolution: Accept
Issue 15: Dual stack LLMNR
configuration
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type: T
Priority: S
Section:
3.1
Rationale/Explanation of issue:
"Note that it is possible for
LLMNR to be enabled for use with IPv6 at
the same time it is disabled for
IPv4, and vice versa."
Yes, but this just means that you have "LLMNR"
over IPv4 or
IPv6. You can still use either to query A or
AAAA.
Proposed change: [From Dave Thaler]
Change:
"Note
that it is possible for LLMNR to be enabled for use with IPv6 at
the same
time it is disabled for IPv4, and vice versa. For example, a
home gateway may
implement a DNS proxy and DHCPv4, but not DHCPv6 for
DNS configuration
[DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In
such a circumstance,
IPv6 hosts will not be configured with a DNS
server. Where DHCPv6 is not
supported, the DNS proxy within the home
gateway will not be able to
dynamically register names learned via
DHCPv6. As a result, unless the DNS
proxy supports client dynamic
update, it will not be able to respond to AAAA
RR queries for local
names sent over IPv4 or IPv6, preventing IPv6 hosts from
resolving the
names of other IPv6 hosts on the local link. In this situation,
LLMNR
enables resolution of dynamic names, and it will be enabled for use
with
IPv6, even though it is disabled for use with
IPv4."
To:
"A home gateway may implement a DNS proxy and DHCPv4,
but not DHCPv6 for
DNS configuration [DHCPv6DNS]. In
such a circumstance,
IPv6-only hosts will not be configured with a DNS
server. Where the DNS proxy
does not support dynamic client update
over IPv6 or DHCPv6-based dynamic
update of the DNS proxy, the home
gateway will not be able to dynamically
register the names of
IPv6 hosts. As a result, the DNS proxy
will not be
able to respond to AAAA RR queries
sent over IPv4 or IPv6. This prevents
hosts from resolving the
names of IPv6-only hosts on the local link. In this
situation,
LLMNR over IPv6 can be used for resolution of dynamic
names."
Proposed resolution: Accept
Issue 16: Conflict resolution
Submitter:
Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 5
Rationale/Explanation of issue:
Where a
host is configured to respond to LLMNR queries on more than one
interface,
the host MUST verify resource record uniqueness on each
interface for each
UNIQUE resource record that could be used on that
interface.
LLMNR is
"LINK LOCAL MULTICAST NAME RESOLUTION". I think all
text about synchronizing
the names across links
should be removed.
Each link should have it's
own independent LLMNR cache.
Proposed change: [From Dave
Thaler]
In Section 5, Change:
"Where a host is configured to
respond to LLMNR queries on more than one
interface, the host MUST verify
resource record uniqueness on each
interface for each UNIQUE resource record
that could be used on that
interface."
To:
"Where a host is
configured to respond to LLMNR queries on more than one
interface, each
interface should have its own independent LLMNR cache.
For each UNIQUE
resource record in a given interface's cache,
the host MUST verify resource
record uniqueness on that interface."
In Section 6.3, change:
"In
order to prevent responses to LLMNR queries from polluting the DNS
cache,
LLMNR implementations MUST use a distinct, isolated cache for
LLMNR. The use
of separate caches is most effective when LLMNR is used
as a name resolution
mechanism of last resort, since the this minimizes
the opportunities for
poisoning the LLMNR cache, and decreases reliance
on
it."
To:
"In order to prevent responses to LLMNR queries from
polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated
cache for
LLMNR on each interface. The use of separate caches is most
effective when LLMNR is used
as a name resolution mechanism of last resort,
since the this minimizes
the opportunities for poisoning the LLMNR cache, and
decreases reliance
on it."
Proposed Resolution:
Accept
Issue 17: Another conflict resolution
issue
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type: T
Priority: S
Section: 5,
2.1
Rationale/Explanation of issue:
- multiple hosts may respond to a
query for a SRV type record
- multiple hosts may respond to a query for an A
type record for a
cluster name (assigned to multiple hosts in the
cluster)
- only a single host may respond to a query for an A type record
for
a hostname.
When querying a name and getting multiple replies, how
does
host know whether name was "hostname" or "cluster name"?
Each
"...for an A type..." in above should be replaced with
text "...for an A or
AAAA type..."
Proposed change: [From Bernard Aboba]
In Section 5,
Change:
"
- multiple hosts may respond to a query for a SRV type
record
- multiple hosts may respond to a query for an A type record for
a
cluster name (assigned to multiple hosts in the cluster)
- only a single
host may respond to a query for an A type record for
a
hostname."
To:
"
- multiple hosts may respond to a query for an
SRV type record
- multiple hosts may respond to a query for an A or AAAA type
record for a
cluster name (assigned to multiple hosts in the cluster)
-
only a single host may respond to a query for an A or AAAA type record for
a
hostname."
In Section 2.1, Change:
"If the LLMNR query is not
resolved during a limited amount of time
(LLMNR_TIMEOUT), then a sender MAY
repeat the transmission of a query
in order to assure themselves that the
query has been received by a host
capable of responding to the query. The
default value for LLMNR_TIMEOUT
is 1 second."
To:
""If the
LLMNR query is not resolved during a limited amount of time
(LLMNR_TIMEOUT),
then a sender MAY repeat the transmission of a query
in order to assure
themselves that the query has been received by a host
capable of responding
to the query. The default value for LLMNR_TIMEOUT
is 1 second. Since a sender
cannot know beforehand whether it will receive
no response, one response, or
more than one response to a query, it
SHOULD wait for LLMNR_TIMEOUT in order
to collect all possible responses,
rather than considering the query answered
after the first response is received."
Proposed Resolution:
Accept
Issue 18: Confusion on dual stack
behavior
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type: T
Priority: S
Section:
1
Rationale/Explanation of issue:
I may have other comments later, but
first this: the introduction
contains a paragraph:
Since IPv4 and IPv6
utilize distinct configuration mechanisms, it
is possible for a dual stack
host to be configured with the address
of a DNS server for IPv4, while
remaining unconfigured with a DNS
server suitable for use with IPv6.
...
I think this contains a fundamental misunderstanding how
a
nameresolving on the dual stack host works.
If a dual stack host has
even one DNS server address (either IPv4 or
IPv6), it can be used for both
IPv4 (A) and IPv6 (AAAA) queries.
It makes no difference how this DNS
server address was obtained
(/etc/resolv.conf, DHCP, DHCPv6 or
whatever).
Proposed Change: [From Bernard
Aboba]:
Change:
"Since IPv4 and IPv6 utilize distinct
configuration mechanisms, it
is possible for a dual stack host to be
configured with the address
of a DNS server for IPv4, while remaining
unconfigured with a DNS
server suitable for use with
IPv6."
To:
"While IPv4 and IPv6 utilize distinct configuration
mechanisms, dual
stack hosts share configuration, so that if a dual stack
host has
been configured with the address of a DNS server over IPv4, both A
and
AAAA queries will be sent to that server over
IPv4."
Proposed Resolution: Accept
Issue 19: LLMR usage
Submitter: Markku
Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: July 26, 2002
Reference:
Document: LLMNR-12
Comment type:
T
Priority: S
Section: 6.2
Rationale/Explanation of
issue:
Having read and commented on
<draft-ietf-dnsext-mdns-11.txt>, I think
we might need a "Scoped name
resolution reference model" or something,
that specifies the framework for
handling overlapping situations.
- we have "traditional" global DNS
-
we have this new Link Local Name resolution
- we may have site local name
resolution
The <draft-ietf-dnsext-mdns-11.txt> includes some text
about not
having global DNS and LLMNR active at same time.
This
assumption requires highly special conditions (a closed meeting
room without
any outside network connections, permanently isolated
network segments). In
normal practise I would claim most useful ad hoc
networks (bluetooth, wlan..)
will also have occasional access to the
global internet and thus global
DNS.
There is a need to accept situation where a node can
- has
neither LLMNR nor global DNS
- has LLMNR (on at least one link)
- has
global DNS
- has both LLMNR and global DNS
and node can transition
between these states unpredictably. Then add
possible site local DNS into
this soup...
It should be noted that LLMNR is somewhat different
"taxonomically"
from global DNS. LLMNR is P2P, global DNS is
peer-to-server.
One could consider P2P on site-local level (SLMNR?)
or
peer-to-server. How\about global P2P name resolution, based on
global
multicast (yeah, does not scale? Unless you have IPsec
protected multicast
group, and only limited membership :-)
The reference model should tell
how an enviroment that has
multiple enclosing name resolutions
behaves:
- which order are queries sent (global -> site - > local
or local ->
site - > global, or something else?)
- are queries
sent in parallel or one at time
- how are conflicts handled (at least
each level must have own cache,
and each LLMNR must be cached separately per
interface) [you can use
<scopelevel, scope-id> from IPv6 scoped
addressing architecture as
cache id, for example]
- if there are
multiple LLMNR interfaces, how are queries handled?
(send queries in parallel
to all?)
- can LLMNR contain only link local addresses in A and AAAA?
Should
name already tell the scope? Eg. only "*.local" names are
resolved
with LLMNR? "*.site"? Or can, any name "foo.bar.com" or
address
appear in any of the levels and you just get what is first
found
based on the search order?
- what happens when some name
resolution level becomes reachable or
unreachable?
Proposed Change:
[From Bernard Aboba]
In Section 1, change:
"The goal of LLMNR is
to enable name resolution in scenarios in which
conventional DNS name
resolution is not possible. These include
scenarios in which hosts are not
configured with the address of a DNS
server.
Since IPv4 and IPv6
utilize distinct configuration mechanisms, it is
possible for a dual stack
host to be configured with the address of a
DNS server for IPv4, while
remaining unconfigured with a DNS server
suitable for use with IPv6. Since
automatic IPv6 DNS configuration
mechanisms such as [DHCPv6DNS] and [DNSDisc]
are not yet widely
deployed, such "partially configuration" may be common in
the short
term. However, in the long term, IPv6 DNS configuration will become
more
common so that LLMNR will typically be restricted to adhoc networks
in
which neither IPv4 nor IPv6 DNS servers are
configured."
To:
"The goal of LLMNR is to enable name resolution
in scenarios in which
conventional DNS name resolution is not possible. These
include
scenarios in which hosts are not configured with the address of a
DNS
server, where configured DNS servers do not reply to a query, or
where
they respond with RCODE set to NXRRSET.
Since IPv4 and IPv6 utilize
distinct configuration mechanisms, it is
possible for a dual stack host to be
configured with the address of a
DNS server over IPv4, while remaining
unconfigured with a DNS server
suitable for use over IPv6. In these
situations, a dual stack host
will send AAAA queries to the configured DNS
server over IPv4. However,
an IPv6-only host will not be able to resolve
names.
Since automatic IPv6 DNS configuration mechanisms such as
[DHCPv6DNS]
and [DNSDisc] are not yet widely deployed, and not all DNS
servers
support IPv6, "partial configuration" may be common in the
short
term, and LLMNR may prove useful in enabling linklocal name
resolution
over IPv6. However, in the long term, IPv6 DNS configuration, and
DNS support
over IPv6 will become more common so that LLMNR usage will
typically
be restricted to adhoc networks in which neither IPv4 nor IPv6 DNS
servers
are configured, and situations in which DNS servers do not respond to
queries."
In Section 2, change:
"Propagation of LLMNR packets on
the local link is considered sufficient
to enable name resolution in small
networks. The assumption is that if a
network has a home gateway, then the
network either has a DNS server or
the home gateway can function as a DNS
proxy. By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home
gateways can provide name
resolution for the names of IPv4 hosts on the local
network.
For small IPv6 networks, equivalent functionality can be
provided by a
home gateway implementing DHCPv6 for DNS configuration
[DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS,
providing name
resolution for the names of IPv6 hosts on the local
network.
This should be adequate as long as home gateways implementing
DNS
configuration also support dynamic DNS in some form. If the
home
gateway only supports DNS discovery [DNSDisc] but not DHCPv6
DNS
configuration [DHCPv6DNS] or dynamic client update, then resolution
of
the names of IPv6 hosts on the local link will not be possible.
Since
IPv6 DNS discovery will configure the DNS server address, LLMNR will
not
be enabled by default. Yet without gateway support for client
dynamic
update or DHCPv6, dynamic DNS will not be
enabled."
To:
"Propagation of LLMNR packets on the local link is
considered sufficient
to enable name resolution in small networks. The
assumption is that if a
network has a home gateway, then the network either
has a DNS server or
the home gateway can function as a DNS proxy. By
implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can
provide name
resolution for the names of hosts over IPv4 on the local
network.
For small IPv6 networks, equivalent functionality can be
provided by a
home gateway implementing DHCPv6 for DNS configuration
[DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS,
providing name
resolution for the names of hosts over IPv6 on the local
network.
This should be adequate as long as home gateways implementing
DNS
configuration also support dynamic DNS in some form."
In Section
3.1.1, change:
"It is possible that DNS servers and/or DNS configuration
mechanisms will
go in and out of service. In these circumstances, it is
possible for
hosts within an administrative domain to be inconsistent in
their DNS
configuration.
For example, where DHCP is used for
configuring DNS servers, one or more
DHCP servers can go down. As a result,
hosts configured prior to the
outage will be configured with a DNS server,
while hosts configured
after the outage will use LLMNR. When the DHCP server
comes back online,
it is desirable that unconfigured hosts obtain their
configuration from
it.
Alternatively, it is possible for the DNS
configuration mechanism to
continue functioning while the configured DNS
servers fail. In this
circumstance, it may be desirable for administrators to
be able to
reconfigure hosts to utilize alternative DNS servers.
In
order to minimize inconsistencies, the following practices
are
recommended:
Periodic retry
Unless unconfigured hosts
periodically retry configuration, an
outage in the DNS configuration
mechanism will result in hosts
continuing to use LLMNR even once the outage
is repaired. Since
LLMNR only enables linklocal name resolution, this
represents an
unnecessary degradation in capabilities. As a result, it
is
recommended that hosts without a configured DNS server
periodically
attempt to obtain DNS configuration. The recommended default
retry
interval is 30 seconds.
DNS failover
For security reasons, by
default LLMNR is not enabled for the
resolution of FQDNs where a DNS server
has been configured. This
implies that where a DNS server has been
configured, LLMNR will not
be used by default for resolution of FQDNs, even
in the event that
all configured DNS servers fail. In this circumstance, it
may
desirable for hosts to retry DNS configuration, so as to
discover
alternative DNS servers, if they are available. If
the
configuration mechanism does not respond, hosts MAY enable
LLMNR.
However, if the configuration mechanism merely configures
non-
functioning DNS servers, this is not sufficient reason to
enable
default LLMNR usage, without an explicit indication that
LLMNR
usage is desired."
To:
"It is possible that DNS servers
and/or DNS configuration mechanisms will
go in and out of service. In these
circumstances, it is possible for
hosts within an administrative domain to be
inconsistent in their DNS
configuration.
For example, where DHCP is
used for configuring DNS servers, one or more
DHCP servers can go down. As a
result, hosts configured prior to the
outage will be configured with a DNS
server, while hosts configured
after the outage will
not.
Alternatively, it is possible for the DNS configuration mechanism
to
continue functioning while configured DNS servers fail.
In order to
minimize inconsistencies, the following practices
are
recommended:
Periodic retry
Unless unconfigured hosts
periodically retry configuration, an
outage in the DNS configuration
mechanism will result in hosts
continuing to prefer LLMNR even once the
outage is repaired. Since
LLMNR only enables linklocal name resolution, this
represents an
unnecessary degradation in capabilities. As a result, it
is
recommended that hosts without a configured DNS server
periodically
attempt to obtain DNS configuration. A default retry interval
of
two (2) minutes is recommended.
DNS failover
By default, LLMNR
queries are not sent unless configured DNS
servers have not responded.
However, where all configured DNS
servers fail, LLMNR queries will be
sent."
In Section 6, change:
"LLMNR is by nature a peer to peer
name resolution protocol, for use in
situations when a DNS server is not
configured. It is therefore
inherently more vulnerable than DNS, since
existing DNS security
mechanisms are difficult to apply to LLMNR and an
attacker only needs to
be misconfigured to answer an LLMNR query with
incorrect information."
To:
"LLMNR is by nature a peer to peer
name resolution protocol.
It is therefore inherently more vulnerable than
DNS, since existing DNS security
mechanisms are difficult to apply to LLMNR
and an attacker only needs to
be misconfigured to answer an LLMNR query with
incorrect information."
In Section 6.2, change:
"As noted in
Section 3.1, LLMNR is intended for usage in scenarios
where a DNS server is
not configured. If an interface has been configured
for a given protocol via
any automatic configuration mechanism which is
able to supply DNS
configuration information, then LLMNR SHOULD NOT
be used on that interface
for that protocol unless it has been explicitly
enabled, whether via that
mechanism or any other. This ensures that
upgraded hosts do not change their
default behavior, without requiring
the source of the configuration
information to be simultaneously updated.
This implies that on the interface,
the host will neither listen on the
LINKLOCAL multicast address, nor will it
send queries to that address.
Violation of this guideline can
significantly increases security
vulnerabilities. For example, if an LLMNR
query were to be sent
whenever a DNS server did not respond in a
timely
way, then an attacker could execute a denial of service attack
on
the DNS server(s) and then poison the LLMNR
cache by responding to the
resulting LLMNR queries with incorrect
information. The vulnerability would
be even
greater if LLMNR is given higher priority than DNS among the
enabled
name resolution mechanisms. In such a
configuration, a denial of
service attack on the DNS server would not
be necessary in order to poison
the LLMNR
cache, since LLMNR queries would be sent even when the DNS server
is
available. In addition, the LLMNR cache,
once poisoned, would take
precedence over the DNS cache, eliminating
the benefits of cache separation.
As a result,
LLMNR is best thought of as a name resolution mechanism of last
resort,
useful only in situations where a DNS server
is not configured.
Where resilience against DNS server failure is
desired, configuration of
additional DNS servers or
DNS server clustering is recommended; LLMNR is not
an appropriate
"failsafe" mechanism."
To:
"As noted in Section
3.1, LLMNR is intended for usage in scenarios
where a DNS server is not
configured or DNS servers do not respond to
queries. If an interface has been
configured via any automatic
configuration mechanism which is able to supply
DNS configuration
information, then LLMNR MUST NOT be used as the primary
name
resolution mechanism on that interface, although it MAY be used
as a
secondary mechanism when DNS servers do not respond to queries.
Note:
enabling LLMNR for use in situations where a DNS server has been
configured
will result in upgraded hosts changing their default
behavior without a
simultaneous update to configuration information.
Where this is considered
undesirable, LLMNR SHOULD NOT be enabled by
default, so that hosts will
neither listen on the
LINKLOCAL multicast address, nor will it send queries
to that address.
Use of LLMNR as a secondary name resolution
mechanism
increases security vulnerabilities. For example, if an
LLMNR
query wis sent whenever a DNS server does not respond in a
timely
way, then an attacker can execute a denial of service attack on
the
DNS server(s) and then poison the LLMNR cache by responding
to the resulting
LLMNR queries with incorrect information.
The vulnerability is more
serious if LLMNR is given higher priority
than DNS among the enabled name
resolution mechanisms. In such a
configuration, a denial of service attack on
the DNS server would not
be necessary in order to poison the LLMNR cache,
since LLMNR queries
would be sent even when the DNS server is available. In
addition,
the LLMNR cache, once poisoned, would take precedence over
the
DNS cache, eliminating the benefits of cache separation. As a
result,
LLMNR is best thought of as a secondary name resolution
mechanism."
Proposed Resolution: Accept
Issue 20: Unqualified names
Submitter: Joshua
Graessley
Submitter email address: jgraessley@apple.com
Date first
submitted: November 1, 2002
Reference:
<CA805F88-EDEE-11D6-9333-000393760260@apple.com>
Document:
LLMNR-12
Comment type: T
Priority: S
Section:
3
Rationale/Explanation of issue:
I've read through the latest LLMNR
draft and a few things are unclear
to me.
In section 3, Usage Model,
an implicit search order for unqualified
names is given. This search order
suggests appending the "current
domain" and then querying for the
unqualified name:
> [1] Request the name with the current domain
appended.
> [2] Request just the name.
It goes on to
say:
> The same host MAY use LLMNR queries for the resolution of
unqualified
> host names, and conventional DNS queries for resolution of
other DNS
> names.".
How does one discern the difference between
an unqualified name and a
top level domain name? If someone wants to query
for "com", should that
be sent using conventional DNS or LLMNR? Are we
changing the semantics
of the APIs to require all top level domains to be
specified as a fully
qualified name (i.e. "com." instead of "com")?
[Comment from Derek Atkins <derek@ihtfp.com>]:
Qualified names
end with a ".", i.e. "com." or "org." or "." (for the root).
Unqualified
names do NOT end with a .
Note, however, this this is irrelevant. LLMNR
is just another
naming service, different from DNS as much as NIS/YP is
diferent
from DNS, which is just as different as
/etc/hosts.
-derek
What is a "current domain". It is possible for a host to have multiple
interfaces with separate configurations. Is the "current domain" a list
of domains to be searched when an unqualified name is specified? This
list can come from DHCP or be manually entered. If DHCPv4 and DHCPv6
are
in use, there could be conflicts? This is a little off topic, but
the point
is that a user may not have a lot of control over the domain
names appended
to unqualified names. At the very least, there are a lot
of sources of a
"current domain" or current domains.
Proposed Resolution: Reject
Issue 21: PTR queries
Submitter: Markku
Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: November 4, 2002
Reference:
<200211041445.QAA12218@burp.tkv.asdf.org>
Document: LLMNR-12
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
I assume that if you end up doing a address (fe80::1) to name query
for
IPv6, you end up sending a query to IPv6 multicast address
generated from the
hash of
"1.0.0. ... 0.0.8.e.f.ip6.int"
and because the hash is
taken from the first label, this will be MD5
from "1"? (basically only 16
different hashes are possible).
IPv4 side you have for example
"1.2.254.169.in-addr.arpa".
Am I right assuming the "resolvers" on nodes
have to deal also with
these for link local name resolution?
[BA] Yes, it is expected that senders will send PTR
queries, and that
receivers will respond to them.
However, it probably doesn't make sense to
send a
PTR query for an address that isn't on the local
link. Here's the
proposed resolution:
Add the following text to Section 3:
"[4] A
sender SHOULD only send LLMNR queries for PTR RRs that
represent addresses
known to be "on link" as defined in Section 2.5."
[Erik Guttman and Erik Nordmark]:
The problem is that in practice a
host may not know the
prefixes in use on a particular link. So this
restriction
can't work in practice.
[Comment from Mark T. Hollinger <MyTH@ucx.lkg.dec.com>]:
I think
we are being too hasty to throw out this restriction. As I
metioned in my
recent Namedroppers post, supporting your original proposal
for issue #3, I
would like the fallback to LLMNR not to occur at all for
apparently non-local
prefixes.
If there is a prefix on your link that you don't know about via
your routing
table, then I don't think LLMNR needs to handle inverse queries
for that
zone. The target user for LLMNR probably won't have multiple
unadvertised
global prefixes in the first place. Anybody sophisticated enough
to set
that up will already have the address of a DNS server
configured.
Also, if you don't know about the other guy's prefix, he may
not know about
yours either, in which case he'll get your multicast request
but try to send
a unicast response via the router, which may decrement the
TTL when
forwarding it back onto the same link. I'm not sure LLMNR will work
in this
case (due to the TTL 255 check), but even if it works, I think
a
configuration where hosts have to communicate (even only initially) via
a
router is out-of-scope for LLMNR. Let traditional DNS handle that case;
we
don't need LLMNR there.
[BA]
Back of the envelope calculations seem to indicate to me
that
bogus PTR queries can be a significant problem in some cases.
Measurements
show that a significant fraction of DNS queries are not
answered, and this is
particularly true with PTR queries. So we can have a
substantial amount of
bogus LLMNR PTR query traffic. I am particularly
worried about wireless
networks with lots of people like at IETF 56. 5
queries a second from
3000 people would end up eating up a significant
fraction of the total
bandwidth of an 802.11 network, particularly if there
are lots of folks
who have to step down to lower rates (1,2,5 Mbps). So there
is some reason
for concern.
In the discussion at IETF 56, there was
concern that it might not be
possible for a host to know all the networks it
was connected to. The
question then arises as to whether it is ok not to send
a PTR query for
addresses on networks the host doesn't know about. It was
pointed out that
if the host doesn't have a route for that address, then it
will route the
packet to the gateway, which might not have a route for it
either.
In view of the proposed resolution to Issue 28 and 29, it
would
appear that it makes little sense to send queries for PTR RRs
that
aren't "on link".
Comment from Mika Liljeberg <mika.liljeberg@welho.com>:
It's
true that the route search is constrained to a single interface but
this does
not essentially simplify the next hop selection algorithm. A
full route
search is still required to do on-link determination (unless
you make some
severe assumptions about the kind of routes that can lead
to a specific
physical interface).
> Perhaps looking at some examples may help make
sense of this.
Ok. I think your example addresses a different case from
the one
discussed in issue 21 (PTR queries), but let's look at the
example
first.
> Let us
> assume that Myhost is attached to
two networks, A and B, and that it is
> talking to host [1] on net A and
host [2] on net B.
>
> net B ----------
---------- net A
>
| | |
|
> [2] [myhost]
[1]
>
> Host [1] sends an LLMNR A/AAAA RR query for
"myhost". Should myhost
> respond with A/AAAA RRs for addresses on net B?
This would be bad
> if host [1] only has a LL address, since it would not
be able to
> reach net B. So I think it makes sense for myhost to only
respond
> with addresses on the interface from which the query
came.
Right. Issue 29 clarifies this. I agree with the proposed
resolution.
> So far so good. However, the question is "what if myhost
does the wrong
> thing?"
I don't think the multihomed and broken
[myhost] is a very common case
but otherwise I agree with what you
say:
> This is harder because host [1] may not have network B in
its
> routing table. It therefore will not know how to reach network B.
Since
> the point of LLMNR is to allow link-local name resolution, if host
[1]
> doesn't know how to reach net B on the local link then RRs
containing that
> address are not useful.
Agreed. To weed out the
unusable address, the LLMNR resolver on [1]
should somehow check whether
there is a route to it. On many operating
systems you can do this by
attempting to connect a UDP socket to the
destination address. If there is no
route, the connect() syscall will
fail.
Note that having a route to a
destination is not the same thing as
knowing that the destination is
on-link.
> Perhaps the right thing to do here is to say that
"addresses that are
> reachable on the local link are preferred" by host
[1].
The LLMNR resolver doesn't *know* which addresses are on-link, so
it
can't prefer them.
> That way, if
> myhost only returned
an address on network B, host [1] can try to connect
> to that, possibly
without success. But since there is no choice, what harm
> can it
do?
By host [1] do you mean the LLMNR responder of host [1] or
the
application running on host [1]?
The LLMNR resolver can, on many
operating systems, check the existence
of a route (e.g. by doing a UDP
connect() to the address). However, what
it *cannot* do (as far as I can
see), is check whether the destination
address is on-link.
In IPv6 the
DNS resolver is already required to prefer reachable
addresses as part of
default address selection [RFC3484].
> Another question is what
happens if myhost attempts to connect to host
> [1], using a source
address on net B.
The only way this can happen is if a) [myhost] is badly
broken, or b)
[myhost] uses the Weak ES model [RFC1122] and the addresses in
question
are not link-locals. [zeroconf] forbids Weak ES model for
link-locals.
> In this case host [1] may attempt to
> send a PTR
RR query using LLMNR, for the address on net B. In this case,
> myhost
might respond to the query with the name myhost which is valid
> on the
interface. No harm is done. However, one might argue that
> host [1]
should not send such a query, and that if received,
> myhost should not
respond to it.
The more realistic example, the one which I thought was
being discussed
in the context of issue 21, is the following:
Internet ---------- ---------- net
A
| | |
|
[2]
[router] [1]
Host [2] is not in the global DNS. It
connects to host [1], which tries
to make a PTR query to DNS with the address
of [2]. [1] receives no
response from DNS (whatever the reason) and falls
back on LLMNR. LLMNR
naturally fails as well.
As you say, no harm is
done, but it would nice to skip the unnecessary
LLMNR query. I agree with the
intent. I just don't see a good way to
actually implement
it.
MikaL
[BA] How about this?
Add the following text to Section 3:
"[4] A sender SHOULD only send LLMNR
queries for PTR RRs
that represent addresses reachable through the link
over which LLMNR is used."
Proposed Resolution: Accept
Issue 22: Bring back "local.arpa"
Submitter:
Itojun
Submitter email address: itojun@iijlab.net
Date first submitted:
September 15, 2002
Reference:
<20020913135833.C489B4B23@coconut.itojun.org>
http://www.merit.edu/mail.archives/zeroconf/msg00604.html
Document:
LLMNR-11
Comment type: T
Priority: S
Section:
Rationale/Explanation
of issue:
[BA]The following exchange related to the removal of the
"local.arpa"
restriction. It is reproduced here so that
these arguments will not need to
be rehashed at a later
time.
itojun:
>if there's no intent to support use of DNS names or DNS-like
names,
>and the group is willing to NOT overload existing name lookup
APIs,
>I'd like that to be stated explicitly and up-front. it
simplifies
>a number of problems, but it also makes zeroconf incompatible
with
>existing programs - so I have my doubts that this is the
intent.
then why "local.arpa" was removed from mDNS/LLMNR document?
indicators
like "local.arpa" or "local" (used by Apple Rendezvous) is a
good
indication of different name space.
kre: No, mangling the names is a poor way to indicate different name
spaces.
And that's for much the same reasons that my suggestion to stick
the
scope id of IPv6 limited scope addresses (LL & SL) inside the
address
itself (as part of the API) was rejected (and I agree now, rightly
so).
itojun: then how can we differentiate mDNS/LLMNR name and DNS name
under
the same API (getaddrinfo/getnameinfo)?
eric hall: LLMNR names are not DNS names. They are not authoritative for the
same
namespaces, and they shouldn't be mixed.
How do you already
multiplex DNS/NetBIOS/NIS/etc under a single API? Why
should this be
different?
itojun: i don't quite parse it. are you against the use of local.arpa,
or
are you for the use of local.arpa?
DNS and NIS names (and /etc/hosts)
are accessed via single API
(gethostby*, getaddrinfo/getnameinfo), so it
makes sense to use
the same API.
erik nordmark: One could envision new flags (such as AI_LLMNR) for lookups in
the local
name space.
itojun: that is certainly one possibility,
but why do we need it when we don't
have AI_NIS? AI_LLMNR removes
transparency (of LLMNR) to the
application.
kre: We don't really. We also don't need .local.arpa (or .local or
whatever)
just as we don't have .nis.arpa or .nis (or whatever) (nor do we
have a
hosts.arpa or a .hosts or anything else for any other kind of
hostname
lookup that might exist).
We already have disjointed
namespaces, all considered equal, where a
name lookup gets satisfied by one
(seemingly at random, but actually as
configured for the node's lookup
order). Adding one more name lookup
mechanism changes nothing. Most nodes are
going to do DNS lookups first
(or attempt them), and then if there is no DNS
server, or it fails, fall
back to whatever lookup mechanism suits (some sites
prefer to insert some
locally configured names ahead of the DNS - I doubt
doing that for
a local multicast lookup would ever make sense).
derek atkins: Note that applications try the various naming services until it
finds
a match (using some locally-defined ordering). The fact that
there
may be name overlaps is irrelevant. If I'm searching NIS before
DNS
and there is a NIS-MAP that provides a response for host.foo.com,
my
application will use that response rather than searching DNS.
I
don't see why LLMNR should behave any differently.
aidan williams: So you would be happy with a LLMNR lookup succeeding
for
"http://www.ietf.org/"? Should what is
returned bear any relationship at all to
what might be returned by a DNS
lookup of the same name?
(without some magic, I can't see how)
Should
an application be able to tell the difference
between something answered by
the DNS and something
answered by LLMNR?
(unless there a different API, or
something like a
well known domain suffix, I can't see how)
One of the
differences between the DNS/NIS/whatever
name service examples and LLMNR is
that there is a server
that is "more trusted" than "just any old host that
happens
to be within earshot of the requester". The use of a well
known
suffix could prevent www.ietf.org from being resolved
using an LLMNR-like
protocol (by ensuring that only
things that are in a particular domain suffix
get resolved).
Another approach may be to stipulate that things looked
up
using LLMNR don't have any dots in them (that would match
the kind of
behaviour that is seen currently with NetBIOS
naming
today).
Personally, I think it would be prudent to do something
to
prevent security problems that may result from looking
up what are supposed
to be DNS names in LLMNR.
It is true that unicast DNS responses to
requests could
be forged, but the multicast nature of LLMNR makes the
task
a whole lot easier.
kre: Yes, of course, in fact, that might often be exactly what I'd want
to
happen, any time it actually succeeded.
Note, that unless I'm insane (in
which case you probably should ignore
this opinion), that won't even get a
chance to succeed unless the DNS
isn't available at all.
If there's no
DNS, and I'm expecting www.ietf.org to work, then I think
I would want it
to...
And where that might be useful, is where I make a local mirror of
the
IETF site, then if my net connection is missing, or similar, and the
DNS
isn't working, I'd want to get to my local mirror, and being able to
find
it using LLMNR (or something) sounds like a win to me. That also has
the
advantage that I use the real site when it is available, avoid
possible
staleness with my slow update mirror (which is still better than
nothing
if necessary).
Yes, there are security issues to be handled,
but if we assume that we
start using dnssec sometime this century, then
multicast lookups will likely
be distinguished as not being properly
signed.
Sticking a funny domain on the end won't solve anything - I'd
configure my
search list to include it anyway (so I can refer to "foo") and
that means
that (unless I happen to do "www.ietf.org.") the resolver is
eventually
likely to try www.ietf.org.local.arpa. as the lookup for me, and
then it
would go find the multicast version anyway (a hacker would just be
pretending
to be that, instead of www.ietf.org - the A record that comes back
to my
browser works the same either way).
If we had to have a
restriction, "names with no dots" would be the only
reasonable one - but I
really believe that's unnecessarily limiting, for
no real gain that
matters.
erik nordmark:
> that is certainly one possibility, but why do we need it when we
don't
> have AI_NIS? AI_LLMNR removes transparency (of LLMNR) to
the
> application.
That is a different question than the one I
chose to answer.
You seemed to initially be concerned that there wasn't an
easy way to
add such support to the getaddrinfo/getnameinfo APIs, and
hopefully
I managed to dispell that concern.
The reason I think AI_NIS
(or AI_LDAP, etc) is that the intent is that they
all be managed with the
intent of providing a consistent appearance.
So if a name exists in NIS and
the same name exists in DNS, the intent
of the common administration is that
those name refer to the same device.
This is very different than the
LLMNR vs. DNS case, where the intent
is that nodes be able to create their
own names in the LLMNR name space.
> Note, however, this this is irrelevant. LLMNR is just another
>
naming service, different from DNS as much as NIS/YP is diferent
> from
DNS, which is just as different as /etc/hosts.
Actually, IMHO *more*
different than NIS/YP and /etc/hosts.
For different naming services there
is typically an administrator
who is trying to prevent inconsistencies
between the answers
from the the different naming services. In some cases one
naming
service might contain a subset of another, but I don't know of
a
case where one naming service explicitly contains inconsistent
information
for the same name as another naming service.
With LLMNR the operational
use might cause inconsistent
information by design, where
www.<localdomain> can be
effectively advertised by anybody using LLMNR
and be different
than the "managed" name service information for that
name.
eric hall: An LLMNR response for that name [www.ietf.org] would be
authoritative.
An LLMNR response for www.ietf.org.local.arpa would also be
authoritative. Both of them
would be non-authoritative for the DNS names,
however, for multiple
reasons (RRs have expired and/or changed, for
example).
Ergo, applying the LLMNR names, data, and authority to the DNS
namespace
would be dangerous in all cases. Therefore, LLMNR data MUST BE
HANDLED
SEPARATELY from DNS data in those cases where the data will be
reused.
Note that once the minimum responsible effort is taken, then the
presence
or lack of any specific label is moot.
In those cases where
it is not reused beyond the context of a single
application, who cares?
aidan williams: [ I'm assuming in all this that the DNS resolver and the
LLMNR
resolver software are two separate pieces of code (ie that the
DNS
resolver isn't going to try multicast for DNS request it is passed,
or
use a "funny suffix" as a trigger for doing multicast lookups. I
though we
had decided that overloading the search list as a trigger
for mDNS lookups
was a bad idea..) ]
There seems to be a confusion here between how
something like
nsswitch.conf operates and how a DNS resolver library
operates.
My understanding is that code dealing with different name
systems
(eg code for nsswitch.conf) will pass just the name through
to
each underlying name service.
For an /etc/nsswitch.conf hosts entry
like
hosts: files dns llmnr
1) www.ietf.org gets looked up in
/etc/hosts
2) www.ietf.org gets passed to the DNS resolver
library,
which may subsequently try the name with various
domain suffixes
tacked on the end
3) www.ietf.org gets passed to the LLMNR resolver
code
which could choose not to do a multicast request
because the name has
dots in it, or because the name
does not have the local.arpa suffix
So
a known suffix and/or no-dots would be a simple prescription that
could work
to ensure that DNS names like www.ietf.org are not resolved
using LLMNR. One
could even put llmnr before DNS with this approach.
I understand that you
are saying that would would like to be able to
resolve "www.ietf.org" via
LLMNR. I have an open mind on that.
Proposed Resolution: Reject
Issue 23: FQDN resolution with
LLMNR
Submitter: Aidan Williams
Submitter email address:
aidan.williams@motorola.com
Date first submitted: September 10,
2002
Reference: <3D7E915C.2000601@motorola.com>
Document:
LLMNR-12
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Before leaping into the next set of comments I should summarise what
I
believe the state of play is with zeroconf naming. I have been
following the
discussion in dnsext, and my understanding was that
there was general
agreement on the following points:
- mDNS/LLMNR was *not* DNS,
rather
it was a seperate protocol, seperate port,
seperate cache, etc
- there
was agreement that mDNS/LLMNR should not be used
as a substitute for DNS --
ie should not be used for
looking up "one true DNS names"
- that
mDNS/LLMNR should not be used to transport DNS requests
to a "back end
resolver"
In my opinion, these comments also apply to the IPv6
Node
Information Query proposal as well.
Rob Austein: I think I believe all of the above.
Right now, the -12
LLMNR document has examples with FQDNs in them.
Unless there have been
conversations that I am unaware of, I
believe it was the intent of the
working group *not* to support
the resolution of names such as
mylaptop.microsoft.com using LLMNR.
Rob Austein:
I don't think I believe this one, although I could of course
be wrong.
If it's a separate namespace, it's a separate namespace. The
fact
that a name in one might happen to look like a name in the other
is
not in itself a reason to forbid it.
The real question underlying
all of this, however, is how these names
are going to be used. In particular,
how applications are going to
deal with the general problem of having
multiple discrete namespaces,
most particularly applications that were not
designed to support such
a thing. Solve that, and the question of whether
there's a strong
reason to restrict the syntax of LLMNR names will probably
be obvious.
Once upon a time (back when dinosaurs still roamed the
machine rooms
in mighty herds) I used a mailsystem on which a
fully-specified
address in the MUA looked
like
sra@xx.lcs.mit.edu.#Chaos
sra@xx.lcs.mit.edu.#Internet
while
saying just
sra@xx.lcs.mit.edu
was an invitation to the MUA to
pick whichever naming realm it felt
good about today. The mail software of
course stripped the .#whatever
tag off the end before handing the message off
to the MTA, so this was
strictly a user interface issue, not a protocol
issue.
I'm not suggesting reviving that particular user interface
or
notation, just pointing out that this is not the first time that
this
problem has arisen, and that there's more than one way to attack
this
kind of problem.
Proposed Resolution: Reject
Issue 24: DNS configuration
Submitter: Joshua
Graessley
Submitter email address: jgraessley@apple.com
Date first
submitted: November 1, 2002
Reference:
<CA805F88-EDEE-11D6-9333-000393760260@apple.com>
Document:
LLMNR-11
Comment type: T
Priority: S
Section:
3.1
Rationale/Explanation of issue:
It seems like the needs of
multi-homed hosts are not fully covered by
this draft. In section 3.1,
"LLMNR configuration", the draft states:
> LLMNR usage can be
configured manually or automatically. On
> interfaces where no manual or
automatic DNS configuration has been
> performed for a given protocol
(IPv4 or IPv6), LLMNR SHOULD be enabled
> for that protocol.
What
does it mean to only enable LLMNR on an interface where no manual
or
automatic DNS configuration has been performed? DNS settings are not
per-interface. When an API such as getaddrinfo is used, the client does
not specify an interface. If a multi-homed host is connected to a
configured network and an unconfigured network, it seems the desired
behavior is nearly impossible to attain.
[BA] -
I agree that the text does not make sense, along
several
dimensions:
a. DNS configuration is not per protocol; if no
DNS
configuration is done for IPv6, AAAA RR queries will
still be sent
over IPv4 if a DNS server was configured
using IPv4.
b. DNS
configuration is typically not handled on a
per-interface basis.
In
-13, the text has been changed to address these issues.
Dual stack hosts are
now handled. In addition, the text
now states that LLMNR is used if the DNS
server does
not respond, or responds with NXRRSET. This means
that if a
host is configured to both configured and
unconfigured networks, that a DNS
query will be sent
first, and then an LLMNR query, assuming that no
answer
is received or NXRRSET is returned.
Proposed Resolution: Accept
Issue 25: Unicast queries
Submitter:
Christian Huitema
Submitter email address: huitema@microsoft.com
Date
first submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment
type: T
Priority: S
Section:
Rationale/Explanation of issue:
Why not either prohibit unicast queries or require
that they be sent
using TCP?
[BA]
There are cases when LLMNR requests need to
be
sent via unicast so this cannot be prohibited. TCP
can be used for
unicast queries; UDP is also allowed
for use with EDNS0. I am not clear that
the latter
adds much value, though.
Here is some text that clarifies
unicast queries
and use of DNS TTL:
"2.3. Unicast queries
A sender MUST NOT send a unicast LLMNR query
except when:
a. A sender repeats a query after it received a
response
to the previous LLMNR query with the TC bit set, or
b. The
sender's LLMNR cache contains an NS resource record that
enables the sender
to send a query directly to the hosts
authoritative for the name in the
query.
If a TC (truncation) bit is set in the response, then the sender
MAY use
the response if it contains all necessary information, or the sender
MAY
discard the response and resend the query over TCP or using EDNS0
with
larger window using the unicast address of the responder. The
RA
(Recursion Available) bit in the header of the response MUST NOT be
set.
If the RA bit is set in the response header, the sender MUST ignore
it.
2.5. DNS TTL
The responder should use a pre-configured TTL value in
the records
returned in the LLMNR query response. Due to the TTL
minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be
set to the
same value. In the additional and authority section of the
response the
responder includes the same records as a DNS server would insert
in the
response to the unicast DNS query."
[BA] Requiring a query to be sent over TCP doesn't add
much security value
beyond requiring that a Responder
be onlink. If the Responder were offlink
then TCP
would just demonstrate that the rogue wasn't using a
spoofed
source address. So if we are going to require
TTL=255 on send, check on
receive, then I don't think
that this adds additional value.
Proposed resolution: Accept
Issue 26: Retransmission timeouts
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: March 17, 2003
Reference:
Document: LLMNR-13
Comment type:
T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
Dynamically estimated timeout values are not supported.
Change:
"If the LLMNR query is not resolved during a limited
amount of time
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
a query in
order to assure themselves that the query has been received by a
host
capable of responding to the query. The default value for
LLMNR_TIMEOUT
is 1 second. Since a sender cannot know beforehand whether it
will
receive no response, one response, or more than one response to a
query,
it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible
responses, rather than considering the query answered after the
first
response is received."
To:
"LLMNR implementations SHOULD
dynamically estimate the timeout
value (LLMNR_TIMEOUT) on a per-interface
basis, using the
algorithms described in [RFC2988], with a minimum timeout
value
of 300 ms. If the LLMNR query is not resolved by LLMNR_TIMEOUT,
then a sender MAY repeat the transmission of a query in
order to assure
themselves that the query has been received by a host
capable of responding
to the query. Since a sender cannot know
beforehand whether it will receive
no response, one response,
or more than one response to a query, it SHOULD
wait for
LLMNR_TIMEOUT in order to collect all possible responses,
rather than considering the query answered after the first
response is
received."
Proposed resolution: Accept
Issue 27: Editorial Nits
Submitter:
Christian Huitema
Submitter email address: huitema@microsoft.com
Date
first submitted: January 17, 2003
Reference:
Document:
LLMNR-13
Comment type: E
Priority: S
Section:
Various
Rationale/Explanation of issue:
Throughout the document, replace "LINKLOCAL" with "link-scope multicast".
Proposed resolution: Accept
Issue 28: Addressing
Submitter: Christian
Huitema
Submitter email address: huitema@microsoft.com
Date first
submitted: January 17, 2003
Reference:
Document: LLMNR-13
Comment
type: T
Priority: S
Section: 2.5
Rationale/Explanation of issue:
Change:
"For IPv4 link-scope addressing, section 2.4 of "Dynamic Configuration
of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect
to
source address selection, TTL settings, and
acceptable
source/destination address combinations. IPv6 is described in
[RFC2460];
IPv6 link-scope addressing is described in [RFC2373]. LLMNR
queries and
responses obey the rules laid out in these documents. "
To:
"The source address of LLMNR queries and responses MUST be "on link".
The
destination address of an LLMNR query MUST be a link-scope
multicast
address or an "on link" unicast address; the destination
address
of an LLMNR response MUST be an "on link" unicast address.
For
IPv4, an "on link" address is defined as a link-local address or
an address
whose prefix belongs
to a subnet on the local link; for IPv6 [RFC2460]
an
"on link" address is either a link-local address, defined in
[RFC2373], or an
address whose prefix
belongs to a subnet on the local link. A sender SHOULD
prefer
RRs including reachable addresses where RRs involving
both
reachable and unreachable addresses are returned in
response to a query."
Proposed resolution: Accept
Issue 29: Valid Responses
Submitter:
Christian Huitema
Submitter email address: huitema@microsoft.com
Date
first submitted: January 17, 2003
Reference:
Document:
LLMNR-13
Comment type: T
Priority: S
Section:
3
Rationale/Explanation of issue:
Insert the following text in Section 3:
"RRs returned in LLMNR responses MUST only include values that are
valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local
link or domain names defended using the mechanism described
in Section 4. In
particular:
[5] If a link-scope IPv6 address is returned in a AAAA RR,
that
address MUST be valid on the local link over which LLMNR
is
used.
[6] If an IPv4 address is returned, it must be reachable
through
the link over which LLMNR is used.
[7] If a name is returned
(for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local
interface."
Proposed resolution: Accept
Issue 30: Why is Dynamic Update
needed?
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first submitted: March 24, 2003
Reference:
Document: LLMNR-16
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
Maybe I'm missing something, but I do not understand why a host
with
UNIQUE RRs needs to test for uniqueness by sending a
Dynamic Update request
for the RR with a prerequisite of NXRRSET.
Why would it not be sufficient to
send a query for the RR?
Within the draft, a host that has a UNIQUE RR
and
receives a Dynamic Update request will respond with the
YXRRSET
error, because the RR does exist. The draft does
not state how the host
should respond if the RR is not
UNIQUE. Doesn't it also send a YXRRSET error?
If so, then
the sender receives no information about whether the
host
thinks that the RR is really UNIQUE or not.
Given this, it seems to me
that the same result could be
accomplished more simply by sending a query for
the RR.
Mika Liljeberg says:
"I tend to agree with Erik. Using dynamic update seems like an
unnecessary
complication when a simple query would do just as well."
[BA] During the LLMNR Issue Conference call of 4/16/03, the
only
advantage that could be ascribed to Dynamic Update
was that responses to a
Dynamic Update request might be
more likely to fit within a single UDP
packet than
responses to an LLMNR query. This reason was felt to
be
insufficient for the added complexity and potential
interoperability problems
resulting from use of dynamic
update. Even where the response to an LLMNR
query is larger
than can fit in a UDP packet (so that the TC bit is
set),
it is not clear that the LLMNR sender needs to make
an additional
request, since the essential information
(that a conflict exists) is already
known.
Change Section 4 from:
"4. Conflict resolution
The
sender MUST anticipate receiving multiple replies to the same LLMNR
query, in
the event that several LLMNR enabled computers receive the
query and respond
with valid answers. When this occurs, the responses
MAY first be
concatenated, and then treated in the same manner that
multiple RRs received
from the same DNS server would.
There are some scenarios when multiple
responders MAY respond to the
same query. There are other scenarios when only
one responder MAY
respond to a query. Resource records for which the latter
queries are
submitted are referred as UNIQUE throughout this document.
The
uniqueness of a resource record depends on a nature of the name in
the
query and type of the query. For example it is expected that:
-
multiple hosts may respond to a query for an SRV type record
- multiple hosts
may respond to a query for an A or AAAA type
record for a cluster name
(assigned to multiple hosts in
the cluster)
- only a single host may
respond to a query for an A or AAAA
type record for a hostname.
Every
responder that responds to a LLMNR query and/or dynamic update
request AND
includes a UNIQUE record in the response:
1. MUST verify that there is no
other host within the scope of the
LLMNR query propagation that can return a
resource record
for the same name, type and class.
2. MUST NOT include a
UNIQUE resource record in the
response without having verified its
uniqueness.
Where a host is configured to respond to LLMNR queries on
more than one
interface, each interface should have its own independent LLMNR
cache.
For each UNIQUE resource record in a given interface's cache, the
host
MUST verify resource record uniqueness on that interface. To
accomplish
this, the host MUST send a dynamic LLMNR update request for each
new
UNIQUE resource record. The format of the dynamic LLMNR update
request
is identical that specified in [RFC2136]. By default, a host SHOULD
be
configured to behave as though all RRs are UNIQUE.
Uniqueness
verification is carried out when the host:
- starts up
or
- is configured to respond to the LLMNR queries on an interface or
- is
configured to respond to the LLMNR queries using additional
UNIQUE resource
records.
The data to be specified in the dynamic update request is as
follows:
Header section
contains values according to
[RFC2136].
Zone section
The zone name in the zone section MUST be set
to the name of the
UNIQUE record. The zone type in the zone section MUST be
set to
SOA. The zone class in the zone section MUST be set to the class
of
the UNIQUE record.
Prerequisite section
This section MUST contain a
record set whose semantics are
described in [RFC2136], Section 2.4.3 "RRset
Does Not Exist"
(NXRRSET), requesting that RRs with the NAME and TYPE of the
UNIQUE
record do not exist.
Update section
This section MUST be
left empty.
Additional section
This section is set according to
[RFC2136].
When a host that owns a UNIQUE record receives a dynamic
update request
that requests that the UNIQUE resource record set does not
exist, the
host MUST respond via unicast with the YXRRSET error, according to
the
rules described in Section 3 of [RFC2136].
After the client
receives an YXRRSET response to its dynamic update
request stating that a
UNIQUE resource record does not exist, the host
MUST check whether the
response arrived on another interface. If this
is the case, then the client
can use the UNIQUE resource record in
response to LLMNR queries and dynamic
update requests. If not, then it
MUST NOT use the UNIQUE resource record in
response to LLMNR queries and
dynamic update requests.
Note that this
name conflict detection mechanism doesn't prevent name
conflicts when
previously partitioned segments are connected by a
bridge. In such a
situation, name conflicts are detected when a sender
receives more than one
response to its LLMNR query.
In this case, the sender sends the first
response that it received to
all responders that responded to this query
except the first one, using
unicast. A host that receives a query response
containing a UNIQUE
resource record that it owns, even if it didn't send such
a query, MUST
verify that no other host within the LLMNR scope is
authoritative for
the same name, using the dynamic LLMNR update request
mechanism
described above. Based on the result, the host detects whether
there is
a name conflict and acts as described above."
To:
"4.
Conflict resolution
The sender MUST anticipate receiving multiple replies
to the same LLMNR
query, in the event that several LLMNR enabled computers
receive the
query and respond with valid answers. When this occurs, the
responses
MAY first be concatenated, and then treated in the same manner
that
multiple RRs received from the same DNS server would.
There are
some scenarios when multiple responders MAY respond to the
same query. There
are other scenarios when only one responder MAY
respond to a query. Resource
records for which the latter queries are
submitted are referred as UNIQUE
throughout this document. The
uniqueness of a resource record depends on a
nature of the name in the
query and type of the query. For example it is
expected that:
- multiple hosts may respond to a query for an SRV type
record
- multiple hosts may respond to a query for an A or AAAA
type
record for a cluster name (assigned to multiple hosts in
the
cluster)
- only a single host may respond to a query for an A or AAAA
type
record for a hostname.
Every responder that responds to a LLMNR query
and/or dynamic update
request AND includes a UNIQUE record in the
response:
1. MUST verify that there is no other host within the scope of
the
LLMNR query propagation that can return a resource record
for the same
name, type and class.
2. MUST NOT include a UNIQUE resource record in
the
response without having verified its uniqueness.
Where a host is
configured to respond to LLMNR queries on more than one
interface, each
interface should have its own independent LLMNR cache.
For each UNIQUE
resource record in a given interface's cache, 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.
By default, a host SHOULD
be configured to behave as though all RRs are
UNIQUE. Uniqueness verification
is carried out when the host:
- starts up or
- is configured to
respond to the LLMNR queries on an interface or
- is configured to respond to
the LLMNR queries using additional
UNIQUE resource records.
When a
host that owns a UNIQUE record receives an LLMNR query for that
record, the
host MUST respond. After the client receives a response, it
MUST check
whether the response arrived on another interface. If this
is the case, then
the client can use the UNIQUE resource record in
response to LLMNR queries.
If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR
queries.
Note that this name conflict detection mechanism doesn't prevent
name
conflicts when previously partitioned segments are connected by
a
bridge. In such a situation, name conflicts are detected when a
sender
receives more than one response to its LLMNR query.
In this
case, the sender sends the first response that it received to
all responders
that responded to this query except the first one, using
unicast. A host that
receives a query response containing a UNIQUE
resource record that it owns,
even if it didn't send such a query, MUST
verify that no other host within
the LLMNR scope is authoritative for
the same name, using the mechanism
described above. Based on the
result, the host detects whether there is a
name conflict and acts
accordingly."
Proposed Resolution: Accept
Issue 31: Miscellaneous Editorial
Issues
Submitter: Randy Presuhn
Submitter email address:
randy_presuhn@mindspring.com
Date first submitted: April 4,
2003
Reference:
Document: LLMNR-15
Comment type: E
Priority:
S
Section: Various
Rationale/Explanation of issue:
A few minor editorial things jumped out at me when I looked
at
<draft-ietf-dnsext-mdns-15.txt>
- In some places "." at the end of
a sentence is followed by
a single space. In others, there are two spaces. It
should
be two spaces consistently.
- On page 11 in section 4, the
second and third bullets go
past column 72.
- sections 7 and 8 don't
consistently follow the format used in
draft-rfc-editor-rfc2223bis-04.txt,
especially regarding
the order of initials and names in author
lists.
- There is a superfluous '"' at the end of the
copyright
statement near the end of the document.
- DNS isn't expanded
on first use. (I wouldn't have noticed,
had the RFC editor not made us expand
"SNMP" and "MIB" on
first use in some recent RFCs. :-)
- DHCPv4 and
DHCPv6 should be expanded on first use.
- Page 3: "adhoc" -> "ad
hoc"
- Page 4: "possible reevaluate" -> "possible to
reevaluate"
- Page 4: "in particular is" -> "in particular,
is"
- Page 4: "Requirements" isn't quite the right title for section
1.1
I'd merge it into the end of section 1.2.
- In general, there are
a lot of DNS-isms (RR, RDATA, RCODE, TC,
AAAA, A, etc.) It might be helpful
to point to the appropriate
document for these in some kind of catch-all
entry in 1.2, rather
than trying to address each one individually on first
use.
- Section 2.1: "Type" -> "type"
- Section 2.1: "exist
(that" -> "exist. (That" and "section)." ->
"section.)"
-
Section 3.2.1, last paragraph: is "recommended" supposed to
be
"RECOMMENDED"?
- Section 4, first paragraph: "would, ordinarily."
-> "would."
- Section 4, second paragraph: is the mix of "MAY" and
"may" intended?
- Section 4.1: "wish" -> "need" (less
anthropomorphic)
- Section 5: "peer to peer" -> "peer-to-peer"
- If
the "TBD" items are to be filled in the RFC editor, it might
be a good idea
to flag them as such, in addition to what's already
there in section 6. (On
section 6, is the intent that the TCP and
UDP port numbers must be the same?
The current text *could*
be read that
way.)
Randy
Recommended resolution: Accept
Issue 32: LLMNR usage
reservations
Submitter: Rob Austein
Submitter email address:
sra+namedroppers@hactrn.net
Date first submitted: April 7, 2003
Reference:
<20030405191340.86BDB18EC@thrintun.hactrn.net>
Document:
LLMNR-15
Comment type: T
Priority: S
Section:
3
Rationale/Explanation of issue:
Please forgive me if I'm confused on the LLMNR issue resolution
protocol,
I didn't see an obvious thread on which to follow up on the
proposed
resolution to issue #3.
I have some reservations about the solution
proposed for LLMNR issue
#3, and while I won't stand in the way, I thought I
should explain my
reservations, since I think they expose a split between
two
fundamentally different usage models.
The scenario we discussed at
the IETF 56 DNSEXT meeting (two laptops
on an ad hoc network, each laptop
knows its own FQDN) is the result of
how I think about naming machines. My
laptop's name is the same no
matter where my laptop goes, and to me the whole
FQDN is the laptop's
name, not just the leftmost label, because the FQDN is
unambiguous.
Because of this, the proposed resolution to issue #3 seems
bizzare to
me: here I have a machine that has a perfectly good unambiguous
name,
but the protocol won't let me use it, and instead forces me to cons
up
a potentially ambiguous name.
I realize that there are operating
systems and networks that operate
on the model that only the leftmost label
is the host's business, and
everything else is imposed by the local
environment, but I don't
operate that way (and yes, my laptop's DHCP client
is configured to
override most of the DNS-related information that might come
from the
local environment).
So it seems to me that this proposed
resolution is somewhat biased in
favor of a particular model for ad-hoc
networks at the expense of
other (perhaps better) models, and increases the
likelihood of name
collisions by forcing users who can supply unambiguous
names to use
potentially ambiguous names instead.
Bill Manning
<bmanning@ISI.EDU> says:
amen. that's why the TBDS project chose to
key off the FQDN for
its version of mDNS.
there is the distinction of
where your computer is
vs who named it. Joe and Jane likely have Internet
access.
They buy that access from someone. perhaps joe@aol.com
and
jane@bbss.net it would seem to not bee too much of a reach to
presume that
bbss and aol will tag the connecting machines of their
customerss with a name
- perhaps joe-pc.aol.com and jane-pda.bbss.net
and assign credentials to
them.... volia, FQDNs.
Now when joe and jane meet at the StarBucks in
Memphis, they get
new IP addresses but their FQDNs stay the same as their
creds... case closed.
Ted Lemon <mellon@nominum.com>
says:
You're right. It is bizarre. It's there for a good reason, which is
that Joe Average doesn't think his laptop is called
"joeaverage.myispsdomain.com". He thinks it's called "joeaverage".
So if
you want Joe Average to be able to exchange data with Jane
Average (assuming
that Jane Average also doesn't think of her laptop as
having an FQDN) when
they meet in a coffee shop to talk about their
homework, and Joe and Jane
average do not use the same ISP, the only
name that either one of them has a
chance of coming up with is
"joeaverage" or "janeaverage."
I think
this falls apart if you think about it a bit, though - chances
are that Joe
and Jane don't even think of their computers as
"joeaverage" and
"janeaverage" - they think of them as "my computer".
So the only chance Joe
and Jane really have of exchanging data is if
they see a menu with a name
that looks right, like "Joe's Computer".
They're just not going to be able
to come up with a name for each
other's computer otherwise. So you might as
well use an fqdn.
This brings us to the next problem, which is that
neither Joe nor Jane
are likely to have a reasonable basis for assigning an
FQDN to their
computer right now. For a computer to have an FQDN, it has to
have a
name registered in the DNS. Any other definition of "having an FQDN"
is meaningless (correct me if I am wrong). Neither Joe nor Jane have
any
idea that their computers ought to have FQDNs, and neither Joe nor
Jane
would have any idea how to get their computers' name registered in
the DNS
even if they realized that it would be useful to do so. So
for Joe and Jane,
it's necessary that LLMNR allow their computers to
have names without
requiring them to go through the process of
registering FQDNs for their
computers.
This gets even more complicated because Joe and Jane's
laptops, being
portable, may very well switch FQDNs as they move from site
to site.
It's quite likely that both laptops do DHCP from time to time,
either
when they're connecting at home or at work. It's also likely that
their respective DHCP servers sometimes assign FQDNs to their laptops,
unbeknownst to them. It is extremely unlikely that Joe or Jane will
be
aware of this, and so if their laptops use those names--and only
those
names--in LLMNR, Joe and Jane won't be able to identify their
laptops.
So I would say that it's fine for your computer to claim
it's
sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers,
which haven't been explicitly configured with FQDNs, but may have been
dynamically configured with FQDNs, don't do so. And if we have to
pick
one or the other behavior as the default, the behavior should
favor Joe and
Jane, because unlike you, they are not prepared to defend
themselves from
misconfiguration.
I should point out that neither Joe nor Jane need be
dunces in this
scenario - they just aren't networking geeks, and don't want
to be
forced to be. Also, I am making no assertions about whether or not
Joe and Jane are a couple; this scenario works with all configurations
of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca,
and so on. :')
Ted Lemon <mellon@nominum.com> says:
>
perhaps. but there is the disticntion of where your computer is
> vs who
named it. Joe and Jane likely have Internet access.
> They buy that access
from someone. perhaps joe@aol.com
> and jane@bbss.net it would seem to not
bee too much of a reach to
> presume that bbss and aol will tag the
connecting machines of their
> customerss with a name - perhaps
joe-pc.aol.com and jane-pda.bbss.net
> and assign credentials to them....
volia, FQDNs.
Um, Joe and Jane don't know from FQDNs. And they may use
their
laptops in more places than just home and Starbucks. So it's entirely
possible that their laptops have more than one FQDN that could be
thought of as "the laptop's FQDN." And then they will see
inconsistent
behavior when they visit Starbucks. Sometimes
joe-pc.aol.com will be Joe's
laptop's FQDN, and sometimes it'll be
joe-pc.megacorp-example.com. Joe and
Jane aren't going to be able to
predict that.
Joe and Jane will learn
about FQDNs only when it's to their advantage
to do so. I'm not saying that
can't happen. But right now it's not
particularly to their advantage, so
chances are they don't know about
them. Joe and Jane think of FQDNs as
things that start with www, smtp
or pop, that only servers have.
I'm
all in favor of changing this - in fact, I'm working to change it -
but I
don't think that the design of a protocol should be predicated on
the
success of my efforts.
Paul Vixie <paul@vix.com> says:
i've
just got to beg to differ.
if joe and jane meet in a coffee shop and, via
some combination of an
apple-style "chooser" and bluetooth or 802.11 or irda
or null-ether cable
see each other at all, then it's probably adequate for
them to see rfc1918
ipv4 addresses or link-local ipv6 addresses (or both).
names are a nicety
but one which the palm-beamers seem to do perfectly well
without, most of
the time (since most palm owners don't ever name their
pda's.)
the more interesting question is: what if it's 802.11 and a large
network,
such as an internet cafe. in that case, one would immediately say
that
ip addresses weren't useful since there would be so many of them.
(when
there's only one, it's safe most of the time to assume you know who it
is;
when there's a lot more than one, you just don't know who's who.) but
if
we take this one step further, unqualified names don't help. on a
large
network like an 802.11 internet cafe, there's going to be more than
one
jane and probably more than one joe.
the cases where the
connectivity is limited to small numbers of other-ends
are such that ip
addresses (or names like "other end of null-ether cable")
are good
enough.
the cases where the connectivity is not so limited are such that
only fully
qualified and "universal" names are good enough.
and in
either case, higher level security like certificates ought to be used,
since
neither ip addresses nor universal fully qualified domain names
are
appropriate for either authentication or authorization.
Christian Huitema says:
"We have a tension between two requirements:
1) Enable rob.example.net
to discover randy.other-example.org on the
same link;
2) Avoid making
it too easy for a hacker to spoof
"www.something-important.com" by convincing
the host to send an LLMNR
query and then feeding the right answer.
The
last-last draft (16) proposes the following:
[1] If a DNS query does not
receive a response, prior to falling
back to LLMNR, the query SHOULD be
retransmitted at least
once.
[2] A sender SHOULD send LLMNR queries
only for names that are
either unqualified or exist within the default
domain.
[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.
[4] A sender SHOULD only send LLMNR queries for PTR
RRs
that represent addresses reachable through the link
over which LLMNR
is used.
Recommendation [2] will effectively prevent the rob/randy
scenario. The
root of the issue is that there is not necessarily a "default
domain"
for a given link -- e.g. a corporate laptop visiting a home
network
keeps its corporate name. The recommendation [2] is thus difficult
to
implement."
Erik Nordmark says:
"This tension is caused by the desire to have the same API do DNS and
LLMNR
lookups with some form of automatic fallback.
What you propose might
be the best compromise in that case.
But there is an option to allow an
explicit user interface knob
to say "always use LLMNR, always use DNS, first
DNS than LLMNR"
and have different rules in the 3 cases.
In the first
case, when the user has explicitly told the system to use LLMNR
for
everything, then LLMNR should be able to lookup any names I think."
[BA] How about this? In section 3, change:
"[2] A sender SHOULD send LLMNR queries only for names that are
either
unqualified or exist within the default domain."
To:
"[2] Where a DNS server is configured, by default a sender
SHOULD send
LLMNR queries only for names that are either
unqualified or exist within the
default domain. Where no
DNS server is configured, an LLMNR query MAY be
sent for
any name."
[Rob Austein]:
Other than the fact that I have no idea what "Where a DNS server
is
configured" means for a laptop that usually runs an iterative
resolver,
this seems ok :).
[Joshua Graessley <jgraessley@apple.com>]:
A knob is often a bad thing. It's an acknowledgment that there is no
good
solution so the user should research the options and come to their
own
conclusion about what will work best. I would not want to always
use LLMNR
first or even simultaneously with DNS. I don't want to make
it easier for
someone to spoof my mail server, or the AIM server, or
any of the other
number of services that are totally insecure that I
make use of on a daily
basis.
The solution to this problem lies in LLMNR issue 22 (Bring back
"local.arpa"). That issue has been rejected. Unless that issue is going
to be reopened, it seems the obvious answer is that DNS should be used
before LLMNR to avoid the security problems. This makes LLMNR useful
only in the case where a device does not have a configured DNS server
or
for names that do not exist in the DNS namespace. This is a pity
since
multi-homed devices are so common these days. This severely
(perhaps
fatally) limits the usefulness of LLMNR. This limitation and
the question of
what name to use will likely limit LLMNR to hobbyists
and
experts.
Since LLMNR issue 22 has been rejected, read no
further.
The problem you're trying to address is the reason that Apple is
using
a special domain to denote names that should always be resolved using
a
specific non DNS method. Dynamic DNS update is nice, but few people use
it. This usually means that a laptop can have many names throughout the
period of a day. When I'm at work, my laptop is graejo5.apple.com..
When
I'm at home, my laptop is
adsl-64-171-18-123.dsl.sntc01.pacbell.net.. If I
had dynamic DNS setup,
I could potentially have something like
joshs-tibook.graessley.com.
always point to whatever IP address is currently
assigned to my laptop.
I don't have that setup and neither does the average
person.
If I meet someone else at an airport or at someone's house where
I'm
assigned a NAT address, I would like an easy way to connect to their
machine by name. In both of these cases, I have a configured DNS
server.
I have no idea what name the other machine has. If my friend
has dynamic DNS
enabled, he might have a useful name that could be up
to date. If we're both
behind the same NAT, we should have no trouble
communicating, but my friend
should not use the NAT address when
updating the DNS record for their name.
Yes, NAT is evil, but we can't
just bury our heads in the sand and ignore
the problem.
By carving off a domain such as "local.arpa." and making
LLMNR the
authority of that domain, you solve two problems. You can make it
very
clear when LLMNR should be used (LLMNR issue 3), if the fully qualified
name ends in "local.arpa.", use LLMNR. You also give people a domain
they can use a name in. Not everyone owns a domain they can assign
names
from. Most ISPs certainly don't assign your computer a name, they
assign a
name to the IP address that you are assigned. Your IP address
often changes,
so that name often changes.
The use of the "local.arpa." domain also
solves some serious
multihoming problems. With multihoming, there is a
possibility that one
interface will be attached to a configured network and
one interface
will be attached to an ad-hoc network. In such a scenario, the
device
connected to both networks will be unable to use LLMNR to resolve
names
on the ad-hoc network. The queries would be sent to DNS first. By
specifying a domain such as local.arpa. to indicate queries should be
sent using LLMNR, we can handle the multi-homed case. The multi-homed
devices sends queries ending in local.arpa. to LLMNR and all other
queries to DNS. We don't have the potential security problem of sending
queries for www.ietf.org to LLMNR but we get the benefit of being able
to resolve, using LLMNR, the names of the devices on the ad-hoc
network.
-josh
[BA]
"I would not want to always
use LLMNR first or even simultaneously with
DNS. I don't want to make
it easier for someone to spoof my mail server, or
the AIM server, or
any of the other number of services that are totally
insecure that I
make use of on a daily basis."
This is certainly a
concern. While both unicast and multicast name
resolution is vulnerable to
spoofing without DNS security, the thinking is
that LLMNR is even easier
because you don't even have to write any
software to do it, just misconfigure
your machine. Also, DNS security
seems difficult to deploy with protocols
such as LLMNR. So the argument is
that even though both usages are vulnerable
today, LLMNR is likely to
remain vulnerable, no matter how DNS security were
to advance.
"The solution to this problem lies in LLMNR issue 22 (Bring
back
"local.arpa")."
I guess I'm missing how "local.arpa" addresses
the spoofing issue. Is this
because instead of spoofing ietf.org, the
attacker now has to spoof
ietf.org.local.arpa? Or is the "security" provided
by this due to only
using linklocal name resolution to resolve unqualified
names
(foo.local.arpa)? In that case, why wouldn't the same scope
restriction
in LLMNR provide equivalent security?
"You can make it
very clear when LLMNR should be used (LLMNR issue 3),
if the fully qualified
name ends in "local.arpa.", use LLMNR."
Actually, this just adds another
"knob to configure" -- the search list.
"You also give people a domain
they can use a name in."
Since this is a flat name space, that doesn't
address the issue of name
conflicts. There will be as many "bob.local.arpa"
hosts as "bob" hosts.
"When I'm at work, my laptop is
graejo5.apple.com.
When I'm at home, my laptop
is
adsl-64-171-18-123.dsl.sntc01.pacbell.net."
Depends on whether your
host allows DHCP to assign the name or not. If
not, your laptop might remain
graejo5.apple.com while a PTR RR query for
your IP address might return
adsl-64-171-18-123.dsl.sntc01.pacbell.net
from the DNS server, and
graejo5.apple.com if handled via LLMNR.
In any case, I'm not sure how
"local.arpa" helps this situation. Does
someone at the airport connect to
your machine as
"graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some
other name?
"If I meet someone else at an airport or at someone's house
where I'm
assigned a NAT address, I would like an easy way to connect to
their
machine by name. In both of these cases, I have a configured
DNS
server. I have no idea what name the other machine has."
This
doesn't sound like a problem that requires a name resolution solution
to me.
It has been pointed out by Erik Guttman that if what is actually
needed to
solve this is to discover the hosts and corresponding services
on the local
link, as well as their attributes, which could include a
"friendly name".
That way you don't have to know what the name is -- which
is a problem
whether you're using "local.arpa" or not.
"there is a possibility that
one
interface will be attached to a configured network and one
interface
will be attached to an ad-hoc network. In such a scenario, the
device
connected to both networks will be unable to use LLMNR to resolve
names
on the ad-hoc network."
I don't think this is true. It might
attempt to do a DNS query first, but
presumably this will fail and an LLMNR
query will go out, potentially on
both interfaces.
Proposed Resolution: Accept
Issue 33: PTR via Unicast
Submitter: Mika
Liljeberg
Submitter email address: mika.liljeberg@welho.com
Date first
submitted: April 17, 2003
Reference:
<F5FEAC407A690E42BD26E4F14530194202806082@esebe002.ntc.nokia.com>
Document:
LLMNR-16
Comment type: T
Priority: S
Section: 2.2, 2.3,
3
Rationale/Explanation of issue:
It occurs to me that it would be a whole lot simpler to do PTR
queries
using unicast. The LLMNR resolver could use a TTL=1 when
sending the query.
This way it would either get an immediate no-route
response from the local
TCPIP stack, a direct response from the holder
of the address, or an ICMP
time exceeded reply from the default router.
Either way, the resolver
wouldn't have to do any checking on the
address. This approach has several
benefits:
1) Immediate error response if there is no route for the
address
2) Error response from default router if the address is
off-link
3) LLMNR resolver does not need to do any checking on the
address
4) Unicast is easier on the network
Note that conflict
resolution for addresses is taken care by DAD, so
using unicast for PTR
shouldn't make any difference there. Another
assumption is that the PTR query
is already vulnerable to spoofing on
the local link, so, as long as we use
TTL=1 for the query there should
be no perceivable additional risk.
[BA] In Section 3, change:
"[4] A sender SHOULD only send LLMNR
queries for PTR RRs
that represent addresses reachable on the link
over
which LLMNR is used."
To:
"[4] A sender SHOULD only send LLMNR
queries for PTR RRs
via unicast, as specified in Section 2.3."
Proposed Resolution: Accept
Issue 34: Unicast Query Transport
Issues
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: April 22, 2003
Reference:
<Pine.LNX.4.53.0304231123110.3226@internaut.com>
Document:
LLMNR-17
Comment type: T
Priority: S
Section: 2.3,
2.6
Rationale/Explanation of issue:
Doing unicast queries only over TCP will make LLMNR more
resilient against
spoofing.
In Section 2.3, change:
"A sender MUST NOT send a unicast LLMNR query
except when:
a. A sender repeats a query after it received a
response
to the previous LLMNR query with the TC bit set, or
b. The
sender's LLMNR cache contains an NS resource record that
enables the sender
to send a query directly to the hosts
authoritative for the name in the
query.
If a TC (truncation) bit is set in the response, then the sender
MAY use
the response if it contains all necessary information, or the sender
MAY
discard the response and resend the query over TCP or using EDNS0
with
larger window using the unicast address of the responder. The
RA
(Recursion Available) bit in the header of the response MUST NOT be
set.
If the RA bit is set in the response header, the sender MUST ignore
it."
To:
"Unicast LLMNR queries MUST be sent using TCP, with
the TTL
(IPv4) or Hop Limit (IPv6) fields set to one (1). Responses
to
unicast LLMNR queries also MUST be sent using TCP (using the
same connection
as the query) and the TTL or Hop Limit fields
set to one. If a query sender
receives a
response to a unicast LLMNR query not using TCP, the response MUST
be
silently discarded. Unicast queries sent using UDP also MUST
be
silently discarded by the responder.
Unicast queries SHOULD be sent
when:
a. A sender repeats a query after it received a response
to the
previous LLMNR multicast query with the TC bit set, or
b. The sender's
LLMNR cache contains an NS resource record that
enables the sender to send a
query directly to the hosts
authoritative for the name in the
query.
c. The sender queries for a PTR RR.
If a TC (truncation)
bit is set in the response, then the sender MAY use
the response if it
contains all necessary information, or the sender MAY
discard the response
and resend the query over TCP using the unicast
address of the responder.
The RA (Recursion Available) bit in the header
of the response MUST NOT be
set. If the RA bit is set in the response header,
the sender MUST ignore the
RA bit.
If an ICMP "Time Exceeded" message is received in response to a
unicast
query, this is treated as a response that no records of the specified
type
and class exist for the specified name (it is treated the same as
a
response with RCODE=0 and an empty answer section)."
In section 2.6, change:
"In order to avoid synchronization, LLMNR
queries and responses are
delayed by a time uniformly distributed between 0
and 200 ms.
If the LLMNR query is not resolved within the timeout
interval
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a
query in
order to assure themselves that the query has been received by a
host
capable of responding to the query. Since a sender cannot
know
beforehand whether it will receive no response, one response, or
more
than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in
order
to collect all possible responses, rather than considering the
query
answered after the first response is received.
LLMNR
implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT)
on a per-interface basis, using the algorithms described
in [RFC2988], with a
minimum timeout value of 300 ms. Retransmission
SHOULD NOT be attempted more
than 3 times."
To:
"In order to avoid synchronization, LLMNR
queries and responses are
delayed by a time uniformly distributed between 0
and 200 ms.
If a multicast LLMNR query is not resolved within the timeout
interval
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
a
multicast query in order to assure themselves that the multicast
query
has been received by a host capable of responding to the query.
Since a
multicast query sender cannot know beforehand whether it will receive
no
response, one response, or more than one response to a multicast
query,
it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible
responses, rather than considering the multicast query answered
after
the first response is received.
LLMNR implementations SHOULD
dynamically estimate the timeout value for
multicast queries (LLMNR_TIMEOUT)
on a per-interface basis, using the
algorithms described in [RFC2988], with a
minimum timeout value of 300
ms. Retransmission of multicast queries SHOULD
NOT be attempted more
than 3 times. Since unicast LLMNR queries must be sent
using TCP, for
these queries, retransmission behavior is handled by the
transport
layer."
Itojun:
i don't think it necesary to require TCP here.
MikaL:
I agree. Connection hijacking on the local link is easy, so using
TCP
doesn't provide any additional protection. Besides, certain
restricted
devices equipped with a minimal protocol stack might only support
UDP.
MikeL, respond to: Joshua Graessley:
Josh,
On Thu, 2003-04-24 at 19:45, Joshua Graessley wrote:
> If
unicast TCP queries with a TTL of 1 are used, it seems quite likely
>
that PTR queries using LLMNR that could have succeeded will fail in
>
cases where more than one ip subnet is present on the local link. If my
>
machine does not have a routing entry, it will send the packet to the
>
router, which will presumably decrement the TTL and put the packet back
>
on the same link. Since the TTL is set to 1 my packet would be dropped.
>
If I sent the same query using multicast, the device on the same link
>
would have a chance to respond.
This seems a bit far fetched. Do you have
a real world example in mind?
Note that if we want to support something
like this, we really have no
choice but try all PTR queries with LLMNR, since
there is no way to tell
which destination addresses the default router might
bounce back to the
local link.
> This TTL=1 setting may get us in a
bind of a response to an LLMNR query
> sets the TC bit and the source
address of the response is on a
> different subnet.
>
> I
also think that for queries in certain domains, LLMNR should always
> be
used. It makes sense to use LLMNR for queries with names ending in
>
"254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa.".
I think I agree,
although I would reverse this and say that it does not
make sense to send
these PTR queries to a DNS server, so that phase may
be skipped.
Joshua Graessley:
At home, I have a network with a NAT and a few global IP addresses.
Both
subnets are on the same network. I would like to be able to use
LLMNR to
resolve the names of devices with global addresses from
devices that have
NAT addresses. There are a lot of problems with this
setup and some tweaks
to routing tables would make the TTL 1 rule work.
My concern is that if the
two devices can get information using
multicast queries, but then fail if
the TC bit is set because of the
TTL requirement, it might be a little
difficult to understand what's
going on. Then again, resolving a name to a
private address won't do
much good without the proper routing configuration
on the local
machines.
So no, I can't think of a real world
example.
Christian Huitema:
The goal is not to protect from connection hijacking on the local
link.
Indeed, an attacker on a local link can use ARP poisoning, and all
bets
are pretty much off.
The goal is to prevent off link attacks, and
also DOS amplification
attacks.
First, off-link attacks. Off link
attacks to a link-local multicast
destination are very hard. Off link attack
to a TCP destination are also
very hard: if the SYN-ACK is sent with TTL 1,
the attacker has to
successfully guess the TCP sequence number, and that is
not easy. Off
link attack to an UDP unicast port with a spoofed IP source
address are
on the contrary much easier. Sure, you get some protection via
TTL
checks, but TTL checks can be bypassed with various
tunneling
technologies, not to mention faulty routers. (The recent slammer
worm
propagated through an off link attack to a UDP listener.)
Second,
DoS amplification. The attack is to send a short UDP request to
an
intermediary, using a spoofed source address, and to have the
intermediary
respond to that target address with a long packet. This
achieves two
interesting goals: hiding the actual source of the attack,
and amplifying the
attack. This can be trivially mounted with a UDP PTR
request.
Clearly,
using TCP for direct queries has some cost. However, these
costs will mostly
appear when a service insists on resolving PTR
records, which is clearly an
"opt-in" function. And the cost does not
appear un-surmountable...
Itojun:
when i hear the word "DoS amplification", i assume that there
are more
than N packet produced in response to N malicious packets.
is it common to
call the above scenario (N larger packet generated by
N malicious packet)
"amplification"? i don't think so.
MikaL (responding to Christian Huitema):
> First, off-link attacks. Off link attacks to a link-local
multicast
> destination are very hard. Off link attack to a TCP
destination are also
> very hard: if the SYN-ACK is sent with TTL 1, the
attacker has to
> successfully guess the TCP sequence number, and that is
not easy. Off
> link attack to an UDP unicast port with a spoofed IP
source address are
> on the contrary much easier.
Even with UDP
there is still the timing problem, which makes off-link
attacks very hard.
However, I conceed they are possible.
> Sure, you get some protection
via TTL
> checks, but TTL checks can be bypassed with various
tunneling
> technologies, not to mention faulty routers. (The recent
slammer worm
> propagated through an off link attack to a UDP
listener.)
If you get access to the link, whether physically or via a
tunnel or a
misconfigured router, all bets are off anyway.
Suppose we
just require that the responder must always send the
responses to the
link-local multicast address and that the resolver must
not accept unicast
responses? That should take care of any off-link
LLMNR cache poisoning
attacks using a spoofed source address.
> Second, DoS amplification.
The attack is to send a short UDP request to
> an intermediary, using a
spoofed source address, and to have the
> intermediary respond to that
target address with a long packet. This
> achieves two interesting goals:
hiding the actual source of the attack,
> and amplifying the attack. This
can be trivially mounted with a UDP PTR
> request.
As Itojun
pointed out, one-for-one isn't really amplification. A TCP
server would send
multiple SYN-ACKs for one SYN before giving up
(although with exponential
backoff).
Also, the scope of the DoS attack is limited to other nodes on
the same
link, since responses would have TTL=1. It doesn't look like a
massive
DDoS is in the cards.
MikaL (responding to Bernard Aboba):
On Fri, 2003-04-25 at 06:11, Bernard Aboba wrote:
> -17 essentially
requires that either TCP or EDNS0 be implemented anyway,
> so as to be to
handle extended replies. The issue is whether *both*
> mechanisms are
required, or only one.
The requirement in the draft is MAY and I think
that is the correct
thing to say. There are implementations that only support
address
queries and for those implementatons it is quite acceptable to
only
support UDP, since they will practically never encounter responses
that
don't fit into a UDP response packet.
I share the concern about
the security issues so I did a little threat
analysis to make sense of the
problem. The analysis is appended below,
in case anyone is interested. It's
probably far from complete but feel
free to expand on it (I hope you can make
sense of the notation). The
upshot of the analysis, however, is that using
TCP for unicast would
indeed address some problems. However, as I would not
like to mandate
TCP for PTR queries, I propose an alternative
solution.
The critical thing is that a sender can easily verify that a
particular
response is not spoofed by an off-link sender. If we have a simple
way
to do that, we can use link-local addressing and TTL to make sure
we
don't leak anything off-link. So, I propose the following simple
rules
for ALL queries:
1. Concatenate a random cookie to the canonical
name. The cookie
should be changed for every new query (but not
retransmission).
The sender must verify that the cookie is correctly echoed
by
the responder or discard the response (this is already done as
part of
normal response processing). Naturally, the responder
must to disregard the
cookie element while looking up the name
database.
2. Send all queries and
responses with TTL=1 to prevent leakage.
3. Don't amplify: respond to unicast
queries with unicast
responses.
Note that we could use the above rules
only for unicast and the current
TTL=255 checks with multicast, but the
proposed rules would work equally
well for both unicast and multicast
queries.
The "when to use unicast" rules are fine as proposed in
resolution 34.
What do you think, did I overlook something?
Threats and alternative solutions to each
threat
================================================
THREAT A:
sender should not accept any responses from off-link.
Alternative
solutions:
[1] check that the destination address of the response
is
link-local (multicast)
[2] check that TTL=255 in response
packets
[8] use TCP unicast, send queries with TTL=1 to avoid
asking
off-link
[9] concatenate a random cookie to the canonical name,
send
queries with TTL=1, verify cookie on receipt
THREAT B: A
responder should not leak information to off-link attackers.
Alternative
solutions:
[3] check that the destination address of the query packet
is
link-local (multicast)
[4] check that TTL=255 in query packets
[5]
send responses with TTL=1
[6] send responses to link-local (multicast)
address
THREAT C: Both sender and responder should guard
against
reflection/amplification attacks. Solution:
[7] don't amplify:
don't respond to a single packet with many
packets and don't respond to a
unicast with multicast
Threat coverage
analysis
========================
Link-local multicast query
A: 1,2
(alternative with 5),!8,9
B: 3,4,5 (alternative with 2),6
C: 7
Outcome:
All three threats countered, alternative solutions
UDP unicast query with
TTL=1
A: !1 (conflicts with 7),!2 (conflicts with 5),!8,9
B: !3,!4,5,!6
(conflicts with 7)
C: 7 => respond with unicast
Outcome: All three
threats countered, solution=9,5,7
TCP unicast query with TTL=1
A: 1,!2
(conflicts with 5),8,9
B: !3,!4,5,!6
C: 7
Outcome: All three threats
countered, solution=8,5,7 or 9,5,7
NOTE: solution=9,5,7 works for all of
the above
[MikaL]:
I'm almost sorry I brought up issue 33. :-) I wanted to make
things
simpler and they got more complex. Anyway, a few comments
follow.
Sections 2.1 and 2.2 do not explicitly state what to do with
received
unicast UDP query/response packets. Presumably they should be
discarded
(except for the special optional empty response with TC bit
set,
described in section 2.3)? This implies destination address checks
for
all received UDP packets.
[BA] Since we're saying that sending unicast queries via TCP is a
SHOULD,
not a MUST, there is no reason for a responder to discard UDP unicast
queries.
Section 2.2:
"A responder listens on UDP port TBD on
the link-scope multicast
address(es) and on ports TBD on the unicast
address(es) that
could be set as the source address(es) when the
responder
responds to the LLMNR query. A responder MUST listen on both
the
UDP and TCP ports TBD unless it is impossible for a response
to be sent with
the TC bit set, in which case the responder MAY
listen only on UDP port TBD.
The host configured as a responder
MUST act as a sender to verify the
uniqueness of names as
described in Section 4."
[Randy Bush]:
In dns, it is legal for a client to send a tcp request
without first
having sent udp and received a tc bit. Note that this would
allow a
server to be udp only.
[MikaL]:
Only one port number is needed, since UDP and TCP can share the same
port
number.
Section 2.3:
"In composing a response to a unicast LLMNR
query, the responder
MUST set the Hop Limit field in the IPv6 header and the
TTL
field in IPv4 header of the response to 1. Since unicast LLMNR
queries
and responses to those queries MUST be sent using TCP,
spoofing a response
would require hijacking a TCP connection on
the local link."
With the
TCP listener, the TTL=1 setting should be set on the listen
socket so that
the SYN-ACK packets will have TTL=1. This prevents an
incoming connection
from being formed if someone tries to connect from
off-link, since the sender
will not receive any SYN-ACK packets.
"Senders MUST support sending TCP
queries, and Responders MUST
listen on TCP port TBD, unless it is impossible
for a response
to the supported queries to be sent with the TC bit
set."
Does this mean that TCP is optional in both sender and responder or
just
responder? The wording is not quite clear on this.
Note that,
since TCP is optional in the responder, it is more efficient
to just send all
queries with multicast in the first place, rather than
try TCP first and fall
back on multicast if responder does not support
TCP. (No, I don't propose to
make TCP mandatory. Simple devices might
not implement the TCP protocol at
all.)
"If an ICMP "Time Exceeded" message is received in response to
a
unicast query, this is treated as a response that no records of
the
specified type and class exist for the specified name (it is
treated the same
as a response with RCODE=0 and an empty answer
section)."
Careful
here. The UDP sender should verify that the ICMP error payload
contains a
valid DNS query packet, which matches a query that is
currently in progress.
Otherwise this can be turned into a DoS attack.
I'm not sure if the last
bit is worth mentioning but it's good to
realize that if the ICMP error
response doesn't have enough payload to
identify the query the sender will
have to fall back on a timeout. The
same thing will happen with TCP
implementations that follow RFC1122 to
the letter and ignore the "ICMP Time
Exceeded" error also during the TCP
connect phase, rather than aborting the
connection immediately.
[BA] - Here is the proposed new text of Section 2.3 and 2.6:
"2.3. Unicast queries and responses
Unicast queries SHOULD be sent
when:
a. A sender repeats a query after it received a response
with
the TC bit set to the previous LLMNR multicast query, or
b. The sender's
LLMNR cache contains an NS resource record that
enables the sender to send a
query directly to the hosts
authoritative for the name in the query,
or
c. The sender queries for a PTR RR.
If a TC (truncation) bit is
set in the response, then the sender MAY use
the response if it contains all
necessary information, or the sender MAY
discard the response and resend the
query over TCP using the unicast
address of the responder. The RA (Recursion
Available) bit in the
header of the response MUST NOT be set. If the RA bit
is set in the
response header, the sender MUST ignore the RA
bit.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to
TCP
unicast LLMNR queries MUST be sent using TCP, using the same
connection
as the query. If the sender of a TCP query receives a response
not
using TCP, the response MUST be silently discarded. Unicast UDP
queries
MAY be responded to with an empty answer section and the TC bit set,
so
as to require the sender to resend the query using TCP. Senders
MUST
support sending TCP queries, and Responders MUST support listening
for
TCP queries. The Responder SHOULD set the TTL or Hop Limit settings
on
the TCP listen socket to one (1) so that SYN-ACK packets will have
TTL
(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an
incoming
connection from off-link since the Sender will not receive a
SYN-ACK
from the Responder.
If an ICMP "Time Exceeded" message is
received in response to a unicast
UDP query, or if TCP connection setup
cannot be completed in order to
send a unicast TCP query, this is treated as
a response that no records
of the specified type and class exist for the
specified name (it is
treated the same as a response with RCODE=0 and an
empty answer
section). The UDP sender receiving an ICMP "Time Exceeded"
message
SHOULD verify that the ICMP error payload contains a valid LLMNR
query
packet, which matches a query that is currently in progress, so as
to
guard against a potential Denial of Service (DoS) attack. If a
match
cannot be made, then the sender relies on the retransmission and
timeout
behavior described in Section 2.6."
and:
"2.6. Retransmissions
In order to avoid synchronization, LLMNR queries
and responses are
delayed by a time uniformly distributed between 0 and 200
ms.
If an LLMNR query sent over UDP is not resolved within the
timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission
of
the query in order to assure that it was received by a host capable
of
responding to it. Since a multicast query sender cannot know
beforehand
whether it will receive no response, one response, or more than
one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect
all
possible responses, rather than considering the multicast query
answered
after the first response is received. A unicast query sender
considers
the query answered after the first response is received, so that it
only
waits for LLMNR_TIMEOUT if no response has been received.
LLMNR
implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT)
based on the last response received, on a per-interface
basis, using the
algorithms described in [RFC2988], with a minimum
timeout value of 300 ms.
Retransmission of UDP queries SHOULD NOT be
attempted more than 3 times.
Where LLMNR queries are sent using TCP,
retransmission is handled by the
transport layer."
Proposed resolution: Accept
Issue 35: IP TTL
Submitter: Christian
Huitema
Submitter email address: huitema@microsoft.com
Date first
submitted: April 22, 2003
Reference:
<Pine.LNX.4.53.0304231125320.3226@internaut.com>
Document:
LLMNR-17
Comment type: T
Priority: S
Section: 2,
2.5
Rationale/Explanation of issue:
The current document is not explicit about use of TTL/Hop Limit
in all
circumstances. Assuming that unicast queries and responses
to those queries
are sent only over TCP with TTL=1, and that
multicast queries are also sent
with TTL=1 so as to avoid possible
propagation beyond the local link, the
only issue left is the
TTL setting for responses to multicast queries.
In Section 2, change:
"[3] Upon the reception of the response, the
sender verifies that the
packet originated on-link (see Section 2.5 for
details). If these
conditions are met, then the sender uses and caches the
returned
response. If not, then the sender ignores the response and
continues
waiting for the response."
To:
"[3] Upon the
reception of the response, the sender performs the checks
described in Section 2.5. If these conditions are met, then
the
sender uses and caches the returned response. If
not, then the
sender ignores the response and continues
waiting for the response."
In Section 2.5, change:
"The source address of LLMNR queries and
responses MUST be "on link".
The destination address of an LLMNR query MUST
be a link-scope multicast
address or an "on link" unicast address; the
destination address of an
LLMNR response MUST be an "on link" unicast
address. For IPv4, an "on
link" address is defined as a link-local address or
an address whose
prefix belongs to a subnet on the local link; for IPv6
[RFC2460] an "on
link" address is either a link-local address, defined in
[RFC2373], or
an address whose prefix belongs to a subnet on the local link.
A sender
SHOULD prefer RRs including reachable addresses where RRs involving
both
reachable and unreachable addresses are returned in response to a
query.
In composing an LLMNR response, the responder MUST set the Hop
Limit
field in the IPv6 header and the TTL field in IPv4 header of the
LLMNR
response to 255. The sender MUST verify that the Hop Limit field
in
IPv6 header and TTL field in IPv4 header of each response to the
LLMNR
query is set to 255. If it is not, then sender MUST ignore
the
response.
Since routers decrement the Hop Limit on all packets
they forward,
received packets containing a Hop Limit of 255 must have
originated from
a neighbor.
Implementation note:
In the sockets
API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set
the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket
option is available on some platforms
to retrieve the IPv4 TTL of received
packets with recvmsg().
[RFC2292] specifies similar options for setting and
retrieving the
IPv6 Hop Limit."
To:
"The source address of
LLMNR queries and responses MUST be "on link".
The destination address of an
LLMNR query MUST be a link-scope multicast
address or an "on link" unicast
address; the destination address of an
LLMNR response MUST be an "on link"
unicast address. On receiving an
LLMNR query, the responder MUST check
whether it was sent to the LLMNR
multicast address; if it was sent to another
multicast address, then the
query MUST be silently discarded.
For
IPv4, an "on link" address is defined as a link-local address or an
address
whose prefix belongs to a subnet on the local link; for IPv6
[RFC2460] an "on
link" address is either a link-local address, defined
in [RFC2373], or an
address whose prefix belongs to a subnet on the
local link. A sender
SHOULD prefer RRs including reachable addresses
where RRs involving both
reachable and unreachable addresses are
returned in response to a
query.
In composing LLMNR queries, the sender MUST set the Hop Limit
field in
the IPv6 header and the TTL field in IPv4 header of the response to
one
(1). Even when LLMNR queries are sent to a link-scope
multicast
address, it is possible that some routers may not properly
implement
link-scope multicast, or that link-scope multicast addresses may
leak
into the multicast routing system. Therefore setting the IPv6 Hop
Limit
or IPv4 TTL field to one provides an additional precaution
against
leakage of LLMNR queries.
In composing a response to an LLMNR
query, the responder MUST set the
Hop Limit field in the IPv6 header and the
TTL field in IPv4 header of
the response to one (1). This is done so as
to prevent the use of LLMNR
for denial of service attacks across the
Internet.
Implementation note:
In the sockets API for
IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to
set the TTL of outgoing unicast and multicast
packets. The
IP_RECVTTL socket option is available on some platforms
to
retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving
the
IPv6 Hop Limit."
Proposed resolution: Accept
Issue 36: Consolidation of addressing
information
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: April 22, 2003
Reference:
<Pine.LNX.4.53.0304231127090.3226@internaut.com>
Document:
LLMNR-17
Comment type: E
Priority: 2
Section: 1,
2.4
Rationale/Explanation of issue:
It is best to put information on link-scope addressing in a single place.
In Section 1, change:
"LLMNR queries are sent to and received on port
TBD using a link-scope
multicast address as specified in "Administratively
Scoped IP Multicast"
[RFC2365] for IPv4. The LLMNR link-scope multicast
address to be used
for IPv4 is 224.0.0.251. For IPv6, the LLMNR link-scope
multicast
address is TBD. Link-scope multicast addresses are used to
prevent
propagation of LLMNR traffic across routers, potentially flooding
the
network; for details, see Section 2.4. In circumstances described
in
Section 2.3, LLMNR queries can also be sent to a unicast
address."
To:
"LLMNR queries are sent to and received on port TBD.
Link-scope multicast addresses are used to prevent
propagation of LLMNR
traffic across routers, potentially flooding the
network; for details, see
Section 2.4. In circumstances described in
Section 2.3, LLMNR queries can
also be sent to a unicast address."
In Section 2.4, change:
"The IPv4 link-scope multicast address a given
responder listens to, and
to which a sender sends all queries, is
224.0.0.251. The IPv6 link-
scope multicast address a given responder listens
to, and to which a
sender sends all queries, is TBD."
To:
"IPv4
administratively scoped multicast usage is specified in
"Administratively
Scoped IP Multicast" [RFC2365].
The IPv4 link-scope multicast address a
given responder listens to, and
to which a sender sends queries, is
224.0.0.251. The IPv6 link-scope
multicast address a given responder listens
to, and to which a
sender sends all queries, is TBD."
Proposed Resolution: Accept
Issue 37: Conflict detection
issues
Submitter: Markku Savela
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: May 8, 2003
Reference:
<200305081347.h48DlusG014194@burp.tkv.asdf.org>
Document:
LLMNR-18
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
In ...
> 4. Conflict resolution
> ...
> Where a host is
configured to respond to LLMNR queries on more than
> one interface, each
interface should have its own independent LLMNR
> cache. For each UNIQUE
resource record in a given interface's
> cache, ...
I have a minor
problem with the term "cache" in above. Normally, I
would associate the term
"cache" in connection with resolver as a
place to store answers to the
queries this node has sent. (And when a
node needs resolve some name, it
first would check this cache, and
only do the real query if answer is not
already cached).
Above paragraph seems to use "cache" as a place for
storing the set
RR's "owned" by this node. A real recursive DNS server might
use
cached values in answering queries, but the LLMNR only answers
for
explicitly configured names, never for anything it has cached as
a
result of a query.
Confused me, at least on first reading. Could
perhaps read:
Where a host is configured to respond to LLMNR queries on
more than
one interface, each interface should have its own independent
LLMNR
configuration. For each UNIQUE resource record in a
given
interface's configuration, the host MUST verify resource
record
uniqueness on that interface....
> 4.1. Considerations for
Multiple Interfaces
> ...
> ----------
----------
> | |
| |
> [A] [myhost] [A]
>
>
>
Figure 2. Off-segment name conflict
> If host myhost is configured to
use LLMNR on both interfaces, it
> will send LLMNR queries on both
interfaces. When host myhost sends
> a query for the host RR for name "A"
it will receive a response from
> hosts on both
interfaces.
>
> Host myhost will then forward a response from the
first responder to
> the second responder, who will attempt to verify the
uniqueness of
> host RR for its name, but will not discover a conflict,
since the
> conflicting host resides on a different link. Therefore it
will
> continue using its name.
I think the latter paragraph may be
misleading, at least on first
reading I was startled: "Am I supposed to do
conflict resolution
across interfaces!!?"
If LLMNR can detect it, it
should not do any forwarding, if responses
come from different interfaces.
(E.g. in above case, "clever" LLMNR
at "myhost" would not forward the
response!).
[BA] Here are the proposed fixes:
In Section 4, change:
"Where a host is configured to respond to LLMNR queries on more than
one
interface, each interface should have its own independent LLMNR
cache. For
each UNIQUE resource record in a given interface's
cache..."
To:
"Where a host is configured to respond to LLMNR queries on more than
one
interface, each interface should have its own independent LLMNR
resolver
cache. For each UNIQUE resource record in a given
interface's configuration,
the host MUST verify resource record
uniqueness on that interface..."
In Section 4.1, change:
"If host myhost is configured to use LLMNR on both interfaces, it
will
send LLMNR queries on both interfaces. When host myhost sends a
query
for the host RR for name "A" it will receive a response from hosts
on
both interfaces.
Host myhost will then forward a response from the
first responder to the
second responder, who will attempt to verify the
uniqueness of host RR
for its name, but will not discover a conflict, since
the conflicting
host resides on a different link. Therefore it will continue
using its
name.
Indeed, host myhost cannot distinguish between the
situation shown in
Figure 2, and that shown in Figure 3 where no conflict
exists."
To:
"If host myhost is configured to use LLMNR on both interfaces, it
will
send LLMNR queries on both interfaces. When host myhost sends a
query
for the host RR for name "A" it will receive a response from hosts
on
both interfaces.
Host myhost will then send the first responder's response to the
second
responder, who will attempt to verify the uniqueness of host RR
for its name,
but will not discover a conflict, since the conflicting
host resides on a
different link. Therefore it will continue using its
name.
Host
myhost cannot distinguish between the situation shown in
Figure 2, and that
shown in Figure 3 where no conflict exists."
Proposed resolution: Accept
Issue 38: DNS proxy undefined
Submitter:
Andreas Gustafsson
Submitter email address: gson@nominum.com
Date first
submitted: May 9, 2003
Reference:
<200305100021.h4A0Ljhh009362@guava.araneus.fi>
Document:
LLMNR-18
Comment type: T
Priority: S
Section: 1,
3.2
Rationale/Explanation of issue:
draft-ietf-dnsext-mdns-18.txt makes repeated references to an
entity
called a "DNS proxy". The term "DNS proxy" is not defined in
the
draft, and there is no DNS standard or RFC defining the behavior
of
such a device.
Requested change:
Remove all references to a
"DNS proxy".
[BA] Proposed resolution is to substitute "DNS server" for "DNS proxy" throughout.
Kevin Darcy <kcd@daimlerchrysler.com>:
I think "recursive resolver" would be more precise. "DNS server" could
be
mistaken for "authoritative server". Speaking of which, I think you
use
the term "DNS server" sometimes to mean an authoritative server, and
at
other times, to mean a recursive resolver. You should probably audit
that
usage simultaneously.
Andreas Gustafsson, gson@nominum.com:
The -18 draft also talked about the DNS proxy "supporting dynamic
update",
which makes no sense if it was indeed referring to a
recursive
resolver.
In the scenario involving a "home gateway", DHCP, and dynamic
DNS,
there actually needs to be both a caching server (aka
recursive
resolver) and an authoritative server (where names are
registered
using DDNS), but each of these can independently be on the local
wire,
integrated into the gateway, or anywhere else on the
Internet
reachable through the gateway.
Since the location of these
servers is entirely immaterial, any time
the draft mentions them being in a
specific location or claiming that
a "proxy" is needed to reach them, it is
only confusing the issue.
This is why I requested that any mention of a proxy
be removed, not
changed.
[BA] Here is a potential resolution:
In Section 1, Change:
"Propagation of LLMNR packets on the local link is considered
sufficient
to enable name resolution in small networks. The assumption
is that if
a network has a home gateway, then the network either has a DNS
server
or the home gateway can function as a DNS proxy. By
implementing
Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as
a DNS
proxy and dynamic DNS, home gateways can provide name resolution for
the
names of hosts over IPv4 on the local network.
For small IPv6
networks, equivalent functionality can be provided by a
home gateway
implementing Dynamic Host Configuration Service for IPv6
(DHCPv6) for DNS
configuration [DHCPv6DNS], as well as a DNS proxy
supporting AAAA RRs and
dynamic DNS, providing name resolution for the
names of hosts over IPv6 on
the local network.
This should be adequate as long as home gateways
implementing DNS
configuration also support dynamic DNS in some form."
To:
"Propagation of LLMNR packets on the local link is considered
sufficient
to enable name resolution in small networks. The assumption
is that if
a network has a home gateway, then the network is able to provide
DNS
server configuration and a DNS server is available that
is
authoritative for the names of local hosts and can support dynamic
DNS.
Configuration issues are discussed in Section 3.2."
In Section 3.2, change:
"LLMNR usage MAY be configured manually or automatically on a
per
interface basis. By default, LLMNR responders SHOULD be enabled on
all
interfaces, at all times.
Since IPv4 and IPv6 utilize distinct
configuration mechanisms, it is
possible for a dual stack host to be
configured with the address of a
DNS server over IPv4, while remaining
unconfigured with a DNS server
suitable for use over IPv6. In these
situations, a dual stack host will
send AAAA queries to the configured DNS
server over IPv4.
However, an IPv6-only host unconfigured with a DNS
server suitable for
use over IPv6 will be unable to resolve names using DNS.
Since
automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS]
and
[DNSDisc]) are not yet widely deployed, and not all DNS servers
support
IPv6, lack of IPv6 DNS configuration may be a common problem in
the
short term, and LLMNR may prove useful in enabling linklocal
name
resolution over IPv6.
For example, a home gateway may implement a
DNS proxy and DHCPv4, but
not DHCPv6 for DNS configuration [DHCPv6DNS]. In
such a circumstance,
IPv6-only hosts will not be configured with a DNS
server. Where the DNS
proxy does not support dynamic client update over IPv6
or DHCPv6-based
dynamic update of the DNS proxy, the home gateway will not be
able to
dynamically register the names of IPv6 hosts. As a result, the
DNS
proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with
an
authoritative name error (RCODE=3). This prevents hosts from
resolving
the names of IPv6-only hosts on the local link. In this
situation,
LLMNR over IPv6 can be used for resolution of dynamic names."
To:
"LLMNR usage MAY be configured manually or automatically on a
per
interface basis. By default, LLMNR responders SHOULD be enabled on
all
interfaces, at all times.
Since IPv4 and IPv6 utilize distinct
configuration mechanisms, it is
possible for a dual stack host to be
configured with the address of a
DNS server over IPv4, while remaining
unconfigured with a DNS server
suitable for use over IPv6.
In these
situations, a dual stack host will send AAAA queries to the
configured DNS
server over IPv4. However, an IPv6-only host
unconfigured with a DNS server
suitable for use over IPv6 will be unable
to resolve names using DNS.
Automatic IPv6 DNS configuration mechanisms
(such as [DHCPv6DNS] and
[DNSDisc]) are not yet widely deployed, and not
all DNS servers support IPv6.
Therefore lack of IPv6 DNS configuration
may be a common problem in the short
term, and LLMNR may prove useful in
enabling linklocal name resolution over
IPv6.
For example, a DHCPv4 server may be available but not a DHCPv6
server
[DHCPv6DNS]. As a result, IPv6-only hosts would not be configured with
a
DNS server. Where there is no DNS server authoritative for the names
of
hosts on the local network or the authoritative DNS server does
not
support dynamic client update over IPv6 or DHCPv6-based dynamic
update,
then hosts on the home network will not be able to dynamically
register
or resolve the names of local IPv6 hosts. For example, if
the
configured DNS server responds to AAAA RR queries sent over IPv4 or
IPv6
with an authoritative name error (RCODE=3), then it will not be
possible
to resolve the names of IPv6-only hosts. In this situation, LLMNR
over
IPv6 can be used for local name resolution.
Similarly, if a
DHCPv4 server is available providing DNS server
configuration, and the DNS
server authoritative for the A RRs of local
hosts also supports either
dynamic client update over IPv4 or
DHCPv4-based dynamic update, then
resolution of the names of local IPv4
hosts can be provided over IPv4 without
LLMNR. However, if there is no
DNS server authoritative for the names of
local hosts, or the
authoritative DNS server does not support dynamic update,
then LLMNR may
prove useful in enabling linklocal name resoltion over
IPv4.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used
to
configure LLMNR on an interface. The LLMNR Enable Option, described
in
[LLMNREnable], can be used to explicitly enable or disable use of
LLMNR
on an interface. The LLMNR Enable Option does not determine whether
or
in which order DNS itself is used for name resolution. The order
in
which various name resolution mechanisms should be used can be
specified
using the Name Service Search Option for DHCP [RFC2937]."
Proposed resolution: Accept
Issue 39: Name conflict detection
algorithm
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: May 12, 2003
Reference:
Document: LLMNR-18
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
It isn't clear to me that the name conflict detection mechanism
defined
in Section 4 makes sense. Here is what it says:
"The name conflict detection mechanism doesn't prevent name
conflicts when
previously partitioned segments are connected by a
bridge. In such a
situation, name conflicts are detected when a sender
receives more than one
response to its LLMNR multicast query.
In this case, the sender sends the
first response that it received to all responders that
responded to this
query except the first one, using UDP unicast. A host that
receives a query
response containing a UNIQUE resource record that it
owns, even if it didn't
send such a query, MUST verify that no other
host within the LLMNR scope is
authoritative for the same name, using
the mechanism described above. Based
on the result, the host detects whether
there is a name conflict and acts
accordingly."
I don't like the idea of sending unsolicited UDP responses. The
goal here
is to enable hosts involved in a conflict to become
aware of it more quickly.
A potential alternative is to mandate that hosts send an LLMNR query
for their own name at some convenient interval (every 30 seconds?)
Joshua Graessley <jgraessley@apple.com>:
It seems another alternative might be to send all responses using
multicast instead of unicast. This would give hosts a chance to detect
conflicts much quicker. The same trick is used with IPv4LL and ARP. The
ARP responses are broadcast to facilitate in quicker discovery of
conflicts. The multicast responses could be used to populate a local
LLMNR cache on all hosts possibly reducing the number of queries that
must be sent.
> Wouldn't it be wasteful to send all responses to the same
>
multicast group?
The response packet has to be sent. If it's sent using
multicast
instead of unicast it will reach more machines but at least a
packet
wouldn't be sent when it isn't needed. Sending every 30 seconds is a
precaution, in case something is wrong. If two hosts are configured to
respond differently to LLMNR requests, there is no problem until
another
host actually queries for the conflicting record. If no host
ever queries
for that record, what do we gain by spewing traffic every
30
seconds?
The multicast response could be used to build a cache on hosts
implementing LLMNR resolvers. This cache could be hit before a query
packet is generated on the wire, potentially eliminating additional
traffic.
[MikaL]:
I agree. There is no need to detect conflicts proactively.
If people
are worried about the CPU usage (and that is certainly a valid
point), we can
just leave the unicast responses as they are, but using
multicast would
simplify the code.
> The multicast response could be used to build a
cache on hosts
> implementing LLMNR resolvers. This cache could be hit
before a query
> packet is generated on the wire, potentially eliminating
additional
> traffic.
I'm not sure I'm comfortable with this one.
This might make cache
poisoning a bit too easy.
Note that, for UDP
unicast responses, comparing received responses to
pending queries is
currently our only defence against spoofed UDP
unicast responses from
off-link, since we no longer test TTL=255 for
responses.
[Erik Guttman]:
I agree that multicasting the name with the conflict would be easier
to
implement (and specify correctly).
If this multicast occurs to a link
local multicast group destination, it
would be hard for an attacker send it
to another link. This mitigates
the security risk of caching.
I
assume the host (llmnr responder) receiving these multicast
unsolicited
replies can distinguish the difference between a message
sent to multicast
and unicast destinations. Either a separate listener
(socket, or whatever)
should be used to listen for unicast requests, to
differentiate them from
multicast requests - or the 'destination
address' of the received datagram
should be examined.
Erik
[Christian Huitema]:
I am afraid that there is no good solution to this problem. I don't
like
the idea of multicasting all replies, as it is either wasteful
or
dangerous; and I also really don't like anything that relies on
periodic
broadcast by all hosts on a network, as it has obvious potential
for
melt-down.
Let's expand on why multicast replies are wasteful or
dangerous. There
is a proposed design in which hosts listen to all replies,
even those to
queries they did not issue, and cache the response. The idea is
that
multicast may be costly, but this cost would be compensated by
more
extensive caching. The problem is that such design is a powerful
tool
for an on-link attacker: the attacker can issue a spoofed query and
then
broadcast spoofed responses, effectively polluting the caches of
all
on-link hosts. In practice, a responsible host will only
accept
responses to its own queries. It will ignore the other
broadcast
responses. The multicast will just be wasteful.
My real
issue with name conflict detection is whether it is actually
needed. Take the
IETF network. Suppose that two attendees come in with
the laptops
"zeus.example1.com" and "zeus.example2.net". There will be a
conflict for the
unqualified name "zeus", but is that a bug that needs
be fixed? None of the
two laptops is going to change its name, as that
would probably invalidate
various security credentials and other
certificates. I guess we will just
have to live with it.
If names are picked at random, then we can just as
well pick them from a
space large enough to avoid the birthday paradox, and
periodic checks
will not be particularly useful. If we assume that names are
configured,
then periodic checks are not needed either. The administrator
may
perform the check during the configuration procedure, or compare to
a
master file kept somewhere, on a computer or a notebook.
The
administrator may also at a later stage perform inventories of
the
network, e.g. by listening to traffic, collecting IP addresses
and
performing reverse look-ups.
In summary, I would rather rely on
occasional checks triggered by an
administrative action, rather than increase
the amount of broadcast on
the network.
[Eric Hall]:
Another option is to stick the client name into the request
message,
perhaps using a special RR in the authority or additional-data
sections.
Other clients which are monitoring the multicast channel can watch
for
collisions and take whatever recovery steps are needed.
That would
only increase the request size by a small percentage, and
wouldn't generate
any additional messages.
[Joshua Graessley]:
> I am afraid that there is no good solution to this problem. I don't
> like the idea of multicasting all replies, as it is either wasteful
or
> dangerous; and I also really don't like anything that relies on
> periodic broadcast by all hosts on a network, as it has obvious
potential for
> melt-down.
We have operational experience with a
wide deployment of an
implementation of something similar to LLMNR that uses
multicasts for
responses to quickly detect conflicts and to implement
caching. We have
received no reports of melt-downs nor have we experienced
any such
problems here at Apple.
> Let's expand on why multicast
replies are wasteful or dangerous. There
> is a proposed design in which
hosts listen to all replies, even those
> to queries they did not issue,
and cache the response. The idea is that
> multicast may be costly, but
this cost would be compensated by more
> extensive caching. The problem is
that such design is a powerful tool
> for an on-link attacker: the
attacker can issue a spoofed query and
> then broadcast spoofed
responses, effectively polluting the caches of all
> on-link hosts. In
practice, a responsible host will only accept
> responses to its own
queries. It will ignore the other broadcast
> responses. The multicast
will just be wasteful.
A node can do the wrong thing and wreck havoc on
the local network. In
the case you note, the multicast would be detected by
anyone
advertising conflict data and the conflict detection would kick in.
Someone could use a unicast hardware address with a multicast IP
address
to spoof a response to just one node. The network is a shared
resource,
unless encryption and authentication is used, it can not be
made secure.
[Erik Guttman]:
The real question is - what is the problem? Early on in the work on
this
protocol it was asserted that it would be unacceptable to allow
multiple
hosts to respond to the same name. (I do not remember who
asserted
this.)
If we accept it is necessary to detect and correct the situation
where
more than one LLMNR responder responds authoritatively to the
same
name we need either a proactive or reactive approach. But do we
really
need to accept this requirement? There are for example cases where
we
*want* multiple responders to answer to the same name (if the
hosts
support redundant identical services, for example.)
It could be
inconvenient and confusing for a user to get inconsistent
results to a
request. But in this case, can't the user intervene?
The host had to have
*gotten* its name somehow. If this was a manual
administrative assignment,
only a similar assignment should be done
to change the name. The name may
have been assigned automatically ,
by a program which attempted to assign a
unique name. This same program
could periodically test to see if the name is
still unique.
I argue that duplicate name detection and suppression does
not need to be
part of the base LLMNR protocol.
> I don't like
> the idea of multicasting all replies, as it is
either wasteful or
> dangerous; and I also really don't like anything that
relies on periodic
> broadcast by all hosts on a network, as it has
obvious potential for
> melt-down.
I agree both are undesirable and
with your argument.
> In summary, I would rather rely on occasional
checks triggered by an
> administrative action, rather than increase the
amount of broadcast on
> the network.
That is basically what I am
suggesting above.
[BA] Here are the proposed fixes:
In Section 2.2, change:
"Responders MUST NOT respond to LLMNR queries
for names they are not
authoritative for, except in the event of a discovered
conflict, as
described in Section 4. Responders SHOULD respond to LLMNR
queries for
names and addresses they are authoritative for. This applies to
both
forward and reverse lookups."
To:
"Responders MUST NOT
respond to LLMNR queries for names they are not
authoritative for. Responders
SHOULD respond to LLMNR queries for
names and addresses they are
authoritative for. This applies to both
forward and reverse lookups."
In Section 4, change:
"The name conflict detection mechanism doesn't
prevent name conflicts
when previously partitioned segments are connected by
a bridge. In such
a situation, name conflicts are detected when a sender
receives more
than one response to its LLMNR multicast query. In this case,
the
sender sends the first response that it received to all responders
that
responded to this query except the first one, using UDP unicast. A
host
that receives a query response containing a UNIQUE resource record
that
it owns, even if it didn't send such a query, MUST verify that no
other
host within the LLMNR scope is authoritative for the same name,
using
the mechanism described above. Based on the result, the host
detects
whether there is a name conflict and acts
accordingly."
To:
"The name conflict detection mechanism doesn't
prevent name conflicts
when previously partitioned segments are connected by
a bridge. In
order to minimize the chance of conflicts in such a situation,
it
is recommended that steps be taken to ensure hostname uniqueness.
For
example, the hostname could be chosen randomly from a large pool of
potential names, or the hostname could be assigned via a process
designed
to guarantee uniqueness."
In Section 4.1, delete:
"Host myhost will then send the first
responder's response to the second
responder, who will attempt to verify the
uniqueness of host RR for its
name, but will not discover a conflict, since
the conflicting host
resides on a different link. Therefore it will continue
using its name."
Proposed resolution: Accept
Issue 40: Administrative
intervention
Submitter: Erik Guttman
Submitter email address:
Erik.Guttman@sun.com
Date first submitted: May 25, 2003
Reference:
Document: LLMNR-20
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
I checked out llmnr-20. I like it except there is no mention I could
find
about administrative intervention. Something like
"To detect duplicate
use of a name, an administrator could use a name
resolution utility which
employs LLMNR and list both the responses and
the responders. This would
allow an administrator to diagnose behavior
and potentially to intervene and
reconfigure llmnr responders who should
not be configured to respond with the
same name."
This heads off the complaint that dupes won't get detected at
all. We
can say sure they do - but by an administrator who cares and
can
intervene.
[BA] Here are the proposed fixes:
In Section 4, add after the last paragraph:
"When name conflicts are detected, they SHOULD be logged.
To detect
duplicate use of a name, an administrator can use a name
resolution utility
which employs LLMNR and list both the responses and
the responders. This
would allow an administrator to diagnose behavior
and potentially to
intervene and reconfigure LLMNR responders who should
not be configured to
respond to the same name."
Proposed Resolution: Accept
Issue 41: When Conflict Detection is
Required
Submitter: Stuart Cheshire
Submitter email address:
Stuart.Cheshire@apple.com
Date first submitted: May 25, 2003
Reference:
Document: LLMNR-20
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
I would have thought it obvious that if a device is powered on without
the
cable attached, then performing probes without the cable
connected is
unlikely to yield any useful information, and consequently,
when the cable is
subsequently connected, any assumption that your
name has been verified
unique is completely baseless. However, this is
evidently not obvious. So
there is a need to be explicit about when conflict
detection is
done:
* Upon reboot/startup
* Upon wake from sleep (if network
interface was inactive during sleep)
* Upon bringing up previously inactive
network interface
* Upon Ethernet hardware link-state change that indicates a
cable was attached.
* Upon association with a wireless base station,
etc.
* (but NOT periodically as a matter of course)
[BA] Here are the proposed fixes:
In Section 4, change:
"By default, a host SHOULD be configured to behave as though all RRs
are
UNIQUE. Uniqueness verification is carried out when the
host:
- starts up or
- is configured to respond to the
LLMNR queries on an interface or
- is configured to respond to the
LLMNR queries using additional
UNIQUE resource
records."
To:
"By default, a host SHOULD be configured to behave as though all RRs
are
UNIQUE. Uniqueness verification is carried out when the
host:
- starts up or is rebooted
- wakes from sleep (if the
network interface was inactive during sleep)
- is configured to respond to
the LLMNR queries on an interface
- is configured to respond to the LLMNR
queries using additional
UNIQUE resource records
- detects that an
interface is connected and is usable
(e.g. an IEEE 802 hardware link-state
change indicating
that a cable was attached or that an association has
occurred
with a wireless base station and that any required authentication
has completed)"
Proposed Resolution: Accept
Issue 42: Authority and additional section
processing
Submitter name: Andreas Gustafsson
Submitter email address:
gson@nominum.com
Date first submitted: July 14,
2003
Reference:
Document: LLMNR-21
Comment type: T
Priority:
S
Section: 2.3, 2.7
Rationale/Explanation of issue:
The mdns draft is vague when it comes to how the authority and
additional
sections of the DNS(-like) message are used. These
sections have well-known
and well-defined uses in the DNS protocol,
but it is far from clear that
these are relevant to and appropriate
for LLMNR.
In particular,
section 2.3 currently says:
Unicast queries SHOULD be sent
when:
[...]
b. The sender's LLMNR cache contains an NS resource record
that
enables the sender to send a query directly to the hosts
I have
several issues with this:
1. Responder behavior
The above text
seems to assume that responders have NS records and
glue address records
associated with them and include them in
responses. The following text in
section 2.7 could be interpreted as
requiring the responder to do
that:
In the additional and authority section of the response
the
responder includes the same records as a DNS server would insert in
the
response to the unicast DNS query.
However, doing this seems
redundant and wasteful - if the responder is
authoritative for some given
name N, the response NS record would
always be of the form "N NS N", which
carries no actual information.
I also find the requirement to include
additional section data "as a
DNS server would" problematic. Other parts of
the mdns specification
takes great care to ensure that LLMNR responders only
respond to
queries for the name for which it is authoritative, yet the
provision
for additional section data seems to allow a responder to
send
additional records whose owner name is not within the
server's
authority.
2. Sender behavior
The text in section 2.3
(b) also seems to assume that senders will
have NS records cached, presumably
ones responders sent in the
authority sections of previous responses.
However, the specification
does not actually require such caching, and I
would argue that it is
wasteful for the same reason as sending the NS record
is wasteful - it
would always be of the form "N NS N" and carry no actual
information.
3. Additional failure modes
Using unicast based
on cached NS records as specified in section 2.3
(b) introduces new failure
modes; for example, if a responder detaches
from the network and reattaches
with a different IP address, queries
will be sent to the old address and
LLMNR resolution will fail until
the NS TTL has expired.
4. Additional
security issues
If a sender caches arbitrary records from the authority
and additional
section, this allows a malicious responder to trivially
inject
information pertaining to another responder in the sender's
cache.
5. No reduction in multicast traffic
While it may at first
glance seem that the text of 2.3 (b) would
reduce the amount of multicast
traffic, in fact it does not. To
illustrate, consider the case of a type A
lookup. To avoid the
failure mode described above, you would have to make the
NS record TTL
no longer than the A record TTL, which means the unicast would
never
actually happen since any time an A record times out in the
LLMNR
sender's cache, the corresponding NS records have also timed out.
On
the other hand, if you don't care about the possibility of failure,
you
can achieve the same reduction in multicast traffic without using
NS records,
simply by increasing the TTL of the A record.
6. Increased
complexity
Implementing the logic of 2.3 (b) would needlessly complicate
the
sender implementation.
Requested change:
Remove item b. in
section 2.3.
Remove the following sentence in section 2.7:
In the
additional and authority section of the response the
responder includes the
same records as a DNS server would insert in the
response to the unicast DNS
query.
Add a new section as follows:
2.8. Use of the authority and
additional sections
Unlike the DNS, LLMNR is a peer-to-peer system and
does not have a
concept of delegation. In LLMNR, the NS resource record type
may
be stored and queried for like any other type, but it has no
special
delegation semantics as it does in the DNS. Responders
MAY have NS records
associated with the names for which they are
authoritative, but they SHOULD
NOT include these NS records in
the authority sections of
responses.
Responders SHOULD insert an SOA record into the authority
section of a
negative response, to facilitate negative caching as specified
in
RFC2308. The owner name of of this SOA record MUST be equal to
the
query name.
Responders SHOULD NOT perform DNS additional section
processing.
Senders MUST NOT cache RRs from the authority or
additional
section of a response as answers, though they may be used
for
other purposes such as negative caching.
--
Andreas Gustafsson,
gson@nominum.com
Proposed Resolution: Accept
Issue 43: PTR queries and cluster
names
Submitter name: Markku Savella
Submitter email address:
msa@burp.tkv.asdf.org
Date first submitted: August 4,
2003
Reference:
Document: LLMNR-22
Comment type: T
Priority:
S
Section: 2.3, 4
Rationale/Explanation of issue:
2.3. Unicast queries and responses
Unicast queries SHOULD be sent
when:
a. A sender repeats a query after it received a response
with
the TC bit set to the previous LLMNR multicast query, or
b. The sender
queries for a PTR
RR.
....
---------------------------------------
Concerning 2.3
(b): How are you supposed to generate a unicast query
out of PTR query, which
is NOT "*.in-addr.arpa" or "*.ip6.arpa"?
Thus, the section should be
amended to include only PTR queries that
are actually constructed from full
IP addresses? Other PTR queries
need to go via normal
UDP?
---------------------------------------
....
4. Conflict
resolution
....
- multiple hosts may respond to a query for an A or AAAA
type
record for a cluster name (assigned to multiple hosts in
the
cluster)
- only a single host may respond to a query for an A or AAAA
type
record for a
hostname.
....
---------------------------------------
The "cluster
name" semantics is unclear to. How does a sender that
queries a name know
whether the name is a "hostname" or "cluster
name"? Two choices:
a)
it's implicitly a "cluster name", if multiple answers are received
(e.g.
there will never be any conflict from sender viewpoint).
b) each host
must be configured locally with the list of legal
"cluster names", and sender
only accepts multiple answers for these
names.
I assume (a) is
intended?
[BA] I agree that a unicast query should only be sent
for PTR RR queries
for fully formed IP addresses within
*.in-addr.arpa or *.ipv6.arpa.
And yes, I believe that a name is inherently a cluster name
if
multiple answers are received (so there is no conflict
from the sender
viewpoint). Of course from the responder
viewpoint, it is different.
Proposed changes:
In Section 2.3, change:
"b. The sender queries for a PTR
RR."
To:
"b. The sender queries for the PTR RR of a fully
formed
IP address within the "in-addr.arpa" or "ip6.arpa" zones."
In
Section 4, change:
"The sender MUST anticipate receiving multiple replies
to the same LLMNR
query, in the event that several LLMNR enabled computers
receive the
query and respond with valid answers. When this occurs, the
responses
MAY first be concatenated, and then treated in the same manner
that
multiple RRs received from the same DNS server
would."
To:
"The sender MUST anticipate receiving multiple replies
to the same LLMNR
query, in the event that several LLMNR enabled computers
receive the
query and respond with valid answers. When this occurs, the
responses
MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would; the sender
perceives no inherent conflict from the receipt of multiple responses."
Proposed resolution: Accept
Issue 44: Reuse of Rendezvous IPv4 multicast
address
Submitter name: Stuart Cheshire
Submitter email address:
cheshire@apple.com
Date first submitted: August 24,
2003
Reference:
Document: LLMNR-22
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
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.
[BA] Before we can decide on this, it's important to understand
what
changes would be required to achieve interoperability, and
whether
that interoperability would extend beyond the wire (e.g. to the
content of the RRs) so that it would be meaningful -- rather than just
a
mechanism for Rendezvous to claim compliance with the LLMNR
Proposed Standard
without yielding the ability to interoperate
with other LLMNR implementations
in meaningful scenarios.
Assuming that LLMNR and Rendezvous can't interoperate, it seems fair
to
request assignment of a distinct IPv4 link-scope multicast address.
The proposed fixes are as follows:
Change "224.0.0.251" throughout the document to TBD.
Proposed resolution: Accept
Issue 45: Handling of Unqualified
Names
Submitter name: Stuart Cheshire
Submitter email address:
cheshire@apple.com
Date first submitted: August 24,
2003
Reference:
Document: LLMNR-22
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
>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.
[BA] I assume you are referring to DNS
queries for "tv." Presumably there
is no harm in allowing LLMNR queries for
this. The draft allows a host to
resolve queries for unqualified names only
via LLMNR, so this can be
avoided. Are you suggesting that this behavior be
recommended?
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.
[BA] Agreed. This should be fixed.
>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?
[BA] The LLMNR
implementation.
>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?
------------------------------------------------------------------------
In
Section 2.1, change:
"An LLMNR sender MAY send a request for any name."
To:
"Section 3 describes the circumstances in which LLMNR requests may be sent."
In Section 3, change:
"LLMNR is a peer-to-peer name resolution
protocol that is not intended as
a replacement for DNS. By default, 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.
As noted in [DNSPerf], even when DNS servers are
configured, a
significant fraction of DNS queries do not receive a response,
or result
in negative responses due to missing inverse mappings or NS records
that
point to nonexistent or inappropriate hosts. Given this, support
for
LLMNR as a secondary name resolution mechanism has the potential
to
result in a large number of inappropriate queries without the
following
additional restrictions:
[1] If a DNS query does not receive
a response, prior to falling
back to LLMNR, the query SHOULD be retransmitted
at least
once.
[2] Where a DNS server is configured, by default a sender
SHOULD send
LLMNR queries only for names that are either
unqualified or exist within the
default domain. Where no
DNS server is configured, an LLMNR query MAY be sent
for
any name.
[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.
[4] A sender SHOULD send LLMNR queries for PTR
RRs
via unicast, as specified in Section 2.3."
To:
"LLMNR is a peer-to-peer name resolution protocol that is not intended
as
a replacement for DNS. By default, 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.
An LLMNR sender may send a request for any name.
As noted in [DNSPerf], even when DNS servers are configured,
a
significant fraction of DNS queries do not receive a response, or
result
in negative responses due to missing inverse mappings or NS records
that
point to nonexistent or inappropriate hosts. Given this, support
for
LLMNR as a secondary name resolution mechanism has the potential
to
result in a large number of inappropriate queries without the
following
additional restrictions:
[1] If a DNS query does not receive
a response, prior to falling
back to LLMNR, the query SHOULD be retransmitted
at least
once.
[2] 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.
[3] A sender SHOULD send LLMNR queries for PTR
RRs
via unicast, as specified in Section 2.3."
Change section 3.1,
from:
"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.
This is the behavior suggested by [RFC1536]. LLMNR
uses this technique
to resolve unqualified host names."
To:
"If
a name is not qualified, for the purposes of LLMNR, the implicit search order is
as follows:
[1] Request the name with the current domain appended.
[2]
Request the name with the root domain (".") appended.
This is the
behavior suggested by [RFC1536]."
Proposed resolution:
Accept
Issue 46: Retransmission behavior
Submitter
name: Stuart Cheshire
Submitter email address: cheshire@apple.com
Date
first submitted: August 24, 2003
Reference:
Document: LLMNR-22
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
>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?
[BA] UNIQUEness verification is handled
similarly to any other query, as
specified in Section 2.6.
What about
tie-breaking in the event of simultaneous startup (e.g. when
power is
restored after an outage)?
[BA] The draft does not specify what is done
in the event of a name
conflict. In general, automatic name change may be
neither possible nor
desirable.
[BA] The proposed fixes are as follows:
Change Section 2.6 from:
"2.6. Retransmissions
In order to
avoid synchronization, LLMNR queries and responses are
delayed by a time
uniformly distributed between 0 and 200 ms.
If an LLMNR query sent over
UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a
sender MAY repeat the transmission of
the query in order to assure that it
was received by a host capable of
responding to it. Since a multicast query
sender cannot know beforehand
whether it will receive no response, one
response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in
order to collect all
possible responses, rather than considering the
multicast query answered
after the first response is received. A unicast
query sender considers
the query answered after the first response is
received, so that it only
waits for LLMNR_TIMEOUT if no response has been
received.
LLMNR implementations SHOULD dynamically estimate the timeout
value
(LLMNR_TIMEOUT) based on the last response received for a query,
on
a per-interface basis. The algorithms described in [RFC2988] are suggested, with
a
minimum timeout value of 300 ms. Retransmission of UDP queries
SHOULD
NOT be attempted more than 3 times. Where LLMNR queries are sent
using
TCP, retransmission is handled by the transport layer."
To:
"2.6. Retransmissions
In order to avoid
synchronization, LLMNR queries and responses are
delayed by a time randomly
selected from the interval 0 to 200 ms.
If an LLMNR query sent over UDP
is not resolved within the timeout interval
(LLMNR_TIMEOUT), then a sender
MAY repeat the transmission of the
query in order to assure that it
was
received by a host capable of responding to it. Retransmission of
UDP
queries SHOULD NOT be attempted more than 3 times. Where
LLMNR queries are
sent using TCP, retransmission is handled by the
transport
layer.
Since a multicast query sender cannot know
beforehand whether
it will receive no response, one response, or
more than one response, it
SHOULD wait for LLMNR_TIMEOUT
in order to collect all possible responses,
rather than considering the
multicast query answered after the first response
is received. A unicast
query sender considers the query answered after the
first response is received,
so that it only waits for LLMNR_TIMEOUT if no
response has been received.
LLMNR implementations SHOULD dynamically
estimate the timeout value
(LLMNR_TIMEOUT) based on the last response
received for a query,
on a per-interface basis. The algorithms described in
[RFC2988] are suggested
(including exponential backoff). Smaller values of
RTOinitial, RTOmin and RTOmax
MAY be used. Recommended values are
RTOinitial=1 second,
RTOmin=200ms, RTOmax=20 seconds. "
Proposed resolution: Accept
Issue 47: Miscellaneous Issues
Submitter
name: Stuart Cheshire
Submitter email address: cheshire@apple.com
Date
first submitted: August 24, 2003
Reference:
Document: LLMNR-22
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
>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..."
[BA] Agreed.
>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"
[BA] Yes.
>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.
[BA] It also means that other
hosts won't see these queries. On a high
populated network such as the
IETF's, such queries could consume a
substantial percentage of all bandwidth,
and so it is desirable to limit
them.
>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?
[BA] On senders. There is no checking requirement on
receivers,
because by setting TTL=1 the possibility of DoS
amplification
is removed. If TTL=255 were set on unicast responses,
then
it would be possible for LLMNR UDP responses to leak
beyond
link-scope if unicast UDP queries were to be allowed. For
TCP this
is not an issue since TTL=1 ensures that the 3-way
handshake cannot succeed
if unless the endpoints are on-link.
>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.
[BA] As recently as a
year ago, we have seen routers that don't
properly implement link local
multicast, so we disagree on this.
>The responder should use a
pre-configured TTL value
Pre-configured by whom?
[BA] By the
implementation. It probably makes sense to add
some text suggesting
appropriate default values.
>[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.)
[BA] The
ZEROCONF WG has recommended this behavior to encourage use of a
routable
address when it is available. The routable address is likely to
be more
stable, and since the IPv4 LL draft will incorporate behavior to
allow hosts
with routable and IPv4 LL addresses to communicate, I'm not
sure why this
should be an issue. Since LLMNR is about linklocal name
resolution, a host
configured to ARP for addresses on the local link
(whether they are routable
or IPv4 LL) should be able to reach both types
of addresses.
>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."?
[BA] This is
just cited as an example of how name conflict can be avoided.
It is not being
recommended necessarily -- and could be usable in
situations where no human
intervention is anticipated.
----------------------------------------------------------------
[BA] Proposed fixes are as follows:
In Section 2.5, change:
"The source address of LLMNR queries and
responses MUST be "on link".
The destination address of an LLMNR query MUST
be a link-scope multicast
address or an "on link" unicast address; the
destination address of an
LLMNR response MUST be an "on link" unicast
address.
On receiving an LLMNR query, the responder MUST check whether it
was
sent to a LLMNR multicast addresses defined in Section 2.4.
If it was
sent to another multicast
address, then the query MUST be silently
discarded."
To:
"A sender MUST select a source address for LLMNR
queries
that is "on link". The destination address of an LLMNR
query
MUST be a link-scope multicast address or an "on link" unicast
address.
A responder MUST select a source address for responses that
is
"on link". The destination address of an
LLMNR response MUST be an "on
link" unicast address.
On receiving an LLMNR query, the responder MUST check
whether it was
sent to a LLMNR multicast addresses defined in Section
2.4.
If it was sent to another multicast address, then the query MUST be
silently discarded."
In Section 2.7 change:
"The responder
should use a pre-configured TTL value in the records
returned in the LLMNR
query response."
To:
"The responder should use a pre-configured TTL value in the
records
returned in the LLMNR query response. A default value of 0 is
recommended
in highly dynamic environments (such as mobile ad-hoc
networks). In more
static environments, LLMNR traffic can be reduced by
setting the TTL to a
higher value."
Change:
"RRs returned in LLMNR responses MUST only include values that
are valid
on the local interface, such as IPv4 or IPv6 addresses valid on
the
local link or names defended using the mechanism described in Section
4.
In particular:"
To:
"It is the responsibility of the
responder to ensure that
RRs returned in LLMNR responses MUST only include
values that are valid
on the local interface, such as IPv4 or IPv6 addresses
valid on the
local link or names defended using the mechanism described in
Section 4.
In particular:"
In Section 3.2, change:
"Where there is no DNS
server authoritative
for the names of hosts on the local network or
the authoritative DNS server
does not support dynamic client update
over IPv6 or DHCPv6-based dynamic
update, hosts on the home network
will not be able to dynamically register or
resolve the names of
local IPv6 hosts."
To:
"Where there is no
DNS server authoritative for the name
of a host or the authoritative DNS
server does not support dynamic
client update over IPv6 or DHCPv6-based
dynamic update, then an
IPv6-only host will not be able to do DNS dynamic
update,
and other hosts will not be able to resolve its
name."
Change:
"linklocal name resoltion over
IPv4."
To:
"linklocal name resolution over IPv4."
In
Section 4, change:
"Where a host is configured to respond to LLMNR
queries on more than one
interface, each interface should have its own
independent LLMNR cache."
To:
"Where a host is configured to issue
LLMNR queries on more than one
interface, each interface should have its own
independent LLMNR cache."
In Section 4, change:
"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.
By default,
a host SHOULD be configured to behave as though all RRs are
UNIQUE.
Uniqueness verification is carried out when the host:
- starts up or is
rebooted
- wakes from sleep (if the network interface was inactive
during sleep)
- is configured to respond to the LLMNR queries on an
interface
- is configured to respond to the LLMNR queries using
additional
UNIQUE resource records
- detects that an interface is
connected and is usable
(e.g. an IEEE 802 hardware link-state change
indicating that a
cable was attached or that an association has occurred with
a
wireless base station and that any required authentication
has
completed)"
To:
"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, as described in Section 2.6.
By default,
a host SHOULD be configured to behave as though all RRs are
UNIQUE.
Uniqueness verification is carried out when the host:
- starts up or is
rebooted
- wakes from sleep (if the network interface was inactive during
sleep)
- is configured to respond to the LLMNR queries on an interface
enabled
for transmission and reception of IP traffic
- is configured to
respond to the LLMNR queries using additional
UNIQUE resource records
Proposed resolution: Accept
Issue 48: Reachability of routable
addresses
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: September 13,
2003
Reference:
Document: LLMNR-23
Comment type: T
Priority:
S
Section: 3
Rationale/Explanation of issue:
If a host has both link-scope and routable addresses, it should only prefer
the routable address in
responses if that routable address is reachable on
the interface on which the query was received.
Otherwise the query sender
could end up resolving a name to an address that would not respond to
ARP or
ND/NS.
In Section 3 change:
"[2] 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."
To:
"[2] A responder with both
link-local and routable addresses
on an interface MUST respond to LLMNR
queries for
A/AAAA RRs only with routable address(es) reachable
on the
interface receiving the query. This encourages
use of routable address(es)
for establishment of new
connections."
[Markku Savela]
Object to must "MUST". I want to be able to reply with link-local
address,
if the query src is using link-local address. And, I reply
with global
addresses, if query source address is global.
[Bernard Aboba]
Section 1.4 of draft-ietf-zeroconf-ipv4-linklocal-09 states:
" In
order to prevent use of Link-Local IPv4 addresses in off-link
communication,
the following cautionary measures are advised:
a. Routable addresses
should be used within applications whenever
they are available.
b.
Names that are globally resolvable to routable addresses should be
used
within applications whenever they are available. Names that are
resolvable
only on the local link (such as through use of protocols
such as Link Local
Multicast Name Resolution [LLMNR]) MUST NOT be
used in off-link
communication. IPV4 addresses and names which can
only be resolved on the
local link SHOULD NOT be forwarded, they
SHOULD only be sent when a
Link-Local address is used as the source
address. This strong advice should
hinder limited scope addresses
and names from leaving the context in which
they apply.
c. Link-Local IPv4 addresses MUST NOT be configured in the
DNS."
Since a routable address is used within applications whenever it
is
available, a responder with a routable address receiving an LLMNR query
will respond to the LLMNR query using a routable source address.
Since
the host does not use the Link-Local IPv4 address as the source,
it
also does not respond with RRs containing the IPv4 Link-Local
address.
This also has the effect of ensuring that a sender querying via
DNS
or LLMNR cannot receive conflicting answers. Since Link-Local
IPv4
addresses are not registered in DNS, a sender cannot receive
an RR containing
a Link-Local IPV4 address as a response to a DNS
query. If the responder has
no routable address to register in DNS,
then it cannot register any address,
and so the sender will query
via LLMNR and can receive an RR in the response
containing a
Link-Local IPv4 address. If the responder is multi-homed,
then
it can register a routable address in DNS. If an LLMNR
query arrives
on the interface using the routable address, then
the sender will reply using
the routable address. If an LLMNR
query arrives on an interface using a
Link-Local IPv4 address,
then the sender will reply using a Link-Local IPv4
address,
since the routable address is not reachable on that
interface.
Replying with a routable address does no harm regardless of
the
sender's source address, since a sender with only an IPv4
Link-Local
address will "ARP for everything" and will be able
to contact the responder
on a routable address.
[Mika Liljeberg]
I also object to the proposed wording.
On Sat, 2003-09-27 at 14:48,
Bernard Aboba wrote:
> Replying with a routable address does no harm
regardless of the
> sender's source address, since a sender with only an
IPv4
> Link-Local address will "ARP for everything" and will be
able
> to contact the responder on a routable address.
The zeroconf
specification also recognizes that the "ARP for everything"
approach does not
work for multihomed hosts. In addition, nodes that
rendezvous in an ad-hoc
situation may have mismatching netmasks, which
will prevent them from
communicating using the associated routable
addresses. In fact, a LLMNR
responder has no reliable way of judging
which address may be usable for the
sender and which might not.
Hence, the responder should just send all
addresses it has and let the
client decide. Note that the client side stub
resolver can be
implemented in such a way that it only returns usable
addresses (or only
the "best" address) to the application.
A node only needs to configure a link-local address if a) it has
no
routable address, or b) its routable address is not working. In
other
words, a node that is compliant with zeroconf will only configure
a
link-local address in addition to a routable one if it really needs
one.
This being the case it is not appropriate for LLMNR to decide not
to
advertise the address.
[Bernard Aboba]
One problematic scenario occurs where the sender has a
routable address on
one interface and a link-local address on another
interface. It sends an
LLMNR query on the interface with a link-local address
and gets back a
response with a routable address. It might then attempt to
contact the
responder via the interface with the routable address (since
presumably
this interface also has the default route). If the address is
not
reachable over that interface, then if the sender does not ARP for
the
routable address on the link-local interface, then communication
will
fail.
If the responder only has a routable address there is no
alternative. If
it has both a routable address and an IPv4 LL address, then
it could
respond with the routable address first, and the IPv4 LL address
2nd.
On failing to reach the responder over the interface with the
routable
address, the sender could try the link-local address over the
interface
with a link-local address. That would work.
However, the
IPv4LL draft does not recommend configuring a single
interface with both a
routable and a link-local address. Perhaps we could
say that the responder
can only respond with addresses that are valid on
the interface on which the
query is received, and that routable addresses
should be listed
first?
> In fact, a LLMNR responder has no reliable way of
judging
> which address may be usable for the sender and which might
not.
I think this is true. However, the LLMNR responder does have the
ability
to decide which of its addresses are reachable over the interface on
which
a query is received.
> Hence, the responder should just send
all addresses it has and let the
> client decide.
Sending addresses
not reachable over the interface on which the query is
received is not
helpful.
> Note that the client side stub resolver can be
>
implemented in such a way that it only returns usable addresses (or only
>
the "best" address) to the application.
In practice, I don't think that
implementations are that likely to do
this.
[Bernard Aboba] Here are the proposed fixes:
Change Section 3 to:
"LLMNR is a peer-to-peer name resolution protocol that is not intended
as
a replacement for DNS. By default, 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.
An LLMNR sender may send a request for any name.
As noted in
[DNSPerf], even when DNS servers are configured, a
significant fraction of
DNS queries do not receive a response, or result
in negative responses due to
missing inverse mappings or NS records that
point to nonexistent or
inappropriate hosts. Given this, support for
LLMNR as a secondary name
resolution mechanism has the potential to
result in a large number of
inappropriate queries without the following
additional
restrictions:
[1] If a DNS query does not receive a response, prior to
falling
back to LLMNR, the query SHOULD be retransmitted at
least
once.
[2] A sender SHOULD send LLMNR queries for PTR RRs
via
unicast, as specified in Section 2.3.
It is the responsibility of the
responder to ensure that
RRs returned in LLMNR responses MUST only include
values that are valid
on the local interface, such as IPv4 or IPv6 addresses
valid on the
local link or names defended using the mechanism described in
Section 4. In particular:
[1] If a link-scope IPv6 address is returned in
a AAAA RR, that
address MUST be valid on the local link over which LLMNR
is
used.
[2] If an IPv4 address is returned, it MUST be reachable
through
the link over which LLMNR is used.
[3] If a name is returned
(for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local
interface.
Routable addresses MUST be included first in the response, if
available.
This encourages use of routable address(es) for establishment
of
new connections."
Issue 49: Security considerations
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: September 26, 2003
Reference:
Document:
LLMNR-23
Comment type: T
Priority: S
Section:
5
Rationale/Explanation of issue:
The security considerations section needs to be updated to provide
a more
complete discussion of denial of service and spoofing
attacks.
Replace Section 5 with the following:
"5. Security
Considerations
LLMNR is by nature a peer-to-peer name resolution
protocol. It is
therefore inherently more vulnerable than DNS, since existing
DNS
security mechanisms are difficult to apply to LLMNR. While tools
exist
to alllow an attacker to spoof a response to a DNS query,
spoofing a response
to an LLMNR query is easier since the query
is sent to a link-scope multicast
address, which can propagate
to multiple switch ports.
In order to
address the security vulnerabilities, the following
mechanisms are
contemplated:
[1] Scope restrictions.
[2] Usage
restrictions.
[3] Cache and port separation.
[4]
Authentication.
These techniques are described in the following
sections.
5.1. Scope restriction
With LLMNR it is possible that
hosts will allocate conflicting names for
a period of time, or that attackers
will attempt to deny service to
other hosts by allocating the same name. Such
attacks also allow hosts
to receive packets destined for other
hosts.
Since LLMNR is typically deployed in situations where no trust
model can
be assumed, it is likely that LLMNR queries and responses will
be
unauthenticated. In the absence of authentication, LLMNR reduces
the
exposure to such threats by utilizing queries sent to a
link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit
(IPv6)
fields to one (1) on both queries and responses.
A TTL of one
(1) was chosen so as to limit the likelihood that LLMNR
can be used to launch
denial of service attacks. For example, were
the TTL of an LLMNR Response to
be set to a value larger than
one (1), an attacker could send a large volume
of queries from a
spoofed source address, causing an off-link target to be
deluged
with responses.
Utilizing a TTL of one (1) in LLMNR
responses ensures that they
will not be forwarded off-link. Using a TTL of
one (1) to set up
a TCP connection in order to send a unicast LLMNR query
reduces the
likelihood of both denial of service attacks and spoofed
responses.
Checking that an LLMNR query is sent to a link-scope multicast
address
should prevent spoofing of multicast queries by off-link attackers.
While this limits the ability of off-link attackers to spoof
LLMNR
queries and responses, it does not eliminate it. For example, it
is
possible for an attacker to spoof a response to a frequent query
(such
as an A/AAAA query for a popular Internet host), and by using a TTL or
Hop
Limit field larger than one (1), for the forged response to reach
the
LLMNR sender. There also are scenarios such as public "hotspots"
where
attackers can be present on the same link.
These threats are
most serious in wireless networks such as 802.11,
since attackers on a wired
network will require physical access to the
home network, while wireless
attackers may reside outside the home.
Link-layer security can be of
assistance against these threats if it is
available.
5.2. Usage
restrictions
As noted in Section 3, LLMNR is intended for usage in a
limited set of
scenarios.
While LLMNR can be used to resolve any name,
if an interface has been
configured with DNS server address(es), then LLMNR
SHOULD NOT be used
as the primary name resolution mechanism on that
interface, although
it MAY be used as a name resolution mechanism of last
resort.
If an LLMNR query is sent whenever a DNS server does not respond
in a timely way, then an attacker can poison the LLMNR cache
by
responding to the query with incorrect information.
To some extent, these
vulnerabilities exist today, since DNS response
spoofing tools are available
that can allow an attacker to respond
to a query more quickly than a distant
DNS server.
Since LLMNR queries are sent and responded to on the
local-link, an attacker
will need to respond more quickly to provide its own
response prior
to arrival of the response from a legitimate responder. If an
LLMNR
query is sent for an off-link host, spoofing a response in a
timely
way is not difficult, since a legitimate response will never be
received.
The vulnerability is more serious if LLMNR is given higher
priority than
DNS among the enabled name resolution mechanisms. In such
a
configuration, a denial of service attack on the DNS server would not
be
necessary in order to poison the LLMNR cache, since LLMNR queries
would
be sent even when the DNS server is available. In addition, the
LLMNR
cache, once poisoned, would take precedence over the DNS
cache,
eliminating the benefits of cache separation. As a result, LLMNR
is
only used as a name resolution mechanism of last resort.
Note:
enabling LLMNR for use in situations where a DNS server has been
configured
will result in upgraded hosts changing their default behavior
without a
simultaneous update to configuration information. Where this
is considered
undesirable, LLMNR SHOULD NOT be enabled by default, so
that hosts will
neither listen on the link-scope multicast address, nor
will they send
queries to that address.
5.3. Cache and port separation
In order
to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR
implementations MUST use a distinct, isolated cache for
LLMNR on each
interface. The use of separate caches is most effective
when LLMNR is used as
a name resolution mechanism of last resort, since
this minimizes the
opportunities for poisoning the LLMNR cache, and
decreases reliance on
it.
LLMNR operates on a separate port from DNS, reducing the likelihood
that
a DNS server will unintentionally respond to an LLMNR query.
5.4.
Authentication
LLMNR does not require use of DNSSEC, and as a result,
responses to
LLMNR queries may be unauthenticated. If authentication is
desired, and
a pre-arranged security configuration is possible, then IPsec
ESP with a
null-transform MAY be used to authenticate LLMNR responses. In a
small
network without a certificate authority, this can be most
easily
accomplished through configuration of a group pre-shared key for
trusted
hosts."
Proposed resolution: Accept
Issue 50: LLMNR-24 Review
Submitter name:
Ralph Droms
Submitter email address: rdroms@cisco.com
Date first
submitted: October 22, 2003
Reference:
Document: LLMNR-24
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
I've been reviewing draft-ietf-dnsext-mdns-24.txt, and I found that I don't
think I would know how to implement LLMNR based on this document. In
particular, the description of some terms like hostname, current domain, as
well as the behavior of senders and responders regarding unqualified names,
needs to be clarified.
One problem I have is the ambiguity between current host implementations of
these concepts and the way the terms are used in the document. I think it
would be useful to give concrete, implementation-independent definitions of
the following terms in the terminology section:
hostname - in section 2.2, the third paragraph begins with the sentence: 'As
an example, a computer "host.example.com." ...' I don't know what this
means in an implementation; is this a configured character string or a
one-component name with the current domain appended or ??? I suggest that
something like "hostname" be defined and used throughout the document for
clarity.
current domain - in section 3.1, the first item in the implicit search order
is "...the name with the current domain appended". What, exactly, is the
"current domain"? Is it the domain search list? I don't think that term is
defined in RFC 1536, which is given as a reference to the list.
authoritative - this term seems to be used in a different way than in DNS,
and is defined by example rather than by a sentence or phrase
owned by - in the fifth paragraph of section 2.2, what are "RRSets owned by
the host"?
(other DNS terms) - it might be good to say something in section 1.2 to the
effect of "Other terminology from DNS is defined in RFC 1034 or RFC 1035
(whichever is appropriate). In fact, it might be good to explicitly state
that the reader should be familiar with the concepts from DNS in RFC 1034
and RFC 1035.
Regarding unqualified names, I'm trying to relate the protocol described in
draft-ietf-dnsext-mdns-24.txt to the scenario I imagine I would use at home,
where I have a couple of computers using private addressing behind NAT,
which are configured with a list of DNS recursive name servers through DHCP.
Each computer is configured with an unqualified name, say "den" and
"laptop" and does not have a domain search list. I'd like to be able to be
able to enter, for example, http://den/some-random-page.html
So, the target of this URL is configured with the unqualified name "den".
The sender presumably first sends a request to the each of the DNS servers
in the configured list of servers, and gets no response or a negative
response. According to section 3.1, the sender skips step 1 (no current
domain or domain search list configured) and sends a request for the name
with the root domain appended: "den." If the target is configured with the
unqualified name "den", does it also respond to requests for the name
"den."? Or, does the hostname always have to be a FQDN, so that if the user
enters "den" as the "computer name", the hostname is then "den."?
By the way, I found the description (section 3, first para) of when to use
LLMNR to be confusing. Could that description be rewritten as a list of
conditions or steps to take?
[BA] The proposed resolution is as follows:
Change "hostname" to "name" throughout the document.
Change "host.example.com" to "foo.example.com" throughout the document.
In Section 2.2, change:
"If a DNS server is running on a host that supports LLMNR, the DNS server
MUST respond to LLMNR queries only for the RRSets owned by the host on
which the server is running, but MUST NOT respond for other records for
which the server is authoritative."
To:
"If a DNS server is running on a host that supports LLMNR, the DNS server
MUST respond to LLMNR queries only for the RRSets relating to the host on
which the server is running, but MUST NOT respond for other records for
which the server is authoritative."
Move the first paragraph of section 3.2 to Section 2.
Move the following paragraph in Section 5.2 to section 2:
"While LLMNR can be used to resolve any name, if an interface has been
configured with DNS server address(es), then LLMNR SHOULD NOT be used as
the primary name resolution mechanism on that interface, although it MAY
be used as a name resolution mechanism of last resort."
Change Section 2 from:
"A typical sequence of events for LLMNR usage is as follows:
[1] A sender needs to resolve a query for a name "host.example.com",
so it sends an LLMNR query to the link-scope multicast address(es)
defined in Section 2.4.
[2] A responder responds to this query only if it is authoritative
for the domain name "host.example.com". The responder sends
a response to the sender via unicast over UDP.
[3] Upon the reception of the response, the sender performs the checks
described in Section 2.5. If these conditions are met, then the
sender uses and caches the returned response. If not, then the
sender ignores the response and continues waiting for the response.
Further details of sender and responder behavior are provided in the
sections that follow."
To:
"LLMNR is a peer-to-peer name resolution protocol that is not intended as
a replacement for DNS. LLMNR usage MAY be configured manually or
automatically on a per interface basis. By default, LLMNR Responders SHOULD
be enabled on all interfaces, at all times.
An LLMNR sender may send a request for any name.
However, by default, LLMNR requests SHOULD be sent only when one of
the following conditions are met:
[1] No manual or automatic DNS configuration has been performed.
If an interface has been configured with DNS server address(es),
then LLMNR SHOULD NOT be used as the primary name resolution
mechanism on that interface, although it MAY be used as a name
resolution mechanism of last resort.
[2] DNS servers do not respond.
[3] DNS servers respond to a query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty
answer section.
A typical sequence of events for LLMNR usage is as follows:
[1] DNS servers are not configured or do not respond to a
query, or respond with RCODE=3, or RCODE=0 and an empty answer section.
[2] An LLMNR sender sends an LLMNR query to the link-scope multicast
address(es) defined in Section 2.4, unless a unicast query is
indicated. A sender SHOULD send LLMNR queries for PTR RRs
via unicast, as specified in Section 2.3.
[3] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.3.
[4] Upon the reception of the response, the sender performs the checks
described in Section 2.5. If these conditions are met, then the
sender uses and caches the returned response. If not, then the
sender ignores the response and continues waiting for the response.
Further details of sender and responder behavior are provided in the
sections that follow."
Replace Section 3.1 with the last 5 paragraphs of Section 3.
Change Section 3 To:
"3. Usage model
Since LLMNR is a secondary name resolution mechanism, its usage is
in part determined by the behavior of DNS implementations. This
document does not specify any changes to DNS resolver
behavior, such as searchlist processing or retransmission/failover
policy. However, robust DNS resolver implementations are more
likely to avoid unnecessary LLMNR queries.
As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or result
in negative responses due to missing inverse mappings or NS records that
point to nonexistent or inappropriate hosts. This has the potential to
result in a large number of unnecessary LLMNR queries.
[RFC1536] describes common DNS implementation errors and fixes.
If the proposed fixes are implemented, unnecessary LLMNR
queries will be reduced substantially, and so implementation of [RFC1536]
is recommended.
For example, [RFC1536] Section 1 describes issues with retransmission
and recommends implementation of a retransmission policy
based on round trip estimates, with exponential backoff.
[RFC1536] Section 4 describes issues with failover, and recommends
that resolvers try another server when they don't receive a response
to a query. These policies are likely to avoid unnecessary LLMNR queries.
[RFC1536] Section 3 describes zero answer bugs, which if addressed will
also reduce unnecessary LLMNR queries.
[RFC1536] Section 6 describes name error bugs and recommended searchlist
processing that will reduce unnecessary RCODE=3 (authoritative name)
errors, thereby also reducing unnecessary LLMNR queries."
Proposed resolution: Accept
Issue 51: Clarity Issues
Submitter name:
Tony Hain
Submitter email address: tony@tndh.net
Date first submitted:
November 18 2003
Reference:
Document: LLMNR-24
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
I am having trouble parsing this:
Pg 13 - After the client receives a
response, it
MUST check whether the response arrived on another interface. If
this
is the case, then the client can use the UNIQUE resource record
in
response to LLMNR queries. If not, then it MUST NOT use the
UNIQUE
resource record in response to LLMNR queries.
The phrase - 'If
this is the case, then ...' is somewhat ambiguous. It
looks like you are
requiring a response to arrive on a different interface
than the outbound
query. Maybe I just don't have the complete context. Is
the point a
split-horizon thing to avoid responding on an interface where
a more
authoritative node lives? If so the paragraph could use beefing up
to make
it clearer that there are multiple queries being discussed.
Pg 15 - '...
which can propagate to multiple switch ports.' Implies a
specific topology
& implementation. Alternative wording - '... where every
node on the
logical link would be made aware of it.'
[BA] Proposed fixes are as follows:
In Section 4, change:
"When a host that owns a UNIQUE record receives an LLMNR query for
that
record, the host MUST respond. After the client receives a response,
it
MUST check whether the response arrived on another interface. If
this
is the case, then the client can use the UNIQUE resource record
in
response to LLMNR queries. If not, then it MUST NOT use the
UNIQUE
resource record in response to LLMNR queries."
To:
"When a host that owns a UNIQUE record receives an LLMNR query for
that
record, the host MUST respond.
After the client receives a response,
it
MUST check whether the response arrived on an interface different
from
the one on which the query was sent. If the response
arrives on a different
interface,
the client can use the UNIQUE resource record in response
to
LLMNR queries. If not, then it MUST
NOT use the UNIQUE resource record in
response to LLMNR
queries."
In Section 5, change:
"LLMNR is by nature a peer-to-peer name resolution protocol. It
is
therefore inherently more vulnerable than DNS, since existing
DNS
security mechanisms are difficult to apply to LLMNR. While tools
exist
to alllow an attacker to spoof a response to a DNS query,
spoofing a response
to an LLMNR query is easier since the query
is sent to a link-scope multicast
address, which can propagate
to multiple switch ports."
To:
"LLMNR is by nature a peer-to-peer name resolution protocol. It
is
therefore inherently more vulnerable than DNS, since existing
DNS
security mechanisms are difficult to apply to LLMNR. While tools
exist
to alllow an attacker to spoof a response to a DNS query,
spoofing a response
to an LLMNR query is easier since the query
is sent to a link-scope multicast
address, where every host on the
logical link will be made aware of it."
Proposed resolution: Accept
Issue 52: LLMNR-25 Review
Submitter name:
Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted:
December 3, 2003
Reference:
Document: LLMNR-25
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of issue:
Bernard - I've taken a close look at draft-ietf-dnsext-mdns-25.txt
The
changes you made address some of the issues I raised in my
previous
review.
I find that I still have some points to raise with
the -25 rev, which
I've listed below. I also have some minor editorial
issues, which I'll send
in a separate message. I'm responding to you directly
with this review,
as I don't know how you'd like to proceed - discussion of
individual
issues through the issue tracker, private e-mail eschange, ignore
my
issues because I'm confused and the doc doesn't require
further
refinement. So, let me start by sending you this review; please
let
me know what next steps you'd like to take.
In the spirit of "send
text", one alternative would be for me to
suggest specific new text for the
document, which I would be willing
to do if yo uwould find it
helpful.
1. What is the format of LLMNR
messages?
----------------------------------------
I don't see where the
format of LLMNR messages is explicitly described
anywhere in the document.
There is text in the "Abstract":
LLMNR supports all current and future
DNS formats, types and
classes, while operating on a separate port from DNS,
and with a
distinct resolver cache.
and in the "Introduction":
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.
that addresses the LLMNR
message formats indirectly. If I were
implementing LLMNR, I think I'd have to
guess that LLMNR queries and
responses use the same message format as DNS
queries and responses.
2. How are names used in
LLMNR?
-------------------------------
I'm still not sure I understand how
names are used in LLMNR. Is a
name resolved by LLMNR assumed to have a
structure, like a domain
name, or is it a simple text string? Are matches
between queries and
LLMNR names required to be exact, complete matches, or is
name
interpretation or expansion allowed? For example, consider three
ways
in which a host might be configured with names:
Host name (local
configuration Domain name (DHCP
or DHCP option 12) option
15)
------------------------------ -----------------
foo
example.com
foo.example.com (none)
foo (none)
For each of those
potential configurations, I don't see an explicit
definition of how a
responder would reply to each of the following
queries:
foo
foo.example.com
foo.example.com.
foo.example
3. Use of
words "authoritative", "owned by", "has" relative to
RRs
------------------------------------------------------------------
The
document uses all of these words (for example, in section 2.2) to
describe
when a responder replies to a specific query. I think
using a single term or
phrase, with an appropriate definition in
section 1.2, throughout the
document would add clarity.
The choice of a term or phrase, coupled with
the description of an RR
as a tangible object that an LLMNR responder manages
or maintains,
relates to the model of LLMNR implementation I mentioned above.
That
is, is an LLMNR responder required to manage real RRs or is the RR
an
abstract concept used to describe how the LLMNR functions?
[BA] 1. LLMNR does indeed use the same packet format as DNS for
both
requests and responses. This should be clarified.
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.
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.
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.
3. The term "authoritative" is used to refer to whether a host responds to a
query for a name.
The term "has" 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 "owned" is used synonymously with
"has" and so the
term "has" can be substituted to improve clarity.
Proposed fixes:
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]."
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 "owns" to "has" where the term refers to RRs.
Proposed resolution: Accept
Issue 53: Miscellaneous NITs (Part
1)
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted:
December 3, 2003
Reference:
Document: LLMNR-25
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of issue:
Section 1, second paragraph: this paragraph is a repeat of the second
and
third sentences of the first paragraph of section 2. I think the
content
belongs in section 2 and this paragraph should be deleted from
section
1.
Section 1, third paragraph: The first sentence is incongruous with
the
remainder of the paragraph and should be moved somewhere
else.
Section 1.2, definition of "Sender": The statement:
may be
configured [...] as a responder, but not a sender.
is apparently in some
degree of conflict with the last sentence in the
first paragraph of section
2.2:
A host configured as a responder MUST act as a sender to verify
the
uniqueness of names as described in Section 4.
(although I can
imagine an interpretation that allows a responder to
act as a sender for
conflict resolution without acting as a sender to
perform name
resolution.)
Section 2.1, first paragraph: including PTR in the list of
RRs for
which a sender uses the link-scope multicast address is potentially
in
conflict with section 2.3:
Section 2.1, second paragraph: I think
the second sentence belongs in
section 2.2, describing responder
behavior.
Section 2.2, third paragraph: the phrase "a
computer
'foo.example.com'" seems to be imprecise. First, the sentence
doesn't
explicitly say that "foo.example.com" is the name for the
computer.
Second, there are so many ways in which a computer might be
"named"
that even "a computer named 'foo.example.com'" seems imprecise.
I
really think this paragraph needs to include text something like "a
host
configured to respond to LLMNR queries for the name
'foo.example.com'", which
purposely avoids the question of which name
is used as the host's name for
LLMNR.
Section 2.2, third paragraph: What is an "A/AAAA resource
record
query"? Does this mean an "A resource record or an AAAA
resource
record"? It might be clearer to just refer to "A resource
record"
throughout.
Section 2.5, third paragraph: needs a reference to
the document that
defines IPv4 link-local addresses (turns out [IPv4Link] is
already in
the references; guess it just needs a citation
here?).
Section 2.5, implementation note: is there a reference for the
version
of the sockets API discussed here?
Section 2.6, fourth paragraph: I think the first paragraph should
read
"...SHOULD dynamically compute the timeout value..."
Section 3, first paragraph: If I understand the first sentence
correctly,
the use of LLMNR is affected by the way in which a host
invokes LLMNR for
name resolution. If so, the phrase "behavior of name
resolution mechanisms"
might be more correct.
Section 3.2, second and third paragraphs: I would
argue that the
reference for DHCPv6 should be RFC 3315, rather
than
draft-droms-dhcpv6-stateless-guide-01.txt.
Section 4, second paragraph: is it necessary to capitalize the "MAYs
in
this paragraph?
Section 5.1, fifth paragraph: perhaps the last sentence
of this
paragraph should be moved to be the first sentence of the
following
paragraph?
[BA] In Section 3, the intent was to indicate that LLMNR, as a secondary name
resolution mechanism, is only invoked if DNS is not able to provide name
resolution for some reason. So the reference was indeed to DNS not to
"name resolution" in general.
Here are the proposed fixes:
Change Section 1 paragraphs 1-3 to the following:
"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.
The
goal of LLMNR is to enable name resolution in scenarios in which
conventional
DNS name resolution is not possible. These include
scenarios in which hosts
are not configured with the address of a DNS
server, where configured DNS
servers do not reply to a query, or where
they respond with errors, as
described in Section 2. Since LLMNR only
operates on the local link, it
cannot be considered a substitute for DNS.
LLMNR queries are sent to and
received on port TBD. Link-scope
multicast addresses are used to prevent
propagation of LLMNR traffic
across routers, potentially flooding the
network; for details, see
Section 2.4. LLMNR queries can also be sent to a
unicast address, as
described in Section 2.3."
Section 1.2 sender
definition has been addressed (see Issue #54)
Change Section 2.1 first
paragraph to:
"A sender sends an LLMNR query for any legal resource
record type (e.g.
A, AAAA, SRV, etc.) to the link-scope multicast address.
As
described in Section 2.3, a sender may also send a unicast
query.
Sections 2 and 3 describe the circumstances in which LLMNR queries
may
be sent."
In Section 2.1, change:
"The RD (Recursion
Desired) bit MUST NOT be set in a query. If a
responder receives a query with
the header containing RD set bit, the
responder MUST ignore the RD
bit."
To:
"The RD (Recursion Desired) bit MUST NOT be set in a
query."
Add the following sentence to Section 2.2:
"If a responder
receives a query with the header containing RD set bit, the
responder MUST
ignore the RD bit."
Change Section 2.2, third paragraph to the
following:
"As an example, a host configured to respond to LLMNR queries
for the name
"foo.example.com." is authoritative for the name
"foo.example.com.". On
receiving an LLMNR query for an A RR with the
name
"foo.example.com." the host authoritatively responds with A
RR(s)
that contain IP address(es) in the RDATA of the
resource
record."
Change the first sentence of the third paragraph of
Section 2.5 to the
following:
"For IPv4, an "on link" address is
defined as a link-local address [IPv4Link] or an
address whose prefix belongs
to a subnet on the local link."
Add a reference to the IPv4 Sockets API
[POSIX].
Change [DHCPv6DNS] to [RFC3315] throughout the document.
Section 4, change:
"When this occurs, the responses
MAY first
be concatenated, and then treated in the same manner that
multiple RRs
received from the same DNS server would; the sender
perceives no inherent
conflict in the receipt of multiple responses."
To:
"When this
occurs, the responses
may first be concatenated, and then treated in the same
manner that
multiple RRs received from the same DNS server would; the
sender
perceives no inherent conflict in the receipt of multiple
responses."
In Section 5.1, change the last two paragraphs to:
"While this limits the ability of off-link attackers to spoof
LLMNR
queries and responses, it does not eliminate it. For example, it
is
possible for an attacker to spoof a response to a frequent query
(such
as an A or AAAA query for a popular Internet host), and by using a TTL
or
Hop Limit field larger than one (1), for the forged response to
reach
the LLMNR sender.
There also are scenarios such as public "hotspots"
where attackers can be
present on the same link.
These threats are most serious in wireless networks
such as 802.11,
since attackers on a wired network will require physical
access to the
home network, while wireless attackers may reside outside the
home.
Link-layer security can be of assistance against these threats if it
is
available."
Proposed resolution: Accept
Issue 54: Comments on -25
Submitter name:
Michael Patton
Submitter email address: MAP@MAP-NE.com
Date first submitted:
December 3, 2003
Reference:
Document: LLMNR-25
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of issue:
I noticed some contradictions in the draft...
In the definitions
section under "Sender" it says that "a host may be
configured ... as a
responder, but not a sender." But, in section 2.2
we have "A host configured
as a responder MUST act as a sender ..."
Also, near the end of section
2.2 it says "A response to an LLMNR
query MUST have RCODE set to zero." while
elsewhere (several places)
responses with RCODE=3 are required.
[BA] Here are the proposed fixes:
In Section 1.1, change:
"Sender A host that sends an LLMNR query. Typically a
host is
configured as
both a sender and a responder. However, a
host
may be configured
as a sender, but not a responder or as
a
responder, but not a
sender."
To:
"Sender A host that sends an LLMNR query."
The references to RCODE=3 either relate to responses to DNS queries, or
to
reasons why a response of RCODE=3 to an LLMNR query would not make
sense.
Therefore there is no contradiction, but clarity could be improved.
In Section 2, change:
"[3] DNS servers respond to a query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty
answer
section."
To:
"[3] DNS servers respond to a DNS query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty
answer
section."
Change:
"[1] DNS servers are not configured or do not respond to
a
query, or respond with RCODE=3, or RCODE=0 and an
empty
answer section."
To:
"[1] DNS servers are not configured or do not respond to
a
DNS query, or respond with RCODE=3, or RCODE=0 and
an empty
answer section."
In Section 2.2, change:
"As a result, "foo.example.com." cannot reply
to a query for
"child.foo.example.com." with RCODE=3 (authoritative name
error). "
To:
"As a result, "foo.example.com." cannot reply to an LLMNR query
for
"child.foo.example.com." with RCODE=3 (authoritative name
error)."
Replace the first paragraph of Section 2 with the following:
"LLMNR is a peer-to-peer name resolution protocol that is not intended
as
a replacement for DNS.
Typically a host is configured as both an
LLMNR sender and a responder.
A host MAY be configured as a sender, but not a
responder. However,
a host configured as a responder MUST act as a sender to
verify
the uniqueness of names as described in Section 4.
LLMNR usage
MAY be configured manually or automatically on a per interface
basis. By
default, LLMNR responders SHOULD be enabled on all interfaces, at all
times."
Change Section 2.2 to the following:
"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]. The response MUST be sent to the sender via unicast.
In
responding to queries:
[a] Responders MUST NOT respond using cached data,
and the AA
(Authoritative Answer) bit MUST be set.
[b] If a responder
receives a query with the header containing the RD
bit set, the responder
MUST ignore the RD bit.
[c] Responders MUST listen on UDP port TBD on the
link-scope multicast
address(es) defined in Section 2, and on UDP and TCP
port TBD on
the unicast address(es) that could be set as the source
address(es)
when the responder responds to the LLMNR query.
[d]
Responders MUST NOT respond to LLMNR queries for names they are
not
authoritative for.
[e] A response to an LLMNR query MUST have
RCODE set to zero.
Responses with RCODE set to zero are referred to in this
document
as "positively resolved".
[f] Responders SHOULD respond to
LLMNR queries for names and addresses
they are authoritative for. This
applies to both forward and
reverse lookups.
[g] If a DNS server is
running on a host that supports LLMNR, the DNS
server MUST respond to LLMNR
queries only for the RRSets relating
to the host on which the server is
running, but MUST NOT respond
for other records for which the server is
authoritative. DNS
servers also MUST NOT send LLMNR queries in order to
resolve DNS
queries.
[h] If a responder is authoritative for a name,
it MAY respond with
RCODE=0 and an empty answer section, if the type of query
does not
match a RR that the responder has.
As an example, a host configured to respond to LLMNR queries for the
name
"foo.example.com." is authoritative for the name
"foo.example.com.". On
receiving an LLMNR query for an A RR with the
name "foo.example.com." the
host authoritatively responds with A RR(s)
that contain IP address(es) in the
RDATA of the resource record. If the
responder has a AAAA RR, but no A RR,
and an A RR query is received, the
responder would respond with RCODE=0 and
an empty answer section.
In conventional DNS terminology a DNS server
authoritative for a zone is
authoritative for all the domain names under the
zone appex except for
the branches delegated into separate zones. Contrary to
conventional
DNS terminology, an LLMNR responder is authoritative only for
the zone
appex.
For example the host "foo.example.com." is not
authoritative for the
name "child.foo.example.com." unless the host is
configured with
multiple names, including "foo.example.com."
and
"child.foo.example.com.". As a result, "foo.example.com." cannot
reply
to an LLMNR query for "child.foo.example.com." with
RCODE=3
(authoritative name error). The purpose of limiting the name
authority
scope of a responder is to prevent complications that could be
caused by
coexistence of two or more hosts with the names representing child
and
parent (or grandparent) nodes in the DNS tree, for
example,
"foo.example.com." and "child.foo.example.com.".
In this
example (unless this limitation is introduced) an LLMNR query
for an A
resource record for the name "child.foo.example.com." would
result in two
authoritative responses: RCODE=3 (authoritative name
error) received from
"foo.example.com.", and a requested A record - from
"child.foo.example.com.".
To prevent this ambiguity, LLMNR enabled
hosts could perform a dynamic update
of the parent (or grandparent) zone
with a delegation to a child zone. In
this example a host
"child.foo.example.com." would send a dynamic update for
the NS and glue
A record to "foo.example.com.", but this approach
significantly
complicates implementation of LLMNR and would not be acceptable
for
lightweight hosts."
Proposed resolution: Accept
Issue 55: Sender checks
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: December 3, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02303.html
Document:
LLMNR-25
Comment type: T
Priority: S
Section:
2-2.8
Rationale/Explanation of issue:
Section 2 states:
[4] Upon the reception of the response, the sender
performs the checks
described in Section 2.5. If these conditions are met,
then the
sender uses and caches the returned response. If not, then
the
sender ignores the response and continues waiting for the
response.
It is not clear what sender checks this paragraph is referring
to. Possibilities include
material in sections 2.3, 2.5, 2.8 and
3.1.
Section 2.3 does include some sender checks. For example:
"If
the sender of a TCP query receives a response not
using TCP, the response
MUST be silently discarded." There is also discussion of
handling of ICMP
"time exceeded" messages.
Section 2.5 does not specify checks to be made
by senders on reception of a response. For example, there are recommendations on
setting of TTL/hop count by senders, but no TTL check specified for receivers.
Since the sender MUST set the TTL/Hop Count field to 1, it is not possible for a
receiver to see a TTL/Hop Count field of 2 or larger. Yet no sender action is
specified upon reception of such a packet.
Within Section 2.5, the
following paragraph is present:
"A sender SHOULD prefer RRs including
reachable addresses where RRs
involving both reachable and unreachable
addresses are returned in
response to a query."
I do not believe that
this sentence implies a reachability test be done on received RRs.
Section 2.8 provides guidelines for sender processing of the authority
and additional section
of responses.
Section 3.1 talks about
responder responsibilities, but not sender checks. It includes the
sentence:
"Routable addresses MUST be included first in the response, if
available.
This encourages use of routable address(es) for establishment of
new
connections."
[Ralph Droms] Section 2.5, third paragraph: what is
an "unreachable address"; did
you intend "unroutable address"?
[BA]
Proposed fixes:
In Section 2, change:
"[4] Upon the reception of the response, the sender performs the
checks
described in Section 2.5. If these conditions are met, then
the
sender uses and caches the returned response. If not, then the
sender
ignores the response and continues waiting for the response."
to:
"[4] Upon reception of the response, the sender processes it."
In Section 2.5, delete:
"A sender SHOULD prefer RRs including reachable addresses where
RRs
involving both reachable and unreachable addresses are returned
in
response to a query."
In Section 2.1, add:
"Since the responder may order the RRs in the response so as to
indicate
preference, the sender SHOULD preserve ordering
in the response to the
querying application."
Proposed resolution: Accept
Issue 56: Miscellaneous NITs (Part
2)
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted:
December 3, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02296.html
Document:
LLMNR-25
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
In Section 2.3, first paragraph, states:
"Unicast queries SHOULD be sent when:
[...]
b. The sender
queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa"
or "ip6.arpa" zones."
I imagine the example list could just be
deleted.
Section 2.6: the retransmission strategy, use and computation
of
LLMNR_TIMEOUT isn't clear to me after reading this section. What
does
the first paragraph mean? Is this delay in addition to
any
exponential backoff delays for retransmitted queries? Will there
be
any unexpected behaviors from lumping all of the observed response
time
from different LLMNR responders into a single RTT computation?
In detail, how
would the algorithms in RFC 2988 be applied? Use the
RTT for the first
received response as the RTT value in the
computation in section 2? Is
LLMNR_TIMEOUT then the value of RTO, as
computed in (2.3):
RTO <-
SRTT + max (G, K*RTTVAR)
Finally, I can't find RTOinitial, RTOmin or
RTOmax anywhere in RFC
2988 or RFC 1122. Where do those variables come
from?
Section 3.2, sixth paragraph: [LLMNREnable] has expired (as far as I
can
tell) and was never picked up as a dhc WG action item, so I'm not
sure it
should be mentioned here.
Creation of RRs in an LLMNR
responder
----------------------------------------
The document refers to
"a RR owned by the responder" and "the
responder has a AAAA RR", but it's not
clear how an LLMNR would
manage these RRs or come to be configured with the
RRs. Should an
LLMNR implementer have in mind a model in which the LLMNR
responder
has a set of RRs managed in an internal store? Where do those
RRs
come from - synthesis based on the host name and or domain
name;
manual configuration?
[BA] Issue 26 discusses dynamic timer estimation. It was felt that
this
was preferred on fast links, since otherwise LLMNR_TIMEOUT would
have
to be chosen to have a fairly substantial static value
(e.g. 1 second) and
this would affect performance.
In Section 2.6, RTOinitial is the value used until an RTT measurement is
made. This
value is 3 seconds, as noted in Section 2 of RFC 2988 (2.1).
RTOmin
and RTOmax are the minimum and maximum RTO values as discussed
in
Section 2 of RFC 2988 (2.4) and (2.5). The intent was for the
LLMNR_TIMEOUT
value to include jittering (that is, it is RTO plus any
computed jitter).
In terms of lumping responders together, this may be
an issue in the case
where one responder responds much more slowly than
others. This could
cause its response to be ignored (and therefore not
concatenated with the
others). However, since LLMNR typically multicasts
queries, individual
estimates can't be made except for unicast queries.
With respect to PTR queries, we wanted to distinguish between
complete IP
addresses, for which it would be possible to form
a unicast query, and
incompletely formed addresses
(e.g. 137.54.204.in-addr.arpa) for which
formation of a
unicast query is not possible.
The reference to the LLMNREnable option is non-normative. My
understanding
was that there is perceived need, although I am not aware of
plans to
implement it. If there is no longer any interest in this
option, it can be removed.
In terms of the handling of RRs in an LLMNR responder, in most cases
RRs
will be synthesized, though manual configuration may
be required to enable
synthesis of some RRs. Typically
A, AAAA and PTR RRs are synthesized once an
IP address is
assigned, and an SOA is synthesized when there are other RRs.
[Ralph Droms]
I'm still not clear about the retransmission strategy described in
section 2.6. Does this text describe it correctly?
If an LLMNR query sent over UDP is not resolved
within
LLMNR_TIMEOUT, then a sender MAY repeat the transmission
of the
query in order to assure that it was received by a host
capable of
responding to it. Retransmission of UDP queries
SHOULD NOT be
attempted more than 3 times. Where LLMNR
queries are sent using
TCP, retransmission is handled by the
transport layer.
Because an LLMNR sender cannot know in advance if a query
sent
using multicast will receive no response, one response, or
more
than one response, the sender SHOULD wait for LLMNR_TIMEOUT
in
order to collect all possible responses, rather than
considering
the multicast query answered after the first
response is
received. A unicast query sender considers the query
answered after
the first response is received, so that it only
waits for
LLMNR_TIMEOUT if no response has been received.
An LLMNR sender SHOULD dynamically compute the value of
LLMNR_TIMEOUT for each transmission. It is suggested that
the
computation of LLMNR_TIMEOUT be based on the response times
for
earlier LLMNR queries sent on the same interface. For
example, the
algorithms described in RFC 2988 [RFC2988]
(including exponential
backoff) to compute an RTO, which is used
as the value of
LLMNR_TIMEOUT. Smaller values MAY be used
for the initial RTO
(discussed in Section 2 of [RFC2988],
paragraph 2.1), the minimum
RTO (discussed in Section 2 of
[RFC2988], paragraph 2.4), and the
maximum RTO (discussed in
Section 2 of [RFC2988], paragraph 2.5).
Recommended values are
an initial RTO of 1 second, a minimum RTO of
200ms, and a
maximum RTO of 20 seconds.
In order to avoid synchronization, the transmission of each
LLMNR
query and response MUST be delayed by a time randomly
selected from
the interval 0 to 200 ms."
[BA] There still are some basic problems. Using an RTO minimum of 200
ms
doesn't make sense if the jitter is 200 ms. Also, exponentially backing
off
on not receiving a response will result in very large RTO values if lots
of queries
are sent that never receive responses. This is very likely because
LLMNR will by
default send queries for any name that is not answered by DNS.
So I think that
the RTO maximum value needs to be a lot smaller, as does the
jitter. The RTO
minimum value should also probably be larger. Also jittering
of responses
probably doesn't make sense where the responses are known to be
UNIQUE.
Here are the proposed fixes:
Change Section 2.6 to the following:
"2.6. Retransmission and jitter
An LLMNR sender uses the timeout
interval LLMNR_TIMEOUT to
determine when to retransmit an LLMNR query and how
long to collect
responses to an LLMNR query.
If an LLMNR query sent
over UDP is not resolved within
LLMNR_TIMEOUT, then a sender MAY repeat the
transmission of the
query in order to assure that it was received by a host
capable of
responding to it. Retransmission of UDP queries SHOULD NOT
be
attempted more than 3 times. Where LLMNR queries are sent using
TCP,
retransmission is handled by the transport layer.
Because an LLMNR sender
cannot know in advance if a query sent
using multicast will receive no
response, one response, or more
than one response, the sender SHOULD wait for
LLMNR_TIMEOUT in
order to collect all possible responses, rather than
considering
the multicast query answered after the first response
is
received. A unicast query sender considers the query answered after
the
first response is received, so that it only waits for
LLMNR_TIMEOUT if no
response has been received.
An LLMNR sender SHOULD dynamically compute
the value of
LLMNR_TIMEOUT for each transmission. It is suggested that
the
computation of LLMNR_TIMEOUT be based on the response times
for
earlier LLMNR queries sent on the same interface.
For example,
the algorithms described in RFC 2988 [RFC2988]
(including exponential
backoff) to compute an RTO, which is
used as the value of LLMNR_TIMEOUT.
Smaller values MAY be
used for the initial RTO (discussed in Section 2 of
[RFC2988],
paragraph 2.1), the minimum RTO (discussed in Section 2 of
[RFC2988], paragraph 2.4), and the maximum RTO (discussed in
Section 2
of [RFC2988], paragraph 2.5).
Recommended values are an initial RTO of 1
second, a minimum RTO of
200ms, and a maximum RTO of 5 seconds.
In order
to avoid synchronization, the transmission of each
LLMNR query and response
SHOULD delayed by a time randomly selected
from the interval 0 to 100 ms.
This delay MAY be avoided by responders
responding with RRs which they have
previously determined to be UNIQUE
(see Section 4 for details)."
Proposed resolution: Discuss
Issue 57: Organizational
improvements
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: December 13, 2003
Reference:
Document: LLMNR-26
Comment type: E
Priority: 1
Section:
Various
Rationale/Explanation of issue:
Details of multicast address usage belong upfront, not buried in Section 2.4.
Section 3.1 has little to do with "Usage model"; it should be moved to
Section 2.
Material related to hop count/ttl usage is included in Section 2.3
as well as
Section 2.5. It should be consolidated in Section 2.5.
Proposed changes:
Add the following sentence to Section 2.5:
"Section 2.3 discusses use
of TCP for LLMNR queries and responses."
Move the following paragraph
from Section 2.3 to Section 2.5 after the
next to last paragraph:
"The
Responder SHOULD set the TTL or Hop Limit settings on the TCP listen
socket
to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop
Limit (IPv6)
set to one (1). This prevents an incoming connection from
off-link since the
Sender will not receive a SYN-ACK from the Responder."
Move the material in Section 2.4 to Section 2 (e.g. multicast address usage).
Change references to Section 2.4 to Section 2 throughout the document.
Renumber Section 2.5 to Section 2.4.
Move Section 3.1 to Section 2.5.
Change references to Section 3.2 to refer to Section 3.1.
Proposed resolution: Accept
Issue 58: DNS server usage of
LLMNR
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: December 13, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02304.html
Document:
LLMNR-26
Comment type: T
Priority: S
Section:
2.2
Rationale/Explanation of issue:
DNS servers are prohibited from responding to LLMNR queries except with
RRs they own. However, DNS servers are not prohibited from sending
LLMNR
queries in order to resolve DNS queries received from DNS clients.
This
seems like a very bad idea.
Add the following sentence to Section 2.2:
"DNS servers also MUST NOT send LLMNR queries in order to resolve DNS queries."
[Olafur] I agree with this.
[Christian Huitema] I am not sure this is such a "very bad idea". Take the
example of an
IPv6 home network. The ISP explicitly delegates an IPv6 prefix
to the
home router. The router advertises this prefix. Hosts
configure
addresses from this prefix. Since there is explicit prefix
delegation to
the router, we may expect the router to also receive delegation
of the
reverse lookup tree. In these conditions, it makes a lot of sense to
use
LLMNR to fulfill a DNS PTR request. If you look at it, the chain
of
trust is exactly the same as what we have today in IPv4, when a
router
fulfills a PTR request using whatever name the host asserted in a
DHCP
request.
[Masataka Ohta] Wrong.
We expect that there are multiple nameservers
of a zone at
multiple locations.
We may expect that a router of a link
corresponding to a PTR
act as the primary nameserver of a zone containg the
PTR.
However, in this case, DHCP is the way for the router
maintain
information of the reverse zone.
LLMNR MUST NOT be queried from DNS
servers.
[Christian Huitema] This is just one scenario. I am convinced
there may be others. "MUST
NOT" is way too strong.
[Masataka Ohta] Your scenario merely is an example that stateless
autoconfiguration
and LLMNR is useless to the Internet. Unlike
stateless
autoconfiguration, however, LLMNR may be useful to an
isolated
IP network with a single link (with no routers).
Proposed resolution: Accept
Issue 59: Miscellaneous Issues
Submitter
name: Olafur Gudmundsson
Submitter email address: ogud@ogud.com
Date first
submitted: December 17, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02305.html
Document:
LLMNR-27
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
The draft could benefit from addition of a section gathering
in one place
all the requirements relating to the use of the
DNS packet format for LLMNR.
For example, use of the TC bit
is not defined and neither are the AD and CD
bits (which I
assume are set to zero).
In Section 2.2, change:
"In conventional DNS terminology a DNS server authoritative for a zone
is
authoritative for all the domain names under the zone root except
for
the branches delegated into separate zones. Contrary to
conventional
DNS terminology, an LLMNR responder is authoritative only for
the zone
root."
To:
"In conventional DNS terminology a DNS server authoritative for a zone
is
authoritative for all the domain names under the zone appex except
for
the branches delegated into separate zones. Contrary to
conventional
DNS terminology, an LLMNR responder is authoritative only for
the zone
appex."
In Section 2.2, change:
"Responders SHOULD respond to LLMNR queries for names and addresses
they
are authoritative for. This applies to both forward and
reverse lookups."
To:
"Responders MUST respond to LLMNR queries for names and addresses
they are
authoritative for. This applies to both forward and
reverse lookups."
Add the following paragraph to Section 2.2:
"Upon configuring an IP address responders typically will
synthesize
corresponding A, AAAA and PTR RRs so
as to be able to respond to LLMNR
queries for these
RRs. An SOA RR is synthesized only when a responder
has
another RR as well; the SOA RR MUST NOT be the only
RR that a responder
has.
However, in general whether RRs are manually or
automatically created
is an implementation decision."
Change Section 2.7 from:
"The responder should use a pre-configured TTL value in the
records
returned in the LLMNR query response. A default value of 0
is
recommended in highly dynamic environments (such as mobile
ad-hoc
networks). In less dynamic environments, LLMNR traffic can be
reduced
by setting the TTL to a higher value.
Due to the TTL
minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be
set to the same value."
To:
"The responder should use a pre-configured TTL value in the
records
returned in the LLMNR query response. A default value of 30
seconds
is RECOMMENDED. In highly dynamic environments (such as mobile
ad-hoc
networks), the TTL value may need to be reduced.
Due to the
TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST
be set to the same value."
[BA] Here are the proposed fixes:
In Section 2.2, change:
"In conventional DNS terminology a DNS server authoritative for a zone
is
authoritative for all the domain names under the zone root except
for
the branches delegated into separate zones. Contrary to
conventional
DNS terminology, an LLMNR responder is authoritative only for
the zone
root."
To:
"In conventional DNS terminology a DNS server authoritative for a zone
is
authoritative for all the domain names under the zone appex except
for
the branches delegated into separate zones. Contrary to
conventional
DNS terminology, an LLMNR responder is authoritative only for
the zone
appex."
In Section 2.2, change:
"Responders SHOULD respond to LLMNR queries for names and addresses
they
are authoritative for. This applies to both forward and
reverse lookups."
To:
"Responders MUST respond to LLMNR queries for names and addresses
they are
authoritative for. This applies to both forward and
reverse lookups."
Add the following paragraph to Section 2.2:
"Upon configuring an IP address responders typically will
synthesize
corresponding A, AAAA and PTR RRs so
as to be able to respond to LLMNR
queries for these
RRs. An SOA RR is synthesized only when a responder
has
another RR as well; the SOA RR MUST NOT be the only
RR that a responder
has.
However, in general whether RRs are manually or
automatically created
is an implementation decision."
Change Section 2.7 from:
"The responder should use a pre-configured TTL value in the
records
returned in the LLMNR query response. A default value of 0
is
recommended in highly dynamic environments (such as mobile
ad-hoc
networks). In less dynamic environments, LLMNR traffic can be
reduced
by setting the TTL to a higher value.
Due to the TTL
minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be
set to the same value."
To:
"The responder should use a pre-configured TTL value in the
records
returned in the LLMNR query response. A default value of 30
seconds
is RECOMMENDED. In highly dynamic environments (such as mobile
ad-hoc
networks), the TTL value may need to be reduced.
Due to the
TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST
be set to the same value."
Insert Section 2.1:
"2.1. LLMNR packet format
LLMNR utilizes the DNS packet format
defined in [RFC1035] Section 4 for
both queries and responses. Although
[RFC1035] restricts DNS queries
and responses to 512 octets in length, since
LLMNR operates only on the
local link, this restriction is not
applicable. LLMNR implementations MUST
accept queries and responses as
large as permitted by the link MTU.
LLMNR queries and responses utilize
the DNS header format defined in
[RFC1035] and [RFC2535], as illustrated
below:
1 1 1 1 1 1
0 1 2
3 4 5 6 7 8 9 0 1 2
3 4
5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ID
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|
Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QDCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ANCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
NSCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ARCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID
A 16 bit identifier assigned by the program that generates any
kind
of query. This identifier is copied from
the query to the response
and can be used by the
sender to match responses to outstanding
queries.
QR A one bit field that specifies whether
this message is an LLMNR
query (0), or an LLMNR
response (1).
OPCODE
A four bit field that
specifies kind of query in this message.
This value
is set by the originator of a query and copied into
the
response. LLMNR senders and responders
MUST support standard
queries (opcode value of
zero). Support for other opcode values is
OPTIONAL.
[TN] Didn't IQUERY get deprecated? That would seem to leave only STATUS.
I
guess that might be useful, if for no other reason than to see
which
nodes actually implemente LLMNR. Is this opcode in actual use in
the
dns?
AA Authoritative Answer. This bit is valid in
LLMNR responses, and
specifies that the responder is
an authority for the domain name in
the question
section. Since responders only respond to
LLMNR
queries for names and addresses they are
authoritative for, the AA
bit MUST be set in LLMNR
responses. If a sender receives a
response
with the header containing the AA bit not set, the
sender
MUST act as though the AA bit was set.
The AA bit MUST NOT be set
in LLMNR queries, and
MUST be ignored by LLMNR responders.
TC TrunCation -
specifies that this message was truncated due to
length greater than that permitted on the transmission
channel.
The TC bit MUST NOT be set in an LLMNR
query and if set is ignored
by a responder. If
the TC bit is set an LLMNR response, then the
sender
MAY use the response if it contains all necessary
information, or the sender MAY discard the response and resend
the
query over TCP using the unicast address of the
responder as the
destination address.
See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit.
RD
Recursion Desired. The RD bit MUST NOT be set in an LLMNR query
or
response. If a responder receives an LLMNR
query with the header
containing the RD bit set, the
responder MUST act as though the RD
bit was not
set. LLMNR senders MUST ignore the RD bit in
LLMNR
responses.
RA Recursion
Available. The RA bit MUST NOT be set in an LLMNR
query
or response. If the RA bit is set in an
LLMNR response, it MUST be
treated by the sender as
though it was not set. LLMNR responders
MUST
ignore the RA bit in LLMNR queries.
Z Reserved for
future use. MUST be zero in all LLMNR queries
and
responses. If these bits are set in an
LLMNR query or response,
they MUST be
ignored.
AD Authentic Data. The AD bit, defined in [RFC3655],
MUST NOT be set
in an LLMNR query, and if set is
ignored by responders. The AD bit
MAY be set
in an LLMNR response. Senders receiving a response
with
the AD bit set MUST act as though the AD bit
were not set unless
either IPsec or DNS transaction
security is used.
[TN] Why MAY? Elsewhere, you tend to say MUST be set to the
following
value, but if received, the value must be ignored. I.e, both
sides
MUST do something the same way. What is the purpose of of MAY
given
the receiver's MUST?
CD Checking Disabled. The CD
bit, defined in [RFC2535], MUST NOT be
set in an
LLMNR query or response. If the CD bit is set in
an
LLMNR query, it MUST be ignored by the
responder. LLMNR senders
MUST ignore the CD
bit in LLMNR responses.
RCODE
Response code -
this 4 bit field is set as part of LLMNR responses.
In both an LLMNR query and response the RCODE MUST be zero.
A
sender MUST ignore a response with an RCODE set to
another value.
[TN] note: does this document need to say anything about extended
RCODEs
and such (RFC 2671)?
Probably.
QDCOUNT
An unsigned 16 bit integer
specifying the number of entries in the
question
section. A sender MAY place more than one question
into
the question section of an LLMNR query.
LLMNR responders MUST
correctly handle LLMNR queries
containing more than one question,
by answering all
of the questions to which they have answers.
Any
questions in the question section of a received
LLMNR response MUST
be ignored by the sender.
[TN] Don't allow multiple questions. DNS allowed this in the original
spec,
but there are problems with it's use and its not been fleshed out.
I
recall there being reasons why it can't be done. (Ambiguity in
responses
and not knowing which question they referred
to.)
ANCOUNT
An unsigned 16 bit integer
specifying the number of resource
records in the
answer section. Any answers in the answer
section
of a received LLMNR query MUST be ignored by
the responder.
NSCOUNT
An unsigned 16 bit
integer specifying the number of name server
resource records in the authority records section.
Authority
record section processing is described in
Section 2.9.
ARCOUNT
An unsigned 16 bit
integer specifying the number of resource
records in
the additional records section. Additional
record
section processing is described in Section
2.9.
Add the following to the normative reference section:
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification",
RFC 2181, July 1997.
[RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the
DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[BA] Here is a revised Section 2.1:
2.1. LLMNR packet format
LLMNR utilizes the DNS packet format
defined in [RFC1035] Section 4 for
both queries and responses. Although
[RFC1035] restricts DNS queries
and responses to 512 octets in length, since
LLMNR operates only on the
local link, this restriction is not
applicable. LLMNR implementations
MUST accept queries and responses as
large as permitted by the link MTU.
2.1.1. LLMNR header
format
LLMNR queries and responses utilize the DNS header format defined
in
[RFC1035] and [RFC2535], as illustrated below:
1 1 1 1 1 1
0 1 2
3 4 5 6 7 8 9 0 1 2
3 4
5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ID
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|
Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QDCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ANCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
NSCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ARCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID
A 16 bit identifier assigned by the program that generates any
kind
of query. This identifier is copied from
the query to the response
and can be used by the
sender to match responses to outstanding
queries.
QR A one bit field that specifies whether this
message is an LLMNR
query (0), or an LLMNR response
(1).
OPCODE
A four bit field that specifies
kind of query in this message.
This value is set by
the originator of a query and copied into the
response. LLMNR senders and responders MUST support
standard
queries (opcode value of zero). LLMNR
queries MUST NOT be sent
with other OPCODE values,
and if sent, MUST be ignored by
responders.
AA Authoritative Answer. This bit is valid in
LLMNR responses, and
specifies that the responder is
an authority for the domain name in
the question
section. Since responders only respond to
LLMNR
queries for names and addresses they are
authoritative for, the AA
bit MUST be set in LLMNR
responses. If a sender receives a
response
with the header containing the AA bit not set, the
sender
MUST act as though the AA bit was set.
The AA bit MUST NOT be set
in LLMNR queries, and
MUST be ignored by LLMNR responders.
TC TrunCation -
specifies that this message was truncated due to
length greater than that permitted on the transmission
channel.
The TC bit MUST NOT be set in an LLMNR
query and if set is ignored
by a responder. If
the TC bit is set an LLMNR response, then the
sender
MAY use the response if it contains all necessary
information, or the sender MAY discard the response and resend
the
query over TCP using the unicast address of the
responder as the
destination address.
See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit.
RD
Recursion Desired. The RD bit MUST NOT be set in an LLMNR query
or
response. If a responder receives an LLMNR
query with the header
containing the RD bit set, the
responder MUST act as though the RD
bit was not
set. LLMNR senders MUST ignore the RD bit in
LLMNR
responses.
RA Recursion
Available. The RA bit MUST NOT be set in an LLMNR
query
or response. If the RA bit is set in an
LLMNR response, it MUST be
treated by the sender as
though it was not set. LLMNR responders
MUST
ignore the RA bit in LLMNR queries.
Z Reserved for
future use. MUST be zero in all LLMNR queries
and
responses. If these bits are set in an
LLMNR query or response,
they MUST be
ignored.
AD Authentic Data. The AD bit, defined in
[RFC3655], MUST NOT be set
in an LLMNR query or
response. If the AD bit is set in an LLMNR
query, it MUST be ignored by the responder. If the AD bit is
set
in an LLMNR response, LLMNR senders MUST act as
though the AD bit
were not
set.
CD Checking Disabled. The CD bit, defined in [RFC2535],
MUST NOT be
set in an LLMNR query or response.
If the CD bit is set in an
LLMNR query, it MUST be
ignored by the responder. LLMNR senders
MUST
ignore the CD bit in LLMNR responses.
"RCODE
Response code -- this 4
bit field is set as part of LLMNR
responses. In an LLMNR query, the RCODE
MUST be zero, and is
ignored by the responder. The RCODE MUST be zero in an
LLMNR response. Instead of sending a response with a
non-zero RCODE, an
LLMNR responder MUST NOT respond to a
query. A sender receiving an LLMNR
response with a
non-zero RCODE value MUST silently discard the
response."
QDCOUNT
An unsigned 16 bit integer specifying
the number of entries in the
question section.
A sender MUST place only one question into the
question section of an LLMNR query. LLMNR responders MUST
ignore
questions after the first
question.
ANCOUNT
An unsigned 16 bit integer
specifying the number of resource
records in the
answer section.
NSCOUNT
An unsigned 16 bit
integer specifying the number of name server
resource records in the authority records section.
Authority
record section processing is described in
Section 2.9.
ARCOUNT
An unsigned 16 bit
integer specifying the number of resource
records in
the additional records section. Additional
record
section processing is described in Section
2.9.
Add the following to the normative reference section:
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the
DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[Mike St. Johns]
In Section 2.1, it says:
"LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
for
both queries and responses. Although [RFC1035] restricts DNS
queries
and responses to 512 octets in length, since LLMNR operates only on
the
local link, this restriction is not applicable."
But in the draft
you have:
"In the future, it may be desirable to consider use of
multicast name resolution with multicast
scopes beyond the link-scope."
This suggests that playing with the length in this manner might be a bad
idea.
"LLMNR implementations MUST accept queries and responses as large
as permitted by the link MTU."
Above is OK I think.
"LLMNR queries
and responses utilize the DNS header format defined in
[RFC1035] and
[RFC2535], as illustrated below:"
Insert somewhere "but with some
exceptions as noted below."
"AA Authoritative Answer. This bit is valid in LLMNR responses,
and
specifies that the responder is an authority for the domain name
in
the question section. Since responders only respond to LLMNR
queries
for names and addresses they are authoritative for, the AA
bit MUST be set in
LLMNR responses. If a sender receives a
response with the header containing
the AA bit not set, the sender
MUST act as though the AA bit was set. The AA
bit MUST NOT be set
in LLMNR queries, and MUST be ignored by LLMNR
responders."
The right answer here is to delete the AA bit and just
declare that all LLMNR
transactions are authoritative. E.g. break with DNS
explicitly rather than try and
change the meaning of the bit. Mark the bit
reserved/don't care. Same comment
for RA and RD as or AA - delete the bit
and declare a fixed behavior.
" TC TrunCation - specifies that this message was truncated due to"
Does the TCP query get sent to LLMNR or to DNS? Probably useful to explictly
state
here.
" CD Checking Disabled. The CD bit, defined in [RFC2535], MUST NOT be
set
in an LLMNR query or response. If the CD bit is set in an
LLMNR query, it
MUST be ignored by the responder. LLMNR senders
MUST ignore the CD bit in
LLMNR responses."
I don't think I understand this. CD says that the client (sender) knows how
to do
DNSSEC resolution itself and just wants the records regardless or
whether or not the
server thinks the records are valid. Why?
"QDCOUNT
An unsigned 16 bit integer specifying the number of entries
in the
question section. A sender MUST place only one question into
the
question section of an LLMNR query. LLMNR responders MUST
ignore
questions after the first question. Any questions in the
question
section of an LLMNR response MUST be ignored by the
sender."
Hmm... no, actually I think its a better idea if any query with
a QDCOUNT <> 1 should
be considered malformed and dropped. Same for the
response where QDCOUNT<>0. Since
these are fixed values there's no
reason to invoke the robustness principle here.
(Generous in what you
accept).
"ANCOUNT
An unsigned 16 bit integer specifying the number of
resource
records in the answer section. Any answers in the answer
section
of a received LLMNR query MUST be ignored by the
responder."
See above - ANCOUNT<>0 in a query should be
dropped.
[BA] Here is a revised Section 2.1:
2.1. LLMNR packet format
LLMNR utilizes the DNS packet format defined
in [RFC1035] Section 4 for
both queries and responses. LLMNR
implementations SHOULD send UDP
queries and responses only as large as are
known to be permissible
without causing fragmentation. When in doubt a
maximum packet size of
512 octets SHOULD be used. LLMNR implementations
MUST accept UDP
queries and responses as large as permitted by the link
MTU.
2.1.1. LLMNR header format
LLMNR queries and responses
utilize the DNS header format defined in
[RFC1035] with exceptions noted
below:
0 1 2
3 4 5 6 7 8 9 0 1 2
3 4
5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ID
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|
Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QDCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ANCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
NSCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ARCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID A 16 bit identifier assigned by the program that
generates any kind
of query. This identifier
is copied from the query to the response
and can be
used by the sender to match responses to outstanding
queries. The ID field in a query SHOULD be set to a
pseudo-random
value.
QR A one bit
field that specifies whether this message is an
LLMNR
query (0), or an LLMNR response
(1).
OPCODE
A four bit field that specifies
the kind of query in this message.
This value is set
by the originator of a query and copied into the
response. This specification defines the behavior of
standard
queries and responses (opcode value of
zero). Future
specifications may define the
use of other opcodes with LLMNR.
LLMNR senders and
responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values
MUST
be silently discarded by
responders.
TC TrunCation - specifies that this message was
truncated due to
length greater than that permitted
on the transmission channel.
The TC bit MUST NOT be
set in an LLMNR query and if set is ignored
by an
LLMNR responder. If the TC bit is set an LLMNR
response,
then the sender MAY use the response if it
contains all necessary
information, or the sender
MAY discard the response and resend the
LLMNR query
over TCP using the unicast address of the responder
as
the destination address. See
[RFC2181] and Section 2.4 of this
specification for
further discussion of the TC bit.
Z Reserved for future
use. Implementations of this specification
MUST set these bits to zero in both queries and responses.
If
these bits are set in a LLMNR query or response,
implementations of
this specification MUST ignore
them. Since reserved bits could
conceivably be
used for different purposes than in DNS,
implementors are advised not to enable processing of these bits
in
an LLMNR implementation starting from a DNS code
base.
RCODE
Response code -- this 4 bit field
is set as part of LLMNR
responses. In an LLMNR
query, the RCODE MUST be zero, and is
ignored by the
responder. The response to a multicast LLMNR
query
MUST have RCODE set to zero. A sender
MUST silently discard an
LLMNR response with a
non-zero RCODE sent in response to a
multicast
query.
If an LLMNR responder is authoritative
for the name in a multicast
query, but an error is
encountered, the responder SHOULD send an
LLMNR
response with an RCODE of zero, no RRs in the answer
section,
and the TC bit set. This will cause
the query to be resent using
TCP, and allow the
inclusion of a non-zero RCODE in the response to
the
TCP query. Responding with the TC bit set is preferrable
to
not sending a response, since it enables errors
to be diagnosed.
Since LLMNR responders only
respond to LLMNR queries for names for
which they
are authoritative, LLMNR responders MUST NOT respond
with an RCODE of 3; instead, they should not respond at
all.
LLMNR implementations MUST support EDNS0
[RFC2671] and extended
RCODE
values.
QDCOUNT
An unsigned 16 bit integer
specifying the number of entries in the
question
section. A sender MUST place only one question into
the
question section of an LLMNR query. LLMNR
responders MUST silently
discard LLMNR queries with
QDCOUNT not equal to one. LLMNR senders
MUST
silently discard LLMNR responses with QDCOUNT not equal
to
one.
ANCOUNT
An unsigned 16 bit integer specifying the number of
resource
records in the answer section. LLMNR
responders MUST silently
discard LLMNR queries with
ANCOUNT not equal to zero.
NSCOUNT
An
unsigned 16 bit integer specifying the number of name
server
resource records in the authority records
section. Authority
record section processing
is described in Section 2.9.
ARCOUNT
An
unsigned 16 bit integer specifying the number of
resource
records in the additional records
section. Additional record
section processing
is described in Section 2.9."
Delete the following sentence from Section 2.2:
"An LLMNR query is composed in exactly the same manner and with the
same
packet format as a DNS query. "
Delete the following sentence from Section 2.3:
"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. "
Add the following to the IANA considerations section 6:
"This specification creates one new name space: the reserved bits in
the
LLMNR header. These are allocated by IETF Consensus, in accordance
with
BCP 26 [RFC2434]."
Add the following to the normative reference section:
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
Proposed resolution: Accept
Issue 60: Uniqueness check on
linkup
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted:
December 3, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02321.html
Document:
LLMNR-27
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
Section 4, fifth paragraph: I think the host should perform the
uniqueness
test when the interface is connected to a link (in addition
to the other
events in the bullet list).
[BA] I think this is probably correct, since while the
host was
disconnected, another host might have checked
for uniqueness of the name, and
not gotten a response.
As a result, once the host connects to the network, it
needs
to do a uniquenss check.
In order to avoid an impact on roaming
latency, it
probably makes sense for this check to be done
optimistically
-- the host does not respond to
LLMNR queries until it verifies uniqueness
of the
name, but it should be able to do other things,
such as initiate
TCP connections, etc. As a
result, the LLMNR name uniqueness test is
not
in the critical path for roaming.
Proposed fix is as
follows:
In Section 4, add to the list of events on which uniqueness
checking is
triggered:
"- detects that an interface is connected and is usable
(e.g. an IEEE 802
hardware link-state change indicating
that a cable was attached or that an
association has occurred
with a wireless base station and that any required
authentication
has completed)"
Proposed resolution: Accept
Issue 61: Miscellaneous
clarifications
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first
submitted: December 27, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02335.html
Document:
LLMNR-27
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
The specification does not discuss the required behavior with respect to destination address and ports.
In Section 2.3, add:
"[b] Responders MUST direct responses to the port
from which the query
was sent. When queries are received via TCP this is an
inherent
part of the transport protocol. For queries received by UDP
the
responder MUST take note of the source port and use that as
the
destination port in the response. Responses SHOULD always be sent
from
the port to which they were directed."
In Section 2.4, add:
"A
responder receiving a unicast query MUST send the response with a
source
address set to the destination address field of the IP header of
the query
causing the response."
Proposed resolution: Accept
Issue 62: RCODEs
Submitter name: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: December 31, 2003
Reference:
Document: LLMNR-28
Comment
type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
Is the RCODE in an LLMNR response to a standard query always 0?
Since LLMNR responders only respond to standard queries for names for
which
they are authoritative, LLMNR responders MUST NOT respond
to a
standard query with an RCODE of 3.
The use of the UPDATE opcode is not defined in this specification, br> so LLMNR responders will not respond with an RCODE of 6-10.
But what about other RCODEs in situations in which DNSSEC or DNS transaction security are used?
While I understand concerns about error storms, without error codes,
it
may be difficult to negotiate use of DNSSEC or diagnose problems.
For example, if DNS transaction security is used, aren't non-zero RCODEs useful?
What if DNSSEC is requested, but isn't available? Aren't non-zero RCODEs needed then as well?
Proposed fixes: Reject as a duplicate (already handled in Issue 59).
Proposed resolution: Reject (duplicate)Issue 63: Miscellaneous NITs (Part
3)
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted:
January 9, 2004
Reference:
Document: LLMNR-28
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of issue:
s/appex/apex/ ?
Should "reachable" or "reachable through the link" be
included in the
terminology section?
Section 2, fourth paragraph: what
are "upgraded hosts"?
Section 3.1, sixth paragraph: if LLMNR is to be
configured in the name
resolution mechanism through the DHCP Name Service
Search Option (NSSO),
there has to be some option concerning LLMNR whose
option code can be
carried in the NSSO data.
The discussion about
dynamic RTO computation seems OK.
I still think it would be useful to
include some text about the use of LLMNR
when responders are authoritative
for names that have only a single
component, for example, when the responders
are hosts on a home network where
users may enter a name with no domain. Here
is some text that might fit
into section 2.3:
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.ip6.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.
[BA] Suggested fixes:
Change "appex" to "apex" throughout the document.
Add the following definition of "reachable" to Section 1.2:
"An address is considered reachable over a link if either an ARP or neighbor
discovery
cache entry exists for the address on the link."
In section 2, change:
"Enabling LLMNR for use in situations where a DNS server has
been
configured will result in a change in default behavior
without a
simultaneous update to configuration information."
To:
"Enabling LLMNR for use in situations where a DNS server has
been
configured will result in a change in default behavior
without a
simultaneous update to configuration information."
In Section 3,.1, change:
" The order in which various name resolution mechanisms should be used can be
specified
using the Name Service Search Option for DHCP [RFC2937]."
To:
" The order in which various name resolution mechanisms should be used can be
specified
using the Name Service Search Option (NSSO) for DHCP [RFC2937],
using the
LLMNR Enable Option code carried in the NSSO data."
In Section 2.3, add:
"For example, a host configured 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.ip6.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."
Issue 64: TTL Revisited
Submitter name:
Olafur Gudmundsson
Submitter email address: ogud@ogud.com
Date first
submitted: March 15, 2004
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html
Document:
LLMNR-29
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
The chairs are looking for closure and rough consensus on this only
remaining issue for LLMNR. The solution below seems like a good solid compromise.
Is there any technical reason why this should not be adopted, please
state so before March 24'th.
Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal
From: Derek Atkins <derek@ihtfp.com>
Date: Tue, 24 Feb 2004 22:14:43 -0500
It sounds like you want two things here, but it also sounds like all
of them need to happen in the responder. The attacker could
theoretically send packets of any type, with any TTL. So you can't
trust anything you receive from the network. To this affect, I think:
1) We want the responder to try to determine that a request came from
the local network. The best way to do this is for the responder to
check that TTL=255 to make sure. If a TTL is less than 255 then it
originiated off-net and can be dropped.
2) We want the responder to make sure response packets don't go
off-net. In other words, we want the responder to respond with
TTL=1, to make sure it can't smurf.
So, to this affect:
a) an LLMNR requestor should send requests with TTL=255
b) an LLMNR responder should verify requests have TTL=255 -- if it is not
255 then it should drop the packet.
c) an LLMNR responder should respond with TTL=1
d) I dont' think an LLMNR requestor needs to check the response TTL.
The only issue this doesn't directly solve is a requester being
spoofed by an off-net attacker, but said attacker would need
to guess the transaction id of the request in order to send a
valid response, which is just as likely in LLMNR as it is in
standard DNS, so it can probably be ignored.
So, other than this issue, does this solve the issue?
[Christian Huitema]
Could we agree in any case that the TTL discussion does not apply when we use
TCP?
As far as I can tell, I would split the problem as
follow:
1) Source address is an IPv6 local-link address: must use
TTL=255, as per IPv6. No need for special code, this is done by the
stack.
2) Operation over TCP: three-ways handshake prevents spoofing.
Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1
provides additional benefit.
3) Multicast query: multicast routing
normally limits propagation of packet to the local link. On-link attackers can
spoof the source address; off-link attackers generally cannot send multicast
packets to the destination. Checking the TTL provides no protection against
on-link attackers (they can set whatever TTL value is expected). Checking that
the source address belongs to an "on-link" prefix prevents the "smurf attack to
an off-link target". Setting the TTL=1 in multicast queries prevent the side
effects of a rare bug in routers, but this bug may not be very frequent
anyhow.
4) UDP unicast query: spoofing of the source address is very
easy, including for off-link attackers. Checking TTL=255 protects against
spoofing by off-link sources. Checking that the source address belongs to a
local range also affords some protection.
5) UDP unicast response:
spoofing of the response requires guessing the transaction identifier, which in
practice requires an "on-link" attacker; TTL games do not protect against
on-link attackers. Setting the TTL to 1 protects against unwitting participation
in a DOS-attack to an off-link target, if the source address of the query was
spoofed.
6) Setting the TTL to either 1 or 255 will create failures in
some network topologies that support multicast but require packets to go through
a router -- some wireless networks and some ad hoc networks can have that
property.
In practice, checking TTL=255 is only useful in UDP unicast
queries, where it provides a slight incremental benefit over a simple check of
the source address prefix. Setting the TTL to 1 provides a limited benefit in
TCP operation, multicast queries and unicast responses, but contradicts the
requirement of TTL=255 for IPv6 link-local addresses. Setting to either value
will create operational problems in some future scenarios.
The simplest
solution is probably to remove all mentions of TTL checks from the LLMNR
document, and simply state that:
1) Nodes should verify that the source
address of queries belong to an authorized range;
2) The TTL field should be
set by the stack to whatever default value is adequate for the interface and the
source address (e.g., TTL=255 for IPv6 link-local addresses.)
[Mika
Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP
operation,
> multicast queries and unicast responses, but contradicts
the
> requirement of TTL=255 for IPv6 link-local addresses. Setting
to
> either value will create operational problems in some future
>
scenarios.
This is untrue. IPv6 does not require nor enforce hop limit
255 for
link-local addresses. Only ICMPv6 neighbor discovery packets use
hop
limit 255. This is not a constraint for LLMNR.
> The simplest
solution is probably to remove all mentions of TTL checks
> from the LLMNR
document, and simply state that:
> 1) Nodes should verify that the source
address of queries belong to an
> authorized range;
This seems
useful.
> 2) The TTL field should be set by the stack to whatever
default value
> is adequate for the interface and the source address
(e.g., TTL=255
> for IPv6 link-local addresses.)
Ok, although I
would rather suggest:
2) Use TTL=1 with TCP.
3) No TTL
requirements for UDP requests and responses, but recommend
setting to 255 for
compatibility with Rendezvous.
[Bernard Aboba]
I'm not sure how to define an "authorized range". A host may not know
all
the prefixes present on a given link.
TTL=255 on UDP request & responses only works if UDP unicast requests
are prohibited. Otherwise, LLMNR would send unicast PTR RR queries
off
the local link, which is not acceptable.
An alternative would be to have
no TTL requirements for multicast UDP
request and unicast UDP responses, but
setting to 255 for compatibility
with Rendezvous. But requiring either TTL=1
for UDP unicast queries or
get rid of unicast UDP queries entirely.
[Christian Huitema]
Getting rid of unicast UDP queries would be by far the
most robust
solution. Multicast routing pretty much guaranties that a
multicast
request only travels one single hop; the TCP 3-ways handshake
combined
with TTL=1 also guarantees an on-link peering.
The residual
risk is address spoofing by an on-link source, to enroll
the LLMNR responder
in a reflection attack. But as long as we devise the
protocol so that only
one node respond to a query, we have not created
an extra vulnerability.
Regular DNS servers are just as easy to enroll
in a reflection attack...
[Joshua Graessley]
The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet.
[Ted Lemon] I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work?
[Mika Liljeberg] As far as I can see, that is only a problem with PTR
queries, which
often fail anyway. And I'd wager overlaid subnets are not a
very common
configuration. Do you think this is something we need to worry
about?
In practice, I don't believe this issue will arise.
Section 1
says:
"The assumption is that if a network has a gateway,
then the
network is able to provide DNS server configuration."
Therefore in the
"overlapping subnet" case LLMNR
assumes that the host has DNS configuration.
From early
on, LLMNR has assumed that the gateway supports the
resolution of the names of local hosts using DHCPv4 and
dynamic DNS
update. However, this assumption cannot be
made for IPv6 at this
point.
So if we are talking about multiple subnets on a link in
IPv4,
then a conventional DNS query will be sent first,
and local names can be
resolved by the gateway. If we are
talking about IPV6, then Router
Advertisement enables
the host to become aware of the multiple subnets,
so
that TCP-based queries can be sent on the local
link, rather than forwarded
by a router.
In terms of the text, here's what section 2.4 says:
"Unicast queries SHOULD be sent when:
[a] A sender repeats a
query after it received a response with the TC
bit set to the previous LLMNR
multicast query, or
[b] The sender queries for a PTR RR of a fully formed
IP address within
the "in-addr.arpa" or "ip6.arpa" zones."
So the
issue can arise if the TC bit is set in any response; or in a query for a PTR
RR.
[Bernard Aboba] Here is the proposed resolution:
In Section 2.4, change:
"Unicast LLMNR queries SHOULD be sent using
TCP."
To:
"Unicast LLMNR queries MUST be sent using
TCP."
Change:
"Unicast UDP queries MAY be responded to with a UDP
response containing
an empty answer section and the TC bit set, so as to
require the sender
to resend the query using TCP."
To:
"Unicast
UDP queries MUST be silently discarded."
Change:
"If an ICMP "Time
Exceeded" message is received in response to a unicast
UDP query, or if TCP
connection setup cannot be completed in order to
send a unicast TCP query,
this is treated as a response that no records
of the specified type and class
exist for the specified name (it is
treated the same as a response with
RCODE=0 and an empty answer
section). The UDP sender receiving an ICMP "Time
Exceeded" message
SHOULD verify that the ICMP error payload contains a valid
LLMNR query
packet, which matches a query that is currently in progress, so
as to
guard against a potential Denial of Service (DoS) attack. If a
match
cannot be made, then the sender relies on the retransmission and
timeout
behavior described in Section 2.7."
To:
"If TCP
connection setup cannot be completed in order to
send a unicast TCP query,
this is treated as a response that no records
of the specified type and class
exist for the specified name (it is
treated the same as a response with
RCODE=0 and an empty answer
section)."
In Section 2.5,
change:
"In composing LLMNR queries, the sender MUST set the Hop Limit
field in
the IPv6 header and the TTL field in IPv4 header of the response to
one
(1). Even when LLMNR queries are sent to a link-scope
multicast
address, it is possible that some routers may not properly
implement
link-scope multicast, or that link-scope multicast addresses may
leak
into the multicast routing system. Therefore setting the IPv6 Hop
Limit
or IPv4 TTL field to one provides an additional precaution
against
leakage of LLMNR queries.
In composing a response to an LLMNR
query, the responder MUST set the
Hop Limit field in the IPv6 header and the
TTL field in IPv4 header of
the response to one (1). This is done so as to
prevent the use of LLMNR
for denial of service attacks across the
Internet.
Section 2.4 discusses use of TCP for LLMNR queries and
responses. The
responder SHOULD set the TTL or Hop Limit settings on the TCP
listen
socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or
Hop
Limit (IPv6) set to one (1). This prevents an incoming connection
from
off-link since the sender will not receive a SYN-ACK from the
responder."
To:
"Section 2.4 discusses use of TCP for LLMNR
queries and responses.
In composing an LLMNR query using TCP, the sender
MUST set the Hop Limit field in
the IPv6 header and the TTL field in the IPv4
header of the response to one
(1). The responder SHOULD set the TTL or Hop
Limit settings on the TCP listen
socket to one (1) so that SYN-ACK packets
will have TTL (IPv4) or Hop
Limit (IPv6) set to one (1). This prevents an
incoming connection from
off-link since the sender will not receive a SYN-ACK
from the responder.
For UDP queries and responses the Hop Limit field in
the IPv6 header,
and the TTL field in the IPV4 header MAY be set to any
value. However,
it is RECOMMENDED that the value 255 be used for
compatibility with
Apple Rendezvous."
In Section 5.1,
change:
"Since LLMNR is typically deployed in situations where no trust
model can
be assumed, it is likely that LLMNR queries and responses will
be
unauthenticated. In the absence of authentication, LLMNR reduces
the
exposure to such threats by utilizing queries sent to a
link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit
(IPv6)
fields to one (1) on both queries and responses.
A TTL of one
(1) was chosen so as to limit the likelihood that LLMNR can
be used to launch
denial of service attacks. For example, were the TTL
of an LLMNR Response to
be set to a value larger than one (1), an
attacker could send a large volume
of queries from a spoofed source
address, causing an off-link target to be
deluged with responses.
Utilizing a TTL of one (1) in LLMNR responses
ensures that they will not
be forwarded off-link. Using a TTL of one (1) to
set up a TCP connection
in order to send a unicast LLMNR query reduces the
likelihood of both
denial of service attacks and spoofed responses. Checking
that an LLMNR
query is sent to a link-scope multicast address should prevent
spoofing
of multicast queries by off-link attackers.
While this limits
the ability of off-link attackers to spoof LLMNR
queries and responses, it
does not eliminate it. For example, it is
possible for an attacker to spoof a
response to a frequent query (such
as an A or AAAA query for a popular
Internet host), and by using a TTL
or Hop Limit field larger than one (1),
for the forged response to reach
the LLMNR sender."
To:
"Since
LLMNR is typically deployed in situations where no trust model can
be
assumed, it is likely that LLMNR queries and responses will
be
unauthenticated. In the absence of authentication, LLMNR reduces
the
exposure to such threats by utilizing UDP queries sent to a
link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit
(IPv6)
fields to one (1) on TCP queries and responses.
Using a TTL of
one (1) to set up a TCP connection
in order to send a unicast LLMNR query
reduces the likelihood of both
denial of service attacks and spoofed
responses. Checking that an LLMNR
query is sent to a link-scope multicast
address should prevent spoofing
of multicast queries by off-link
attackers.
While this limits the ability of off-link attackers to spoof
LLMNR
queries and responses, it does not eliminate it. For example, it
is
possible for an attacker to spoof a response to a frequent query
(such
as an A or AAAA query for a popular Internet host), and by using a
TTL
or Hop Limit field larger than one (1), for the forged response to
reach
the LLMNR sender.
When LLMNR queries are sent to a link-scope
multicast
address, it is possible that some routers may not properly
implement
link-scope multicast, or that link-scope multicast addresses may
leak
into the multicast routing system.
Setting the IPv6 Hop Limit or
IPv4 TTL field to a value larger than one
in an LLMNR UDP response may enable
denial of service attacks across the
Internet. However, since LLMNR
responders only respond to queries
for which they are authoritative, and
LLMNR does not provide
wildcard query support, it is believed that this
threat is minimal."
Proposed resolution: Accept
Issue 65: IANA Assignment
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: May 15, 2004
Reference:
Document: LLMNR-30
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
The LLMNR specification does not include assignments of addresses and a TCP/UDP port, needed by implementers.
Change "port TBD" to "port 5355" throughout the document.
Change the first paragraph of Section 2 to:
" LLMNR is a peer-to-peer name resolution protocol that is not
intended
as a replacement for DNS. LLMNR queries are sent
to and received on
port 5355. IPv4 administratively scoped
multicast usage is specified
in "Administratively Scoped IP
Multicast" [RFC2365]. The IPv4 link-
scope multicast
address a given responder listens to, and to which a
sender
sends queries, is 224.0.0.252. The IPv6 link-scope
multicast
address a given responder listens to, and to which a
sender sends all
queries, is FF02:0:0:0:0:0:1:3."
Change paragraphs 2 and 3 of Section 6 to:
" LLMNR requires allocation of port 5355 for both TCP and
UDP.
LLMNR requires allocation of link-scope multicast IPv4
address
224.0.0.252, as well as link-scope multicast IPv6
address
FF02:0:0:0:0:0:1:3."
Proposed resolution: Accept
Issue 66: Unicast Query Cleanup
Submitter:
Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: June 24, 2004
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01214.html
Document:
LLMNR-31
Comment type: E
Priority: 1
Section:
2.4
Rationale/Explanation of issue:
While reading section "2.4. Unicast queries and responses", I think
it
might be clearer with few added (+) and deleted (-) lines. This is
just
for consideration. Idea is make it clear from upfront that
UNICAST == TCP
use!
----------------------------------------------------------
2.4.
Unicast queries and responses
Unicast queries SHOULD be sent
when:
[a] A sender repeats a query after it received a response
with
the TC bit set to the previous LLMNR multicast query, or
[b] The sender
queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa"
or "ip6.arpa" zones.
- A responder receiving a unicast query MUST send
the response with a
- source address set to the destination address field of
the IP header
- of the query causing the response.
- [above is unnecessary
statement, because it is implicitly true
- when using TCP!]
- Unicast
LLMNR queries MUST be sent using TCP. Senders MUST support
+ Unicast LLMNR
queries MUST be done using TCP and the responses MUST
+ be sent using the
same connection as the query. Senders MUST support
sending TCP queries, and
responders MUST support listening for TCP queries.
- Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection as the
query. If the sender of a TCP query
+ If the sender of a TCP
query
receives a response to that query not using TCP, the response MUST
be
silently discarded.
Unicast UDP queries MUST be silently
discarded.
If TCP connection setup cannot be completed in order to send
a
unicast TCP query, this is treated as a response that no records of
the
specified type and class exist for the specified name (it is
treated the same
as a response with RCODE=0 and an empty answer
section).
[Bernard Aboba] Proposed resolution:
Change Section 2.4 from:
"2.4. Unicast queries and responses
Unicast queries SHOULD be sent
when:
[a] A sender repeats a query after it received a response
with
the TC bit set to the previous LLMNR multicast query, or
[b] The sender
queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa"
or "ip6.arpa" zones.
A responder receiving a unicast query MUST send the
response with a
source address set to the destination address field of the IP
header
of the query causing the response.
Unicast LLMNR queries MUST
be sent using TCP. Senders MUST support
sending TCP queries, and responders
MUST support listening for TCP
queries.
Responses to TCP unicast LLMNR
queries MUST be sent using TCP, using
the same connection as the query. If
the sender of a TCP query
receives a response to that query not using TCP,
the response MUST be
silently discarded.
Unicast UDP queries MUST be
silently discarded.
If TCP connection setup cannot be completed in order
to send a
unicast TCP query, this is treated as a response that no records
of
the specified type and class exist for the specified name (it
is
treated the same as a response with RCODE=0 and an empty
answer
section)."
To:
"2.4. Unicast queries and responses
Unicast queries SHOULD be sent
when:
[a] A sender repeats a query after it received a response
with
the TC bit set to the previous LLMNR multicast query, or
[b] The sender
queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa"
or "ip6.arpa" zones.
Unicast LLMNR queries MUST be done using TCP and the
responses MUST
be sent using the same TCP connection as the query. Senders
MUST support
sending TCP queries, and responders MUST support listening for
TCP
queries. If the sender of a TCP query receives a response to that
query not using TCP, the response MUST be silently discarded.
Unicast
UDP queries MUST be silently discarded.
If TCP connection setup cannot be
completed in order to send a
unicast TCP query, this is treated as a response
that no records of
the specified type and class exist for the specified name
(it is
treated the same as a response with RCODE=0 and an empty
answer
section)."
Proposed resolution: Accept
Issue 67: Editorial Issues
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of issue:
> becomes ubiquitous. For example, expanded support for multicast
name
> resolution might be required for mobile ad-hoc networking
scenarios,
> or where no DNS server is available that is authoritative for
the
> names of local hosts, and can support dynamic DNS, such as
in
> wireless hotspots.
reword? sentence is hard to parse
(especially last part).
> by an LLMNR responder. If the TC bit is set an LLMNR
response,
s/an/in an/
> (e.g. A, AAAA, SRV, etc.) to the link-scope multicast
address.
s/e.g./e.g.,/
> Upon configuring an IP address responders typically will
synthesize
s/address/address,/
>
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.
>
ip6.arpa IN PTR host1.
> IN PTR host1.example.com.
Text should
somehow indicate that the above is one line that had to
be split for
formatting reasons...
> For UDP queries and responses the Hop Limit field in the IPv6
header,
s/responses/responses,/ and drop the last , ??
> The responder should use a pre-configured TTL value in the
records
> returned an LLMNR response. A default value of 30 seconds
is
s/an/in an/?
> The responder should use a pre-configured TTL
value in the records
> returned an LLMNR response. A default value of 30
seconds is
s/use a/insert a/ ??
[Bernard Aboba] Here are the proposed resolutions:
In Section 1 change:
" In the future, it may be desirable to consider use of multicast
name
resolution with multicast scopes beyond the
link-scope. This could
occur if LLMNR deployment is
successful, the need arises for
multicast name resolution beyond
the link-scope, or multicast routing
becomes ubiquitous.
For example, expanded support for multicast name
resolution
might be required for mobile ad-hoc networking scenarios,
or
where no DNS server is available that is authoritative for the
names of local hosts, and can support dynamic DNS, such as in
wireless hotspots."
To:
"In the future, it may be desirable to consider use of multicast name
resolution
with multicast scopes beyond
the link-scope. This could occur
if LLMNR deployment is successful,
the need arises for multicast name
resolution beyond the link-scope, or
multicast routing becomes ubiquitous.
For example, expanded support
for multicast name resolution might be
required for mobile ad-hoc
networks. "
Accept all the other editorial modifications.
Proposed resolution: Accept
Issue 68: Caching
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
> [e] Responders MUST NOT respond using cached data.
add something
like "learned from other LLMNR queries" (or DNS queries,
etc....)
> Where a host is configured to issue LLMNR queries on more than
one
> interface, each interface should have its own independent
LLMNR
> cache.
what exactly is in such a cache?
> [f] If a DNS server is running on a host that supports LLMNR, the
DNS
> server MUST respond to LLMNR queries only for the RRSets
relating
> to the host on which the server is running, but MUST NOT
respond
> for other records for which the server is authoritative.
DNS
> servers also MUST NOT send LLMNR queries in order to resolve
DNS
> queries.
Might be better to say something like "if the same
process/application
implements both LLMNR and DNS (e.g., for code sharing
purposes),
.... the must keep things logically separate".
[Bernard Aboba] The problems can occur whether LLMNR and DNS are implemented within the same process or not.
[Bernard Aboba] The proposed resolution is:
In Section 2.3, Change:
"Responders MUST NOT respond using cached data."
To:
"Responders MUST NOT respond using data from the LLMNR or DNS resolver cache."
In Section 4, delete:
" Where a host is configured to issue LLMNR queries on more than
one
interface, each interface should have its own independent
LLMNR
cache. "
Add the following to Section 4.1:
" Where a host is configured to issue LLMNR queries on more than
one
interface, each interface maintains its own independent
LLMNR
resolver cache, containing the responses to LLMNR
queries."
Proposed resolution: Accept
Issue 69: On-Link
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
> Reachable
> An address is considered reachable over a link if
either an ARP or
> neighbor discovery cache entry exists for the address
on the link.
funny definition, since an ARP/ND entry might exists but be
very old.
> For IPv4, an "on link" address is defined as a link-local
address
> [IPv4Link] or an address whose prefix belongs to a subnet on
the
> local link. For IPv6 [RFC2460] an "on link" address is either
a
> link-local address, defined in [RFC2373], or an address whose
prefix
> belongs to a subnet on the local link.
Actually 2461 has a
very specific definition of on-link. It's one
where the RA says the prefix is
"on link". This may in some cases be
different than what is stated above.
There maybe a subtle limitation
here. 2461 allows routers to say "nothing is
on link, send it to me",
even if it then forwards stuff back onto the same
link. This feature
is not being used today, but might be used in the
future.
[Bernard Aboba] Other than in the definition in Section 1.2,
the term
"reachable" is only used once in the document,
in Section 2.6 (Responder
responsibilities):
[b] If an IPv4 address is returned, it MUST be
reachable
through the link over which LLMNR is used.
Here the issue is
whether a responder may return a particular
IPv4 address in a response. For
that purpose it is not
relevant whether an ARP or NS/ND cache entry exists
for
that address on the sender or responder. It is only
relevant whether
the responder would respond to an
ARP or ND query for that address on the
interface over
which the LLMNR query arrived.
The proposed
resolution is as follows:
In Section 1.2, change:
Reachable
An
address is considered reachable over a link if either an ARP or
neighbor
discovery cache entry exists for the address on the
link.
To:
Reachable
An LLMNR responder considers one of its
addresses reachable
over a link if it will respond to an ARP or Neighbor
Discovery
query for that address sent over the link.
In Section 2.5,
change:
" For IPv4, an "on link" address is defined as a link-local
address
[IPv4Link] or an address whose prefix belongs to a subnet on
the
local link. For IPv6 [RFC2460] an "on link" address is either
a
link-local address, defined in [RFC2373], or an address whose
prefix
belongs to a subnet on the local link."
To:
" For IPv4,
an "on link" address is defined as a link-local address
[IPv4Link] or an
address whose prefix belongs to a subnet on the
local link. For IPv6
[RFC2460] an "on link" address is either a
link-local address, defined in
[RFC2373], or one belonging to a prefix
that a Router Advertisement indicates
is on-link [RFC2461]."
Add a normative reference to
[RFC2461]:
Narten, T., Nordmark, E. and W. Simpson,
"Neighbor
Discovery for IP Version 6 (IPv6), RFC 2461, December 1998.
Proposed resolution: Accept
Issue 70: Uniqueness
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
E
Priority: S
Section: Various
Rationale/Explanation of
issue:
> Every responder that responds to an LLMNR query AND includes a
UNIQUE
> record in the response:
This is an odd use/defn. of
UNIQUE. UNIQUE depends on there being only
one response. The words here seem
to say that the responder (if it
cares) needs to ensure this. But the wording
is weak. When does a
responder care about a UNIQUE record? If not, it won't
bother doing
any steps.
> [1] MUST verify that there is no other
host within the
> scope of the LLMNR query propagation that can
return
> a resource record for the same name, type and class.
What
responder cares about this?
If you are trying to say that there are
certain RRsets that must be
unique, then better just say that...
>
cache. 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.
again, I sense that a UNIQUE RR is something
that needs to be
configured. Are there words to that effect
somewhere?
> record, the host MUST respond. After the client receives
a response,
> it MUST check whether the response arrived on an interface
different
> from the one on which the query was sent. If the response
arrives on
> a different interface, the client can use the UNIQUE resource
record
> in response to LLMNR queries. If not, then it MUST NOT use
the
> UNIQUE resource record in response to LLMNR queries.
I'm
confused. Is this part of the uniqueness verification algorithm?
It seems
like the first sentence and the rest of the paragraph don't
quite go
together.
> record, the host MUST respond. After the client receives a
response,
Who is the client now? Is this not just requester?
> The sender MUST anticipate receiving multiple replies to the
same
> LLMNR query, in the event that several LLMNR enabled
computers
> receive the query and respond with valid answers. When this
occurs,
> the responses may first be concatenated, and then treated in the
same
> manner that multiple RRs received from the same DNS server would;
the
> sender perceives no inherent conflict in the receipt of
multiple
> responses.
Do you mean concatenate valid answers? it
doesn't make sense to
concatenate various errors, ...
> There are some scenarios when multiple responders MAY respond to
the
> same query. There are other scenarios when only one responder
MAY
> respond to a query. Resource records for which the latter
queries
MAY seems wrong here. MAY is not about implementation choices
(when
you receive them...)
[Bernard Aboba] The proposed resolution is as follows:
In
Section 2.2, add:
" The sender MUST anticipate receiving multiple
replies to the same
LLMNR query, in the event that several LLMNR enabled
computers
receive the query and respond with valid answers. When
multiple
valid answers are received, they may first be concatenated, and
then
treated in the same manner that multiple RRs received from the
same
DNS server would; the sender perceives no inherent conflict in
the
receipt of multiple responses."
Add the following definition to Section 1.2:
UNIQUE
There are some scenarios when multiple responders may respond to the
same
query. There are other scenarios when only one responder may
respond to a
query. Resource records for which only a single
responder is
anticipated are referred to as UNIQUE.
Resource record uniqueness is
configured on the responder,
and therefore uniqueness verification is the
responder's
responsibility.
Replace Section 4 with the following:
"4. Conflict resolution
The uniqueness of a
resource record depends on the nature of the name
in the query
and type of the query. For example it is expected
that:
- multiple hosts may respond to a
query for an SRV type record
- multiple hosts
may respond to a query for an A or AAAA
type
record for a cluster name
(assigned to multiple hosts in
the
cluster)
- only a single host may respond to a
query for an A or AAAA
type record
for a name.
By default, a responder SHOULD be configured to
behave as though all
RRs are UNIQUE on each interface on which
LLMNR is enabled. Prior to
including a UNIQUE resource
record in a response, for each UNIQUE
resource record in a given
interface's configuration, the host MUST
verify that there is no
other host within the scope of LLMNR query
propagation that can
return a resource record for the same name, type
and class on
that interface. Once a responder has verified the
uniqueness of a UNIQUE resource record, if it receives an LLMNR
query
for that resource record, it MUST
respond.
To verify uniqueness, a responder MUST send an
LLMNR query for each
UNIQUE resource record. If no
response is received after a suitable number of
attempts (see
Section 2.7), the responder can use the UNIQUE resource record
in
response to LLMNR queries. If a response is received,
the responder
MUST check whether the response arrived on an
interface different
from the one on which the query was
sent. If the response arrives on
a different interface,
the responder can use the UNIQUE resource
record in response to
LLMNR queries. If not, then it MUST NOT use
the UNIQUE
resource record in response to LLMNR queries.
Uniqueness
verification is carried out when the host:
-
starts up or is rebooted
- wakes from sleep (if the
network interface was inactive
during
sleep)
- is configured to respond to LLMNR queries
on an interface
enabled for transmission
and reception of IP traffic
- is configured to
respond to LLMNR queries using
additional
UNIQUE resource
records
- verifies the acquisition of a new IP
address and configuration
on an
interface
The name conflict detection mechanism doesn't
prevent name conflicts
when previously partitioned segments are
connected by a bridge. In
order to minimize the chance of
conflicts in such a situation, it is
recommended that steps be
taken to ensure name uniqueness. For
example, the name could be
chosen randomly from a large pool of
potential names, or the
name could be assigned via a process designed
to guarantee
uniqueness.
When name conflicts are detected, they SHOULD be
logged. To detect
duplicate use of a name, an
administrator can use a name resolution
utility which employs
LLMNR and lists both responses and responders.
This would allow
an administrator to diagnose behavior and
potentially to
intervene and reconfigure LLMNR responders who should
not be
configured to respond to the same name."
[Thomas Narten] Isn't there a potential chicken-and-egg situation where
two
nodes both attempt to verify uniqueness, but since neither
has
verified uniqueness, they don't respond to each other, and
both
conclude they can use the same name? I.e., ND would have this
problem
except that it deals with it be taking queries as an indication
that
someone else is also trying to use the same address. Is there
a
corresponding way of handling that case here?
[Bernard Aboba] Yes, the situation you describe is possible. However,
there is nothing in
an LLMNR query that indicates that the sender believes it
is the owner of
a UNIQUE name. So I'm not sure how this could be used
to break the
deadlock.
[Thomas Narten]
"If the response arrives on a different interface,
the responder can use the UNIQUE resource
record in response to LLMNR
queries."
The above is suspect, because you might have multiple interfaces on the same
link.
[Bernard Aboba] I'm not sure why a response would come back on
a
different interface, since responses MUST be sent to back to the
address
and port in the query. So perhaps that text can be deleted.
[Bernard Aboba] Here is an updated resolution:
Replace Section 4 with the following:
"4. Conflict
resolution
The uniqueness of a resource record depends on
the nature of the name
in the query and type of the query.
For example it is expected that:
-
multiple hosts may respond to a query for an SRV type
record
- multiple hosts may respond to a query
for an A or AAAA type
record for a
cluster name (assigned to multiple hosts
in
the
cluster)
- only a single host may respond to a
query for an A or AAAA
type record
for a name.
By default, a responder SHOULD be configured to
behave as though all
RRs are UNIQUE on each interface on which
LLMNR is enabled. Prior to
including a UNIQUE resource
record in a response, for each UNIQUE
resource record in a given
interface's configuration, the host MUST
verify that there is no
other host within the scope of LLMNR query
propagation that can
return a resource record for the same name, type
and class on
that interface. Once a responder has verified the
uniqueness of a UNIQUE resource record, if it receives an LLMNR
query
for that resource record, it MUST
respond.
To verify uniqueness, a responder MUST send an
LLMNR query for each
UNIQUE resource record. If no
response is received after a suitable number of
attempts (see
Section 2.7), the responder can use the UNIQUE resource record
in
response to LLMNR queries. If a response is received,
the responder
MUST NOT use the UNIQUE resource record in
response to LLMNR queries.
Uniqueness verification is
carried out when the host:
- starts up or is
rebooted
- wakes from sleep (if the network
interface was inactive
during
sleep)
- is configured to respond to LLMNR queries
on an interface
enabled for transmission
and reception of IP traffic
- is configured to
respond to LLMNR queries using
additional
UNIQUE resource
records
- verifies the acquisition of a new IP
address and configuration
on an
interface
The name conflict detection mechanism doesn't
prevent name conflicts
when previously partitioned segments are
connected by a bridge. It also
does not prevent deadlocks
where two hosts attempt to verify
uniqueness of the same RR, yet
neither can yet respond to queries since
uniqueness has not yet
been verified.
In order to minimize the chance of conflicts in such situations,
it is
recommended that steps be taken to ensure name uniqueness.
For
example, the name could be chosen randomly from a large pool
of
potential names, or the name could be assigned via a process
designed
to guarantee uniqueness.
When name
conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name
resolution
utility which employs LLMNR and lists both responses
and responders.
This would allow an administrator to diagnose
behavior and
potentially to intervene and reconfigure LLMNR
responders who should
not be configured to respond to the same
name."
Proposed resolution: Accept
Issue 71: Configuration
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
> [1] No manual or automatic DNS configuration has been
> performed.
If an interface has been configured with DNS
> server address(es), then
LLMNR SHOULD NOT be used as the
> primary name resolution mechanism on
that interface, although
> it MAY be used as a name resolution mechanism
of last resort.
DNS server addresses are not what I'd consider
"per-interface" information.
> Unless unconfigured hosts periodically retry configuration, an
outage
> in the DNS configuration mechanism will result in hosts
continuing to
> use LLMNR even once the outage is repaired. Since LLMNR
only enables
> linklocal name resolution, this represents an unnecessary
degradation
> in capabilities. As a result, it is recommended that hosts
without a
> configured DNS server periodically attempt to obtain
DNS
> configuration. For example, where DHCP is used for DNS
>
configuration, [RFC2131] recommends a maximum retry interval of 64
>
seconds. In the absence of other guidance, a default retry interval
> of
one (1) minute is RECOMMENDED.
Again, this seems simplistic. You should
not go back to your DHC
server every 64 seconds if has given you parameters
other than DNS.
> For example, if the configured DNS server responds to AAAA RR
queries
> sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3),
> then it will not be possible to resolve the names of
IPv6-only hosts.
> In this situation, LLMNR over IPv6 can be used for
local name
> resolution.
seems to narrow. Getting RCODE=3 for one
query, can't be generalized
to say AAAA is not supported at all by that
server.
[Bernard Aboba] Here are the proposed resolutions:
In Section 2, change:
" [1] No manual or automatic DNS configuration has been
performed. If an interface has been configured with DNS
server address(es), then LLMNR SHOULD NOT be used as the
primary name resolution mechanism on that interface, although
it MAY be used as a name resolution mechanism of last resort."
To:
" [1] No manual or automatic DNS configuration has been performed. If an interface has been configured with DNS server address(es), or if DNS server address(es) have been configured which apply to all interfaces, then LLMNR SHOULD NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a secondary name resolution mechanism."
In Section 3.1, change:
" Unless unconfigured hosts periodically retry configuration, an outage
in the DNS configuration mechanism will result in hosts continuing to
use LLMNR even once the outage is repaired. Since LLMNR only enables
linklocal name resolution, this represents an unnecessary degradation
in capabilities. As a result, it is recommended that hosts without a
configured DNS server periodically attempt to obtain DNS
configuration. For example, where DHCP is used for DNS
configuration, [RFC2131] recommends a maximum retry interval of 64
seconds. In the absence of other guidance, a default retry interval
of one (1) minute is RECOMMENDED."
To:
" An outage in the DNS configuration mechanism may result in hosts
continuing to use LLMNR even once the outage is repaired.
Since LLMNR only enables linklocal name resolution, this represents a
degradation in capabilities. As a result, hosts without a
configured DNS server may wish to periodically attempt to obtain DNS
configuration if permitted by the configuration mechanism in use.
In the absence of other guidance, a default retry interval
of one (1) minute is RECOMMENDED."
Change:
" For example, if the configured DNS server responds to AAAA RR queries
sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
then it will not be possible to resolve the names of IPv6-only hosts.
In this situation, LLMNR over IPv6 can be used for local name
resolution."
To:
" For example, if the configured DNS server responds to a AAAA RR query
sent over IPv4 or IPv6 with an authoritative name error (RCODE=3)
or RCODE=0 and an empty answer section, then a AAAA RR
query sent using LLMNR over IPv6 may be successful in
resolving the name of an IPv6-only host on the local link."
Proposed resolution: Accept
Issue 72: MAYs
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
> [b] Responders MUST direct responses to the port from which the
query
> was sent. When queries are received via TCP this is an
inherent
> part of the transport protocol. For queries received by UDP
the
> responder MUST take note of the source port and use that as
the
> destination port in the response. Responses SHOULD always be
sent
> from the port to which they were directed.
SHOULD is no good
here, unless you also specify what sender MUST do.
> [g] If a responder is authoritative for a name, it MAY respond
with
> RCODE=0 and an empty answer section, if the type of query does
not
> match a RR that the responder has.
why the MAY? Is this
useful? What impact does this have on a recipient??
> As an example, a
host configured to respond to LLMNR queries for the
> name
"foo.example.com." is authoritative for the name
> "foo.example.com.". On
receiving an LLMNR query for an A RR with the
> name "foo.example.com."
the host authoritatively responds with A
> RR(s) that contain IP
address(es) in the RDATA of the resource
> record. If the responder has a
AAAA RR, but no A RR, and an A RR
> query is received, the responder would
respond with RCODE=0 and an
> empty answer section.
above won't
happen if [g] is only a MAY....
> If an LLMNR query sent over UDP is not resolved within
LLMNR_TIMEOUT,
> then a sender MAY repeat the transmission of the query in
order to
> assure that it was received by a host capable of responding to
it.
MAY? Come on, this should be a SHOULD/MUST. It's hardly robust to
do
this query exactly one time.
[Bernard Aboba] Here is the proposed resolution:
In Section 2.3, change:
"Responses SHOULD always be sent from the port to which they were directed."
To:
"Responses MUST always be sent from the port to which they were directed."
In Section 2.3, change:
"If a responder is authoritative for a name, it MAY respond with
RCODE=0
and an empty answer section, if the type of query does not match a
RR
that the responder has."
To:
"If a responder is authoritative for a name, it SHOULD respond with
RCODE=0
and an empty answer section, if the type of query does not match a
RR
that the responder has."
In Section 2.7, change:
" If an LLMNR query sent over UDP is not resolved within
LLMNR_TIMEOUT,
then a sender MAY repeat the transmission of the
query in order to
assure that it was received by a host capable
of responding to it."
To:
" If an LLMNR query sent over UDP is not resolved within
LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of
the query in order to
assure that it was received by a host
capable of responding to it."
In Section 2.7, change:
" An LLMNR sender SHOULD dynamically compute the value of
LLMNR_TIMEOUT
for each transmission. It is suggested that
the computation of
LLMNR_TIMEOUT be based on the response times
for earlier LLMNR
queries sent on the same
interface.
For example, the algorithms described in RFC 2988
[RFC2988]
(including exponential backoff) compute an RTO, which
is used as the
value of LLMNR_TIMEOUT. Smaller values MAY
be used for the initial
RTO (discussed in Section 2 of
[RFC2988], paragraph 2.1), the minimum
RTO (discussed in Section
2 of [RFC2988], paragraph 2.4), and the
maximum RTO (discussed
in Section 2 of [RFC2988], paragraph 2.5).
Recommended
values are an initial RTO of 1 second, a minimum RTO of
200ms,
and a maximum RTO of 5 seconds."
To:
" An LLMNR sender SHOULD dynamically compute the value of
LLMNR_TIMEOUT
for each transmission. For example, the
algorithms described in RFC 2988 [RFC2988]
(including
exponential backoff) compute an RTO, which is used as the
value
of LLMNR_TIMEOUT. Smaller values MAY be used for the
initial
RTO (discussed in Section 2 of [RFC2988], paragraph
2.1), the minimum
RTO (discussed in Section 2 of [RFC2988],
paragraph 2.4), and the
maximum RTO (discussed in Section 2 of
[RFC2988], paragraph 2.5).
Recommended values are an initial RTO of 500 ms, a minimum RTO
of
100ms, and a maximum RTO of 5 seconds."
Proposed resolution: Accept
Issue 73: RCODEs/TSIG/DNSSEC
Submitter:
Thomas Narten
Submitter email address: narten@us.ibm.com
Date first
submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
> LLMNR implementations MUST support EDNS0 [RFC2671] and extended
>
RCODE values.
Is this necessary? Earlier, the spec says non-zero RCODEs
must be
ignored. Isn't an EDNS0 extended RCODE by definition non-zero
(I
couldn't quite tell from a quick check, but that would seem to be
the
case.)
> Responders SHOULD NOT perform DNS additional section processing,
>
except as required for EDNS0 and DNSSEC.
DNSSEC is a part of this?
> If an LLMNR responder is authoritative for the name in a
multicast
> query, but an error is encountered, the responder SHOULD send
an
> LLMNR response with an RCODE of zero, no RRs in the answer
section,
> and the TC bit set. This will cause the query to be resent
using
> TCP, and allow the inclusion of a non-zero RCODE in the response
to
> the TCP query. Responding with the TC bit set is preferable to
not
> sending a response, since it enables errors to be
diagnosed.
Don't follow the above. "but an error" is general (not just
for too
much data to fit in response). Why would requerying with TCP get
a
better response?
[Bernard Aboba] Here's what the specification says with respect to RCODE
values:
"In an LLMNR query, the RCODE MUST be zero, and is
ignored by
the responder. The response to a multicast LLMNR query
MUST have RCODE set to
zero. A sender MUST silently discard an
LLMNR response with a non-zero RCODE
sent in response to a
multicast query...
Since LLMNR responders only
respond to LLMNR queries for names for
which they are authoritative, LLMNR
responders MUST NOT respond
with an RCODE of 3; instead, they should not
respond at all."
So all non-zero RCODE values are ignored in LLMNR
queries
(unicast or multicast) and in responses to multicast
queries.
LLMNR responders never respond with RCODE=3 to any type of
query.
This was to avoid the situation where a multicast query could
elicit
an error response from multiple responders (e.g.
an authoritative response
from one responder, non-authoritative
errors from all other responders).
However, non-zero RCODE values are not prohibited in
responses to
unicast queries, and in addition a responder
can set the TC bit if there is a
non-zero RCODE to communicate.
It is somewhat difficult to envisage use of DNSSEC with
LLMNR, since
LLMNR does not support delegation of
trust and therefore a DNSSEC aware LLMNR
resolver would
be required. Nevertheless, LLMNR does support
resolution of
any name, and if all the signatories
in the trust chain were available on the
local link,
and a suitable trust anchor were provisioned, then
it might be
possible.
Similarly, it seems unlikely that TSIG will be used
with
LLMNR, but if it were, then we did not want
to prohibit use of the extended
RCODEs that would
be required.
In Section 2.9 ,
change:
"Responders SHOULD NOT perform DNS additional section
processing,
except as required for EDNS0 and DNSSEC."
To:
"In
LLMNR, the additional section is only intended for use by EDNS0, TSIG
and
SIG(0). As a result, senders MAY only include pseudo RR-types in
the
additional section of a query; responders MUST ignore the
additional
section of queries containing other RR types."
Change
Section 5.4 to:
"LLMNR implementations MAY support TSIG and/or SIG(0)
security mechanisms.
Since LLMNR does not support "delegated trust" (CD or AD
bits), and
LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR
is not
compatible with DNSSEC.
Since LLMNR implementations MAY NOT
support TSIG or SIG(0),
responses to LLMNR queries may be unauthenticated.
If
authentication is desired, and a pre-arranged security configuration
is
possible, then IPsec ESP with a null-transform MAY be used to
authenticate
unicast LLMNR queries and responses or LLMNR responses
to multicast queries.
In a small network without a
certificate authority, this can be most easily
accomplished through
configuration of a group pre-shared key for trusted
hosts."
Proposed resolution: Accept
Issue 74: Partial Responses/TC
Bit
Submitter: Thomas Narten
Submitter email address:
narten@us.ibm.com
Date first submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
> by an LLMNR responder. If the TC bit is set an LLMNR response,
>
then the sender MAY use the response if it contains all necessary
>
information, or the sender MAY discard the response and resend the
> LLMNR
query over TCP using the unicast address of the responder as
> the
destination address. See [RFC2181] and Section 2.4 of this
> specification
for further discussion of the TC bit.
section 9 of 2181 does not allow
use of a partial response. the issue
is that one can't know whether all the
data that one needs is in the
response. Should this spec be deviating from
DNS here? I suspect not,
especially since truncation should be much less of
an issue given the
requirement that the link MTU be supported.
[Bernard Aboba] Here is the proposed resolution:
In Section 2.1.1, change:
"If the TC bit is set in an LLMNR
response,
then the sender MAY use the response if it contains all
necessary
information, or the sender MAY discard the response and resend
the
LLMNR query over TCP using the unicast address of the responder as
the
destination address. See [RFC2181] and Section 2.4 of this
specification for
further discussion of the TC bit."
To:
"If the TC bit is set in
an LLMNR response,
then the sender SHOULD discard the response and resend
the
LLMNR query over TCP using the unicast address of the responder as
the
destination address. See [RFC2181] and Section 2.4 of this
specification for
further discussion of the TC bit."
Proposed resolution: Accept
Issue 75: Miscellaneous
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
> packet size of 512 octets SHOULD be used. LLMNR implementations
MUST
> accept UDP queries and responses as large as permitted by the
link
> MTU.
Some links support ridiculous MTUs (e.g., 65K). Would
it be useful to
place an upper bound on the max size to something big, but
not
ridiculous? E.g., 5K? 10k?
> queries. The ID field in a query
SHOULD be set to a pseudo-random
> value.
Does this need to be
unpredictable for security? If so, say so, and
perhaps cite the relevant
RFC.
[Bernard Aboba] The proposed resolutions are as follows:
In Section 2.1, change:
"When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST
accept UDP queries and responses as large as permitted by the link MTU."
To:
"When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link MTU or 8192 octets."
In Section 2.1.1, change:
"The ID field in a query SHOULD be set to a pseudo-random value."
To:
"The ID field in a query SHOULD be set to a pseudo-random value. For advice on generation of
pseudo-random values, please consult [RFC1750]."
Add to non-normative references:
[RFC 1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
Proposed resolution: Accept
Issue 76: Address preferences
Submitter:
Thomas Narten
Submitter email address: narten@us.ibm.com
Date first
submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type:
T
Priority: S
Section: 2.2, 2.6
Rationale/Explanation of
issue:
In Section 2.2:
"Since the responder may order the RRs in the response so as to
indicate
preference, the sender SHOULD preserve ordering in the
response to the
querying application."
this is a change from DNS.
In Section 2.6:
"Routable addresses MUST be included first in the
response, if
available. This encourages use of routable address(es)
for
establishment of new connections."
hmm.
[Bernard Aboba] In thinking this over, I'm not sure that putting
routable
addresses first is always correct.
For example, consider a sender that only has an IPv4LL address querying
a
responder that has both an IPv4LL *and* a routable address. In this
case, it
is better for the responder to include the IPv4LL address first
in the
response, since unless the sender can "ARP for any" then the
sender will not
be able to reach the routable address. Thus, a more
reasonable rule might be:
"Where multiple addresses represent valid responses to a query,
the
order in which the addresses are returned is as follows:
[d] If
the source address of the query is a link-scope address,
then the responder
SHOULD include a link-scope address first
in the response, if available.
[e] If the source address of the query is a routable address,
then
the responder MUST include a routable address first
in the response, if
available."
Proposed resolution: Accept
Issue 77: Per-interface
Configuration
Submitter: Thomas Narten
Submitter email address:
narten@us.ibm.com
Date first submitted: October 8, 2004
Reference:
Document: LLMNR-36
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue:
" [1] No manual or automatic DNS configuration has been
performed. If an
interface has been configured with DNS
server address(es), or if DNS server
address(es) have
been configured which apply to all interfaces, then
LLMNR
SHOULD NOT be used as the primary name resolution
mechanism on that
interface, although it MAY be used
as a secondary name resolution
mechanism."
I don't like even seeing the words "per-interface dns server
address"
because I don't think it makes sense and don't understand how
this
works. I also know of no IETF document that talks about
DNS
configuration stuff being per-interface. Can we just remove it? Is
it
even needed?
Indeed, the idea of using LLMNR on one interface, and
DNS on another
seems a bit strange. There is an architectural issue here.
Does an
application bind to an interface first, and then do address
lookups
after having eliminated addresses related to other interfaces, or
do
they bind to addresses first and then figure out which interface
is
used. I don't at all understand how this is implemented, unless this
is
all very visible to individual applications, which I somehow
doubt. Is
it?
[Bernard Aboba]
From an LLMNR perspective, all that matters is that DNS servers,
if
available, should be queried first, using whatever algorithm the
host
implements. Given this, the proposed resolution is as follows:
In Section 2, change:
" [1] No manual or automatic DNS configuration has been
performed. If an
interface has been configured with DNS
server address(es), or if DNS server
address(es) have
been configured which apply to all interfaces, then
LLMNR
SHOULD NOT be used as the primary name resolution
mechanism on that
interface, although it MAY be used
as a secondary name resolution
mechanism."
To:
"[1] No manual or automatic DNS configuration has been
performed. If DNS
server address(es) have been
configured, then LLMNR SHOULD NOT be used as
the
primary name resolution mechanism, although it MAY
be used as a
secondary name resolution mechanism."
Proposed resolution: Accept
Issue 78: UNIQUEness Probing
Submitter:
Thomas Narten
Submitter email address: narten@us.ibm.com
Date first
submitted: October 8, 2004
Reference:
Document: LLMNR-36
Comment type:
T
Priority: S
Section: 4
Rationale/Explanation of
issue:
"To verify uniqueness, a responder MUST send an LLMNR query
for
each UNIQUE resource record. If no response is received after
a
suitable number of attempts (see Section 2.7), the responder can
use the
UNIQUE resource record in response to LLMNR queries. If
a response is
received, the responder MUST NOT use the UNIQUE
resource record in response
to LLMNR queries."
It sounds like two nodes attempting to use the same
name at
the same time will end up both deciding that the name is not
in
use. Ooops.
Could we:
- use the source address of queries to
distinguish between queries
sent out for a "tentative" name vs. a query from
someone else?
- could we (if we see other simultaneous queries) say
"danger,
conflict may be present", and do some sort of random wait
before
trying again, so that two nodes doing the same thing will
wait
different times, with one presumably then able to grab the name?
Will this all be too complicated and take too long? I dunno. But
the
algorithm as specified now seems like it wil fail with
high
probability (e.g, recovery after powerfail scenario).
[Olafur Gudmundsson]
>ID A 16 bit identifier assigned by the
program that generates any kind
>of query. This identifier is copied from
the query to the response
>and can be used by the sender to match
responses to outstanding
>queries. The ID field in a query SHOULD be set
to a pseudo-random
>value. For advice on generation of pseudo-random
values, please
>consult [RFC1750].
>
>QR A one bit field that
specifies whether this message is an LLMNR
>query (0), or an LLMNR
response (1).
I think it is more common to say the bit is Clear or Set
than
using a value. (esthetic issue) (And you use that notation in
other
places).
>OPCODE
>A four bit field that specifies the kind of
query in this message.
>This value is set by the originator of a query and
copied into the
>response. This specification defines the behavior of
standard
>queries and responses (opcode value of zero).
Future
>specifications may define the use of other opcodes with
LLMNR.
>LLMNR senders and responders MUST support standard queries
(opcode
>value of zero). LLMNR queries with unsupported OPCODE values
MUST
>be silently discarded by responders.
>
>TC TrunCation -
specifies that this message was truncated due to
>length greater than that
permitted on the transmission channel.
>The TC bit MUST NOT be set in an
LLMNR query and if set is ignored
>by an LLMNR responder. If the TC bit is
set in an LLMNR response,
>then the sender SHOULD discard the response and
resend the LLMNR
>query over TCP using the unicast address of the
responder as the
>destination address. See [RFC2181] and Section 2.4 of
this
>specification for further discussion of the TC
bit.
>
>
>U UNIQUE - specifies that this message is a
UNIQUEness query. The U
>bit MUST NOT be set in an LLMNR response, and if
set is ignored by
>an LLMNR sender. If the U bit is set in an LLMNR query,
this
>indicates that the sender believes that it is authoritative for
the
>name. See Section 4.1 and 4.2 for discussion of name
conflict
>detection.
>
>C Conflict - specifies that a sender
has previously received multiple
Previously: In my mind this can be
anytime in the past I think a more
precise word needs to be
used.
s/previously/recently/ or s/previously//
>LLMNR responses to
this query. The C bit MUST NOT be set in an
>LLMNR response, and if set is
ignored by an LLMNR sender.
>Responders do not respond to LLMNR queries
with the 'C' bit set;
>since no response is expected, LLMNR senders do not
retransmit.
This text in my mind may lead to some confusion, how
about
saying
LLMNR senders do not retransmit.
Responders do not respond
to LLMNR queries with the 'C' bit set;
since no response is expected but may
start uniqueness verification process
as described in section 4.
[Markku Savela] Some thoughts
1) to
prevent cluster name always triggering the conflict resolution,
could the 'C'
bit be used in replies? Any name configured as a
cluster name would set the C
bit in reply. Thus, if multiple
replies are received, but all had C -bit set,
no conflict message
would need to be sent.
2) if there is a host with
configured cluster name, the cluster name
will always win the "conflict war",
as it keeps responding to
queries forever, regardless of 'U' bits..
3)
in 4.1. "Uniqueness Verification" there is
---
To verify uniqueness, a
responder MUST send an LLMNR query with the
'U' bit set for each UNIQUE
resource record. If no response is
received, the sender retransmits the
query, ...
---
Strickly speaking, if there is a conflict with unique
names, there
will be no actual response. Instead, there will be a query
with
'U'-bit. I suppose "response" in above is interpreted generally,
and
not just restricted to actual DNS response message.
The only case, where
an actual response may happen, is when the
name is configured as a cluster
name on some other node. This will
just reply normally.
4) Is 'U'-bit really useful?
The only
thing going for the 'U'-bit seems to be the case where a
node seeing
conflicting query with 'U'-bit directly surrenders, and
does not want to
defend it at all.
The only place where I would code this type of
"surrender", is the
initial unique testing when the interface comes up. But,
in that
case the old "query - response" logic worked just fine with
equal
number of exchanged messages.
If I have been using the name, I
would definitely code a defensive
'U'-bit transmissions. And, in case of
network join, triggered by
'C'-bit query, all nodes would do the same, each
resending their
'U'-bit queries, and eventually all stopping the use of the
name.
It would be clearer if some other logic was used, like
a)
everyone disables the name on first conflict, or
b) the winner is chosen
statically (like based on some value of
related RR, the highest/lowest
(address or something) wins, and
others surrender without defense -- the
winner, not receiving any
replies, of course, will do the retransmits, just
to be sure)
There doesn't seem to be any need for 'U'-bit in this
process?
[Bernard Aboba]
> 1) to prevent cluster name always triggering
the conflict resolution,
> could the 'C' bit be used in replies? Any name
configured as a
> cluster name would set the C bit in reply. Thus, if
multiple
> replies are received, but all had C -bit set, no conflict
message
> would need to be sent.
I think this makes sense. Where
the resource record is not UNIQUE, a
responder sets the 'C' bit set in the
response. A query is only sent with
the 'C' bit set if multiple responses
were received, and one or more of
them did not have the 'C' bit
set.
> 2) if there is a host with configured cluster name, the cluster
name
> will always win the "conflict war", as it keeps responding
to
> queries forever, regardless of 'U' bits..
A responder can
respond immediately to a query for a resource record that
is not UNIQUE,
since there is no uniqueness verification phase. Such a
host will never send
a query with the 'U' bit set. This implies that if
the cluster name were to
be configured *after* a host had previously
verified the UNIQUEness of the
resource record, then a conflict would only
be detected by a third party
obtaining multiple responses, some of which
did not have the 'C' bit
set.
Since a responder without a UNIQUE RR ignores queries with the 'C'
bit set
and does not send queries with the 'U' bit set, it continues to use
the
name. A host that believes that the RR is UNIQUE may elect to stop
using
the name, or may continue to use the name. So while the cluster
name
owner always 'wins' it is possible that the owner of a UNIQUE RR may
also
'win'.
> 3) in 4.1. "Uniqueness Verification" there is
>
---
> To verify uniqueness, a responder MUST send an LLMNR query with
the
> 'U' bit set for each UNIQUE resource record. If no response
is
> received, the sender retransmits the query, ...
>
---
>
> Strickly speaking, if there is a conflict with unique names,
there
> will be no actual response. Instead, there will be a query
with
> 'U'-bit. I suppose "response" in above is interpreted
generally,
> and not just restricted to actual DNS response
message.
If the responder had previously verified UNIQUEness, it will
indeed
respond. However, if multiple hosts are verifying
UNIQUEness
simultaneously, then they will send queries with the 'U' bit set,
to
create mutual awareness of a conflict.
In the above sentence, I
intended to distinguish between a situation where
a true response is received
(in which case the name is not used) and one
where a query with the 'U' bit
set is received (in which case the conflict
needs to be
resolved).
> The only case, where an actual response may happen, is
when the
> name is configured as a cluster name on some other node. This
will
> just reply normally.
Actually, a response can also occur
where a host booted earlier, and
successfully verified uniqueness. In this
case, that host would get to
keep using the name.
> 4) Is 'U'-bit
really useful?
>
> The only thing going for the 'U'-bit seems to be
the case where a
> node seeing conflicting query with 'U'-bit directly
surrenders, and
> does not want to defend it at all.
The 'U' bit
was first introduced to address the case where multiple hosts
are testing
UNIQUEness simultaneously (e.g. after power restoration).
Without the 'U'
bit, a responder could not know when it received a query
whether that
represented an attempt at UNIQUEness verification or not.
> The only
place where I would code this type of "surrender", is the
> initial unique
testing when the interface comes up. But, in that
> case the old "query -
response" logic worked just fine with equal
> number of exchanged
messages.
"Surrender" is only mandated in the case where a sender queries
for
UNIQUEness and gets a response with the 'U' bit set. If it receives
a
query with the 'U' bit set, it becomes aware of a conflict, and if
it
hasn't already sent a query with the 'U' bit set, it does so. At
that
point, it only surrenders if it chooses to do so, or if it
receives
conflict indications frequently enough to force
surrender.
> If I have been using the name, I would definitely code a
defensive
> 'U'-bit transmissions. And, in case of network join, triggered
by
> 'C'-bit query, all nodes would do the same, each resending
there
> 'U'-bit queries, and eventually all stopping the use of the
name.
The current language does not force surrender in the case where 'U'
bit
queries are received. A host *could* decide to continue to use the
name.
If other hosts are only querying for the name occasionally, it is
possible
that conflicts would only be rarely detected, in which case the
conflict
does no real harm, and all hosts can continue using the name. It is
only
in the case where conflicts become frequent that surrender is
required.
However, it is true that in that case all conflicting hosts would
stop
using the name.
> It would be clearer if some other logic was
used, like
>
> a) everyone disables the name on first conflict,
or
In the current draft, a host attempting UNIQUEness verification cannot
use
the name if it receives a response to a query with the 'U' bit set. So
if
a host had verified UNIQUEness and responds to such a query, it gets
to
keep the name if it wants to. Essentially this says that the first
host
to verify UNIQUEness wins. I think this is ok.
However, in the
case of partition, multiple hosts could have verified
UNIQUEness. Here
responders can choose to stop using the name, but if
they continue to use it
and the conflicts persist then they must stop.
This enables a host to
continue to use the name if it needs to and others
are willing to give it up.
This is not "fair" in the sense that an
implementation coding continued usage
will gain an advantage over
implementations that immediately surrender upon
conflict detection.
> b) the winner is chosen statically (like based
on some value of
> related RR, the highest/lowest (address or something)
wins, and
> others surrender without defense -- the winner, not receiving
any
> replies, of course, will do the retransmits, just to be
sure)
This would be "fair" in the sense that one implementation would not
gain
an advantage over another. However, on the other hand there
are
circumstances where giving up using of a name can be very
inconvenient.
For example, if my server is www.microsoft.com and an attacker
configures
his host to also advertise www.microsoft.com, should the
server
immediately surrender on first detecting a conflict, if it had
previously
verified UNIQUEness? I think it makes sense for it to defend the
name, and
only disable it if the problem persists.
> There doesn't
seem to be any need for 'U'-bit in this process?
The 'U' bit is only
needed in the case where multiple responders are
simultaneously verifying
UNIQUEness. In the case of partition healing,
the 'C' bit will suffice. A
sender receiving multiple responses, one or
more of which do not have the 'C'
bit set in the response, will send a
query with the 'C' bit set. On receiving
such a query, responders
believing the RR to be UNIQUE will send their own
query, without the 'C'
bit set.
If they receive a response, they will
have confirmed a conflict. The only
benefit that the 'U' bit might have in
this situation is if one or more of
the conflicting hosts did not receive the
query with the 'C' bit set. In
that case, the receipt of a query without the
'U' bit set would leave them
unaware of the existence of a
conflict.
[Bernard Aboba]
To address this, we suggest the addition of a 'T'entative bit, which is set when the responder has not yet verified uniqueness of the RRs in the Answer section.
Change the beginning of Section 2.1.1 to:
"2.1.1. LLMNR header format
LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z|TC| T| C| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+"
Add the following paragraph:"T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified
the uniqueness of the name. A sender receiving a response with the
'T' bit set MUST silently discard the response unless it is
received in response to a uniqueness query. A responder MUST
ignore the 'T' bit in a query, if set. When a response with the
'T' bit set is received in response to a uniqueness query, a
conflict has been detected and a responder MUST resolve the
conflict. Use of the 'T' bit is described in more detail in
Sections 4.1 and 4.2."
Proposed resolution: Accept
Issue 79: Constant Cleanup
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: December 26, 2004
Reference:
Document: LLMNR-37
Comment
type: E
Priority: 2
Section: 7
Rationale/Explanation of
issue:
Rather than including constant values throughout the text, these should be
reorganized into a separate section.
The proposed changes are as follows:
Change Section 2.7 to:
"2.7. Retransmission and jitter
An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
when to retransmit an LLMNR query and how long to collect responses
to an LLMNR query.
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer.
Because an LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
collect all possible responses, rather than considering the multicast
query answered after the first response is received. A unicast query
sender considers the query answered after the first response is
received, so that it only waits for LLMNR_TIMEOUT if no response has
been received.
An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
for each transmission. For example, the algorithms described in RFC
2988 [RFC2988] (including exponential backoff) compute an RTO, which
is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used
for the initial RTO (discussed in Section 2 of [RFC2988], paragraph
2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph
2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
paragraph 2.5).
In order to avoid synchronization, the transmission of each LLMNR
query and response SHOULD delayed by a time randomly selected from
the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responders responding with RRs which they have previously determined
to be UNIQUE (see Section 4 for details).
Recommended values for constants (including LLMNR_TIMEOUT if it is
set statically) are given in Section 7."
Add Section 7:
"7. Constants
The following timing constants are used in this protocol; they are
not intended to be user configurable.
JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (only if set statically)
RTOinit 500 ms (initial value of LLMNR_TIMEOUT)
RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT)
RTOmin 100 ms (minimum value of LLMNR_TIMEOUT)"
Proposed resolution: Accept
Issue 80: Multi-Protocol
Conflicts
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: March 3, 2005
Reference:
Document: LLMNR-38
Comment type:
T
Priority: 1
Section: 4.2
Rationale/Explanation of issue:
When LLMNR messages are sent over multiple protocols (IPv4 and IPv6),
some
interesting conflict scenarios can arise.
For example:
Host A
supports both IPv4 and IPv6 but only sends and responds to LLMNR queries
over IPv6. Host B supports IPv4 only and sends and responds to LLMNR queries
only
over IPv4. What happens if Host A and B configure the same name?
A sender (Host C) will send an LLMNR query and will get a single
response, whether
the query is sent over IPv4 or IPv6. However, when it sends
a query over IPv6,
Host A could respond with an A RR conflicting with the A
RR that Host B would
respond with if the query were sent over IPv4.
Since the sender only gets a single response, it never sends a query
with the 'C'
bit set. The responders never detect a conflict via the
uniqueness verification
mechanism.
Yet a conflict does exist.
[Bernard Aboba] My suggestion is that a host should only respond
with
resource records corresponding to protocols that it supports for use
with LLMNR.
If Host A only supports LLMNR over IPv6, it should not configure
an A RR, even
if it has an IPv4 address. Similarly, if Host A only supports
LLMNR over IPv4,
it should not configure a AAAA RR.
[Markku Savela]
The only icky case is when one host has only IPv6 and another has only IPv4. In such case they don't see each others queries or replies. They are as if they were on different interfaces/links. This is probably ok situation. If one has either IPv4 or IPv6 only, and other has both, then conflict is detected, because the one with both IPv4 and IPv6 will always reply (and will do uniqueness test for both IPv4 and IPv6).
There is one caution: currently, there is a special kludge for A and AAAA queries. A query is sent only over IPv4, and AAAA query is sent only over IPv6. Thus, uniqueness test on IPv4+6 host would have to a) avoid using A,AAAA in test query (use ANY, or some other) b) take care to send the test over IPv4 with A, and over IPv6 with AAAA [I'm not sure where this kludge came from, and whether it is still requirement on the current version (I guess I need to reread it :-). As far as real DNS is concerned, A/AAAA and the link type over which queries are sent, are independent.]
[Bernard Aboba]
Here is the proposed resolution:
In Section 2.6, add clause [d]:
" [d] When LLMNR is implemented on a
dual stack host, LLMNR SHOULD
be supported on both IPv4 and IPv6. An
implementation only
supporting LLMNR over IPv6 SHOULD NOT return IPv4
addresses;
an implementation only supporting LLMNR over IPv4 SHOULD
NOT
return IPv6 addresses."
Proposed resolution: Accept
Issue 81: Conflicts from Healing of a Network
Partition
Submitter: Thomas Narten
Submitter email address:
narten@us.ibm.com
Date first submitted: October 8, 2004
Reference:
Document: LLMNR-38
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
When a previously partitioned network heals, revealing one or more
name
conflicts, LLMNR does not detect these conflicts
since uniqueness
verification is not done periodically and responses are
sent via unicast, not
multicast.
[BA] Here is the proposed resolution:
In Section 2.1.1 add the following paragraph:
"C
Conflict. When set within a request, the 'C'onflict bit
indicates
that a sender has received multiple LLMNR
responses to this query
with the 'T' bit
clear. In an LLMNR response, the 'C' bit is
clear
if the responder considers the name in the
query to be UNIQUE;
otherwise the 'C' bit is
set. LLMNR senders do not retransmit
queries
with the 'C' bit set. When receiving an LLMNR query
with
the 'C' bit set, an LLMNR responder MUST NOT
respond, but will
attempt to verify the conflict, as
described in Section 4.2."
Change Section 4.1 and 4.2 to the following:
"4.1. Uniqueness Verification Before responding with the 'T' bit clear to a query for a UNIQUE name, a responder MUST verify that there is no other host within the scope of LLMNR query propagation using the same name on that interface. Prior to verifying uniqueness of a name, a responder MUST set the 'T' bit in responses to queries for that name. Once a responder has verified the uniqueness of a name, if it receives an LLMNR query for that name with the 'C' bit clear, it MUST respond, with the 'T' and 'C' bits clear. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface To verify uniqueness of a name, a responder MUST send an LLMNR query for the name with the 'C' bit clear over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). Any query type will do, including 'ANY'. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query. If so, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). For the purpose of uniqueness verification, the contents of the answer section in a response is irrelevant.
Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. LLMNR responders SHOULD NOT periodically attempt uniqueness verification. 4.2. Conflict Detection and Defense Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts which are now on the same link, trying to use the same name. In order to enable ongoing detection of name conflicts, when an LLMNR sender receives multiple LLMNR responses to a query, the sender behaves as follows: [1] Responses with the 'T' bit set MUST be silently discarded. [2] If multiple responses remain, the sender MUST check if the 'C' bit is clear in any of the remaining responses. If so, a potential conflict has been detected; the sender SHOULD send another query for the same name, type and class, this time with the 'C' bit set. The potentially conflicting resource records are included in the additional section. Responders receiving a query with the 'C' bit set behave as follows:
[3] Queries with the 'C' bit set are considered advisory and responders MUST verify the existence of a conflict before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond. [4] A responder receiving a query for a non-UNIQUE name with the 'C' bit set silently discards the query. A responder receiving a query for a UNIQUE name with the 'C' bit set MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received with the 'T' bit clear, then a conflict has been detected. An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST immediately stop using the name in response to LLMNR queries received over any supported protocol, if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the uniqueness verification query. After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available."
Delete DEFEND_INTERVAL from Section 7.
Proposed resolution: Accept
Issue 82: Conflict Merging
Submitter: Thomas
Narten
Submitter email address: narten@us.ibm.com
Date first submitted:
March 8, 2004
Reference:
Document: LLMNR-38
Comment type:
T
Priority: S
Section: 2.2
Rationale/Explanation of issue:
Section 2.2 states:
" The sender MUST anticipate receiving multiple replies to the
same
LLMNR query, in the event that several LLMNR enabled
computers
receive the query and respond with valid
answers. When multiple
valid answers are received, they
may first be concatenated, and then
treated in the same manner
that multiple RRs received from the same
DNS server would."
Is this really what you want in the case where responses conflict?
Merging of responses makes sense for RRs which are not expected to be UNIQUE,
but
What about merging of responses from conflicting responders?
Merged
conflicting responses will be cached according to the TTL, which
could
result in persistence of inconsistencies.
Example: merging of SRV RRs from
conflicting responders will result in
inconsistent weighting
[Bernard Aboba] Here is the proposed resolution:
In Section 2.2, change:
" The sender MUST anticipate receiving multiple replies to the
same
LLMNR query, in the event that several LLMNR enabled
computers
receive the query and respond with valid
answers. When multiple
valid answers are received, they
may first be concatenated, and then
treated in the same manner
that multiple RRs received from the same
DNS server would."
To:
" The sender MUST anticipate receiving multiple replies to the same
LLMNR query, in the event that several LLMNR responders receive the
query and respond with valid answers. When multiple valid answers
are received in response to a query (other than a uniqueness query),
they are treated as follows:
[1] Responses with the 'T' bit set are silently discarded.
[2] If all the remaining responses have the 'C' bit set, the responses
are concatenated and then treated in the same manner that multiple
RRs received from the same DNS server would.
[3] If one or more of the responses have both the 'C' and 'T' bits
clear, a conflict has been detected. The responses are
concatenated, but are not cached. A query for the same name, type
and class is sent, with the 'C' bit set. Conflict detection and
resolution is described in more detail in Section 4.2."
Proposed resolution: Accept
Issue 83: Conflict Definition
Submitter:
Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first
submitted: March 5, 2005
Reference:
Document: LLMNR-38
Comment type:
T
Priority: S
Section: 1.2
Rationale/Explanation of issue:
Could we just base the "uniqueness" just for plain <name>, and not to <name,RR> combination? I'm not quite sure what the proposed resolution actually recommends now... ----- 4.1. Uniqueness Verification Prior to including a UNIQUE resource record in a response with the 'T' bit clear, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. ---- Seems to indicate, that uniquenes is <name,RR> feature, but later ---- To verify uniqueness, a responder MUST send an LLMNR query with the 'C' bit clear, over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify uniqueness of a name by sending a query for the name with type='ANY'.
seems to indicate, that uniqueness is name only. (If not, then sending ANY won't work, because ANY does not need to return all RR's...)
[Bernard Aboba]
I agree that uniqueness is based on the name, not the <name,RR> combination. > 4.1. Uniqueness Verification > > Prior to including a UNIQUE resource record in a response with the > 'T' bit clear, for each UNIQUE resource record in a given interface's > configuration, the host MUST verify that there is no other host > within the scope of LLMNR query propagation that can return a > resource record for the same name, type and class on that interface. > ---- > > Seems to indicate, that uniquenes is <name,RR> feature, but later What this is trying to say is that the uniqueness of each RR must be verified in order to prevent a name conflict. Since sending an ANY query is only a SHOULD, it also might be possible to send individual queries. However, regardless of how it is done, if a conflict is detected, the name is not used in response to any query. Is there a way to make this more clear?
[Markku Savela]
If uniqueness is for name only, the test becomes very simple: send query using the name for whatever RR you want to use. The actual type of RR used in the query does not matter. Any other node that thinks it owns the name, will answer to the query. If it does not have any matching type of RR, the answer section is just empty.
Here is the proposed resolution:
In Section 1.2, change the definition of UNIQUE to the
following:
"UNIQUE
There are some scenarios when multiple responders
may respond to a
query. There are other scenarios when only one responder
may
respond to a query. A responder considers a name to be UNIQUE
if
multiple responses are not expected in response to a query for a
name,
regardless of the type and class."
Change Section 4 to the following:
"4. Conflict Resolution A responder considers a name to be UNIQUE if multiple responses are not expected in response to a query for that name, regardless of the type and class. By default, a responder SHOULD be configured to behave as though its names are UNIQUE on each interface on which LLMNR is enabled. When responding to a query for a UNIQUE name, the 'C' bit is clear in the response. Where the name in the query is not UNIQUE, an LLMNR responder sets the 'C' bit in the response. For example, where multiple responders may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster), the 'C' bit is set in the response, regardless of the type and class of the query. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name."
Proposed resolution: Accept
Issue 84: Chair Review
Submitter: Olafur Gudmundsson
Submitter email address:
ogud@ogud.com
Date first submitted: May 25, 2005
Reference:
Document:
LLMNR-39
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Sorry for taking so long,
The document is in good shape, after reading all
the messages that have
been sent out on the topic in the last year, diffed
all drafts from the
same timeframe, and read the document over like I never
saw it before,
here are few minor comments:
Section
1.2:
Reachable:
I had a minor trouble parsing this definition suggested
wording below:
An LLMNR responder considers one of its addresses reachable
over a
link if it will respond to an ARP or Neighbor Discovery query
for
that address sent over the link.
how about:
An LLMNR responder
considers one of its own addresses reachable over a
link if it will respond
to an ARP or Neighbor Discovery query for
that address received on that
link.
(change is s/sent over/received on/)
[Bernard Aboba] OK.
Nit: section 2.3
in examples do not start an
example continuation line in the first column.
ie:
IN PTR
host1.example.com.
[Bernard Aboba] OK.
Nit: section 2.3
Last paragraph the beginning
of the paragraph implies that
the restriction of scope of authority is still
open to
discussion. Rewrite as an example why restriction is
there.
"Without the restriction on authority ..."
[Bernard Aboba] How is this?
"Without the restriction on authority an
LLMNR query
for an A resource record for the name "child.foo.example.com."
would
result in two authoritative responses: RCODE=3 (authoritative name
error)
received from "foo.example.com.", and a requested A record -
from
"child.foo.example.com.". To prevent this ambiguity, LLMNR
enabled
hosts could perform a dynamic update of the parent (or grandparent)
zone
with a delegation to a child zone; for example a
host
"child.foo.example.com." could send a dynamic update for the NS
and
glue A record to "foo.example.com.". However, this approach
significantly
complicates implementation of LLMNR and would not be acceptable
for
lightweight hosts."
[Olafur] Just what I had in mind. While some
more details of complexity can be
given, I think this is just the right
amount.
2.5 Nit:
Apple renamed Rendezvous to Bonjour :-)
[Bernard Aboba] Fixed. Also added a reference to the Bonjour specification.
Reminder: need still some text about the situation where
LLMNR is enabled
for IPn and no DNS available,
but not for IPm there is DNS, IPn is the
default protocol to use
we need to mandate that DNS enabled protocol(s) be
tried first.
[Bernard Aboba] How about this?
In Section 2,
change:
"An LLMNR sender may send a request for any name.
However, by
default, LLMNR requests SHOULD be sent only when one of
the following
conditions are met:
[1] No manual or automatic DNS configuration has
been
performed. If DNS server address(es) have been
configured, then LLMNR
SHOULD NOT be used as the
primary name resolution mechanism, although it
MAY
be used as a secondary name resolution mechanism.
[2] DNS servers
do not respond.
[3] DNS servers respond to a DNS query with
RCODE=3
(Authoritative Name Error) or RCODE=0, and an
empty
answer section."
To:
"An LLMNR sender may send a
request for any name.
However, by default, LLMNR requests SHOULD be sent only
when one of
the following conditions are met:
[1] No manual or
automatic DNS configuration has been
performed. If DNS server
address(es) have been
configured, then LLMNR SHOULD NOT be used as
the
primary name resolution mechanism, although it MAY
be used
as a secondary name resolution mechanism.
For dual stack hosts
configured with DNS server
address(es) for one protocol but not
another,
this implies that DNS queries SHOULD be sent
over the
protocol configured with a DNS
server, prior to sending LLMNR
queries.
[2] DNS servers do not respond. For a dual stack
host,
the host SHOULD attempt to reach
DNS servers over all protocols on
which
DNS server address(es) are configured, prior
to use of
LLMNR.
[3] DNS servers respond to a DNS query with RCODE=3
(Authoritative
Name Error) or RCODE=0, and an empty
answer section."
[Olafur]
That seems to capture the intent.
Proposed resolution: Accept
Issue 85: General Comments
Submitter: Stuart Cheshire
Submitter email address:
cheshire@apple.com
Date first submitted: May 25, 2005
Reference:
Document: LLMNR-40
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Reading draft-ietf-dnsext-mdns-40.txt, the problem I ran into was trying
to understand what problem it is trying to solve. The abstract states
that it is for "ad-hoc networks operating without a Domain Name System
(DNS) server." Superficially that sounds all well and good, but what does
it really mean? When it says, "DNS server", does it mean "authoritative
name server", or "recursive name server"? The document needs to say
clearly which it is talking about, because they are very different
problems. One scenario is a device that has a name, but no authoritative
server to answer for that name. The other is a resolver client that wants
to look up a name, but has no recursive server to ask.
There are
several problems I can imagine this document *might* be trying
to
solve:
1. A device that has a conventionally allocated, properly
delegated,
fully-qualified domain name, but there is no (authoritative) name
server
to answer for that name.
2. A device that has *no*
conventionally allocated, properly delegated,
fully-qualified domain name,
because the user doesn't know how to do
that, or doesn't want to pay the
annual fee to register a domain, or
simply because the device has just
shipped from the factory, and doesn't
even have a human owner yet to go
through the steps of allocating and
assigning a unique FQDN for
it.
3. A client that wants to look up a host name, but there is no
authoritative name server for that name.
4. A client that wants to
look up a host name, but there is no recursive
name server available for the
client to talk to.
5. A client that wants to look up a host name, and
there is an
authoritative name server for that name, but for whatever reason
it's not
responding right now.
These are all very different
scenarios, and the document needs to state
clearly which, if any (or all) of
them it is addressing. Right now
reading the document feels a bit like
playing the shell game, where you
try (usually unsuccessfully) to keep track
of which shell has the pea
underneath as they slide around. Reading the
document, I kept finding
things that didn't work for one or more of the
above scenarios, but it
wasn't clear if that was a problem because it wasn't
clear if the
document was seeking to solve that particular problem.
[BA] A host implementing IPv6 may require LLMNR for name
resolution in
each of the scenarios you describe. For
example, an IPv6-only host may not
have a DNS server
configured, or it may have an anycast DNS server
address
configured, but there is no server present listening on
that
address that is reachable from the hosts's location.
There is also an
additional scenario not listed, which
is that a host may have an
authoritative name server
which may not answer for all RR types. For
example,
a home gateway may have a DNS server built-in which
may support
DDNS via DHCPv4. However, the DNS
server may only answer with A RRs, not AAAA
RRs, and
it may not answer queries over IPv6.
Scenario 1 cannot
necessarily be distinguished
from Scenario 5, or even Scenario 4. For
example, with IPv6,
anycast addresses can be configured for DNS servers, so
that a DNS
server address can be configured but there is no DNS server
listening on the anycast address. Also, it is possible that
a DNS server
may have been configured, but the host has moved to
an adhoc network where
that server is no longer reachable.
Perhaps if you would provide a list
of things that you found
that didn't work, then we could better address the
issue.
For example, a host configured to have computer name "host1" and
to
be a member of the "example.com" domain, and with IPv4
address
192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6
might be
authoritative for the following
records:
host1. IN A
192.0.2.1
IN AAAA
2001:0DB8::1:2:3:FF:FE:4:5:6
This seems to be the most egregious
pollution of the top level of the DNS
namespace. If I call my television
"tv.myhouse.", then that means it
answers for the name "tv." How does that
coexist with the global DNS
records for Tuvalu?
[BA] Since there is no concept of delegation in LLMNR, configuring
a host
to answer LLMNR queries for "tv.myhouse" or even "tv" will
not cause a
responder to answer queries for "foo.tv" or any other name within
the tv TLD.
2.5. "Off link" Detection
For IPv4, an "on
link" address is defined as a link-local address
[IPv4Link] or
an address whose prefix belongs to a subnet on the
local
link.
How does a given device *know* what subnets are on the local link?
To
know this, a device has to have perfectly accurate configuration
information, but the whole point of LLMNR is for scenarios where
configuration infrastructure has failed, and the device is left to fend
for itself as best it can. To be useful, the device has to be able to
operate even if some or all of its configuration information is wrong.
[BA] Section 2.5 should only relate to what source addresses a host
can
use in responding to an LLMNR query. However, there are also two
instances
where it also talks about whether a destination address
is "on link". By
removing those two instances we can remove the
need for the host to know what
prefixes are on the link, and only
depend on its knowing what addresses have
been assigned on which
interfaces.
Section 2.4 discusses use of TCP for LLMNR queries and
responses. In
composing an LLMNR query using TCP, the
sender MUST set the Hop Limit
field in the IPv6 header and the
TTL field in the IPv4 header of the
response to one (1).
The responder SHOULD set the TTL or Hop Limit
settings on the
TCP listen socket to one (1) so that SYN-ACK packets
will have
TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
prevents an
incoming connection from off-link since the sender will
not
receive a SYN-ACK from the responder.
A common enterprise configuration
is to have two or more IP subnets
overlayed on the same physical link. (You
can argue that this is
misconfiguration, but it is still common.) This means
that two laptops
sitting next to each other on the same Ethernet hub can be
apparently two
hops from each other. Setting the TTL to 1 means that half of
the LAN
becomes unreachable from the other half.
Also, how does this interact with multi-link subnets?
[BA] In this scenario, the router could send an ICMP redirect
if it wanted
the host to treat the other subnet as local. It
is also possible that the
router would include a built-in DNS
server so that LLMNR would not be
necessary.
With respect to "multi-link" subnets, some instances of
these
do not decrement TTL and others (MANET) do. In those that do,
my
understanding is that LLMNR queries will not propagate
beyond the link scope
either.
Since DNS PTR queries frequently fail, applications need
to
be prepared for this. So using TCP and setting
the TTL field to 1 for PTR RR
queries shouldn't have much
negative impact.
For
UDP queries and responses, the Hop Limit field in the IPv6
header
and the TTL field in the IPV4 header MAY be set to any
value.
However, it is RECOMMENDED that the value 255 be used
for
compatibility with Apple Bonjour [Bonjour].
Has this
compatibility been tested? I don't have access to any LLMNR
implementation.
(I don't even know if there are any LLMNR
implementations). Windows users
can easily test this by just downloaded
Bonjour for Windows.
<http://www.apple.com/bonjour/>
If
one of the LLMNR supporters could try it, that would be very useful
information.
[BA] To my knowledge compatibility has not been tested. Since
you
submitted the original comment that lead to the incorporation
of this text,
can you suggest something more appropriate?
IPv4 administratively scoped multicast usage is
specified
in "Administratively Scoped IP Multicast"
[RFC2365].
Does LLMNR use Administratively Scoped IP
Multicast?
The IPv4 link-
scope multicast
address a given responder listens to, and to which a
sender
sends queries, is 224.0.0.252.
Why this address? My mDNS protocol uses
link-local address 224.0.0.251
for consistency with Administratively Scoped
Multicast addresses, which
are allocated from the top down. 239.x.x.251 was
the Administratively
Scoped address group originally allocated for mDNS; for
consistency I
picked 224.0.0.251 as its link-local counterpart. The
Administratively
Scoped address group 239.x.x.252 is allocated for MZAP,
which does not
(as far as I know) have anything to do with
LLMNR.
[BA] 224.0.0.252 was the address assigned by IANA. The "252" has
no
broader significance. LLMNR does not use Administratively Scoped IP
Multicast.
<http://www.iana.org/assignments/multicast-addresses>
[BA] The proposed resolution is as follows:
Change the abstract to:
"The goal of Link-Local Multicast Name Resolution (LLMNR)
is to enable
name resolution in scenarios in which
conventional DNS name resolution is not
possible.
LLMNR supports all current and future
DNS formats, types and
classes, while operating on a separate port
from DNS, and with a distinct
resolver cache.
Since LLMNR only operates on the local link, it cannot be
considered a
substitute for DNS."
In Section 1, change:
" This document discusses Link Local Multicast Name Resolution
(LLMNR),
which utilizes the DNS packet format 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.
The goal of
LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These
include
scenarios in which hosts are not configured with the
address of a DNS
server, where configured DNS servers do not
reply to a query, or
where they respond with errors, as
described in Section 2. Since
LLMNR only operates on the
local link, it cannot be considered a
substitute for DNS."
To:
"This document discusses Link Local Multicast Name Resolution (LLMNR), which is based on the DNS packet format 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. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Usage scenarios (discussed in more detail in Section 3.1) include situations in which hosts are not configured with the address of a DNS server; where the DNS server is unavailable or unreachable; where there is no DNS server authoritative for the name of a host, or where the authoritative DNS server does not have the desired RRs, as described in Section 2."
Move the following sentence from Section 2 to Section 1:
"IPv4 administratively scoped multicast usage is specified
in
"Administratively Scoped IP Multicast" [RFC2365]."
In Section 2.5, change:
"2.5. "Off link" Detection For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]. A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link- scope multicast address or an "on link" unicast address. A responder MUST select a source address for responses that is "on link". The destination address of an LLMNR response MUST be an "on link" unicast address."
To:
"2.5. "Off link" Detection A sender MUST select a source address for LLMNR queries that is assigned on the interface on which the query is sent. The destination address of an LLMNR query MUST be a link-scope multicast address or a unicast address. A responder MUST select a source address for responses that is assigned on the interface on which the query was received. The destination address of an LLMNR response MUST be a unicast address."
Add the following sentence to Section 2.6:
"IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local addresses are defined in [RFC2373]."
Delete references to [RFC2460] and [RFC2461].
Proposed resolution: Accept
Issue 86: NITs
Submitter: Stuart Cheshire
Submitter email address:
cheshire@apple.com
Date first submitted: May 25, 2005
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document:
LLMNR-40
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Some other general comments and questions:
LLMNR implementations MUST
accept UDP queries
and responses as large as the smaller of the link
MTU or 8192
octets.
I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural
packet
size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header,
that leaves 8952 for the DNS message, which allows for an 8K resource
record to be carried (should such a thing ever be needed in future).
[BA] Is 9000 bytes the IP MTU or Ethernet Frame Size?
T
Tentative. The 'T'entative bit is set in a response if
the
responder is authoritative for the name, but has
not yet verified
the uniqueness of one or more of
the resource record(s) in the
answer section.
A responder MUST ignore the 'T' bit in a query, if
set. When a response with the 'T' bit set is received in
response
to a uniqueness query, a conflict has been
detected and a responder
MUST resolve the conflict
as described in Section 4.1.
The document says nothing about how response
with the 'T' bit set are to
be interpreted by senders. Should they be
ignored, or used in answer to
the question?
[BA] If a sender receives
a response to a normal query with the 'T' bit set,
the response is ignored.
If an LLMNR responder is authoritative for the
name in a multicast
query, but an error is
encountered, the responder SHOULD send an
LLMNR
response with an RCODE of zero, no RRs in the answer
section,
and the TC bit set.
What kind of
error is this anticipating? Either the responder knows the
answer, or it
does not. Some example of a plausible error would motivate
this
section.
[BA] Examples include error codes sent in response to TSIG
queries.
Upon configuring an IP address, responders typically will
synthesize
corresponding A, AAAA and PTR RRs so as to be able to
respond to
LLMNR queries for these RRs. An SOA RR is
synthesized only when a
responder has another RR as
well
Another RR in addition to A, AAAA and PTR?
If no response is received, the sender retransmits the query,
as
specified in Section 2.7. If a response is received
with the 'T' bit
clear, the responder MUST NOT use the name in
response to LLMNR
queries received over any protocol (IPv4 or
IPv6). If a response is
received with the 'T' bit set, the
responder MUST check if the source
IP address in the resp