Subject: Proposed changes to draft-ietf-dnsext-mdns-12.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Nov 2002 10:49:28 -0800 (PST)

Proposed Changes to draft-ietf-dnsext-mdns-12.txt
Bernard Aboba <[email-masked]>

Issue 12.1: LLMNR port usage
Requester: Bernard Aboba <[email-masked]>
Date: October 25, 2002
Section: 2, 2.2, 6.3, 7
Rationale for change:

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."

Proposed resolution: accept

----------------------------------------------
Issue 12-2: Terminology
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 1.2
Rationale for change:

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-3: Dual stack implementation issues
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 2
Rationale for change:

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.  By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can
provide name resolution 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 over IPv6 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 12-4: Sending of NXRRSET
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 2.5
Rationale for 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, 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 12-5: Concatenation of Responses
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 2.5
Rationale for 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, 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?

Proposed resolution: No change

It is possible that there may be RRs owned by multiple responders, and
therefore receiving multiple replies is not always evidence of a conflict.

----------------------------------------------------

Issue 12-6: LLMNR configuration
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 3.1
Rationale for 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.

	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.  On an interface where no manual or automatic DNS configuration has
been performed, LLMNR SHOULD be enabled."

Proposed Resolution: Accept

----------------------------------------------------

Issue 12-7: Dual stack LLMNR configuration
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 3.1
Rationale for 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.

	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:

"Note that it is possible for LLMNR to be enabled for use over IPv6 at
the same time it is disabled over IPv4, or vice versa. 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 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 hosts from resolving the
names of other IPv6-only hosts on the local link. In this situation, LLMNR
enables resolution of dynamic names, and it will be enabled for use over
IPv6, even though it is disabled for use over IPv4."

Proposed resolution: Accept
----------------------------------------------------

Issue 12-8: Conflict resolution
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 5
Rationale for 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.

	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 interface, the host MUST verify resource record uniqueness
for each UNIQUE resource record in that interface's cache."

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 12-9: Another conflict resolution issue
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 5, 2.1
Rationale for 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.

	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 12-11: Confusion on dual stack behavior
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 1
Rationale for change:

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 12-12: LLMNR Usage issues
Requester: Markku Savela <[email-masked]>
Date: July 26, 2002
Section: 6.2
Rationale for change:

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 hava 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 occational 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. Howabout 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 to behave in enviroment that has
multiple enclosing name resolutions:

- which order are queries sent (global -> site - > local or local ->
  site - > global, or something else?)

- are gueries 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, or where configured DNS servers do not reply to a query.

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.

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: Discuss

-------------------------------------------------

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 3 Nov 2002 19:52:43 +0100 (CET)

> 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.

   Erik

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Nov 2002 04:42:33 -0800 (PST)

> about this future or not.

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?

BTW, a version of the draft with all changes applied is available here:

http://www.drizzle.com/~aboba/dnsext/draft-ietf-dnsext-mdns-13.txt