-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-29.txt> Microsoft
-20 January 2004
-
-
- 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 (2004). 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 System (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.
-
-The goal of LLMNR is to enable name resolution in scenarios in which
-conventional DNS name resolution is not possible. Since LLMNR only
-operates on the local link, it cannot be considered a substitute for
-DNS.
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 3
- 1.2 Terminology ..................................... 4
-2. Name resolution using LLMNR ........................... 4
- 2.1 LLMNR packet format ............................. 5
- 2.2 Sender behavior ................................. 8
- 2.3 Responder behavior .............................. 8
- 2.4 Unicast queries ................................. 10
- 2.5 Off-link detection .............................. 11
- 2.6 Responder responsibilities ...................... 12
- 2.7 Retransmission and jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the authority and additional sections .... 14
-3. Usage model ........................................... 14
- 3.1 LLMNR configuration ............................. 15
-4. Conflict resolution ................................... 16
- 4.1 Considerations for multiple interfaces .......... 18
- 4.2 API issues ...................................... 19
-5. Security considerations ............................... 20
- 5.1 Scope restriction ............................... 20
- 5.2 Usage restriction ............................... 21
- 5.3 Cache and port separation ....................... 22
- 5.4 Authentication .................................. 22
-6. IANA considerations ................................... 22
-7. References ............................................ 22
- 7.1 Normative References ............................ 22
- 7.2 Informative References .......................... 23
-Acknowledgments .............................................. 24
-Authors' Addresses ........................................... 25
-Intellectual Property Statement .............................. 25
-Full Copyright Statement ..................................... 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-1. Introduction
-
-This document discusses Link Local Multicast Name Resolution (LLMNR),
-which utilizes the DNS packet format and supports all current and future
-DNS formats, types and classes. LLMNR operates on a separate port from
-the Domain Name System (DNS), with a distinct resolver cache.
-
-The goal of LLMNR is to enable name resolution in scenarios in which
-conventional DNS name resolution is not possible. These include
-scenarios in which hosts are not configured with the address of a DNS
-server, where configured DNS servers do not reply to a query, or where
-they respond with errors, as described in Section 2. Since LLMNR only
-operates on the local link, it cannot be considered a substitute for
-DNS.
-
-Link-scope multicast addresses are used to prevent propagation of LLMNR
-traffic across routers, potentially flooding the network. LLMNR queries
-can also be sent to a unicast address, as described in Section 2.4.
-
-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 gateway, then the network is able to provide DNS server
-configuration. Configuration issues are discussed in Section 3.1.
-
-In the future, it may be desirable to consider use of multicast name
-resolution with multicast scopes beyond the link-scope. This could
-occur if LLMNR deployment is successful, the need for multicast name
-resolution beyond the link-scope, or multicast routing becomes
-ubiquitous. For example, expanded support for multicast name resolution
-might be required for mobile ad-hoc networking scenarios, or where no
-DNS server is available that is authoritative for the names of local
-hosts, and can support dynamic DNS, such as in wireless hotspots.
-
-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.
-
-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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-interpreted as described in [RFC2119].
-
-1.2. Terminology
-
-This document assumes familiarity with DNS terminology defined in
-[RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An address is considered reachable over a link if either an ARP or
- neighbor discovery cache entry exists for the address on the link.
-
-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.
-
-2. Name resolution using LLMNR
-
-LLMNR is a peer-to-peer name resolution protocol that is not intended as
-a replacement for DNS. LLMNR queries are sent to and received on port
-TBD. 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 TBD. The IPv6 link-scope multicast address a given
-responder listens to, and to which a sender sends all queries, is TBD.
-
-Typically a host is configured as both an LLMNR sender and a responder.
-A host MAY be configured as a sender, but not a responder. However, a
-host configured as a responder MUST act as a sender to verify the
-uniqueness of names as described in Section 4. This document does not
-specify how names are chosen or configured. This may occur via any
-mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
-
-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. Enabling LLMNR for use in situations where a
-DNS server has been configured will result in a change in default
-behavior without a simultaneous update to configuration information.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Where this is considered undesirable, LLMNR SHOULD NOT be enabled by
-default, so that hosts will neither listen on the link-scope multicast
-address, nor will they send queries to that address.
-
-An LLMNR sender may send a request for any name. However, by default,
-LLMNR requests SHOULD be sent only when one of the following conditions
-are met:
-
-[1] No manual or automatic DNS configuration has been performed. If an
- interface has been configured with DNS server address(es), then
- LLMNR SHOULD NOT be used as the primary name resolution mechanism
- on that interface, although it MAY be used as a name resolution
- mechanism of last resort.
-
-[2] DNS servers do not respond.
-
-[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section.
-
-A typical sequence of events for LLMNR usage is as follows:
-
-[a] DNS servers are not configured or do not respond to a DNS query, or
- respond with RCODE=3, or RCODE=0 and an empty answer section.
-
-[b] An LLMNR sender sends an LLMNR query to the link-scope multicast
- address(es) defined in Section 2, unless a unicast query is
- indicated. A sender SHOULD send LLMNR queries for PTR RRs via
- unicast, as specified in Section 2.4.
-
-[c] A responder responds to this query only if it is authoritative for
- the domain name in the query. A responder responds to a multicast
- query by sending a unicast UDP response to the sender. Unicast
- queries are responded to as indicated in Section 2.4.
-
-[d] Upon reception of the response, the sender processes it.
-
-Further details of sender and responder behavior are provided in the
-sections that follow.
-
-2.1. LLMNR packet format
-
-LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
-both queries and responses. LLMNR implementations SHOULD send UDP
-queries and responses only as large as are known to be permissible
-without causing fragmentation. When in doubt a maximum packet size of
-512 octets SHOULD be used. LLMNR implementations MUST accept UDP
-queries and responses as large as permitted by the link MTU.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-2.1.1. LLMNR header format
-
-LLMNR queries and responses utilize the DNS header format defined in
-[RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ID |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| QDCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ANCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| NSCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ARCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value.
-
-QR A one bit field that specifies whether this message is an LLMNR
- query (0), or an LLMNR response (1).
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set an LLMNR response,
- then the sender MAY use the response if it contains all necessary
- information, or the sender MAY discard the response and resend the
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
- LLMNR query over TCP using the unicast address of the responder as
- the destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the RCODE MUST be zero, and is
- ignored by the responder. The response to a multicast LLMNR query
- MUST have RCODE set to zero. A sender MUST silently discard an
- LLMNR response with a non-zero RCODE sent in response to a
- multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferrable to
- not sending a response, since it enables errors to be diagnosed.
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender behavior
-
-A sender may send an LLMNR query for any legal resource record type
-(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
-
-As described in Section 2.4, a sender may also send a unicast query.
-Sections 2 and 3 describe the circumstances in which LLMNR queries may
-be sent.
-
-The sender MUST anticipate receiving no replies to some LLMNR queries,
-in the event that no responders are available within the link-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).
-
-Since the responder may order the RRs in the response so as to indicate
-preference, the sender SHOULD preserve ordering in the response to the
-querying application.
-
-2.3. Responder behavior
-
-An LLMNR response MUST be sent to the sender via unicast.
-
-Upon configuring an IP address responders typically will synthesize
-corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR
-queries for these RRs. An SOA RR is synthesized only when a responder
-has another RR as well; the SOA RR MUST NOT be the only RR that a
-responder has. However, in general whether RRs are manually or
-automatically created is an implementation decision.
-
-For example, a host configured to have computer name "host1" and to be a
-member of the "example.com" domain, and with IPv4 address 10.1.1.1 and
-IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the
-following records:
-
-host1. IN A 10.1.1.1
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-host1.example.com. IN A 10.1.1.1
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-1.1.1.10.in-addr.arpa. IN PTR host1.
-IN PTR host1.example.com.
-
-6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
-IN PTR host1.
-IN PTR host1.example.com
-
-An LLMNR responder might be further manually configured with the name of
-a local mail server with an MX RR included in the "host1." and
-"host1.example.com." records.
-
-In responding to queries:
-
-[a] Responders MUST listen on UDP port TBD on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port TBD on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses SHOULD always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using cached data.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MAY respond with
- RCODE=0 and an empty answer section, if the type of query does not
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
- match a RR that the responder has.
-
-As an example, a host configured to respond to LLMNR queries for the
-name "foo.example.com." is authoritative for the name
-"foo.example.com.". On receiving an LLMNR query for an A RR with the
-name "foo.example.com." the host authoritatively responds with A RR(s)
-that contain IP address(es) in the RDATA of the resource record. If the
-responder has a AAAA RR, but no A RR, and an A RR query is received, the
-responder would respond with RCODE=0 and an empty answer section.
-
-In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone apex except for
-the branches delegated into separate zones. Contrary to conventional
-DNS terminology, an LLMNR responder is authoritative only for the zone
-apex.
-
-For example the host "foo.example.com." is not authoritative for the
-name "child.foo.example.com." unless the host is configured with
-multiple names, including "foo.example.com." and
-"child.foo.example.com.". As a result, "foo.example.com." cannot reply
-to an LLMNR query for "child.foo.example.com." with RCODE=3
-(authoritative name error). The purpose of limiting the name authority
-scope of a responder is to prevent complications that could be caused by
-coexistence of two or more hosts with the names representing child and
-parent (or grandparent) nodes in the DNS tree, for example,
-"foo.example.com." and "child.foo.example.com.".
-
-In this example (unless this limitation is introduced) an LLMNR query
-for an A resource record for the name "child.foo.example.com." would
-result in two authoritative responses: RCODE=3 (authoritative name
-error) received from "foo.example.com.", and a requested A record - from
-"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
-hosts could perform a dynamic update of the parent (or grandparent) zone
-with a delegation to a child zone. In this example a host
-"child.foo.example.com." would send a dynamic update for the NS and glue
-A record to "foo.example.com.", but this approach significantly
-complicates implementation of LLMNR and would not be acceptable for
-lightweight hosts.
-
-2.4. Unicast queries and responses
-
-Unicast queries SHOULD be sent when:
-
-[a] A sender repeats a query after it received a response with the TC
- bit set to the previous LLMNR multicast query, or
-
-[b] The sender queries for a PTR RR of a fully formed IP address within
- the "in-addr.arpa" or "ip6.arpa" zones.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-A responder receiving a unicast query MUST send the response with a
-source address set to the destination address field of the IP header of
-the query causing the response.
-
-Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support
-sending TCP queries, and responders MUST support listening for TCP
-queries.
-
-Responses to TCP unicast LLMNR queries MUST be sent using TCP, using
-the same connection as the query. If the sender of a TCP query receives
-a response to that query not using TCP, the response MUST be silently
-discarded.
-
-Unicast UDP queries MAY be responded to with a UDP response containing
-an empty answer section and the TC bit set, so as to require the sender
-to resend the query using TCP.
-
-If an ICMP "Time Exceeded" message is received in response to a unicast
-UDP query, or if TCP connection setup cannot be completed in order to
-send a unicast TCP query, this is treated as a response that no records
-of the specified type and class exist for the specified name (it is
-treated the same as a response with RCODE=0 and an empty answer
-section). The UDP sender receiving an ICMP "Time Exceeded" message
-SHOULD verify that the ICMP error payload contains a valid LLMNR query
-packet, which matches a query that is currently in progress, so as to
-guard against a potential Denial of Service (DoS) attack. If a match
-cannot be made, then the sender relies on the retransmission and timeout
-behavior described in Section 2.7.
-
-2.5. "Off link" detection
-
-For IPv4, an "on link" address is defined as a link-local address
-[IPv4Link] or an address whose prefix belongs to a subnet on the local
-link. For IPv6 [RFC2460] an "on link" address is either a link-local
-address, defined in [RFC2373], or an address whose prefix belongs to a
-subnet on the local link.
-
-A sender MUST select a source address for LLMNR queries that is "on
-link". The destination address of an LLMNR query MUST be a link-scope
-multicast address or an "on link" unicast address.
-
-A responder MUST select a source address for responses that is "on
-link". The destination address of an LLMNR response MUST be an "on link"
-unicast address.
-
-On receiving an LLMNR query, the responder MUST check whether it was
-sent to a LLMNR multicast addresses defined in Section 2. If it was
-sent to another multicast address, then the query MUST be silently
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-discarded.
-
-In composing LLMNR queries, the sender MUST set the Hop Limit field in
-the IPv6 header and the TTL field in IPv4 header of the response to one
-(1). Even when LLMNR queries are sent to a link-scope multicast
-address, it is possible that some routers may not properly implement
-link-scope multicast, or that link-scope multicast addresses may leak
-into the multicast routing system. Therefore setting the IPv6 Hop Limit
-or IPv4 TTL field to one provides an additional precaution against
-leakage of LLMNR queries.
-
-In composing a response to an LLMNR query, the responder MUST set the
-Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
-the response to one (1). This is done so as to prevent the use of LLMNR
-for denial of service attacks across the Internet.
-
-Section 2.4 discusses use of TCP for LLMNR queries and responses. The
-responder SHOULD set the TTL or Hop Limit settings on the TCP listen
-socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop
-Limit (IPv6) set to one (1). This prevents an incoming connection from
-off-link since the sender will not receive a SYN-ACK from the responder.
-
-Implementation note:
-
- In the sockets API for IPv4 [POSIX], 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. Responder responsibilities
-
-It is the responsibility of the responder to ensure that RRs returned in
-LLMNR responses MUST only include values that are valid on the local
-interface, such as IPv4 or IPv6 addresses valid on the local link or
-names defended using the mechanism described in Section 4. In
-particular:
-
-[a] 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.
-
-[b] If an IPv4 address is returned, it MUST be reachable through the
- link over which LLMNR is used.
-
-[c] If a name is returned (for example in a CNAME, MX or SRV RR), the
- name MUST be resolvable on the local link over which LLMNR is used.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Routable addresses MUST be included first in the response, if available.
-This encourages use of routable address(es) for establishment of new
-connections.
-
-2.7. Retransmission and jitter
-
-An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-when to retransmit an LLMNR query and how long to collect responses to
-an LLMNR query.
-
-If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-then a sender MAY repeat the transmission of the query in order to
-assure that it was received by a host capable of responding to it.
-Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.
-Where LLMNR queries are sent using TCP, retransmission is handled by the
-transport layer.
-
-Because an LLMNR sender cannot know in advance if a query sent using
-multicast will receive no response, one response, or more than one
-response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect
-all possible responses, rather than considering the multicast query
-answered after the first response is received. A unicast query sender
-considers the query answered after the first response is received, so
-that it only waits for LLMNR_TIMEOUT if no response has been received.
-
-An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
-for each transmission. It is suggested that the computation of
-LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries
-sent on the same interface.
-
-For example, the algorithms described in RFC 2988 [RFC2988] (including
-exponential backoff) to compute an RTO, which is used as the value of
-LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed
-in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in
-Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed
-in Section 2 of [RFC2988], paragraph 2.5).
-
-Recommended values are an initial RTO of 1 second, a minimum RTO of
-200ms, and a maximum RTO of 5 seconds. In order to avoid
-synchronization, the transmission of each LLMNR query and response
-SHOULD delayed by a time randomly selected from the interval 0 to 100
-ms. This delay MAY be avoided by responders responding with RRs which
-they have previously determined to be UNIQUE (see Section 4 for
-details).
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-2.8. DNS TTL
-
-The responder should use a pre-configured TTL value in the records
-returned an LLMNR response. A default value of 30 seconds is
-RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
-networks), the TTL value may need to be reduced.
-
-Due to the TTL minimalization necessary when caching an RRset, all TTLs
-in an RRset MUST be set to the same value.
-
-2.9. Use of the authority and additional sections
-
-Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-concept of delegation. In LLMNR, the NS resource record type may be
-stored and queried for like any other type, but it has no special
-delegation semantics as it does in the DNS. Responders MAY have NS
-records associated with the names for which they are authoritative, but
-they SHOULD NOT include these NS records in the authority sections of
-responses.
-
-Responders SHOULD insert an SOA record into the authority section of a
-negative response, to facilitate negative caching as specified in
-[RFC2308]. The owner name of this SOA record MUST be equal to the query
-name.
-
-Responders SHOULD NOT perform DNS additional section processing, except
-as required for EDNS0 and DNSSEC.
-
-Senders MUST NOT cache RRs from the authority or additional section of a
-response as answers, though they may be used for other purposes such as
-negative caching.
-
-3. Usage model
-
-Since LLMNR is a secondary name resolution mechanism, its usage is in
-part determined by the behavior of DNS implementations. This document
-does not specify any changes to DNS resolver behavior, such as
-searchlist processing or retransmission/failover policy. However,
-robust DNS resolver implementations are more likely to avoid unnecessary
-LLMNR queries.
-
-As noted in [DNSPerf], even when DNS servers are configured, a
-significant fraction of DNS queries do not receive a response, or result
-in negative responses due to missing inverse mappings or NS records that
-point to nonexistent or inappropriate hosts. This has the potential to
-result in a large number of unnecessary LLMNR queries.
-
-[RFC1536] describes common DNS implementation errors and fixes. If the
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-proposed fixes are implemented, unnecessary LLMNR queries will be
-reduced substantially, and so implementation of [RFC1536] is
-recommended.
-
-For example, [RFC1536] Section 1 describes issues with retransmission
-and recommends implementation of a retransmission policy based on round
-trip estimates, with exponential backoff. [RFC1536] Section 4 describes
-issues with failover, and recommends that resolvers try another server
-when they don't receive a response to a query. These policies are
-likely to avoid unnecessary LLMNR queries.
-
-[RFC1536] Section 3 describes zero answer bugs, which if addressed will
-also reduce unnecessary LLMNR queries.
-
-[RFC1536] Section 6 describes name error bugs and recommended searchlist
-processing that will reduce unnecessary RCODE=3 (authoritative name)
-errors, thereby also reducing unnecessary LLMNR queries.
-
-3.1. LLMNR configuration
-
-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-possible for a dual stack host to be configured with the address of a
-DNS server over IPv4, while remaining unconfigured with a DNS server
-suitable for use over IPv6.
-
-In these situations, a dual stack host will send AAAA queries to the
-configured DNS server over IPv4. However, an IPv6-only host
-unconfigured with a DNS server suitable for use over IPv6 will be unable
-to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
-(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not
-all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
-may be a common problem in the short term, and LLMNR may prove useful in
-enabling linklocal name resolution over IPv6.
-
-Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-IPv6-only hosts may not be configured with a DNS server. Where there is
-no DNS server authoritative for the name of a host or the authoritative
-DNS server does not support dynamic client update over IPv6 or
-DHCPv6-based dynamic update, then an IPv6-only host will not be able to
-do DNS dynamic update, and other hosts will not be able to resolve its
-name.
-
-For example, if the configured DNS server responds to AAAA RR queries
-sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then
-it will not be possible to resolve the names of IPv6-only hosts. In
-this situation, LLMNR over IPv6 can be used for local name resolution.
-
-Similarly, if a DHCPv4 server is available providing DNS server
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-configuration, and DNS server(s) exist which are authoritative for the A
-RRs of local hosts and support either dynamic client update over IPv4 or
-DHCPv4-based dynamic update, then the names of local IPv4 hosts can be
-resolved over IPv4 without LLMNR. However, if no DNS server is
-authoritative for the names of local hosts, or the authoritative DNS
-server(s) do not support dynamic update, then LLMNR enables linklocal
-name resolution over IPv4.
-
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure LLMNR on an interface. The LLMNR Enable Option, described in
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
-on an interface. The LLMNR Enable Option does not determine whether or
-in which order DNS itself is used for name resolution. The order in
-which various name resolution mechanisms should be used can be specified
-using the Name Service Search Option (NSSO) for DHCP [RFC2937], using
-the LLMNR Enable Option code carried in the NSSO data.
-
-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 fail. As a result, hosts configured prior to the
-outage will be configured with a DNS server, while hosts configured
-after the outage will not. Alternatively, it is possible for the DNS
-configuration mechanism to continue functioning while configured DNS
-servers fail.
-
-Unless unconfigured hosts periodically retry configuration, an outage in
-the DNS configuration mechanism will result in hosts continuing to use
-LLMNR even once the outage is repaired. Since LLMNR only enables
-linklocal name resolution, this represents an unnecessary degradation in
-capabilities. As a result, it is recommended that hosts without a
-configured DNS server periodically attempt to obtain DNS configuration.
-For example, where DHCP is used for DNS configuration, [RFC2131]
-recommends a maximum retry interval of 64 seconds. In the absence of
-other guidance, a default retry interval of one (1) minute is
-RECOMMENDED.
-
-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; the sender
-perceives no inherent conflict in the receipt of multiple responses.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-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 name.
-
-Every responder that responds to an LLMNR query 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 issue 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 configuration,
-the host MUST verify resource record uniqueness on that interface. To
-accomplish this, the host MUST send an LLMNR query for each UNIQUE
-resource record.
-
-By default, a host SHOULD be configured to behave as though all RRs are
-UNIQUE. Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive during sleep)
- - is configured to respond to the LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records
- - detects that an interface is connected and is usable
- (e.g. an IEEE 802 hardware link-state change indicating
- that a cable was attached or that an association has occurred
- with a wireless base station and that any required authentication
- has completed)
-
-When a host that has a UNIQUE record receives an LLMNR query for that
-record, the host MUST respond. After the client receives a response, it
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-MUST check whether the response arrived on an interface different from
-the one on which the query was sent. If the response arrives on a
-different interface, the client can use the UNIQUE resource record in
-response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
-resource record in response to LLMNR queries.
-
-The name conflict detection mechanism doesn't prevent name conflicts
-when previously partitioned segments are connected by a bridge. In order
-to minimize the chance of conflicts in such a situation, it is
-recommended that steps be taken to ensure name uniqueness. For example,
-the name could be chosen randomly from a large pool of potential names,
-or the name could be assigned via a process designed to guarantee
-uniqueness.
-
-When name conflicts are detected, they SHOULD be logged. To detect
-duplicate use of a name, an administrator can use a name resolution
-utility which employs LLMNR and lists both responses and responders.
-This would allow an administrator to diagnose behavior and potentially
-to intervene and reconfigure LLMNR responders who should not be
-configured to respond to the same name.
-
-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,
-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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-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 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.
-
-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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-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. While tools exist
-to alllow an attacker to spoof a response to a DNS query, spoofing a
-response to an LLMNR query is easier since the query is sent to a link-
-scope multicast address, where every host on the logical link will be
-made aware of it.
-
-In order to address the security vulnerabilities, the following
-mechanisms are contemplated:
-
-[1] Scope restrictions.
-
-[2] Usage restrictions.
-
-[3] Cache and port separation.
-
-[4] Authentication.
-
-These techniques are described in the following sections.
-
-5.1. Scope restriction
-
-With LLMNR it is possible that hosts will allocate conflicting names for
-a period of time, or that attackers will attempt to deny service to
-other hosts by allocating the same name. Such attacks also allow hosts
-to receive packets destined for other hosts.
-
-Since LLMNR is typically deployed in situations where no trust model can
-be assumed, it is likely that LLMNR queries and responses will be
-unauthenticated. In the absence of authentication, LLMNR reduces the
-exposure to such threats by utilizing queries sent to a link-scope
-multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
-fields to one (1) on both queries and responses.
-
-A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can
-be used to launch denial of service attacks. For example, were the TTL
-of an LLMNR Response to be set to a value larger than one (1), an
-attacker could send a large volume of queries from a spoofed source
-address, causing an off-link target to be deluged with responses.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Utilizing a TTL of one (1) in LLMNR responses ensures that they will not
-be forwarded off-link. Using a TTL of one (1) to set up a TCP connection
-in order to send a unicast LLMNR query reduces the likelihood of both
-denial of service attacks and spoofed responses. Checking that an LLMNR
-query is sent to a link-scope multicast address should prevent spoofing
-of multicast queries by off-link attackers.
-
-While this limits the ability of off-link attackers to spoof LLMNR
-queries and responses, it does not eliminate it. For example, it is
-possible for an attacker to spoof a response to a frequent query (such
-as an A or AAAA query for a popular Internet host), and by using a TTL
-or Hop Limit field larger than one (1), for the forged response to reach
-the LLMNR sender.
-
-There also are scenarios such as public "hotspots" where attackers can
-be present on the same link. These threats are most serious in wireless
-networks such as 802.11, since attackers on a wired network will require
-physical access to the home network, while wireless attackers may reside
-outside the home. Link-layer security can be of assistance against
-these threats if it is available.
-
-5.2. Usage restriction
-
-As noted in Sections 2 and 3, LLMNR is intended for usage in a limited
-set of scenarios.
-
-If an LLMNR query is sent whenever a DNS server does not respond in a
-timely way, then an attacker can poison the LLMNR cache by responding to
-the query with incorrect information. To some extent, these
-vulnerabilities exist today, since DNS response spoofing tools are
-available that can allow an attacker to respond to a query more quickly
-than a distant DNS server.
-
-Since LLMNR queries are sent and responded to on the local-link, an
-attacker will need to respond more quickly to provide its own response
-prior to arrival of the response from a legitimate responder. If an
-LLMNR query is sent for an off-link host, spoofing a response in a
-timely way is not difficult, since a legitimate response will never be
-received.
-
-The vulnerability is more serious if LLMNR is given higher priority than
-DNS among the enabled name resolution mechanisms. In such a
-configuration, a denial of service attack on the DNS server would not be
-necessary in order to poison the LLMNR cache, since LLMNR queries would
-be sent even when the DNS server is available. In addition, the LLMNR
-cache, once poisoned, would take precedence over the DNS cache,
-eliminating the benefits of cache separation. As a result, LLMNR is only
-used as a name resolution mechanism of last resort.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-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 implementations may not support DNSSEC or TSIG, 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 creates one new name space: the reserved bits in the
-LLMNR header. These are allocated by IETF Consensus, in accordance with
-BCP 26 [RFC2434].
-
-LLMNR requires allocation of a port TBD for both TCP and UDP.
-Assignment of the same port for both transports is requested.
-
-LLMNR requires allocation of a link-scope multicast IPv4 address TBD.
-LLMNR also requires allocation of a link-scope multicast IPv6 address
-TBD.
-
-7. References
-
-7.1. 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.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 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.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-7.2. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 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.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[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-10.txt, October
- 2003.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[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.
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-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
-
-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.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2004). 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.
-
-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-29.txt>, and expires
-August 4, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 26]
-
+DNSEXT Working Group Levon Esibov\r
+INTERNET-DRAFT Bernard Aboba\r
+Category: Standards Track Dave Thaler\r
+<draft-ietf-dnsext-mdns-30.txt> Microsoft\r
+17 March 2004\r
+\r
+\r
+\r
+ Linklocal Multicast Name Resolution (LLMNR)\r
+\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
+\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
+\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
+\r
+The list of current Internet-Drafts can be accessed at\r
+http://www.ietf.org/ietf/1id-abstracts.txt\r
+\r
+\r
+The list of Internet-Draft Shadow Directories can be accessed at\r
+http://www.ietf.org/shadow.html.\r
+\r
+\r
+Copyright Notice\r
+\r
+\r
+Copyright (C) The Internet Society (2004). All Rights Reserved.\r
+\r
+\r
+Abstract\r
+\r
+\r
+Today, with the rise of home networking, there are an increasing number\r
+of ad-hoc networks operating without a Domain Name System (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
+The goal of LLMNR is to enable name resolution in scenarios in which\r
+conventional DNS name resolution is not possible. Since LLMNR only\r
+operates on the local link, it cannot be considered a substitute for\r
+DNS.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 1]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+Table of Contents\r
+\r
+\r
+1. Introduction .......................................... 3\r
+ 1.1 Requirements .................................... 3\r
+ 1.2 Terminology ..................................... 4\r
+2. Name resolution using LLMNR ........................... 4\r
+ 2.1 LLMNR packet format ............................. 5\r
+ 2.2 Sender behavior ................................. 8\r
+ 2.3 Responder behavior .............................. 8\r
+ 2.4 Unicast queries ................................. 10\r
+ 2.5 Off-link detection .............................. 11\r
+ 2.6 Responder responsibilities ...................... 12\r
+ 2.7 Retransmission and jitter ....................... 12\r
+ 2.8 DNS TTL ......................................... 13\r
+ 2.9 Use of the authority and additional sections .... 13\r
+3. Usage model ........................................... 14\r
+ 3.1 LLMNR configuration ............................. 15\r
+4. Conflict resolution ................................... 16\r
+ 4.1 Considerations for multiple interfaces .......... 18\r
+ 4.2 API issues ...................................... 19\r
+5. Security considerations ............................... 19\r
+ 5.1 Scope restriction ............................... 20\r
+ 5.2 Usage restriction ............................... 21\r
+ 5.3 Cache and port separation ....................... 21\r
+ 5.4 Authentication .................................. 22\r
+6. IANA considerations ................................... 22\r
+7. References ............................................ 22\r
+ 7.1 Normative References ............................ 22\r
+ 7.2 Informative References .......................... 23\r
+Acknowledgments .............................................. 24\r
+Authors' Addresses ........................................... 25\r
+Intellectual Property Statement .............................. 25\r
+Full Copyright Statement ..................................... 26\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
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+1. Introduction\r
+\r
+\r
+This document discusses Link Local Multicast Name Resolution (LLMNR),\r
+which utilizes the DNS packet format and supports all current and future\r
+DNS formats, types and classes. LLMNR operates on a separate port from\r
+the Domain Name System (DNS), with a distinct resolver cache.\r
+\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 2. Since LLMNR only\r
+operates on the local link, it cannot be considered a substitute for\r
+DNS.\r
+\r
+\r
+Link-scope multicast addresses are used to prevent propagation of LLMNR\r
+traffic across routers, potentially flooding the network. LLMNR queries\r
+can also be sent to a unicast address, as described in Section 2.4.\r
+\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 gateway, then the network is able to provide DNS server\r
+configuration. Configuration issues are discussed in Section 3.1.\r
+\r
+\r
+In the future, it may be desirable to consider use of multicast name\r
+resolution with multicast scopes beyond the link-scope. This could\r
+occur if LLMNR deployment is successful, the need for multicast name\r
+resolution beyond the link-scope, or multicast routing becomes\r
+ubiquitous. For example, expanded support for multicast name resolution\r
+might be required for mobile ad-hoc networking scenarios, or where no\r
+DNS server is available that is authoritative for the names of local\r
+hosts, and can support dynamic DNS, such as in wireless hotspots.\r
+\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.\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
+\r
+1.1. Requirements\r
+\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
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 3]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+interpreted as described in [RFC2119].\r
+\r
+\r
+1.2. Terminology\r
+\r
+\r
+This document assumes familiarity with DNS terminology defined in\r
+[RFC1035]. Other terminology used in this document includes:\r
+\r
+\r
+Positively Resolved\r
+ Responses with RCODE set to zero are referred to in this document\r
+ as "positively resolved".\r
+\r
+\r
+Routable Address\r
+ An address other than a Link-Local address. This includes globally\r
+ routable addresses, as well as private addresses.\r
+\r
+\r
+Reachable\r
+ An address is considered reachable over a link if either an ARP or\r
+ neighbor discovery cache entry exists for the address on the link.\r
+\r
+\r
+Responder\r
+ A host that listens to LLMNR queries, and responds to those for\r
+ which it is authoritative.\r
+\r
+\r
+Sender\r
+ A host that sends an LLMNR query.\r
+\r
+\r
+2. Name resolution using LLMNR\r
+\r
+\r
+LLMNR is a peer-to-peer name resolution protocol that is not intended as\r
+a replacement for DNS. LLMNR queries are sent to and received on port\r
+TBD. 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 TBD. The IPv6 link-scope multicast address a given\r
+responder listens to, and to which a sender sends all queries, is TBD.\r
+\r
+\r
+Typically a host is configured as both an LLMNR sender and a responder.\r
+A host MAY be configured as a sender, but not a responder. However, a\r
+host configured as a responder MUST act as a sender to verify the\r
+uniqueness of names as described in Section 4. This document does not\r
+specify how names are chosen or configured. This may occur via any\r
+mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].\r
+\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. Enabling LLMNR for use in situations where a\r
+DNS server has been configured will result in a change in default\r
+behavior without a simultaneous update to configuration information.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 4]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+Where this is considered undesirable, LLMNR SHOULD NOT be enabled by\r
+default, so that hosts will neither listen on the link-scope multicast\r
+address, nor will they send queries to that address.\r
+\r
+\r
+An LLMNR sender may send a request for any name. However, by default,\r
+LLMNR requests SHOULD be sent only when one of the following conditions\r
+are met:\r
+\r
+\r
+[1] No manual or automatic DNS configuration has been performed. If an\r
+ interface has been configured with DNS server address(es), then\r
+ LLMNR SHOULD NOT be used as the primary name resolution mechanism\r
+ on that interface, although it MAY be used as a name resolution\r
+ mechanism of last resort.\r
+\r
+\r
+[2] DNS servers do not respond.\r
+\r
+\r
+[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name\r
+ Error) or RCODE=0, and an empty answer section.\r
+\r
+\r
+A typical sequence of events for LLMNR usage is as follows:\r
+\r
+\r
+[a] DNS servers are not configured or do not respond to a DNS query, or\r
+ respond with RCODE=3, or RCODE=0 and an empty answer section.\r
+\r
+\r
+[b] An LLMNR sender sends an LLMNR query to the link-scope multicast\r
+ address(es) defined in Section 2, unless a unicast query is\r
+ indicated. A sender SHOULD send LLMNR queries for PTR RRs via\r
+ unicast, as specified in Section 2.4.\r
+\r
+\r
+[c] A responder responds to this query only if it is authoritative for\r
+ the domain name in the query. A responder responds to a multicast\r
+ query by sending a unicast UDP response to the sender. Unicast\r
+ queries are responded to as indicated in Section 2.4.\r
+\r
+\r
+[d] Upon reception of the response, the sender processes it.\r
+\r
+\r
+Further details of sender and responder behavior are provided in the\r
+sections that follow.\r
+\r
+\r
+2.1. LLMNR packet format\r
+\r
+\r
+LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for\r
+both queries and responses. LLMNR implementations SHOULD send UDP\r
+queries and responses only as large as are known to be permissible\r
+without causing fragmentation. When in doubt a maximum packet size of\r
+512 octets SHOULD be used. LLMNR implementations MUST accept UDP\r
+queries and responses as large as permitted by the link MTU.\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 5]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+2.1.1. LLMNR header format\r
+\r
+\r
+LLMNR queries and responses utilize the DNS header format defined in\r
+[RFC1035] with exceptions noted below:\r
+\r
+\r
+ 1 1 1 1 1 1\r
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+| ID |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+| QDCOUNT |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+| ANCOUNT |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+| NSCOUNT |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+| ARCOUNT |\r
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+\r
+\r
+where:\r
+\r
+\r
+ID A 16 bit identifier assigned by the program that generates any kind\r
+ of query. This identifier is copied from the query to the response\r
+ and can be used by the sender to match responses to outstanding\r
+ queries. The ID field in a query SHOULD be set to a pseudo-random\r
+ value.\r
+\r
+\r
+QR A one bit field that specifies whether this message is an LLMNR\r
+ query (0), or an LLMNR response (1).\r
+\r
+\r
+OPCODE\r
+ A four bit field that specifies the kind of query in this message.\r
+ This value is set by the originator of a query and copied into the\r
+ response. This specification defines the behavior of standard\r
+ queries and responses (opcode value of zero). Future\r
+ specifications may define the use of other opcodes with LLMNR.\r
+ LLMNR senders and responders MUST support standard queries (opcode\r
+ value of zero). LLMNR queries with unsupported OPCODE values MUST\r
+ be silently discarded by responders.\r
+\r
+\r
+TC TrunCation - specifies that this message was truncated due to\r
+ length greater than that permitted on the transmission channel.\r
+ The TC bit MUST NOT be set in an LLMNR query and if set is ignored\r
+ by an LLMNR responder. If the TC bit is set an LLMNR response,\r
+ then the sender MAY use the response if it contains all necessary\r
+ information, or the sender MAY discard the response and resend the\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 6]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+ LLMNR query over TCP using the unicast address of the responder as\r
+ the destination address. See [RFC2181] and Section 2.4 of this\r
+ specification for further discussion of the TC bit.\r
+\r
+\r
+Z Reserved for future use. Implementations of this specification\r
+ MUST set these bits to zero in both queries and responses. If\r
+ these bits are set in a LLMNR query or response, implementations of\r
+ this specification MUST ignore them. Since reserved bits could\r
+ conceivably be used for different purposes than in DNS,\r
+ implementors are advised not to enable processing of these bits in\r
+ an LLMNR implementation starting from a DNS code base.\r
+\r
+\r
+RCODE\r
+ Response code -- this 4 bit field is set as part of LLMNR\r
+ responses. In an LLMNR query, the RCODE MUST be zero, and is\r
+ ignored by the responder. The response to a multicast LLMNR query\r
+ MUST have RCODE set to zero. A sender MUST silently discard an\r
+ LLMNR response with a non-zero RCODE sent in response to a\r
+ multicast query.\r
+\r
+\r
+ If an LLMNR responder is authoritative for the name in a multicast\r
+ query, but an error is encountered, the responder SHOULD send an\r
+ LLMNR response with an RCODE of zero, no RRs in the answer section,\r
+ and the TC bit set. This will cause the query to be resent using\r
+ TCP, and allow the inclusion of a non-zero RCODE in the response to\r
+ the TCP query. Responding with the TC bit set is preferrable to\r
+ not sending a response, since it enables errors to be diagnosed.\r
+\r
+\r
+ Since LLMNR responders only respond to LLMNR queries for names for\r
+ which they are authoritative, LLMNR responders MUST NOT respond\r
+ with an RCODE of 3; instead, they should not respond at all.\r
+\r
+\r
+ LLMNR implementations MUST support EDNS0 [RFC2671] and extended\r
+ RCODE values.\r
+\r
+\r
+QDCOUNT\r
+ An unsigned 16 bit integer specifying the number of entries in the\r
+ question section. A sender MUST place only one question into the\r
+ question section of an LLMNR query. LLMNR responders MUST silently\r
+ discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders\r
+ MUST silently discard LLMNR responses with QDCOUNT not equal to\r
+ one.\r
+\r
+\r
+ANCOUNT\r
+ An unsigned 16 bit integer specifying the number of resource\r
+ records in the answer section. LLMNR responders MUST silently\r
+ discard LLMNR queries with ANCOUNT not equal to zero.\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 7]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+NSCOUNT\r
+ An unsigned 16 bit integer specifying the number of name server\r
+ resource records in the authority records section. Authority\r
+ record section processing is described in Section 2.9.\r
+\r
+\r
+ARCOUNT\r
+ An unsigned 16 bit integer specifying the number of resource\r
+ records in the additional records section. Additional record\r
+ section processing is described in Section 2.9.\r
+\r
+\r
+2.2. Sender behavior\r
+\r
+\r
+A sender may send an LLMNR query for any legal resource record type\r
+(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.\r
+\r
+\r
+As described in Section 2.4, a sender may also send a unicast query.\r
+Sections 2 and 3 describe the circumstances in which LLMNR queries may\r
+be sent.\r
+\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
+\r
+Since the responder may order the RRs in the response so as to indicate\r
+preference, the sender SHOULD preserve ordering in the response to the\r
+querying application.\r
+\r
+\r
+2.3. Responder behavior\r
+\r
+\r
+An LLMNR response MUST be sent to the sender via unicast.\r
+\r
+\r
+Upon configuring an IP address responders typically will synthesize\r
+corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR\r
+queries for these RRs. An SOA RR is synthesized only when a responder\r
+has another RR as well; the SOA RR MUST NOT be the only RR that a\r
+responder has. However, in general whether RRs are manually or\r
+automatically created is an implementation decision.\r
+\r
+\r
+For example, a host configured to have computer name "host1" and to be a\r
+member of the "example.com" domain, and with IPv4 address 10.1.1.1 and\r
+IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the\r
+following records:\r
+\r
+\r
+host1. IN A 10.1.1.1\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 8]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6\r
+\r
+\r
+host1.example.com. IN A 10.1.1.1\r
+IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6\r
+\r
+\r
+1.1.1.10.in-addr.arpa. IN PTR host1.\r
+IN PTR host1.example.com.\r
+\r
+\r
+6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa\r
+IN PTR host1.\r
+IN PTR host1.example.com\r
+\r
+\r
+An LLMNR responder might be further manually configured with the name of\r
+a local mail server with an MX RR included in the "host1." and\r
+"host1.example.com." records.\r
+\r
+\r
+In responding to queries:\r
+\r
+\r
+[a] Responders MUST listen on UDP port TBD on the link-scope multicast\r
+ address(es) defined in Section 2, and on UDP and TCP port TBD on\r
+ the unicast address(es) that could be set as the source address(es)\r
+ when the responder responds to the LLMNR query.\r
+\r
+\r
+[b] Responders MUST direct responses to the port from which the query\r
+ was sent. When queries are received via TCP this is an inherent\r
+ part of the transport protocol. For queries received by UDP the\r
+ responder MUST take note of the source port and use that as the\r
+ destination port in the response. Responses SHOULD always be sent\r
+ from the port to which they were directed.\r
+\r
+\r
+[c] Responders MUST respond to LLMNR queries for names and addresses\r
+ they are authoritative for. This applies to both forward and\r
+ reverse lookups.\r
+\r
+\r
+[d] Responders MUST NOT respond to LLMNR queries for names they are not\r
+ authoritative for.\r
+\r
+\r
+[e] Responders MUST NOT respond using cached data.\r
+\r
+\r
+[f] If a DNS server is running on a host that supports LLMNR, the DNS\r
+ server MUST respond to LLMNR queries only for the RRSets relating\r
+ to the host on which the server is running, but MUST NOT respond\r
+ for other records for which the server is authoritative. DNS\r
+ servers also MUST NOT send LLMNR queries in order to resolve DNS\r
+ queries.\r
+\r
+\r
+[g] If a responder is authoritative for a name, it MAY respond with\r
+ RCODE=0 and an empty answer section, if the type of query does not\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 9]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+ match a RR that the responder has.\r
+\r
+\r
+As an example, a host configured to respond to LLMNR queries for the\r
+name "foo.example.com." is authoritative for the name\r
+"foo.example.com.". On receiving an LLMNR query for an A RR with the\r
+name "foo.example.com." the host authoritatively responds with A RR(s)\r
+that contain IP address(es) in the RDATA of the resource record. If the\r
+responder has a AAAA RR, but no A RR, and an A RR query is received, the\r
+responder would respond with RCODE=0 and an empty answer section.\r
+\r
+\r
+In conventional DNS terminology a DNS server authoritative for a zone is\r
+authoritative for all the domain names under the zone apex 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
+apex.\r
+\r
+\r
+For example the host "foo.example.com." is not authoritative for the\r
+name "child.foo.example.com." unless the host is configured with\r
+multiple names, including "foo.example.com." and\r
+"child.foo.example.com.". As a result, "foo.example.com." cannot reply\r
+to an LLMNR query for "child.foo.example.com." with RCODE=3\r
+(authoritative name error). 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
+"foo.example.com." and "child.foo.example.com.".\r
+\r
+\r
+In this example (unless this limitation is introduced) an LLMNR query\r
+for an A resource record for the name "child.foo.example.com." would\r
+result in two authoritative responses: RCODE=3 (authoritative name\r
+error) received from "foo.example.com.", and a requested A record - from\r
+"child.foo.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.foo.example.com." would send a dynamic update for the NS and glue\r
+A record to "foo.example.com.", but this approach significantly\r
+complicates implementation of LLMNR and would not be acceptable for\r
+lightweight hosts.\r
+\r
+\r
+2.4. Unicast queries and responses\r
+\r
+\r
+Unicast queries SHOULD be sent when:\r
+\r
+\r
+[a] A sender repeats a query after it received a response with the TC\r
+ bit set to the previous LLMNR multicast query, or\r
+\r
+\r
+[b] The sender queries for a PTR RR of a fully formed IP address within\r
+ the "in-addr.arpa" or "ip6.arpa" zones.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 10]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+A responder receiving a unicast query MUST send the response with a\r
+source address set to the destination address field of the IP header of\r
+the query causing the response.\r
+\r
+\r
+Unicast LLMNR queries MUST be sent using TCP. Senders MUST support\r
+sending TCP queries, and responders MUST support listening for TCP\r
+queries.\r
+\r
+\r
+Responses to TCP unicast LLMNR queries MUST be sent using TCP, using\r
+the same connection as the query. If the sender of a TCP query receives\r
+a response to that query not using TCP, the response MUST be silently\r
+discarded.\r
+\r
+\r
+Unicast UDP queries MUST be silently discarded.\r
+\r
+\r
+If TCP connection setup cannot be completed in order to send a unicast\r
+TCP query, this is treated as a response that no records of the\r
+specified type and class exist for the specified name (it is treated the\r
+same as a response with RCODE=0 and an empty answer section).\r
+\r
+\r
+2.5. "Off link" detection\r
+\r
+\r
+For IPv4, an "on link" address is defined as a link-local address\r
+[IPv4Link] or an address whose prefix belongs to a subnet on the local\r
+link. For IPv6 [RFC2460] an "on link" address is either a link-local\r
+address, defined in [RFC2373], or an address whose prefix belongs to a\r
+subnet on the local link.\r
+\r
+\r
+A sender MUST select a source address for LLMNR queries that is "on\r
+link". The destination address of an LLMNR query MUST be a link-scope\r
+multicast address or an "on link" unicast address.\r
+\r
+\r
+A responder MUST select a source address for responses that is "on\r
+link". The destination address of an LLMNR response MUST be an "on link"\r
+unicast address.\r
+\r
+\r
+On receiving an LLMNR query, the responder MUST check whether it was\r
+sent to a LLMNR multicast addresses defined in Section 2. If it was\r
+sent to another multicast address, then the query MUST be silently\r
+discarded.\r
+\r
+\r
+Section 2.4 discusses use of TCP for LLMNR queries and responses. In\r
+composing an LLMNR query using TCP, the sender MUST set the Hop Limit\r
+field in the IPv6 header and the TTL field in the IPv4 header of the\r
+response to one (1). The responder SHOULD set the TTL or Hop Limit\r
+settings on the TCP listen socket to one (1) so that SYN-ACK packets\r
+will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents\r
+an incoming connection from off-link since the sender will not receive a\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 11]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+SYN-ACK from the responder.\r
+\r
+\r
+For UDP queries and responses the Hop Limit field in the IPv6 header,\r
+and the TTL field in the IPV4 header MAY be set to any value. However,\r
+it is RECOMMENDED that the value 255 be used for compatibility with\r
+Apple Rendezvous.\r
+\r
+\r
+Implementation note:\r
+\r
+\r
+ In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL\r
+ socket options are used to set the TTL of outgoing unicast and\r
+ multicast packets. The IP_RECVTTL socket option is available on some\r
+ platforms to retrieve the IPv4 TTL of received packets with\r
+ recvmsg(). [RFC2292] specifies similar options for setting and\r
+ retrieving the IPv6 Hop Limit.\r
+\r
+\r
+2.6. Responder responsibilities\r
+\r
+\r
+It is the responsibility of the responder to ensure that RRs returned in\r
+LLMNR responses MUST only include values that are valid on the local\r
+interface, such as IPv4 or IPv6 addresses valid on the local link or\r
+names defended using the mechanism described in Section 4. In\r
+particular:\r
+\r
+\r
+[a] If a link-scope IPv6 address is returned in a AAAA RR, that address\r
+ MUST be valid on the local link over which LLMNR is used.\r
+\r
+\r
+[b] If an IPv4 address is returned, it MUST be reachable through the\r
+ link over which LLMNR is used.\r
+\r
+\r
+[c] If a name is returned (for example in a CNAME, MX or SRV RR), the\r
+ name MUST be resolvable on the local link over which LLMNR is used.\r
+\r
+\r
+Routable addresses MUST be included first in the response, if available.\r
+This encourages use of routable address(es) for establishment of new\r
+connections.\r
+\r
+\r
+2.7. Retransmission and jitter\r
+\r
+\r
+An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine\r
+when to retransmit an LLMNR query and how long to collect responses to\r
+an LLMNR query.\r
+\r
+\r
+If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,\r
+then a sender MAY repeat the transmission of the query in order to\r
+assure that it was received by a host capable of responding to it.\r
+Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.\r
+Where LLMNR queries are sent using TCP, retransmission is handled by the\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 12]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+transport layer.\r
+\r
+\r
+Because an LLMNR sender cannot know in advance if a query sent using\r
+multicast will receive no response, one response, or more than one\r
+response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect\r
+all possible responses, rather than considering the multicast query\r
+answered after the first response is received. A unicast query sender\r
+considers the query answered after the first response is received, so\r
+that it only waits for LLMNR_TIMEOUT if no response has been received.\r
+\r
+\r
+An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT\r
+for each transmission. It is suggested that the computation of\r
+LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries\r
+sent on the same interface.\r
+\r
+\r
+For example, the algorithms described in RFC 2988 [RFC2988] (including\r
+exponential backoff) compute an RTO, which is used as the value of\r
+LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO\r
+(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO\r
+(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum\r
+RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).\r
+\r
+\r
+Recommended values are an initial RTO of 1 second, a minimum RTO of\r
+200ms, and a maximum RTO of 5 seconds. In order to avoid\r
+synchronization, the transmission of each LLMNR query and response\r
+SHOULD delayed by a time randomly selected from the interval 0 to 100\r
+ms. This delay MAY be avoided by responders responding with RRs which\r
+they have previously determined to be UNIQUE (see Section 4 for\r
+details).\r
+\r
+\r
+2.8. DNS TTL\r
+\r
+\r
+The responder should use a pre-configured TTL value in the records\r
+returned an LLMNR response. A default value of 30 seconds is\r
+RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc\r
+networks), the TTL value may need to be reduced.\r
+\r
+\r
+Due to the TTL minimalization necessary when caching an RRset, all TTLs\r
+in an RRset MUST be set to the same value.\r
+\r
+\r
+2.9. Use of the authority and additional sections\r
+\r
+\r
+Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a\r
+concept of delegation. In LLMNR, the NS resource record type may be\r
+stored and queried for like any other type, but it has no special\r
+delegation semantics as it does in the DNS. Responders MAY have NS\r
+records associated with the names for which they are authoritative, but\r
+they SHOULD NOT include these NS records in the authority sections of\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 13]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+responses.\r
+\r
+\r
+Responders SHOULD insert an SOA record into the authority section of a\r
+negative response, to facilitate negative caching as specified in\r
+[RFC2308]. The owner name of this SOA record MUST be equal to the query\r
+name.\r
+\r
+\r
+Responders SHOULD NOT perform DNS additional section processing, except\r
+as required for EDNS0 and DNSSEC.\r
+\r
+\r
+Senders MUST NOT cache RRs from the authority or additional section of a\r
+response as answers, though they may be used for other purposes such as\r
+negative caching.\r
+\r
+\r
+3. Usage model\r
+\r
+\r
+Since LLMNR is a secondary name resolution mechanism, its usage is in\r
+part determined by the behavior of DNS implementations. This document\r
+does not specify any changes to DNS resolver behavior, such as\r
+searchlist processing or retransmission/failover policy. However,\r
+robust DNS resolver implementations are more likely to avoid unnecessary\r
+LLMNR queries.\r
+\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 negative responses due to missing inverse mappings or NS records that\r
+point to nonexistent or inappropriate hosts. This has the potential to\r
+result in a large number of unnecessary LLMNR queries.\r
+\r
+\r
+[RFC1536] describes common DNS implementation errors and fixes. If the\r
+proposed fixes are implemented, unnecessary LLMNR queries will be\r
+reduced substantially, and so implementation of [RFC1536] is\r
+recommended.\r
+\r
+\r
+For example, [RFC1536] Section 1 describes issues with retransmission\r
+and recommends implementation of a retransmission policy based on round\r
+trip estimates, with exponential backoff. [RFC1536] Section 4 describes\r
+issues with failover, and recommends that resolvers try another server\r
+when they don't receive a response to a query. These policies are\r
+likely to avoid unnecessary LLMNR queries.\r
+\r
+\r
+[RFC1536] Section 3 describes zero answer bugs, which if addressed will\r
+also reduce unnecessary LLMNR queries.\r
+\r
+\r
+[RFC1536] Section 6 describes name error bugs and recommended searchlist\r
+processing that will reduce unnecessary RCODE=3 (authoritative name)\r
+errors, thereby also reducing unnecessary LLMNR queries.\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 14]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+3.1. LLMNR configuration\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.\r
+\r
+\r
+In these situations, a dual stack host will send AAAA queries to the\r
+configured DNS server over IPv4. However, an IPv6-only host\r
+unconfigured with a DNS server suitable for use over IPv6 will be unable\r
+to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms\r
+(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not\r
+all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration\r
+may be a common problem in the short term, and LLMNR may prove useful in\r
+enabling linklocal name resolution over IPv6.\r
+\r
+\r
+Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],\r
+IPv6-only hosts may not be configured with a DNS server. Where there is\r
+no DNS server authoritative for the name of a host or the authoritative\r
+DNS server does not support dynamic client update over IPv6 or\r
+DHCPv6-based dynamic update, then an IPv6-only host will not be able to\r
+do DNS dynamic update, and other hosts will not be able to resolve its\r
+name.\r
+\r
+\r
+For example, if the configured DNS server responds to AAAA RR queries\r
+sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then\r
+it will not be possible to resolve the names of IPv6-only hosts. In\r
+this situation, LLMNR over IPv6 can be used for local name resolution.\r
+\r
+\r
+Similarly, if a DHCPv4 server is available providing DNS server\r
+configuration, and DNS server(s) exist which are authoritative for the A\r
+RRs of local hosts and support either dynamic client update over IPv4 or\r
+DHCPv4-based dynamic update, then the names of local IPv4 hosts can be\r
+resolved over IPv4 without LLMNR. However, if no DNS server is\r
+authoritative for the names of local hosts, or the authoritative DNS\r
+server(s) do not support dynamic update, then LLMNR enables linklocal\r
+name resolution over IPv4.\r
+\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 (NSSO) for DHCP [RFC2937], using\r
+the LLMNR Enable Option code carried in the NSSO data.\r
+\r
+\r
+It is possible that DNS configuration mechanisms will go in and out of\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 15]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+service. In these circumstances, it is possible for hosts within an\r
+administrative domain to be inconsistent in their DNS configuration.\r
+\r
+\r
+For example, where DHCP is used for configuring DNS servers, one or more\r
+DHCP servers can fail. 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
+\r
+Unless unconfigured hosts periodically retry configuration, an outage in\r
+the DNS configuration mechanism will result in hosts continuing to use\r
+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
+For example, where DHCP is used for DNS configuration, [RFC2131]\r
+recommends a maximum retry interval of 64 seconds. In the absence of\r
+other guidance, a default retry interval of one (1) minute is\r
+RECOMMENDED.\r
+\r
+\r
+4. Conflict resolution\r
+\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; the sender\r
+perceives no inherent conflict in the receipt of multiple responses.\r
+\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
+\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 name.\r
+\r
+\r
+Every responder that responds to an LLMNR query AND includes a UNIQUE\r
+record in the response:\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 16]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\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 for the\r
+ same name, type and class.\r
+\r
+\r
+[2] MUST NOT include a UNIQUE resource record in the response without\r
+ having verified its uniqueness.\r
+\r
+\r
+Where a host is configured to issue 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 configuration,\r
+the host MUST verify resource record uniqueness on that interface. To\r
+accomplish this, the host MUST send an LLMNR query for each UNIQUE\r
+resource record.\r
+\r
+\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
+\r
+ - starts up or is rebooted\r
+ - wakes from sleep (if the network interface was inactive during sleep)\r
+ - is configured to respond to the LLMNR queries on an interface\r
+ enabled for transmission and reception of IP traffic\r
+ - is configured to respond to the LLMNR queries using additional\r
+ UNIQUE resource records\r
+ - detects that an interface is connected and is usable\r
+ (e.g. an IEEE 802 hardware link-state change indicating\r
+ that a cable was attached or completion of authentication\r
+ (and if needed, association) with a wireless base station\r
+ or adhoc network\r
+\r
+\r
+When a host that has 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 an interface different from\r
+the one on which the query was sent. If the response arrives on a\r
+different interface, 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
+\r
+The name conflict detection mechanism doesn't prevent name conflicts\r
+when previously partitioned segments are connected by a bridge. In order\r
+to minimize the chance of conflicts in such a situation, it is\r
+recommended that steps be taken to ensure name uniqueness. For example,\r
+the name could be chosen randomly from a large pool of potential names,\r
+or the name could be assigned via a process designed to guarantee\r
+uniqueness.\r
+\r
+\r
+When name conflicts are detected, they SHOULD be logged. To detect\r
+duplicate use of a name, an administrator can use a name resolution\r
+utility which employs LLMNR and lists both responses and responders.\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 17]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+This would allow an administrator to diagnose behavior and potentially\r
+to intervene and reconfigure LLMNR responders who should not be\r
+configured to respond to the same name.\r
+\r
+\r
+4.1. Considerations for Multiple Interfaces\r
+\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
+\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
+ | | | |\r
+ [A] [myhost] [myhost]\r
+\r
+\r
+ Figure 1. Link-scope name conflict\r
+\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
+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
+ | | | |\r
+ [A] [myhost] [A]\r
+\r
+\r
+\r
+ Figure 2. Off-segment name conflict\r
+\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
+\r
+Host myhost cannot distinguish between the situation shown in Figure 2,\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 18]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+and that shown in Figure 3 where no conflict exists.\r
+\r
+\r
+ [A]\r
+ | |\r
+ ----- -----\r
+ | |\r
+ [myhost]\r
+\r
+\r
+ Figure 3. Multiple paths to same host\r
+\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
+\r
+4.2. API issues\r
+\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
+addresses) and IPv6 addresses.\r
+\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
+\r
+5. Security Considerations\r
+\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. While tools exist\r
+to alllow an attacker to spoof a response to a DNS query, spoofing a\r
+response to an LLMNR query is easier since the query is sent to a link-\r
+scope multicast address, where every host on the logical link will be\r
+made aware of it.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 19]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+In order to address the security vulnerabilities, the following\r
+mechanisms are contemplated:\r
+\r
+\r
+[1] Scope restrictions.\r
+\r
+\r
+[2] Usage restrictions.\r
+\r
+\r
+[3] Cache and port separation.\r
+\r
+\r
+[4] Authentication.\r
+\r
+\r
+These techniques are described in the following sections.\r
+\r
+\r
+5.1. Scope restriction\r
+\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
+\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 UDP 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 TCP queries and responses.\r
+\r
+\r
+Using a TTL of one (1) to set up a TCP connection in order to send a\r
+unicast LLMNR query reduces the likelihood of both denial of service\r
+attacks and spoofed responses. Checking that an LLMNR query is sent to\r
+a link-scope multicast address should prevent spoofing of multicast\r
+queries by off-link attackers.\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 or AAAA query for a popular Internet host), and by using a TTL\r
+or Hop Limit field larger than one (1), for the forged response to reach\r
+the LLMNR sender.\r
+\r
+\r
+When LLMNR queries are sent to a link-scope multicast address, it is\r
+possible that some routers may not properly implement link-scope\r
+multicast, or that link-scope multicast addresses may leak into the\r
+multicast routing system.\r
+\r
+\r
+Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one\r
+in an LLMNR UDP response may enable denial of service attacks across the\r
+Internet. However, since LLMNR responders only respond to queries for\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 20]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+which they are authoritative, and LLMNR does not provide wildcard query\r
+support, it is believed that this threat is minimal.\r
+\r
+\r
+There also are scenarios such as public "hotspots" where attackers can\r
+be present on the same link. These threats are most serious in wireless\r
+networks such as 802.11, since attackers on a wired network will require\r
+physical access to the home network, while wireless attackers may reside\r
+outside the home. Link-layer security can be of assistance against\r
+these threats if it is available.\r
+\r
+\r
+5.2. Usage restriction\r
+\r
+\r
+As noted in Sections 2 and 3, LLMNR is intended for usage in a limited\r
+set of scenarios.\r
+\r
+\r
+If an LLMNR query is sent whenever a DNS server does not respond in a\r
+timely way, then an attacker can poison the LLMNR cache by responding to\r
+the query with incorrect information. To some extent, these\r
+vulnerabilities exist today, since DNS response spoofing tools are\r
+available that can allow an attacker to respond to a query more quickly\r
+than a distant DNS server.\r
+\r
+\r
+Since LLMNR queries are sent and responded to on the local-link, an\r
+attacker will need to respond more quickly to provide its own response\r
+prior to arrival of the response from a legitimate responder. If an\r
+LLMNR query is sent for an off-link host, spoofing a response in a\r
+timely way is not difficult, since a legitimate response will never be\r
+received.\r
+\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 only\r
+used as a name resolution mechanism of last resort.\r
+\r
+\r
+5.3. Cache and port separation\r
+\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
+\r
+LLMNR operates on a separate port from DNS, reducing the likelihood that\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 21]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+a DNS server will unintentionally respond to an LLMNR query.\r
+\r
+\r
+5.4. Authentication\r
+\r
+\r
+LLMNR implementations may not support DNSSEC or TSIG, and as a result,\r
+responses to LLMNR queries may be unauthenticated. If authentication is\r
+desired, and a pre-arranged security configuration is possible, then\r
+IPsec ESP with a null-transform MAY be used to authenticate LLMNR\r
+responses. In a small network without a certificate authority, this can\r
+be most easily accomplished through configuration of a group pre-shared\r
+key for trusted hosts.\r
+\r
+\r
+6. IANA Considerations\r
+\r
+\r
+This specification creates one new name space: the reserved bits in the\r
+LLMNR header. These are allocated by IETF Consensus, in accordance with\r
+BCP 26 [RFC2434].\r
+\r
+\r
+LLMNR requires allocation of a port TBD for both TCP and UDP.\r
+Assignment of the same port for both transports is requested.\r
+\r
+\r
+LLMNR requires allocation of a link-scope multicast IPv4 address TBD.\r
+LLMNR also requires allocation of a link-scope multicast IPv6 address\r
+TBD.\r
+\r
+\r
+7. References\r
+\r
+\r
+7.1. Normative References\r
+\r
+\r
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and\r
+ Specification", RFC 1035, November 1987.\r
+\r
+\r
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,\r
+ April 1992.\r
+\r
+\r
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+\r
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS\r
+ Specification", RFC 2181, July 1997.\r
+\r
+\r
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",\r
+ RFC 2308, March 1998.\r
+\r
+\r
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC\r
+ 2365, July 1998.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 22]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing\r
+ Architecture", RFC 2373, July 1998.\r
+\r
+\r
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA\r
+ Considerations Section in RFCs", BCP 26, RFC 2434, October\r
+ 1998.\r
+\r
+\r
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6\r
+ (IPv6) Specification", RFC 2460, December 1998.\r
+\r
+\r
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC\r
+ 2535, March 1999.\r
+\r
+\r
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,\r
+ August 1999.\r
+\r
+\r
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission\r
+ Timer", RFC 2988, November 2000.\r
+\r
+\r
+7.2. Informative References\r
+\r
+\r
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested\r
+ Fixes", RFC 1536, October 1993.\r
+\r
+\r
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,\r
+ March 1997.\r
+\r
+\r
+[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic\r
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,\r
+ April 1997.\r
+\r
+\r
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",\r
+ RFC 2292, February 1998.\r
+\r
+\r
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic\r
+ Socket Interface Extensions for IPv6", RFC 2553, March 1999.\r
+\r
+\r
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC\r
+ 2937, September 2000.\r
+\r
+\r
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for\r
+ IPv6 (DHCPv6)", RFC 3315, July 2003.\r
+\r
+\r
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of\r
+ Caching", IEEE/ACM Transactions on Networking, Volume 10,\r
+ Number 5, pp. 589, October 2002.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 23]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local\r
+ unicast addresses to communicate with recursive DNS servers",\r
+ Internet draft (work in progress), draft-ietf-ipv6-dns-\r
+ discovery-07.txt, October 2002.\r
+\r
+\r
+[IPV4Link]\r
+ Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration\r
+ of IPv4 Link-Local Addresses", Internet draft (work in\r
+ progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April\r
+ 2004.\r
+\r
+\r
+[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --\r
+ Portable Operating System Interface (POSIX). Open Group\r
+ Technical Standard: Base Specifications, Issue 6, December\r
+ 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin\r
+\r
+\r
+[LLMNREnable]\r
+ Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work\r
+ in progress), draft-guttman-mdns-enable-02.txt, April 2002.\r
+\r
+\r
+[NodeInfo]\r
+ Crawford, M., "IPv6 Node Information Queries", Internet draft\r
+ (work in progress), draft-ietf-ipn-gwg-icmp-name-\r
+ lookups-09.txt, May 2002.\r
+\r
+\r
+Acknowledgments\r
+\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
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 24]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+Authors' Addresses\r
+\r
+\r
+Levon Esibov\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+\r
+EMail: levone@microsoft.com\r
+\r
+\r
+Bernard Aboba\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+\r
+Phone: +1 425 706 6605\r
+EMail: bernarda@microsoft.com\r
+\r
+\r
+Dave Thaler\r
+Microsoft Corporation\r
+One Microsoft Way\r
+Redmond, WA 98052\r
+\r
+\r
+Phone: +1 425 703 8835\r
+EMail: dthaler@microsoft.com\r
+\r
+\r
+Intellectual Property Statement\r
+\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
+\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
+\r
+\r
+\r
+\r
+\r
+Esibov, Aboba & Thaler Standards Track [Page 25]\r
+\r
+\r
+\r
+\r
+\r
+\r
+INTERNET-DRAFT LLMNR 17 March 2004\r
+\r
+\r
+\r
+Full Copyright Statement\r
+\r
+\r
+Copyright (C) The Internet Society (2004). 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
+Open Issues\r
+\r
+\r
+Open issues with this specification are tracked on the following web\r
+site:\r
+\r
+\r
+http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html\r
+\r
+\r
+Expiration Date\r
+\r
+\r
+This memo is filed as <draft-ietf-dnsext-mdns-30.txt>, and expires\r
+October 4, 2004.\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 26]
\ No newline at end of file
projects / thirdparty / bind9.git / commitdiff
