draft-ietf-dnsext-mdns-28.txt   draft-ietf-dnsext-mdns-29.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-28.txt> Microsoft <draft-ietf-dnsext-mdns-29.txt> Microsoft
1 January 2004 20 January 2004
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 13 skipping to change at page 2, line 13
DNS. DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
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 LLMNR packet format ............................. 5 2.1 LLMNR packet format ............................. 5
2.2 Sender behavior ................................. 8 2.2 Sender behavior ................................. 8
2.3 Responder behavior .............................. 9 2.3 Responder behavior .............................. 8
2.4 Unicast queries ................................. 10 2.4 Unicast queries ................................. 10
2.5 Off-link detection .............................. 11 2.5 Off-link detection .............................. 11
2.6 Responder responsibilities ...................... 12 2.6 Responder responsibilities ...................... 12
2.7 Retransmission and jitter ....................... 13 2.7 Retransmission and jitter ....................... 13
2.8 DNS TTL ......................................... 14 2.8 DNS TTL ......................................... 14
2.9 Use of the authority and additional sections .... 14 2.9 Use of the authority and additional sections .... 14
3. Usage model ........................................... 14 3. Usage model ........................................... 14
3.1 LLMNR configuration ............................. 15 3.1 LLMNR configuration ............................. 15
4. Conflict resolution ................................... 16 4. Conflict resolution ................................... 16
4.1 Considerations for multiple interfaces .......... 18 4.1 Considerations for multiple interfaces .......... 18
skipping to change at page 4, line 20 skipping to change at page 4, line 20
[RFC1035]. Other terminology used in this document includes: [RFC1035]. Other terminology used in this document includes:
Positively Resolved Positively Resolved
Responses with RCODE set to zero are referred to in this document Responses with RCODE set to zero are referred to in this document
as "positively resolved". as "positively resolved".
Routable Address Routable Address
An address other than a Link-Local address. This includes globally An address other than a Link-Local address. This includes globally
routable addresses, as well as private addresses. 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 Responder
A host that listens to LLMNR queries, and responds to those for A host that listens to LLMNR queries, and responds to those for
which it is authoritative. which it is authoritative.
Sender Sender
A host that sends an LLMNR query. A host that sends an LLMNR query.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
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
skipping to change at page 4, line 47 skipping to change at page 4, line 51
Typically a host is configured as both an LLMNR sender and a responder. 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 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 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 uniqueness of names as described in Section 4. This document does not
specify how names are chosen or configured. This may occur via any specify how names are chosen or configured. This may occur via any
mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
LLMNR usage MAY be configured manually or automatically on a per LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on all interface basis. By default, LLMNR responders SHOULD be enabled on all
interfaces, at all times. Enabling LLMNR for use in situations where a interfaces, at all times. Enabling LLMNR for use in situations where a
DNS server has been configured will result in upgraded hosts changing DNS server has been configured will result in a change in default
their default behavior without a simultaneous update to configuration behavior without a simultaneous update to configuration information.
information. Where this is considered undesirable, LLMNR SHOULD NOT be
enabled by default, so that hosts will neither listen on the link-scope Where this is considered undesirable, LLMNR SHOULD NOT be enabled by
multicast address, nor will they send queries to that address. 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, 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 LLMNR requests SHOULD be sent only when one of the following conditions
are met: are met:
[1] No manual or automatic DNS configuration has been performed. If an [1] No manual or automatic DNS configuration has been performed. If an
interface has been configured with DNS server address(es), then interface has been configured with DNS server address(es), then
LLMNR SHOULD NOT be used as the primary name resolution mechanism LLMNR SHOULD NOT be used as the primary name resolution mechanism
on that interface, although it MAY be used as a name resolution on that interface, although it MAY be used as a name resolution
mechanism of last resort. mechanism of last resort.
skipping to change at page 5, line 43 skipping to change at page 5, line 47
queries are responded to as indicated in Section 2.4. queries are responded to as indicated in Section 2.4.
[d] Upon reception of the response, the sender processes it. [d] Upon reception of the response, the sender processes it.
Further details of sender and responder behavior are provided in the Further details of sender and responder behavior are provided in the
sections that follow. sections that follow.
2.1. LLMNR packet format 2.1. LLMNR packet format
LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
both queries and responses. Although [RFC1035] restricts DNS queries both queries and responses. LLMNR implementations SHOULD send UDP
and responses to 512 octets in length, since LLMNR operates only on the queries and responses only as large as are known to be permissible
local link, this restriction is not applicable. LLMNR implementations without causing fragmentation. When in doubt a maximum packet size of
MUST accept queries and responses as large as permitted by the link MTU. 512 octets SHOULD be used. LLMNR implementations MUST accept UDP
queries and responses as large as permitted by the link MTU.
2.1.1. LLMNR header format 2.1.1. LLMNR header format
LLMNR queries and responses utilize the DNS header format defined in LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] and [RFC2535], as illustrated below: [RFC1035] with exceptions noted below:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | | QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | | ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | | NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where: where:
ID A 16 bit identifier assigned by the program that generates any kind 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 of query. This identifier is copied from the query to the response
and can be used by the sender to match responses to outstanding and can be used by the sender to match responses to outstanding
queries. 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 QR A one bit field that specifies whether this message is an LLMNR
query (0), or an LLMNR response (1). query (0), or an LLMNR response (1).
OPCODE OPCODE
A four bit field that specifies kind of query in this message. 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 This value is set by the originator of a query and copied into the
response. LLMNR senders and responders MUST support standard response. This specification defines the behavior of standard
queries (opcode value of zero). LLMNR queries MUST NOT be sent queries and responses (opcode value of zero). Future
with other OPCODE values, and if sent, MUST be ignored by specifications may define the use of other opcodes with LLMNR.
responders. LLMNR senders and responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values MUST
AA Authoritative Answer. This bit is valid in LLMNR responses, and be silently discarded by responders.
specifies that the responder is an authority for the domain name in
the question section. Since responders only respond to LLMNR
queries for names and addresses they are authoritative for, the AA
bit MUST be set in LLMNR responses. If a sender receives a
response with the header containing the AA bit not set, the sender
MUST act as though the AA bit was set. The AA bit MUST NOT be set
in LLMNR queries, and MUST be ignored by LLMNR responders.
TC TrunCation - specifies that this message was truncated due to TC TrunCation - specifies that this message was truncated due to
length greater than that permitted on the transmission channel. 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 The TC bit MUST NOT be set in an LLMNR query and if set is ignored
by a responder. If the TC bit is set an LLMNR response, then the by an LLMNR responder. If the TC bit is set an LLMNR response,
sender MAY use the response if it contains all necessary then the sender MAY use the response if it contains all necessary
information, or the sender MAY discard the response and resend the information, or the sender MAY discard the response and resend the
query over TCP using the unicast address of the responder as the LLMNR query over TCP using the unicast address of the responder as
destination address. See [RFC2181] and Section 2.4 of this the destination address. See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit. specification for further discussion of the TC bit.
RD Recursion Desired. The RD bit MUST NOT be set in an LLMNR query or Z Reserved for future use. Implementations of this specification
response. If a responder receives an LLMNR query with the header MUST set these bits to zero in both queries and responses. If
containing the RD bit set, the responder MUST act as though the RD these bits are set in a LLMNR query or response, implementations of
bit was not set. LLMNR senders MUST ignore the RD bit in LLMNR this specification MUST ignore them. Since reserved bits could
responses. conceivably be used for different purposes than in DNS,
implementors are advised not to enable processing of these bits in
RA Recursion Available. The RA bit MUST NOT be set in an LLMNR query an LLMNR implementation starting from a DNS code base.
or response. If the RA bit is set in an LLMNR response, it MUST be
treated by the sender as though it was not set. LLMNR responders
MUST ignore the RA bit in LLMNR queries.
Z Reserved for future use. MUST be zero in all LLMNR queries and
responses. If these bits are set in an LLMNR query or response,
they MUST be ignored.
AD Authentic Data. The AD bit, defined in [RFC3655], MUST NOT be set
in an LLMNR query or response. If the AD bit is set in an LLMNR
query, it MUST be ignored by the responder. If the AD bit is set
in an LLMNR response, LLMNR senders MUST act as though the AD bit
were not set.
CD Checking Disabled. The CD bit, defined in [RFC2535], MUST NOT be
set in an LLMNR query or response. If the CD bit is set in an
LLMNR query, it MUST be ignored by the responder. LLMNR senders
MUST ignore the CD bit in LLMNR responses.
RCODE RCODE
Response code -- this 4 bit field is set as part of LLMNR Response code -- this 4 bit field is set as part of LLMNR
responses. In an LLMNR query, the RCODE MUST be zero, and is responses. In an LLMNR query, the RCODE MUST be zero, and is
ignored by the responder. The RCODE MUST be zero in an LLMNR ignored by the responder. The response to a multicast LLMNR query
response. Instead of sending a response with a non-zero RCODE, a MUST have RCODE set to zero. A sender MUST silently discard an
LLMNR responder MUST NOT respond to a query. A sender receiving an LLMNR response with a non-zero RCODE sent in response to a
LLMNR response with a non-zero RCODE value MUST silently discard multicast query.
the response.
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 QDCOUNT
An unsigned 16 bit integer specifying the number of entries in the 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. A sender MUST place only one question into the
question section of an LLMNR query. LLMNR responders MUST ignore question section of an LLMNR query. LLMNR responders MUST silently
questions after the first question. discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
MUST silently discard LLMNR responses with QDCOUNT not equal to
one.
ANCOUNT ANCOUNT
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the answer section. records in the answer section. LLMNR responders MUST silently
discard LLMNR queries with ANCOUNT not equal to zero.
NSCOUNT NSCOUNT
An unsigned 16 bit integer specifying the number of name server An unsigned 16 bit integer specifying the number of name server
resource records in the authority records section. Authority resource records in the authority records section. Authority
record section processing is described in Section 2.9. record section processing is described in Section 2.9.
ARCOUNT ARCOUNT
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the additional records section. Additional record records in the additional records section. Additional record
section processing is described in Section 2.9. section processing is described in Section 2.9.
2.2. Sender behavior 2.2. Sender behavior
An LLMNR query is composed in exactly the same manner and with the same A sender may send an LLMNR query for any legal resource record type
packet format as a DNS query. A sender may send an LLMNR query for any (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
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. 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 Sections 2 and 3 describe the circumstances in which LLMNR queries may
be sent. be sent.
The sender MUST anticipate receiving no replies to some LLMNR queries, 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 that no responders are available within the link-scope or
in the event no positive non-null responses exist for the transmitted 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 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 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 specified name (it is treated the same as a response with RCODE=0 and an
empty answer section). empty answer section).
Since the responder may order the RRs in the response so as to indicate 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 preference, the sender SHOULD preserve ordering in the response to the
querying application. querying application.
2.3. Responder behavior 2.3. Responder behavior
A response to an LLMNR query is composed in exactly the same manner and An LLMNR response MUST be sent to the sender via unicast.
with the same packet format as a response to a DNS query. The response
MUST be sent to the sender via unicast.
Upon configuring an IP address responders typically will synthesize Upon configuring an IP address responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR 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 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 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 responder has. However, in general whether RRs are manually or
automatically created is an implementation decision. 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
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: In responding to queries:
[a] Responders MUST listen on UDP port TBD on the link-scope multicast [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 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) the unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query. when the responder responds to the LLMNR query.
[b] Responders MUST direct responses to the port from which the 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 was sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the part of the transport protocol. For queries received by UDP the
responder MUST take note of the source port and use that as the responder MUST take note of the source port and use that as the
destination port in the response. Responses SHOULD always be sent destination port in the response. Responses SHOULD always be sent
from the port to which they were directed. from the port to which they were directed.
[c] Responders MUST NOT respond using cached data. The AA bit MUST be [c] Responders MUST respond to LLMNR queries for names and addresses
set in LLMNR responses. 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 [d] Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for. authoritative for.
[e] Responders MUST respond to LLMNR queries for names and addresses [e] Responders MUST NOT respond using cached data.
they are authoritative for. This applies to both forward and
reverse lookups.
[f] If a DNS server is running on a host that supports LLMNR, the DNS [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 server MUST respond to LLMNR queries only for the RRSets relating
to the host on which the server is running, but MUST NOT respond to the host on which the server is running, but MUST NOT respond
for other records for which the server is authoritative. DNS for other records for which the server is authoritative. DNS
servers also MUST NOT send LLMNR queries in order to resolve DNS servers also MUST NOT send LLMNR queries in order to resolve DNS
queries. queries.
[g] If a responder is authoritative for a name, it MAY respond with [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 RCODE=0 and an empty answer section, if the type of query does not
skipping to change at page 9, line 49 skipping to change at page 10, line 15
As an example, a host configured to respond to LLMNR queries for the As an example, a host configured to respond to LLMNR queries for the
name "foo.example.com." is authoritative for the name name "foo.example.com." is authoritative for the name
"foo.example.com.". On receiving an LLMNR query for an A RR with the "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) 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 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 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. responder would respond with RCODE=0 and an empty answer section.
In conventional DNS terminology a DNS server authoritative for a zone is In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone appex except for authoritative for all the domain names under the zone apex except for
the branches delegated into separate zones. Contrary to conventional the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone DNS terminology, an LLMNR responder is authoritative only for the zone
appex. apex.
For example the host "foo.example.com." is not authoritative for the For example the host "foo.example.com." is not authoritative for the
name "child.foo.example.com." unless the host is configured with name "child.foo.example.com." unless the host is configured with
multiple names, including "foo.example.com." and multiple names, including "foo.example.com." and
"child.foo.example.com.". As a result, "foo.example.com." cannot reply "child.foo.example.com.". As a result, "foo.example.com." cannot reply
to an LLMNR query for "child.foo.example.com." with RCODE=3 to an LLMNR query for "child.foo.example.com." with RCODE=3
(authoritative name error). The purpose of limiting the name authority (authoritative name error). The purpose of limiting the name authority
scope of a responder is to prevent complications that could be caused by 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 coexistence of two or more hosts with the names representing child and
parent (or grandparent) nodes in the DNS tree, for example, parent (or grandparent) nodes in the DNS tree, for example,
skipping to change at page 13, line 26 skipping to change at page 13, line 43
sent on the same interface. sent on the same interface.
For example, the algorithms described in RFC 2988 [RFC2988] (including For example, the algorithms described in RFC 2988 [RFC2988] (including
exponential backoff) to compute an RTO, which is used as the value of 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 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 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 Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed
in Section 2 of [RFC2988], paragraph 2.5). in Section 2 of [RFC2988], paragraph 2.5).
Recommended values are an initial RTO of 1 second, a minimum RTO of Recommended values are an initial RTO of 1 second, a minimum RTO of
500ms, and a maximum RTO of 5 seconds. In order to avoid 200ms, and a maximum RTO of 5 seconds. In order to avoid
synchronization, the transmission of each LLMNR query and response synchronization, the transmission of each LLMNR query and response
SHOULD delayed by a time randomly selected from the interval 0 to 100 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 ms. This delay MAY be avoided by responders responding with RRs which
they have previously determined to be UNIQUE (see Section 4 for they have previously determined to be UNIQUE (see Section 4 for
details). details).
2.8. DNS TTL 2.8. 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 an LLMNR response. A default value of 30 seconds is returned an LLMNR response. A default value of 30 seconds is
skipping to change at page 14, line 10 skipping to change at page 14, line 30
delegation semantics as it does in the DNS. Responders MAY have NS delegation semantics as it does in the DNS. Responders MAY have NS
records associated with the names for which they are authoritative, but records associated with the names for which they are authoritative, but
they SHOULD NOT include these NS records in the authority sections of they SHOULD NOT include these NS records in the authority sections of
responses. responses.
Responders SHOULD insert an SOA record into the authority section of a Responders SHOULD insert an SOA record into the authority section of a
negative response, to facilitate negative caching as specified in negative response, to facilitate negative caching as specified in
[RFC2308]. The owner name of this SOA record MUST be equal to the query [RFC2308]. The owner name of this SOA record MUST be equal to the query
name. name.
Responders SHOULD NOT perform DNS additional section processing. 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 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 response as answers, though they may be used for other purposes such as
negative caching. negative caching.
3. Usage model 3. Usage model
Since LLMNR is a secondary name resolution mechanism, its usage is in Since LLMNR is a secondary name resolution mechanism, its usage is in
part determined by the behavior of DNS implementations. This document part determined by the behavior of DNS implementations. This document
does not specify any changes to DNS resolver behavior, such as does not specify any changes to DNS resolver behavior, such as
skipping to change at page 15, line 49 skipping to change at page 16, line 19
authoritative for the names of local hosts, or the authoritative DNS authoritative for the names of local hosts, or the authoritative DNS
server(s) do not support dynamic update, then LLMNR enables linklocal server(s) do not support dynamic update, then LLMNR enables linklocal
name resolution over IPv4. name resolution over IPv4.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR [LLMNREnable], can be used to explicitly enable or disable use of LLMNR
on an interface. The LLMNR Enable Option does not determine whether or 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 in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937]. 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 It is possible that DNS configuration mechanisms will go in and out of
service. In these circumstances, it is possible for hosts within an service. In these circumstances, it is possible for hosts within an
administrative domain to be inconsistent in their DNS configuration. administrative domain to be inconsistent in their DNS configuration.
For example, where DHCP is used for configuring DNS servers, one or more 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 DHCP servers can fail. As a result, hosts configured prior to the
outage will be configured with a DNS server, while hosts configured outage will be configured with a DNS server, while hosts configured
after the outage will not. Alternatively, it is possible for the DNS after the outage will not. Alternatively, it is possible for the DNS
configuration mechanism to continue functioning while configured DNS configuration mechanism to continue functioning while configured DNS
servers fail. servers fail.
Unless unconfigured hosts periodically retry configuration, an outage in Unless unconfigured hosts periodically retry configuration, an outage in
skipping to change at page 21, line 50 skipping to change at page 22, line 19
LLMNR on each interface. The use of separate caches is most effective 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 when LLMNR is used as a name resolution mechanism of last resort, since
this minimizes the opportunities for poisoning the LLMNR cache, and this minimizes the opportunities for poisoning the LLMNR cache, and
decreases reliance on it. decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood that LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query. a DNS server will unintentionally respond to an LLMNR query.
5.4. Authentication 5.4. Authentication
LLMNR implementations may not support DNSSEC, and as a result, responses LLMNR implementations may not support DNSSEC or TSIG, and as a result,
to LLMNR queries may be unauthenticated. If authentication is desired, responses to LLMNR queries may be unauthenticated. If authentication is
and a pre-arranged security configuration is possible, then IPsec ESP desired, and a pre-arranged security configuration is possible, then
IPsec ESP with a null-transform MAY be used to authenticate LLMNR
with a null-transform MAY be used to authenticate LLMNR responses. In a responses. In a small network without a certificate authority, this can
small network without a certificate authority, this can be most easily be most easily accomplished through configuration of a group pre-shared
accomplished through configuration of a group pre-shared key for trusted key for trusted hosts.
hosts.
6. IANA Considerations 6. IANA Considerations
This specification does not create any new name spaces for IANA This specification creates one new name space: the reserved bits in the
administration. LLMNR requires allocation of a port TBD for both TCP LLMNR header. These are allocated by IETF Consensus, in accordance with
and UDP. Assignment of the same port for both transports is requested. 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 requires allocation of a link-scope multicast IPv4 address TBD.
LLMNR also requires allocation of a link-scope multicast IPv6 address LLMNR also requires allocation of a link-scope multicast IPv6 address
TBD. TBD.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
skipping to change at page 23, line 11 skipping to change at page 23, line 30
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
7.2. Informative References 7.2. Informative References
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
skipping to change at page 26, line 25 skipping to change at page 26, line 37
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-28.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-29.txt>, and expires
July 4, 2004. August 4, 2004.
 End of changes. 

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