Link-local Multicast Name Resolution (LLMNR)
RFC 4795
Network Working Group B. Aboba
Request for Comments: 4795 D. Thaler
Category: Informational L. Esibov
Microsoft Corporation
January 2007
Link-Local Multicast Name Resolution (LLMNR)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IESG Note
This document was originally intended for advancement as a Proposed
Standard, but the IETF did not achieve consensus on the approach.
The document has had significant review and input. At time of
publication, early versions were implemented and deployed.
Abstract
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
name resolution in scenarios in which conventional DNS name
resolution is not possible. 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. Since LLMNR only
operates on the local link, it cannot be considered a substitute for
DNS.
Aboba, et al. Informational [Page 1]
RFC 4795 LLMNR January 2007
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.1.1. LLMNR Header Format .................................5
2.2. Sender Behavior ............................................8
2.3. Responder Behavior .........................................9
2.4. Unicast Queries and Responses .............................11
2.5. "Off-Link" Detection ......................................11
2.6. Responder Responsibilities ................................12
2.7. Retransmission and Jitter .................................13
2.8. RR TTL ....................................................14
2.9. Use of the Authority and Additional Sections ..............14
3. Usage Model ....................................................15
3.1. LLMNR Configuration .......................................17
4. Conflict Resolution ............................................18
4.1. Uniqueness Verification ...................................19
4.2. Conflict Detection and Defense ............................20
4.3. Considerations for Multiple Interfaces ....................21
4.4. API Issues ................................................22
5. Security Considerations ........................................23
5.1. Denial of Service .........................................23
5.2. Spoofing ..................................................24
5.3. Authentication ............................................25
5.4. Cache and Port Separation .................................25
6. IANA Considerations ............................................26
7. Constants ......................................................26
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
9. Acknowledgments ................................................29
Aboba, et al. Informational [Page 2]
RFC 4795 LLMNR January 2007
1. Introduction
This document discusses Link-Local Multicast Name Resolution (LLMNR),
which is based on 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.
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. In such
networks, if a network has a gateway, then typically the network is
able to provide DNS server configuration. Configuration issues are
discussed in Section 3.1.
Show full document text