draft-ietf-dnsext-mdns-21.txt   draft-ietf-dnsext-mdns-22.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-21.txt> Microsoft <draft-ietf-dnsext-mdns-22.txt> Microsoft
9 June 2003 23 July 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4 2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 4 2.1 Sender behavior ................................. 4
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 7 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 9 2.7 DNS TTL ......................................... 9
2.8 Use of the authority and additional sections .... 9
3. Usage model ........................................... 9 3. Usage model ........................................... 9
3.1 Unqualified names ............................... 10 3.1 Unqualified names ............................... 10
3.2 LLMNR configuration ............................. 10 3.2 LLMNR configuration ............................. 10
4. Conflict resolution ................................... 12 4. Conflict resolution ................................... 12
4.1 Considerations for multiple interfaces .......... 13 4.1 Considerations for multiple interfaces .......... 13
4.2 API issues ...................................... 14 4.2 API issues ...................................... 15
5. Security considerations ............................... 15 5. Security considerations ............................... 15
5.1 Scope restriction ............................... 15 5.1 Scope restriction ............................... 16
5.2 Usage restriction ............................... 16 5.2 Usage restriction ............................... 16
5.3 Cache and port separation ....................... 17 5.3 Cache and port separation ....................... 17
5.4 Authentication .................................. 17 5.4 Authentication .................................. 17
6. IANA considerations ................................... 17 6. IANA considerations ................................... 17
7. Normative References .................................. 17 7. Normative References .................................. 18
8. Informative References ................................ 18 8. Informative References ................................ 18
Acknowledgments .............................................. 19 Acknowledgments .............................................. 19
Authors' Addresses ........................................... 19 Authors' Addresses ........................................... 19
Intellectual Property Statement .............................. 20 Intellectual Property Statement .............................. 20
Full Copyright Statement ..................................... 20 Full Copyright Statement ..................................... 20
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from the Domain Name System (DNS), which operates on a separate port from the Domain Name System (DNS),
skipping to change at page 6, line 40 skipping to change at page 6, line 40
resolved". LLMNR responders may respond only to queries which they can resolved". LLMNR responders may respond only to queries which they can
resolve positively. resolve positively.
2.3. Unicast queries and responses 2.3. Unicast queries and responses
Unicast queries SHOULD be sent when: Unicast queries SHOULD be sent when:
a. A sender repeats a query after it received a response a. A sender repeats a query after it received a response
with the TC bit set to the previous LLMNR multicast query, or with the TC bit set to the previous LLMNR multicast query, or
b. The sender's LLMNR cache contains an NS resource record that b. The sender queries for a PTR RR.
enables the sender to send a query directly to the hosts
authoritative for the name in the query, or
c. The sender queries for a PTR RR.
If a TC (truncation) bit is set in the response, then the sender MAY use If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP using the unicast discard the response and resend the query over TCP using the unicast
address of the responder. The RA (Recursion Available) bit in the address of the responder. The RA (Recursion Available) bit in the
header of the response MUST NOT be set. If the RA bit is set in the header of the response MUST NOT be set. If the RA bit is set in the
response header, the sender MUST ignore the RA bit. response header, the sender MUST ignore the RA bit.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection unicast LLMNR queries MUST be sent using TCP, using the same connection
skipping to change at page 9, line 4 skipping to change at page 8, line 49
possible responses, rather than considering the multicast query answered possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received. waits for LLMNR_TIMEOUT if no response has been received.
LLMNR implementations SHOULD dynamically estimate the timeout value LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface (LLMNR_TIMEOUT) based on the last response received, on a per-interface
basis. The algorithms described in [RFC2988] are suggested, with a basis. The algorithms described in [RFC2988] are suggested, with a
minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD
NOT be attempted more than 3 times. Where LLMNR queries are sent using NOT be attempted more than 3 times. Where LLMNR queries are sent using
TCP, retransmission is handled by the transport layer. TCP, retransmission is handled by the transport layer.
2.7. DNS TTL 2.7. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the same value.
responder includes the same records as a DNS server would insert in the
response to the unicast DNS query. 2.8. 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 of this SOA record MUST be equal to the
query name.
Responders SHOULD NOT perform DNS additional section processing.
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 3. Usage model
LLMNR is a peer-to-peer name resolution protocol that is not intended as LLMNR is a peer-to-peer name resolution protocol that is not intended as
a replacement for DNS. By default, LLMNR requests SHOULD be sent only a replacement for DNS. By default, LLMNR requests SHOULD be sent only
when no manual or automatic DNS configuration has been performed, when when no manual or automatic DNS configuration has been performed, when
DNS servers do not respond, or when they respond to a query with RCODE=3 DNS servers do not respond, or when they respond to a query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty answer section. (Authoritative Name Error) or RCODE=0, and an empty answer section.
As noted in [DNSPerf], even when DNS servers are configured, a As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or result significant fraction of DNS queries do not receive a response, or result
in a negative responses due to missing inverse mappings or NS records in negative responses due to missing inverse mappings or NS records that
that point to nonexistent or inappropriate hosts. Given this, support point to nonexistent or inappropriate hosts. Given this, support for
for LLMNR as a secondary name resolution mechanism has the potential to LLMNR as a secondary name resolution mechanism has the potential to
result in a large number of inappropriate queries without the following result in a large number of inappropriate queries without the following
additional restrictions: additional restrictions:
[1] If a DNS query does not receive a response, prior to falling [1] If a DNS query does not receive a response, prior to falling
back to LLMNR, the query SHOULD be retransmitted at least back to LLMNR, the query SHOULD be retransmitted at least
once. once.
[2] Where a DNS server is configured, by default a sender [2] Where a DNS server is configured, by default a sender
SHOULD send LLMNR queries only for names that are either SHOULD send LLMNR queries only for names that are either
unqualified or exist within the default domain. Where no unqualified or exist within the default domain. Where no
skipping to change at page 21, line 14 skipping to change at page 21, line 27
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-21.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-22.txt>, and expires
December 22, 2003. January 22, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/