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