draft-ietf-dnsext-mdns-19.txt

bind-3.2.

name "child.host.example.com." unless the host is configured with
multiple names, including "host.example.com."  and
"child.host.example.com.".  As a result, "host" cannot reply to a query
for "child" with NXDOMAIN.  The purpose of limiting the name authority
scope of a responder is to prevent complications that could be caused by
coexistence of two or more hosts with the names representing child and
parent (or grandparent) nodes in the DNS tree, for example,
"host.example.com." and "child.host.example.com.".

In this example (unless this limitation is introduced) an LLMNR query
for an A resource record for the name "child.host.example.com." would
result in two authoritative responses: a name error received from
"host.example.com.", and a requested A record - from
"child.host.example.com.".  To prevent this ambiguity, LLMNR enabled
hosts could perform a dynamic update of the parent (or grandparent) zone
with a delegation to a child zone.  In this example a host
"child.host.example.com." would send a dynamic update for the NS and
glue A record to "host.example.com.", but this approach significantly
complicates implementation of LLMNR and would not be acceptable for
lightweight hosts.

A response to a LLMNR query is composed in exactly the same manner as a
response to the unicast DNS query as specified in [RFC1035].  Responders
MUST NOT respond using cached data, and the AA (Authoritative Answer)
bit MUST be set.  The response is sent to the sender via unicast.  A
response to an LLMNR query MUST have RCODE set to zero.  Responses with
RCODE set to zero are referred to in this document as "positively
resolved".  LLMNR responders may respond only to queries which they can
resolve positively.

2.3.  Unicast queries and responses

Unicast queries SHOULD be sent when:

  a.  A sender repeats a query after it received a response
      with the TC bit set to the previous LLMNR multicast query, or

  b.  The sender's LLMNR cache contains an NS resource record that



Esibov, Aboba & Thaler       Standards Track                    [Page 6]





INTERNET-DRAFT                    LLMNR                      12 May 2003


      enables the sender to send a query directly to the hosts
      authoritative for the name in the query, or

  c.  The sender queries for a PTR RR.

If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP using the unicast
address of the responder.  The RA (Recursion Available) bit in the
header of the response MUST NOT be set.  If the RA bit is set in the
response header, the sender MUST ignore the RA bit.

Unicast LLMNR queries SHOULD be sent using TCP.  Responses to TCP
unicast LLMNR queries MUST be sent using TCP,  using the same connection
as the query.  If the sender of a TCP query receives a response not
using TCP, the response MUST be silently discarded.  Unicast UDP queries
MAY be responded to with an empty answer section and the TC bit set, so
as to require the sender to resend the query using TCP.  Senders MUST
support sending TCP queries, and Responders MUST support listening for
TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
the TCP listen socket to one (1) so that SYN-ACK packets will have TTL
(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
connection from off-link since the Sender will not receive a SYN-ACK
from the Responder.

If an ICMP "Time Exceeded" message is received in response to a unicast
UDP query, or if TCP connection setup cannot be completed in order to
send a unicast TCP query, this is treated as a response that no records
of the specified type and class exist for the specified name (it is
treated the same as a response with RCODE=0 and an empty answer
section). The UDP sender receiving an ICMP "Time Exceeded" message
SHOULD verify that the ICMP error payload contains a valid LLMNR query
packet, which matches a query that is currently in progress, so as to
guard against a potential Denial of Service (DoS) attack. If a match
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6.

2.4.  Addressing

IPv4 administratively scoped multicast usage is specified in
"Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-scope
multicast address a given responder listens to, and to which a sender
sends queries, is 224.0.0.251.  The IPv6 link-scope multicast address a
given responder listens to, and to which a sender sends all queries, is
TBD.






Esibov, Aboba & Thaler       Standards Track                    [Page 7]





INTERNET-DRAFT                    LLMNR                      12 May 2003


2.5.  Off-link detection

The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address.  On receiving an
LLMNR query, the responder MUST check whether it was sent to the LLMNR
multicast address; if it was sent to another multicast address, then the
query MUST be silently discarded.

For IPv4, an "on link" address is defined as a link-local address or an
address whose prefix belongs to a subnet on the local link; for IPv6
[RFC2460] an "on link" address is either a link-local address, defined
in [RFC2373], or an address whose prefix belongs to a subnet on the
local link.  A sender SHOULD prefer RRs including reachable addresses
where RRs involving both reachable and unreachable addresses are
returned in response to a query.

In composing LLMNR queries, the sender MUST set the Hop Limit field in
the IPv6 header and the TTL field in IPv4 header of the response to one
(1).  Even when LLMNR queries are sent to a link-scope multicast
address, it is possible that some routers may not properly implement
link-scope multicast, or that link-scope multicast addresses may leak
into the multicast routing system.  Therefore setting the IPv6 Hop Limit
or IPv4 TTL field to one provides an additional precaution against
leakage of LLMNR queries.

In composing a response to an LLMNR query, the responder MUST set the
Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
the response to one (1).  This is done so as to prevent the use of LLMNR
for denial of service attacks across the Internet.

Implementation note:

   In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
   options are used to set the TTL of outgoing unicast and multicast
   packets. The IP_RECVTTL socket option is available on some platforms
   to retrieve the IPv4 TTL of received packets with recvmsg().
   [RFC2292] specifies similar options for setting and retrieving the
   IPv6 Hop Limit.

2.6.  Retransmissions

In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of



Esibov, Aboba & Thaler       Standards Track                    [Page 8]





INTERNET-DRAFT                    LLMNR                      12 May 2003


the query in order to assure that it was received by a host capable of
responding to it.  Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface
basis, using the algorithms described in [RFC2988], with a minimum
timeout value of 300 ms.  Retransmission of UDP queries SHOULD NOT be
attempted more than 3 times.  Where LLMNR queries are sent using TCP,
retransmission is handled by the transport layer.

2.7.  DNS TTL

The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response.  Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value.  In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the
response to the unicast DNS query.

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] Where a DNS server is configured, by default a sender
    SHOULD send LLMNR queries only for names that are either
    unqualified or exist within the default domain. Where no



