-
-
-
-
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-17.txt> Microsoft
-16 April 2003
-
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC 2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-Today, with the rise of home networking, there are an increasing number
-of ad-hoc networks operating without a Domain Name Service (DNS) server.
-In order to allow name resolution in such environments, Link-Local
-Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
-current and future DNS formats, types and classes, while operating on a
-separate port from DNS, and with a distinct resolver cache.
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name resolution using LLMNR ........................... 4
- 2.1 Sender behavior ................................. 5
- 2.2 Responder behavior .............................. 5
- 2.3 Unicast queries ................................. 6
- 2.4 Addressing ...................................... 7
- 2.5 Off-link detection .............................. 7
- 2.6 Retransmissions ................................. 8
- 2.7 DNS TTL ......................................... 8
-3. Usage model ........................................... 8
- 3.1 Unqualified names ............................... 9
- 3.2 LLMNR configuration ............................. 10
-4. Conflict resolution ................................... 11
- 4.1 Considerations for multiple interfaces .......... 12
- 4.2 API issues ...................................... 14
-5. Security considerations ............................... 14
- 5.1 Scope restriction ............................... 14
- 5.2 Usage restriction ............................... 15
- 5.3 Cache and port separation ....................... 16
- 5.4 Authentication .................................. 16
-6. IANA considerations ................................... 16
-7. Normative References .................................. 16
-8. Informative References ................................ 17
-Acknowledgments .............................................. 18
-Authors' Addresses ........................................... 18
-Intellectual Property Statement .............................. 19
-Full Copyright Statement ..................................... 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-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 errors, as described in Section 3.
-
-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.
-
-Propagation of LLMNR packets on the local link is considered sufficient
-to enable name resolution in small networks. The assumption is that if
-a network has a home gateway, then the network either has a DNS server
-or the home gateway can function as a DNS proxy. By implementing
-Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS
-proxy and dynamic DNS, home gateways can provide name resolution for the
-names of hosts over IPv4 on the local network.
-
-For small IPv6 networks, equivalent functionality can be provided by a
-home gateway implementing Dynamic Host Configuration Service for IPv6
-(DHCPv6) for DNS configuration [DHCPv6DNS], as well as a DNS proxy
-supporting AAAA RRs and dynamic DNS, providing name resolution for the
-names of hosts over IPv6 on the local network.
-
-This should be adequate as long as home gateways implementing DNS
-configuration also support dynamic DNS in some form.
-
-In the future, LLMNR may be defined to support greater than link-scope
-multicast. 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 ad hoc networking scenarios.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-Once we have experience in LLMNR deployment in terms of administrative
-issues, usability and impact on the network it will be possible to
-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.
-
-1.1. Requirements
-
-In this document, several words are used to signify the requirements of
-the specification. These words are often capitalized. The key words
-"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
-NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
-interpreted as described in [RFC2119].
-
-1.2. Terminology
-
-Responder A host that listens to LLMNR queries, and responds to
- those for which it is authoritative.
-
-Sender A host that sends an LLMNR query. Typically a host is
- configured as both a sender and a responder. However, a
- host may be configured as a sender, but not a responder
- or as a responder, but not a sender.
-
-Routable address
- An address other than a linklocal address. This includes
- site local and globally routable addresses, as well as
- private addresses.
-
-2. Name resolution using LLMNR
-
-The sequence of events for LLMNR usage is as follows:
-
-[1] If a sender needs to resolve a query for a name "host.example.com",
- then it sends an LLMNR query to the link-scope multicast address.
-
-[2] A responder responds to this query only if it is authoritative
- for the domain name "host.example.com". The responder sends
- a response to the sender via unicast over UDP.
-
-[3] Upon the reception of the response, the sender verifies that the
- packet originated on-link (see Section 2.5 for details). If these
- conditions are met, then the sender uses and caches the returned
- response. If not, then the sender ignores the response and continues
- waiting for the response.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-Further details of sender and responder behavior are provided in the
-sections that follow.
-
-2.1. Sender behavior
-
-A sender sends an LLMNR query for any legal type of resource record
-(e.g. A, PTR, etc.) to the link-scope multicast address. An LLMNR
-sender MAY send requests for any name.
-
-Under conditions described in Section 2.3, a sender may also send a
-unicast query. The RD (Recursion Desired) bit MUST NOT be set. If a
-responder receives a query with the header containing RD set bit, the
-responder MUST ignore the RD bit.
-
-The sender MUST anticipate receiving no replies to some LLMNR queries,
-in the event that no responders are available within the linklocal
-multicast scope, or in the event no positive non-null responses exist
-for the transmitted query. If no positive response is received, a
-resolver treats it 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).
-
-2.2. Responder behavior
-
-A responder listens on port TBD on the link-scope multicast address(es)
-and on the unicast address(es) that could be set as the source
-address(es) when the responder responds to the LLMNR query. The host
-configured as a responder MUST act as a sender to verify the uniqueness
-of names as described in Section 4.
-
-Responders MUST NOT respond to LLMNR queries for names they are not
-authoritative for. Responders SHOULD respond to LLMNR queries for names
-and addresses they are authoritative for. This applies to both forward
-and reverse lookups.
-
-As an example, a computer "host.example.com." configured to respond to
-the LLMNR queries is authoritative for the name "host.example.com.". On
-receiving an LLMNR A/AAAA resource record query for the name
-"host.example.com." the host authoritatively responds with A/AAAA
-record(s) that contain IP address(es) in the RDATA of the resource
-record.
-
-If a responder is authoritative for a name, it MAY respond with RCODE=0
-and an empty answer section, if the type of query does not match a RR
-owned by the responder. 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=0
-and an empty answer section.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-If a DNS server is running on a host that supports LLMNR, the DNS server
-MUST respond to LLMNR queries only for the RRSets owned by the host on
-which the server is running, but MUST NOT respond for other records for
-which the server is authoritative.
-
-In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone root except for
-the branches delegated into separate zones. Contrary to conventional
-DNS terminology, an LLMNR responder is authoritative only for the zone
-root.
-
-For example the host "host.example.com." is not authoritative for the
-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 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
-
-A sender MUST NOT send a unicast LLMNR query except when:
-
- a. A sender repeats a query after it received a response
- to the previous LLMNR query with the TC bit set, or
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
- b. The sender's LLMNR cache contains an NS resource record that
- enables the sender to send a query directly to the hosts
- authoritative for the name in the query.
-
-If a TC (truncation) bit is set in the response, then the sender MAY use
-the response if it contains all necessary information, or the sender MAY
-discard the response and resend the query over TCP or using EDNS0 with
-larger window using the unicast address of the responder. The RA
-(Recursion Available) bit in the header of the response MUST NOT be set.
-If the RA bit is set in the response header, the sender MUST ignore it.
-
-2.4. Addressing
-
-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.
-
-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. For IPv4, an "on
-link" address is defined as a link-local address or an address whose
-prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on
-link" address is either a link-local address, defined in [RFC2373], or
-an address whose prefix belongs to a subnet on the local link. A sender
-SHOULD prefer RRs including reachable addresses where RRs involving both
-reachable and unreachable addresses are returned in response to a query.
-
-In composing an LLMNR response, the responder MUST set the Hop Limit
-field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
-response to 255. The sender MUST verify that the Hop Limit field in
-IPv6 header and TTL field in IPv4 header of each response to the LLMNR
-query is set to 255. If it is not, then sender MUST ignore the
-response.
-
-Since routers decrement the Hop Limit on all packets they forward,
-received packets containing a Hop Limit of 255 must have originated from
-a neighbor.
-
- Implementation note:
-
- In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
- options are used to set the TTL of outgoing unicast and multicast
- packets. The IP_RECVTTL socket option is available on some platforms
- to retrieve the IPv4 TTL of received packets with recvmsg().
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
- [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 the LLMNR query is not resolved within the timeout interval
-(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
-order to assure themselves that the query has been received by a host
-capable of responding to the query. Since a sender cannot know
-beforehand whether it will receive no response, one response, or more
-than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order
-to collect all possible responses, rather than considering the query
-answered after the first response is received.
-
-LLMNR implementations SHOULD dynamically estimate the timeout value
-(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described
-in [RFC2988], with a minimum timeout value of 300 ms. Retransmission
-SHOULD NOT be attempted more than 3 times.
-
-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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
- back to LLMNR, the query SHOULD be retransmitted at least
- once.
-
-[2] Where a DNS server is configured, by default a sender
- SHOULD send LLMNR queries only for names that are either
- unqualified or exist within the default domain. Where no
- DNS server is configured, an LLMNR query MAY be sent for
- any name.
-
-[3] A responder with both link-local and routable addresses
- MUST respond to LLMNR queries for A/AAAA RRs only with
- routable address(es). This encourages use of routable
- address(es) for establishment of new connections.
-
-[4] A sender SHOULD only send LLMNR queries for PTR RRs
- that represent addresses reachable on the link
- over which LLMNR is used.
-
-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.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-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.
-
-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-possible for a dual stack host to be configured with the address of a
-DNS server over IPv4, while remaining unconfigured with a DNS server
-suitable for use over IPv6. In these situations, a dual stack host will
-send AAAA queries to the configured DNS server over IPv4.
-
-However, an IPv6-only host unconfigured with a DNS server suitable for
-use over IPv6 will be unable to resolve names using DNS. Since
-automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
-[DNSDisc]) are not yet widely deployed, and not all DNS servers support
-IPv6, lack of IPv6 DNS configuration may be a common problem in the
-short term, and LLMNR may prove useful in enabling linklocal name
-resolution over IPv6.
-
-For example, a home gateway may implement a DNS proxy and DHCPv4, but
-not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance,
-IPv6-only hosts will not be configured with a DNS server. Where the DNS
-proxy does not support dynamic client update over IPv6 or DHCPv6-based
-dynamic update of the DNS proxy, the home gateway will not be able to
-dynamically register the names of IPv6 hosts. As a result, the DNS
-proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an
-authoritative name error (RCODE=3). This prevents hosts from resolving
-the names of IPv6-only hosts on the local link. In this situation,
-LLMNR over IPv6 can be used for resolution of dynamic names.
-
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure LLMNR on an interface. The LLMNR Enable Option, described in
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
-on an interface. The LLMNR Enable Option does not determine whether or
-in which order DNS itself is used for name resolution. The order in
-which various name resolution mechanisms should be used can be specified
-using the Name Service Search Option for DHCP [RFC2937].
-
-3.2.1. Configuration consistency
-
-It is possible that 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-after the outage will not. Alternatively, it is possible for the DNS
-configuration mechanism to continue functioning while configured DNS
-servers fail.
-
-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.
-
-4. Conflict resolution
-
-The sender MUST anticipate receiving multiple replies to the same LLMNR
-query, in the event that several LLMNR enabled computers receive the
-query and respond with valid answers. When this occurs, the responses
-MAY first be concatenated, and then treated in the same manner that
-multiple RRs received from the same DNS server would.
-
-There are some scenarios when multiple responders MAY respond to the
-same query. There are other scenarios when only one responder MAY
-respond to a query. Resource records for which the latter queries are
-submitted are referred as UNIQUE throughout this document. The
-uniqueness of a resource record depends on a nature of the name in the
-query and type of the query. For example it is expected that:
-
- - multiple hosts may respond to a query for an SRV type record
- - multiple hosts may respond to a query for an A or AAAA type
- record for a cluster name (assigned to multiple hosts in
- the cluster)
- - only a single host may respond to a query for an A or AAAA
- type record for a hostname.
-
-Every responder that responds to a LLMNR query and/or dynamic update
-request AND includes a UNIQUE record in the response:
-
- 1. MUST verify that there is no other host within the scope of the
- LLMNR query propagation that can return a resource record
- for the same name, type and class.
- 2. MUST NOT include a UNIQUE resource record in the
- response without having verified its uniqueness.
-
-Where a host is configured to respond to LLMNR queries on more than one
-interface, each interface should have its own independent LLMNR cache.
-For each UNIQUE resource record in a given interface's cache, the host
-MUST verify resource record uniqueness on that interface. To accomplish
-this, the host MUST send an LLMNR query for each UNIQUE resource record.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-By default, a host SHOULD be configured to behave as though all RRs are
-UNIQUE. Uniqueness verification is carried out when the host:
-
- - starts up or
- - is configured to respond to the LLMNR queries on an interface or
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records.
-
-When a host that owns a UNIQUE record receives an LLMNR query for that
-record, the host MUST respond. After the client receives a response, it
-MUST check whether the response arrived on another interface. If this
-is the case, then the client can use the UNIQUE resource record in
-response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
-resource record in response to LLMNR queries.
-
-Note that this name conflict detection mechanism doesn't prevent name
-conflicts when previously partitioned segments are connected by a
-bridge. In such a situation, name conflicts are detected when a sender
-receives more than one response to its LLMNR query.
-
-In this case, the sender sends the first response that it received to
-all responders that responded to this query except the first one, using
-unicast. A host that receives a query response containing a UNIQUE
-resource record that it owns, even if it didn't send such a query, MUST
-verify that no other host within the LLMNR scope is authoritative for
-the same name, using the mechanism described above. Based on the
-result, the host detects whether there is a name conflict and acts
-accordingly.
-
-4.1. Considerations for Multiple Interfaces
-
-A multi-homed host may elect to configure LLMNR on only one of its
-active interfaces. In many situations this will be adequate. However,
-should a host need to configure LLMNR on more than one of its active
-interfaces, there are some additional precautions it MUST take.
-Implementers who are not planning to support LLMNR on multiple
-interfaces simultaneously may skip this section.
-
-A multi-homed host checks the uniqueness of UNIQUE records as described
-in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
-In this situation, the multi-homed myhost will probe for, and defend,
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-its host name on both interfaces. A conflict will be detected on one
-interface, but not the other. The multi-homed myhost will not be able
-to respond with a host RR for "myhost" on the interface on the right
-(see Figure 1). The multi-homed host may, however, be configured to use
-the "myhost" name on the interface on the left.
-
-Since names are only unique per-link, hosts on different links could be
-using the same name. If an LLMNR client sends requests over multiple
-interfaces, and receives replies from more than one, the result returned
-to the client is defined by the implementation. The situation is
-illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
-If host myhost is configured to use LLMNR on both interfaces, it will
-send LLMNR queries on both interfaces. When host myhost sends a query
-for the host RR for name "A" it will receive a response from hosts on
-both interfaces.
-
-Host myhost will then forward a response from the first responder to the
-second responder, who will attempt to verify the uniqueness of host RR
-for its name, but will not discover a conflict, since the conflicting
-host resides on a different link. Therefore it will continue using its
-name.
-
-Indeed, host myhost cannot distinguish between the situation shown in
-Figure 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
-This illustrates that the proposed name conflict resolution mechanism
-does not support detection or resolution of conflicts between hosts on
-different links. This problem can also occur with unicast DNS when a
-multi-homed host is connected to two different networks with separated
-name spaces. It is not the intent of this document to address the issue
-of uniqueness of names within DNS.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-4.2. API issues
-
-[RFC2553] provides an API which can partially solve the name ambiguity
-problem for applications written to use this API, since the sockaddr_in6
-structure exposes the scope within which each scoped address exists, and
-this structure can be used for both IPv4 (using v4-mapped IPv6
-addresses) and IPv6 addresses.
-
-Following the example in Figure 2, an application on 'myhost' issues the
-request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
-interfaces and the resolver library will return a list containing
-multiple addrinfo structures, each with an associated sockaddr_in6
-structure. This list will thus contain the IPv4 and IPv6 addresses of
-both hosts responding to the name 'A'. Link-local addresses will have a
-sin6_scope_id value that disambiguates which interface is used to reach
-the address. Of course, to the application, Figures 2 and 3 are still
-indistinguishable, but this API allows the application to communicate
-successfully with any address in the list.
-
-5. Security Considerations
-
-LLMNR is by nature a peer-to-peer name resolution protocol. It is
-therefore inherently more vulnerable than DNS, since existing DNS
-security mechanisms are difficult to apply to LLMNR and an attacker only
-needs to be misconfigured to answer an LLMNR query with incorrect
-information.
-
-In order to address the security vulnerabilities, the following
-mechanisms are contemplated:
-
-[1] Scope restrictions.
-
-[2] Usage restrictions.
-
-[3] Cache and port separation.
-
-[4] Authentication.
-
-These techniques are described in the following sections.
-
-5.1. Scope restriction
-
-With LLMNR it is possible that hosts will allocate conflicting names for
-a period of time, or that attackers will attempt to deny service to
-other hosts by allocating the same name. Such attacks also allow hosts
-to receive packets destined for other hosts.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-In the absence of authentication, LLMNR reduces the exposure to such
-threats by ignoring LLMNR query response packets received from off-link
-senders. While ignoring packets received from off-link senders reduces
-the level of vulnerability, it does not eliminate it. There are
-scenarios such as public "hotspots" where attackers can be present on
-the same link. These threats are most serious in wireless networks such
-as 802.11, since attackers on a wired network will require physical
-access to the home network, while wireless attackers may reside outside
-the home. Link-layer security can be of assistance against these
-threats if it is available.
-
-5.2. Usage restriction
-
-As noted in Section 3, LLMNR is intended for usage in a limited set of
-scenarios.
-
-If an interface has been configured via any automatic configuration
-mechanism which is able to supply DNS configuration information, then
-LLMNR SHOULD NOT be used as the primary name resolution mechanism on
-that interface, although it MAY be used as a name resolution mechanism
-of last resort.
-
-Note: enabling LLMNR for use in situations where a DNS server has been
-configured will result in upgraded hosts changing their default behavior
-without a simultaneous update to configuration information. Where this
-is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
-that hosts will neither listen on the link-scope multicast address, nor
-will it send queries to that address.
-
-Use of LLMNR as a name resolution mechanism increases security
-vulnerabilities. For example, if an LLMNR query is 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 name resolution mechanism of last resort.
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-5.3. Cache and port separation
-
-In order to prevent responses to LLMNR queries from polluting the DNS
-cache, LLMNR implementations MUST use a distinct, isolated cache for
-LLMNR on each interface. The use of separate caches is most effective
-when LLMNR is used as a name resolution mechanism of last resort, since
-this minimizes the opportunities for poisoning the LLMNR cache, and
-decreases reliance on it.
-
-LLMNR operates on a separate port from DNS, reducing the likelihood that
-a DNS server will unintentionally respond to an LLMNR query.
-
-5.4. Authentication
-
-LLMNR does not require use of DNSSEC, and as a result, responses to
-LLMNR queries may be unauthenticated. If authentication is desired, and
-a pre-arranged security configuration is possible, then IPsec ESP with a
-null-transform MAY be used to authenticate LLMNR responses. In a small
-network without a certificate authority, this can be most easily
-accomplished through configuration of a group pre-shared key for trusted
-hosts.
-
-6. IANA Considerations
-
-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.
-
-7. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
- System (DNS UPDATE)", RFC 2136, April 1997.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
- 23, RFC 2365, July 1998.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-8. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and
- Suggested Fixes", RFC 1536, October 1993.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for
- IPv6", RFC 2292, February 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
- "Basic Socket Interface Extensions for IPv6", RFC 2553,
- March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6
- Service", Internet draft (work in progress), draft-droms-
- dhcpv6-stateless-guide-01.txt, October 2002.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness
- of Caching", IEEE/ACM Transactions on Networking, Volume
- 10, Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site
- local unicast addresses to communicate with recursive DNS
- servers", Internet draft (work in progress), draft-ietf-
- ipv6-dns-discovery-07.txt, October 2002.
-
-[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
- Configuration of IPv4 Link-Local Addresses", Internet
- draft (work in progress), draft-ietf-zeroconf-
- ipv4-linklocal-07.txt, August 2002.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
- (work in progress), draft-guttman-mdns-enable-02.txt,
- April 2002.
-
-[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
-
-Acknowledgments
-
-This work builds upon original work done on multicast DNS by Bill
-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-grant #F30602-99-1-0523. The authors gratefully acknowledge their
-contribution to the current specification. Constructive input has also
-been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
-Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
-Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
-Savela.
-
-Authors' Addresses
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: levone@microsoft.com
-
-Bernard Aboba
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 706 6605
-EMail: bernarda@microsoft.com
-
-Dave Thaler
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 703 8835
-EMail: dthaler@microsoft.com
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are included
-on all such copies and derivative works. However, this document itself
-may not be modified in any way, such as by removing the copyright notice
-or references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to translate it into
-languages other than English. The limited permissions granted above are
-perpetual and will not be revoked by the Internet Society or its
-successors or assigns. This document and the information contained
-herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2003
-
-
-Open Issues
-
-Open issues with this specification are tracked on the following web
-site:
-
-http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-Expiration Date
-
-This memo is filed as <draft-ietf-dnsext-mdns-17.txt>, and expires
-November 22, 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
+\r
+\r
+\r
+\r
+\r
+\r
+DNSEXT Working Group Levon Esibov\r
+INTERNET-DRAFT Bernard Aboba\r
+Category: Standards Track Dave Thaler\r
+<draft-ietf-dnsext-mdns-18.txt> Microsoft\r
+1 May 2003\r
+\r
+\r
+ Linklocal Multicast Name Resolution (LLMNR)\r
+\r
+This document is an Internet-Draft and is in full conformance with all\r
+provisions of Section 10 of RFC 2026.\r
+\r
+Internet-Drafts are working documents of the Internet Engineering Task\r
+Force (IETF), its areas, and its working groups. Note that other groups\r
+may also distribute working documents as Internet-Drafts.\r
+\r
+Internet-Drafts are draft documents valid for a maximum of six months\r
+and may be updated, replaced, or obsoleted by other documents at any\r
+time. It is inappropriate to use Internet-Drafts as reference material\r
+or to cite them other than as "work in progress."\r
+\r
+The list of current Internet-Drafts can be accessed at\r
+http://www.ietf.org/ietf/1id-abstracts.txt\r
+\r
+The list of Internet-Draft Shadow Directories can be accessed at\r
+http://www.ietf.org/shadow.html.\r
+\r
+Copyright Notice\r
+\r
+Copyright (C) The Internet Society (2003). All Rights Reserved.\r
+\r
+Abstract\r
+\r
+Today, with the rise of home networking, there are an increasing number\r
+of ad-hoc networks operating without a Domain Name Service (DNS) server.\r
+In order to allow name resolution in such environments, Link-Local\r
+Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all\r
+current and future DNS formats, types and classes, while operating on a\r
+separate port from DNS, and with a distinct resolver cache.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 1]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Table of Contents\r
+\r
+1. Introduction .......................................... 3\r
+ 1.1 Requirements .................................... 4\r
+ 1.2 Terminology ..................................... 4\r
+2. Name resolution using LLMNR ........................... 4\r
+ 2.1 Sender behavior ................................. 5\r
+ 2.2 Responder behavior .............................. 5\r
+ 2.3 Unicast queries ................................. 6\r
+ 2.4 Addressing ...................................... 7\r
+ 2.5 Off-link detection .............................. 7\r
+ 2.6 Retransmissions ................................. 8\r
+ 2.7 DNS TTL ......................................... 9\r
+3. Usage model ........................................... 9\r
+ 3.1 Unqualified names ............................... 10\r
+ 3.2 LLMNR configuration ............................. 10\r
+4. Conflict resolution ................................... 11\r
+ 4.1 Considerations for multiple interfaces .......... 13\r
+ 4.2 API issues ...................................... 14\r
+5. Security considerations ............................... 15\r
+ 5.1 Scope restriction ............................... 15\r
+ 5.2 Usage restriction ............................... 16\r
+ 5.3 Cache and port separation ....................... 16\r
+ 5.4 Authentication .................................. 17\r
+6. IANA considerations ................................... 17\r
+7. Normative References .................................. 17\r
+8. Informative References ................................ 18\r
+Acknowledgments .............................................. 19\r
+Authors' Addresses ........................................... 19\r
+Intellectual Property Statement .............................. 20\r
+Full Copyright Statement ..................................... 20\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 2]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+1. Introduction\r
+\r
+This document discusses Link Local Multicast Name Resolution (LLMNR),\r
+which operates on a separate port from DNS, with a distinct resolver\r
+cache, but does not change the format of DNS packets. LLMNR supports\r
+all current and future DNS formats, types and classes. However, since\r
+LLMNR only operates on the local link, it cannot be considered a\r
+substitute for DNS.\r
+\r
+The goal of LLMNR is to enable name resolution in scenarios in which\r
+conventional DNS name resolution is not possible. These include\r
+scenarios in which hosts are not configured with the address of a DNS\r
+server, where configured DNS servers do not reply to a query, or where\r
+they respond with errors, as described in Section 3.\r
+\r
+LLMNR queries are sent to and received on port TBD. Link-scope\r
+multicast addresses are used to prevent propagation of LLMNR traffic\r
+across routers, potentially flooding the network; for details, see\r
+Section 2.4. LLMNR queries can also be sent to a unicast address, as\r
+described in Section 2.3.\r
+\r
+Propagation of LLMNR packets on the local link is considered sufficient\r
+to enable name resolution in small networks. The assumption is that if\r
+a network has a home gateway, then the network either has a DNS server\r
+or the home gateway can function as a DNS proxy. By implementing\r
+Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS\r
+proxy and dynamic DNS, home gateways can provide name resolution for the\r
+names of hosts over IPv4 on the local network.\r
+\r
+For small IPv6 networks, equivalent functionality can be provided by a\r
+home gateway implementing Dynamic Host Configuration Service for IPv6\r
+(DHCPv6) for DNS configuration [DHCPv6DNS], as well as a DNS proxy\r
+supporting AAAA RRs and dynamic DNS, providing name resolution for the\r
+names of hosts over IPv6 on the local network.\r
+\r
+This should be adequate as long as home gateways implementing DNS\r
+configuration also support dynamic DNS in some form.\r
+\r
+In the future, LLMNR may be defined to support greater than link-scope\r
+multicast. This would occur if LLMNR deployment is successful, the\r
+assumption that LLMNR is not needed on multiple links proves incorrect,\r
+and multicast routing becomes ubiquitous. For example, it is not clear\r
+that this assumption will be valid in large ad hoc networking scenarios.\r
+\r
+Once we have experience in LLMNR deployment in terms of administrative\r
+issues, usability and impact on the network it will be possible to\r
+reevaluate which multicast scopes are appropriate for use with multicast\r
+name resolution mechanisms.\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 3]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Service discovery in general, as well as discovery of DNS servers using\r
+LLMNR in particular, is outside of the scope of this document, as is\r
+name resolution over non-multicast capable media.\r
+\r
+1.1. Requirements\r
+\r
+In this document, several words are used to signify the requirements of\r
+the specification. These words are often capitalized. The key words\r
+"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD\r
+NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be\r
+interpreted as described in [RFC2119].\r
+\r
+1.2. Terminology\r
+\r
+Responder A host that listens to LLMNR queries, and responds to\r
+ those for which it is authoritative.\r
+\r
+Sender A host that sends an LLMNR query. Typically a host is\r
+ configured as both a sender and a responder. However, a\r
+ host may be configured as a sender, but not a responder\r
+ or as a responder, but not a sender.\r
+\r
+Routable address\r
+ An address other than a linklocal address. This includes\r
+ site local and globally routable addresses, as well as\r
+ private addresses.\r
+\r
+2. Name resolution using LLMNR\r
+\r
+A typical sequence of events for LLMNR usage is as follows:\r
+\r
+[1] A sender needs to resolve a query for a name "host.example.com",\r
+ so it sends an LLMNR query to the link-scope multicast address.\r
+\r
+[2] A responder responds to this query only if it is authoritative\r
+ for the domain name "host.example.com". The responder sends\r
+ a response to the sender via unicast over UDP.\r
+\r
+[3] Upon the reception of the response, the sender performs the checks\r
+ described in Section 2.5. If these conditions are met, then the\r
+ sender uses and caches the returned response. If not, then the\r
+ sender ignores the response and continues waiting for the response.\r
+\r
+Further details of sender and responder behavior are provided in the\r
+sections that follow.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 4]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+2.1. Sender behavior\r
+\r
+A sender sends an LLMNR query for any legal resource record type (e.g.\r
+A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As\r
+described in Section 2.3, a sender may also send a unicast query. An\r
+LLMNR sender MAY send a request for any name.\r
+\r
+The RD (Recursion Desired) bit MUST NOT be set in a query. If a\r
+responder receives a query with the header containing RD set bit, the\r
+responder MUST ignore the RD bit.\r
+\r
+The sender MUST anticipate receiving no replies to some LLMNR queries,\r
+in the event that no responders are available within the link-scope or\r
+in the event no positive non-null responses exist for the transmitted\r
+query. If no positive response is received, a resolver treats it as a\r
+response that no records of the specified type and class exist for the\r
+specified name (it is treated the same as a response with RCODE=0 and an\r
+empty answer section).\r
+\r
+2.2. Responder behavior\r
+\r
+A responder MUST listen on UDP port TBD on the link-scope multicast\r
+address(es) and on UDP and TCP port TBD on the unicast address(es) that\r
+could be set as the source address(es) when the responder responds to\r
+the LLMNR query. A host configured as a responder MUST act as a sender\r
+to verify the uniqueness of names as described in Section 4.\r
+\r
+Responders MUST NOT respond to LLMNR queries for names they are not\r
+authoritative for. Responders SHOULD respond to LLMNR queries for names\r
+and addresses they are authoritative for. This applies to both forward\r
+and reverse lookups.\r
+\r
+As an example, a computer "host.example.com." configured to respond to\r
+LLMNR queries is authoritative for the name "host.example.com.". On\r
+receiving an LLMNR A/AAAA resource record query for the name\r
+"host.example.com." the host authoritatively responds with A/AAAA\r
+record(s) that contain IP address(es) in the RDATA of the resource\r
+record.\r
+\r
+If a responder is authoritative for a name, it MAY respond with RCODE=0\r
+and an empty answer section, if the type of query does not match a RR\r
+owned by the responder. For example, if the host has a AAAA RR, but no\r
+A RR, and an A RR query is received, the host would respond with RCODE=0\r
+and an empty answer section.\r
+\r
+If a DNS server is running on a host that supports LLMNR, the DNS server\r
+MUST respond to LLMNR queries only for the RRSets owned by the host on\r
+which the server is running, but MUST NOT respond for other records for\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 5]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+which the server is authoritative.\r
+\r
+In conventional DNS terminology a DNS server authoritative for a zone is\r
+authoritative for all the domain names under the zone root except for\r
+the branches delegated into separate zones. Contrary to conventional\r
+DNS terminology, an LLMNR responder is authoritative only for the zone\r
+root.\r
+\r
+For example the host "host.example.com." is not authoritative for the\r
+name "child.host.example.com." unless the host is configured with\r
+multiple names, including "host.example.com." and\r
+"child.host.example.com.". As a result, "host" cannot reply to a query\r
+for "child" with NXDOMAIN. The purpose of limiting the name authority\r
+scope of a responder is to prevent complications that could be caused by\r
+coexistence of two or more hosts with the names representing child and\r
+parent (or grandparent) nodes in the DNS tree, for example,\r
+"host.example.com." and "child.host.example.com.".\r
+\r
+In this example (unless this limitation is introduced) an LLMNR query\r
+for an A resource record for the name "child.host.example.com." would\r
+result in two authoritative responses: a name error received from\r
+"host.example.com.", and a requested A record - from\r
+"child.host.example.com.". To prevent this ambiguity, LLMNR enabled\r
+hosts could perform a dynamic update of the parent (or grandparent) zone\r
+with a delegation to a child zone. In this example a host\r
+"child.host.example.com." would send a dynamic update for the NS and\r
+glue A record to "host.example.com.", but this approach significantly\r
+complicates implementation of LLMNR and would not be acceptable for\r
+lightweight hosts.\r
+\r
+A response to a LLMNR query is composed in exactly the same manner as a\r
+response to the unicast DNS query as specified in [RFC1035]. Responders\r
+MUST NOT respond using cached data, and the AA (Authoritative Answer)\r
+bit MUST be set. The response is sent to the sender via unicast. A\r
+response to an LLMNR query MUST have RCODE set to zero. Responses with\r
+RCODE set to zero are referred to in this document as "positively\r
+resolved". LLMNR responders may respond only to queries which they can\r
+resolve positively.\r
+\r
+2.3. Unicast queries and responses\r
+\r
+Unicast queries SHOULD be sent when:\r
+\r
+ a. A sender repeats a query after it received a response\r
+ with the TC bit set to the previous LLMNR multicast query, or\r
+\r
+ b. The sender's LLMNR cache contains an NS resource record that\r
+ enables the sender to send a query directly to the hosts\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 6]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+ authoritative for the name in the query, or\r
+\r
+ c. The sender queries for a PTR RR.\r
+\r
+If a TC (truncation) bit is set in the response, then the sender MAY use\r
+the response if it contains all necessary information, or the sender MAY\r
+discard the response and resend the query over TCP using the unicast\r
+address of the responder. The RA (Recursion Available) bit in the\r
+header of the response MUST NOT be set. If the RA bit is set in the\r
+response header, the sender MUST ignore the RA bit.\r
+\r
+Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP\r
+unicast LLMNR queries MUST be sent using TCP, using the same connection\r
+as the query. If the sender of a TCP query receives a response not\r
+using TCP, the response MUST be silently discarded. Unicast UDP queries\r
+MAY be responded to with an empty answer section and the TC bit set, so\r
+as to require the sender to resend the query using TCP. Senders MUST\r
+support sending TCP queries, and Responders MUST support listening for\r
+TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on\r
+the TCP listen socket to one (1) so that SYN-ACK packets will have TTL\r
+(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming\r
+connection from off-link since the Sender will not receive a SYN-ACK\r
+from the Responder.\r
+\r
+If an ICMP "Time Exceeded" message is received in response to a unicast\r
+UDP query, or if TCP connection setup cannot be completed in order to\r
+send a unicast TCP query, this is treated as a response that no records\r
+of the specified type and class exist for the specified name (it is\r
+treated the same as a response with RCODE=0 and an empty answer\r
+section). The UDP sender receiving an ICMP "Time Exceeded" message\r
+SHOULD verify that the ICMP error payload contains a valid LLMNR query\r
+packet, which matches a query that is currently in progress, so as to\r
+guard against a potential Denial of Service (DoS) attack. If a match\r
+cannot be made, then the sender relies on the retransmission and timeout\r
+behavior described in Section 2.6.\r
+\r
+2.4. Addressing\r
+\r
+IPv4 administratively scoped multicast usage is specified in\r
+"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope\r
+multicast address a given responder listens to, and to which a sender\r
+sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a\r
+given responder listens to, and to which a sender sends all queries, is\r
+TBD.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 7]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+2.5. Off-link detection\r
+\r
+The source address of LLMNR queries and responses MUST be "on link".\r
+The destination address of an LLMNR query MUST be a link-scope multicast\r
+address or an "on link" unicast address; the destination address of an\r
+LLMNR response MUST be an "on link" unicast address. On receiving an\r
+LLMNR query, the responder MUST check whether it was sent to the LLMNR\r
+multicast address; if it was sent to another multicast address, then the\r
+query MUST be silently discarded.\r
+\r
+For IPv4, an "on link" address is defined as a link-local address or an\r
+address whose prefix belongs to a subnet on the local link; for IPv6\r
+[RFC2460] an "on link" address is either a link-local address, defined\r
+in [RFC2373], or an address whose prefix belongs to a subnet on the\r
+local link. A sender SHOULD prefer RRs including reachable addresses\r
+where RRs involving both reachable and unreachable addresses are\r
+returned in response to a query.\r
+\r
+In composing LLMNR queries, the sender MUST set the Hop Limit field in\r
+the IPv6 header and the TTL field in IPv4 header of the response to one\r
+(1). Even when LLMNR queries are sent to a link-scope multicast\r
+address, it is possible that some routers may not properly implement\r
+link-scope multicast, or that link-scope multicast addresses may leak\r
+into the multicast routing system. Therefore setting the IPv6 Hop Limit\r
+or IPv4 TTL field to one provides an additional precaution against\r
+leakage of LLMNR queries.\r
+\r
+In composing a response to an LLMNR query, the responder MUST set the\r
+Hop Limit field in the IPv6 header and the TTL field in IPv4 header of\r
+the response to one (1). This is done so as to prevent the use of LLMNR\r
+for denial of service attacks across the Internet.\r
+\r
+Implementation note:\r
+\r
+ In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket\r
+ options are used to set the TTL of outgoing unicast and multicast\r
+ packets. The IP_RECVTTL socket option is available on some platforms\r
+ to retrieve the IPv4 TTL of received packets with recvmsg().\r
+ [RFC2292] specifies similar options for setting and retrieving the\r
+ IPv6 Hop Limit.\r
+\r
+2.6. Retransmissions\r
+\r
+In order to avoid synchronization, LLMNR queries and responses are\r
+delayed by a time uniformly distributed between 0 and 200 ms.\r
+\r
+If an LLMNR query sent over UDP is not resolved within the timeout\r
+interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 8]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+the query in order to assure that it was received by a host capable of\r
+responding to it. Since a multicast query sender cannot know beforehand\r
+whether it will receive no response, one response, or more than one\r
+response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all\r
+possible responses, rather than considering the multicast query answered\r
+after the first response is received. A unicast query sender considers\r
+the query answered after the first response is received, so that it only\r
+waits for LLMNR_TIMEOUT if no response has been received.\r
+\r
+LLMNR implementations SHOULD dynamically estimate the timeout value\r
+(LLMNR_TIMEOUT) based on the last response received, on a per-interface\r
+basis, using the algorithms described in [RFC2988], with a minimum\r
+timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be\r
+attempted more than 3 times. Where LLMNR queries are sent using TCP,\r
+retransmission is handled by the transport layer.\r
+\r
+2.7. DNS TTL\r
+\r
+The responder should use a pre-configured TTL value in the records\r
+returned in the LLMNR query response. Due to the TTL minimalization\r
+necessary when caching an RRset, all TTLs in an RRset MUST be set to the\r
+same value. In the additional and authority section of the response the\r
+responder includes the same records as a DNS server would insert in the\r
+response to the unicast DNS query.\r
+\r
+3. Usage model\r
+\r
+LLMNR is a peer-to-peer name resolution protocol that is not intended as\r
+a replacement for DNS. By default, LLMNR requests SHOULD be sent only\r
+when no manual or automatic DNS configuration has been performed, when\r
+DNS servers do not respond, or when they respond to a query with RCODE=3\r
+(Authoritative Name Error) or RCODE=0, and an empty answer section.\r
+\r
+As noted in [DNSPerf], even when DNS servers are configured, a\r
+significant fraction of DNS queries do not receive a response, or result\r
+in a negative responses due to missing inverse mappings or NS records\r
+that point to nonexistent or inappropriate hosts. Given this, support\r
+for LLMNR as a secondary name resolution mechanism has the potential to\r
+result in a large number of inappropriate queries without the following\r
+additional restrictions:\r
+\r
+[1] If a DNS query does not receive a response, prior to falling\r
+ back to LLMNR, the query SHOULD be retransmitted at least\r
+ once.\r
+\r
+[2] Where a DNS server is configured, by default a sender\r
+ SHOULD send LLMNR queries only for names that are either\r
+ unqualified or exist within the default domain. Where no\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 9]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+ DNS server is configured, an LLMNR query MAY be sent for\r
+ any name.\r
+\r
+[3] A responder with both link-local and routable addresses\r
+ MUST respond to LLMNR queries for A/AAAA RRs only with\r
+ routable address(es). This encourages use of routable\r
+ address(es) for establishment of new connections.\r
+\r
+[4] A sender SHOULD send LLMNR queries for PTR RRs\r
+ via unicast, as specified in Section 2.3.\r
+\r
+RRs returned in LLMNR responses MUST only include values that are valid\r
+on the local interface, such as IPv4 or IPv6 addresses valid on the\r
+local link or names defended using the mechanism described in Section 4.\r
+In particular:\r
+\r
+[1] If a link-scope IPv6 address is returned in a AAAA RR, that\r
+ address MUST be valid on the local link over which LLMNR is\r
+ used.\r
+\r
+[2] If an IPv4 address is returned, it must be reachable through\r
+ the link over which LLMNR is used.\r
+\r
+[3] If a name is returned (for example in a CNAME, MX\r
+ or SRV RR), the name MUST be valid on the local interface.\r
+\r
+3.1. Unqualified names\r
+\r
+The same host MAY use LLMNR queries for the resolution of unqualified\r
+host names, and conventional DNS queries for resolution of other DNS\r
+names.\r
+\r
+If a name is not qualified and does not end in a trailing dot, for the\r
+purposes of LLMNR, the implicit search order is as follows:\r
+\r
+[1] Request the name with the current domain appended.\r
+[2] Request just the name.\r
+\r
+This is the behavior suggested by [RFC1536]. LLMNR uses this technique\r
+to resolve unqualified host names.\r
+\r
+3.2. LLMNR configuration\r
+\r
+LLMNR usage MAY be configured manually or automatically on a per\r
+interface basis. By default, LLMNR responders SHOULD be enabled on all\r
+interfaces, at all times.\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 10]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is\r
+possible for a dual stack host to be configured with the address of a\r
+DNS server over IPv4, while remaining unconfigured with a DNS server\r
+suitable for use over IPv6. In these situations, a dual stack host will\r
+send AAAA queries to the configured DNS server over IPv4.\r
+\r
+However, an IPv6-only host unconfigured with a DNS server suitable for\r
+use over IPv6 will be unable to resolve names using DNS. Since\r
+automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and\r
+[DNSDisc]) are not yet widely deployed, and not all DNS servers support\r
+IPv6, lack of IPv6 DNS configuration may be a common problem in the\r
+short term, and LLMNR may prove useful in enabling linklocal name\r
+resolution over IPv6.\r
+\r
+For example, a home gateway may implement a DNS proxy and DHCPv4, but\r
+not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance,\r
+IPv6-only hosts will not be configured with a DNS server. Where the DNS\r
+proxy does not support dynamic client update over IPv6 or DHCPv6-based\r
+dynamic update of the DNS proxy, the home gateway will not be able to\r
+dynamically register the names of IPv6 hosts. As a result, the DNS\r
+proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an\r
+authoritative name error (RCODE=3). This prevents hosts from resolving\r
+the names of IPv6-only hosts on the local link. In this situation,\r
+LLMNR over IPv6 can be used for resolution of dynamic names.\r
+\r
+Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to\r
+configure LLMNR on an interface. The LLMNR Enable Option, described in\r
+[LLMNREnable], can be used to explicitly enable or disable use of LLMNR\r
+on an interface. The LLMNR Enable Option does not determine whether or\r
+in which order DNS itself is used for name resolution. The order in\r
+which various name resolution mechanisms should be used can be specified\r
+using the Name Service Search Option for DHCP [RFC2937].\r
+\r
+3.2.1. Configuration consistency\r
+\r
+It is possible that DNS configuration mechanisms will go in and out of\r
+service. In these circumstances, it is possible for hosts within an\r
+administrative domain to be inconsistent in their DNS configuration.\r
+\r
+For example, where DHCP is used for configuring DNS servers, one or more\r
+DHCP servers can go down. As a result, hosts configured prior to the\r
+outage will be configured with a DNS server, while hosts configured\r
+after the outage will not. Alternatively, it is possible for the DNS\r
+configuration mechanism to continue functioning while configured DNS\r
+servers fail.\r
+\r
+Unless unconfigured hosts periodically retry configuration, an outage in\r
+the DNS configuration mechanism will result in hosts continuing to\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 11]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+prefer LLMNR even once the outage is repaired. Since LLMNR only enables\r
+linklocal name resolution, this represents an unnecessary degradation in\r
+capabilities. As a result, it is recommended that hosts without a\r
+configured DNS server periodically attempt to obtain DNS configuration.\r
+A default retry interval of two (2) minutes is RECOMMENDED.\r
+\r
+4. Conflict resolution\r
+\r
+The sender MUST anticipate receiving multiple replies to the same LLMNR\r
+query, in the event that several LLMNR enabled computers receive the\r
+query and respond with valid answers. When this occurs, the responses\r
+MAY first be concatenated, and then treated in the same manner that\r
+multiple RRs received from the same DNS server would.\r
+\r
+There are some scenarios when multiple responders MAY respond to the\r
+same query. There are other scenarios when only one responder MAY\r
+respond to a query. Resource records for which the latter queries are\r
+submitted are referred as UNIQUE throughout this document. The\r
+uniqueness of a resource record depends on a nature of the name in the\r
+query and type of the query. For example it is expected that:\r
+\r
+ - multiple hosts may respond to a query for an SRV type record\r
+ - multiple hosts may respond to a query for an A or AAAA type\r
+ record for a cluster name (assigned to multiple hosts in\r
+ the cluster)\r
+ - only a single host may respond to a query for an A or AAAA\r
+ type record for a hostname.\r
+\r
+Every responder that responds to a LLMNR query and/or dynamic update\r
+request AND includes a UNIQUE record in the response:\r
+\r
+ 1. MUST verify that there is no other host within the scope of the\r
+ LLMNR query propagation that can return a resource record\r
+ for the same name, type and class.\r
+ 2. MUST NOT include a UNIQUE resource record in the\r
+ response without having verified its uniqueness.\r
+\r
+Where a host is configured to respond to LLMNR queries on more than one\r
+interface, each interface should have its own independent LLMNR cache.\r
+For each UNIQUE resource record in a given interface's cache, the host\r
+MUST verify resource record uniqueness on that interface. To accomplish\r
+this, the host MUST send an LLMNR query for each UNIQUE resource record.\r
+By default, a host SHOULD be configured to behave as though all RRs are\r
+UNIQUE. Uniqueness verification is carried out when the host:\r
+\r
+ - starts up or\r
+ - is configured to respond to the LLMNR queries on an interface or\r
+ - is configured to respond to the LLMNR queries using additional\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 12]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+ UNIQUE resource records.\r
+\r
+When a host that owns a UNIQUE record receives an LLMNR query for that\r
+record, the host MUST respond. After the client receives a response, it\r
+MUST check whether the response arrived on another interface. If this\r
+is the case, then the client can use the UNIQUE resource record in\r
+response to LLMNR queries. If not, then it MUST NOT use the UNIQUE\r
+resource record in response to LLMNR queries.\r
+\r
+Note that this name conflict detection mechanism doesn't prevent name\r
+conflicts when previously partitioned segments are connected by a\r
+bridge. In such a situation, name conflicts are detected when a sender\r
+receives more than one response to its LLMNR query.\r
+\r
+In this case, the sender sends the first response that it received to\r
+all responders that responded to this query except the first one, using\r
+unicast. A host that receives a query response containing a UNIQUE\r
+resource record that it owns, even if it didn't send such a query, MUST\r
+verify that no other host within the LLMNR scope is authoritative for\r
+the same name, using the mechanism described above. Based on the\r
+result, the host detects whether there is a name conflict and acts\r
+accordingly.\r
+\r
+4.1. Considerations for Multiple Interfaces\r
+\r
+A multi-homed host may elect to configure LLMNR on only one of its\r
+active interfaces. In many situations this will be adequate. However,\r
+should a host need to configure LLMNR on more than one of its active\r
+interfaces, there are some additional precautions it MUST take.\r
+Implementers who are not planning to support LLMNR on multiple\r
+interfaces simultaneously may skip this section.\r
+\r
+A multi-homed host checks the uniqueness of UNIQUE records as described\r
+in Section 4. The situation is illustrated in figure 1.\r
+\r
+ ---------- ----------\r
+ | | | |\r
+ [A] [myhost] [myhost]\r
+\r
+ Figure 1. Link-scope name conflict\r
+\r
+In this situation, the multi-homed myhost will probe for, and defend,\r
+its host name on both interfaces. A conflict will be detected on one\r
+interface, but not the other. The multi-homed myhost will not be able\r
+to respond with a host RR for "myhost" on the interface on the right\r
+(see Figure 1). The multi-homed host may, however, be configured to use\r
+the "myhost" name on the interface on the left.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 13]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Since names are only unique per-link, hosts on different links could be\r
+using the same name. If an LLMNR client sends requests over multiple\r
+interfaces, and receives replies from more than one, the result returned\r
+to the client is defined by the implementation. The situation is\r
+illustrated in figure 2.\r
+\r
+ ---------- ----------\r
+ | | | |\r
+ [A] [myhost] [A]\r
+\r
+\r
+ Figure 2. Off-segment name conflict\r
+\r
+If host myhost is configured to use LLMNR on both interfaces, it will\r
+send LLMNR queries on both interfaces. When host myhost sends a query\r
+for the host RR for name "A" it will receive a response from hosts on\r
+both interfaces.\r
+\r
+Host myhost will then forward a response from the first responder to the\r
+second responder, who will attempt to verify the uniqueness of host RR\r
+for its name, but will not discover a conflict, since the conflicting\r
+host resides on a different link. Therefore it will continue using its\r
+name.\r
+\r
+Indeed, host myhost cannot distinguish between the situation shown in\r
+Figure 2, and that shown in Figure 3 where no conflict exists.\r
+\r
+ [A]\r
+ | |\r
+ ----- -----\r
+ | |\r
+ [myhost]\r
+\r
+ Figure 3. Multiple paths to same host\r
+\r
+This illustrates that the proposed name conflict resolution mechanism\r
+does not support detection or resolution of conflicts between hosts on\r
+different links. This problem can also occur with unicast DNS when a\r
+multi-homed host is connected to two different networks with separated\r
+name spaces. It is not the intent of this document to address the issue\r
+of uniqueness of names within DNS.\r
+\r
+4.2. API issues\r
+\r
+[RFC2553] provides an API which can partially solve the name ambiguity\r
+problem for applications written to use this API, since the sockaddr_in6\r
+structure exposes the scope within which each scoped address exists, and\r
+this structure can be used for both IPv4 (using v4-mapped IPv6\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 14]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+addresses) and IPv6 addresses.\r
+\r
+Following the example in Figure 2, an application on 'myhost' issues the\r
+request getaddrinfo("A", ...) with ai_family=AF_INET6 and\r
+ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both\r
+interfaces and the resolver library will return a list containing\r
+multiple addrinfo structures, each with an associated sockaddr_in6\r
+structure. This list will thus contain the IPv4 and IPv6 addresses of\r
+both hosts responding to the name 'A'. Link-local addresses will have a\r
+sin6_scope_id value that disambiguates which interface is used to reach\r
+the address. Of course, to the application, Figures 2 and 3 are still\r
+indistinguishable, but this API allows the application to communicate\r
+successfully with any address in the list.\r
+\r
+5. Security Considerations\r
+\r
+LLMNR is by nature a peer-to-peer name resolution protocol. It is\r
+therefore inherently more vulnerable than DNS, since existing DNS\r
+security mechanisms are difficult to apply to LLMNR and an attacker only\r
+needs to be misconfigured to answer an LLMNR query with incorrect\r
+information.\r
+\r
+In order to address the security vulnerabilities, the following\r
+mechanisms are contemplated:\r
+\r
+[1] Scope restrictions.\r
+\r
+[2] Usage restrictions.\r
+\r
+[3] Cache and port separation.\r
+\r
+[4] Authentication.\r
+\r
+These techniques are described in the following sections.\r
+\r
+5.1. Scope restriction\r
+\r
+With LLMNR it is possible that hosts will allocate conflicting names for\r
+a period of time, or that attackers will attempt to deny service to\r
+other hosts by allocating the same name. Such attacks also allow hosts\r
+to receive packets destined for other hosts.\r
+\r
+Since LLMNR is typically deployed in situations where no trust model can\r
+be assumed, it is likely that LLMNR queries and responses will be\r
+unauthenticated. In the absence of authentication, LLMNR reduces the\r
+exposure to such threats by utilizing queries sent to a link-scope\r
+multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)\r
+fields to one (1) on both queries and responses.\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 15]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+While this limits the ability of off-link attackers to spoof LLMNR\r
+queries and responses, it does not eliminate it. For example, it is\r
+possible for an attacker to spoof a response to a frequent query (such\r
+as an A/AAAA query for a popular Internet host), and using a TTL or Hop\r
+Limit field larger than one (1), for the forged response to reach the\r
+LLMNR sender. There also are scenarios such as public "hotspots" where\r
+attackers can be present on the same link.\r
+\r
+These threats are most serious in wireless networks such as 802.11,\r
+since attackers on a wired network will require physical access to the\r
+home network, while wireless attackers may reside outside the home.\r
+Link-layer security can be of assistance against these threats if it is\r
+available.\r
+\r
+5.2. Usage restriction\r
+\r
+As noted in Section 3, LLMNR is intended for usage in a limited set of\r
+scenarios.\r
+\r
+If an interface has been configured via any automatic configuration\r
+mechanism which is able to supply DNS configuration information, then\r
+LLMNR SHOULD NOT be used as the primary name resolution mechanism on\r
+that interface, although it MAY be used as a name resolution mechanism\r
+of last resort.\r
+\r
+Note: enabling LLMNR for use in situations where a DNS server has been\r
+configured will result in upgraded hosts changing their default behavior\r
+without a simultaneous update to configuration information. Where this\r
+is considered undesirable, LLMNR SHOULD NOT be enabled by default, so\r
+that hosts will neither listen on the link-scope multicast address, nor\r
+will it send queries to that address.\r
+\r
+Use of LLMNR as a name resolution mechanism increases security\r
+vulnerabilities. For example, if an LLMNR query is sent whenever a DNS\r
+server does not respond in a timely way, then an attacker can execute a\r
+denial of service attack on the DNS server(s) and then poison the LLMNR\r
+cache by responding to the resulting LLMNR queries with incorrect\r
+information.\r
+\r
+The vulnerability is more serious if LLMNR is given higher priority than\r
+DNS among the enabled name resolution mechanisms. In such a\r
+configuration, a denial of service attack on the DNS server would not be\r
+necessary in order to poison the LLMNR cache, since LLMNR queries would\r
+be sent even when the DNS server is available. In addition, the LLMNR\r
+cache, once poisoned, would take precedence over the DNS cache,\r
+eliminating the benefits of cache separation. As a result, LLMNR is\r
+best thought of as a name resolution mechanism of last resort.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 16]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+5.3. Cache and port separation\r
+\r
+In order to prevent responses to LLMNR queries from polluting the DNS\r
+cache, LLMNR implementations MUST use a distinct, isolated cache for\r
+LLMNR on each interface. The use of separate caches is most effective\r
+when LLMNR is used as a name resolution mechanism of last resort, since\r
+this minimizes the opportunities for poisoning the LLMNR cache, and\r
+decreases reliance on it.\r
+\r
+LLMNR operates on a separate port from DNS, reducing the likelihood that\r
+a DNS server will unintentionally respond to an LLMNR query.\r
+\r
+5.4. Authentication\r
+\r
+LLMNR does not require use of DNSSEC, and as a result, responses to\r
+LLMNR queries may be unauthenticated. If authentication is desired, and\r
+a pre-arranged security configuration is possible, then IPsec ESP with a\r
+null-transform MAY be used to authenticate LLMNR responses. In a small\r
+network without a certificate authority, this can be most easily\r
+accomplished through configuration of a group pre-shared key for trusted\r
+hosts.\r
+\r
+6. IANA Considerations\r
+\r
+This specification does not create any new name spaces for IANA\r
+administration. LLMNR requires allocation of a port TBD for both TCP\r
+and UDP. Assignment of the same port for both transports is requested.\r
+LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that\r
+has been previously allocated to LLMNR by IANA. It also requires\r
+allocation of a link-scope multicast IPv6 address.\r
+\r
+7. Normative References\r
+\r
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and\r
+ Specification", RFC 1035, November 1987.\r
+\r
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,\r
+ April 1992.\r
+\r
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name\r
+ System (DNS UPDATE)", RFC 2136, April 1997.\r
+\r
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP\r
+ 23, RFC 2365, July 1998.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 17]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing\r
+ Architecture", RFC 2373, July 1998.\r
+\r
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6\r
+ (IPv6) Specification", RFC 2460, December 1998.\r
+\r
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions",\r
+ RFC 2535, March 1999.\r
+\r
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission\r
+ Timer", RFC 2988, November 2000.\r
+\r
+8. Informative References\r
+\r
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and\r
+ Suggested Fixes", RFC 1536, October 1993.\r
+\r
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for\r
+ IPv6", RFC 2292, February 1998.\r
+\r
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an\r
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,\r
+ October 1998.\r
+\r
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,\r
+ "Basic Socket Interface Extensions for IPv6", RFC 2553,\r
+ March 1999.\r
+\r
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC\r
+ 2937, September 2000.\r
+\r
+[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6\r
+ Service", Internet draft (work in progress), draft-droms-\r
+ dhcpv6-stateless-guide-01.txt, October 2002.\r
+\r
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness\r
+ of Caching", IEEE/ACM Transactions on Networking, Volume\r
+ 10, Number 5, pp. 589, October 2002.\r
+\r
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site\r
+ local unicast addresses to communicate with recursive DNS\r
+ servers", Internet draft (work in progress), draft-ietf-\r
+ ipv6-dns-discovery-07.txt, October 2002.\r
+\r
+[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic\r
+ Configuration of IPv4 Link-Local Addresses", Internet\r
+ draft (work in progress), draft-ietf-zeroconf-\r
+ ipv4-linklocal-07.txt, August 2002.\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 18]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft\r
+ (work in progress), draft-guttman-mdns-enable-02.txt,\r
+ April 2002.\r
+\r
+[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet\r
+ draft (work in progress), draft-ietf-ipn-gwg-icmp-name-\r
+ lookups-09.txt, May 2002.\r
+\r
+Acknowledgments\r
+\r
+This work builds upon original work done on multicast DNS by Bill\r
+Manning and Bill Woodcock. Bill Manning's work was funded under DARPA\r
+grant #F30602-99-1-0523. The authors gratefully acknowledge their\r
+contribution to the current specification. Constructive input has also\r
+been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert\r
+Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron\r
+Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-\r
+Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku\r
+Savela.\r
+\r
+Authors' Addresses\r
+\r
+Levon Esibov\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+EMail: levone@microsoft.com\r
+\r
+Bernard Aboba\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+Phone: +1 425 706 6605\r
+EMail: bernarda@microsoft.com\r
+\r
+Dave Thaler\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+Phone: +1 425 703 8835\r
+EMail: dthaler@microsoft.com\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 19]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Intellectual Property Statement\r
+\r
+The IETF takes no position regarding the validity or scope of any\r
+intellectual property or other rights that might be claimed to pertain\r
+to the implementation or use of the technology described in this\r
+document or the extent to which any license under such rights might or\r
+might not be available; neither does it represent that it has made any\r
+effort to identify any such rights. Information on the IETF's\r
+procedures with respect to rights in standards-track and standards-\r
+related documentation can be found in BCP-11. Copies of claims of\r
+rights made available for publication and any assurances of licenses to\r
+be made available, or the result of an attempt made to obtain a general\r
+license or permission for the use of such proprietary rights by\r
+implementors or users of this specification can be obtained from the\r
+IETF Secretariat.\r
+\r
+The IETF invites any interested party to bring to its attention any\r
+copyrights, patents or patent applications, or other proprietary rights\r
+which may cover technology that may be required to practice this\r
+standard. Please address the information to the IETF Executive\r
+Director.\r
+\r
+Full Copyright Statement\r
+\r
+Copyright (C) The Internet Society (2003). All Rights Reserved.\r
+This document and translations of it may be copied and furnished to\r
+others, and derivative works that comment on or otherwise explain it or\r
+assist in its implementation may be prepared, copied, published and\r
+distributed, in whole or in part, without restriction of any kind,\r
+provided that the above copyright notice and this paragraph are included\r
+on all such copies and derivative works. However, this document itself\r
+may not be modified in any way, such as by removing the copyright notice\r
+or references to the Internet Society or other Internet organizations,\r
+except as needed for the purpose of developing Internet standards in\r
+which case the procedures for copyrights defined in the Internet\r
+Standards process must be followed, or as required to translate it into\r
+languages other than English. The limited permissions granted above are\r
+perpetual and will not be revoked by the Internet Society or its\r
+successors or assigns. This document and the information contained\r
+herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE\r
+INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR\r
+IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE\r
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 20]\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 1 May 2003\r
+\r
+\r
+Open Issues\r
+\r
+Open issues with this specification are tracked on the following web\r
+site:\r
+\r
+http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html\r
+\r
+Expiration Date\r
+\r
+This memo is filed as <draft-ietf-dnsext-mdns-18.txt>, and expires\r
+November 22, 2003.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 21]\r
+\r
+\r
projects / thirdparty / bind9.git / commitdiff