Esibov, Aboba & Thaler       Standards Track                    [Page 9]





INTERNET-DRAFT                    LLMNR                      12 May 2003


    DNS server is configured, an LLMNR query MAY be sent for
    any name.

[3] A responder with both link-local and routable addresses
    MUST respond to LLMNR queries for A/AAAA RRs only with
    routable address(es).  This encourages use of routable
    address(es) for establishment of new connections.

[4] A sender SHOULD send LLMNR queries for PTR RRs
    via unicast, as specified in Section 2.3.

RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4.
In particular:

[1] If a link-scope IPv6 address is returned in a AAAA RR, that
    address MUST be valid on the local link over which LLMNR is
    used.

[2] If an IPv4 address is returned, it must be reachable through
    the link over which LLMNR is used.

[3] If a name is returned (for example in a CNAME, MX
    or SRV RR), the name MUST be valid on the local interface.

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.

3.2.  LLMNR configuration

LLMNR usage MAY be configured manually or automatically on a per
interface basis.  By default, LLMNR responders SHOULD be enabled on all
interfaces, at all times.





Esibov, Aboba & Thaler       Standards Track                   [Page 10]





INTERNET-DRAFT                    LLMNR                      12 May 2003


Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6.  In these situations, a dual stack host will
send AAAA queries to the configured DNS server over IPv4.

However, an IPv6-only host unconfigured with a DNS server suitable for
use over IPv6 will be unable to resolve names using DNS.  Since
automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
[DNSDisc]) are not yet widely deployed, and not all DNS servers support
IPv6, lack of IPv6 DNS configuration may be a common problem in the
short term, and LLMNR may prove useful in enabling linklocal name
resolution over IPv6.

For example, a home network may provide a DHCPv4 server but may not
support DHCPv6 for DNS configuration [DHCPv6DNS].  In such a
circumstance, IPv6-only hosts will not be configured with a DNS server.
Where a DNS server is configured but does not support dynamic client
update over IPv6 or DHCPv6-based dynamic update, hosts on the home
network will not be able to dynamically register or resolve the names of
local IPv6  hosts.  If the configured DNS server responds to AAAA RR
queries sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3), then it will not be possible to resolve the names of
IPv6-only hosts.  In this situation, LLMNR over IPv6 can be used for
local name resolution.