RFC 4795
Link-local Multicast Name Resolution (LLMNR)
📬 RFC 4795: Link-Local Multicast Name Resolution (LLMNR) 🎀
Network Working Group ✨ Request for Comments: 4795 💖 Category: Informational 🦋 Published: January 2007 🌸
Okay bestie, the authors are B. Aboba, D. Thaler, and L. Esibov, all from Microsoft Corporation 💅 This RFC is Informational, which means it shares info with the Internet community and does NOT set an Internet standard 🫶 Its title block doesn't list anything it obsoletes or updates, so no drama there 🙈
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 🌸
Okay so the spicy backstory: this document was originally meant to be a Proposed Standard, but the IETF didn't reach consensus on the approach 😭 It got a LOT of review and input though, and by the time it was published, early versions were already implemented and deployed. Iconic rise-and-fall-and-still-slaying energy 💀✨
Abstract 🦋
The goal of Link-Local Multicast Name Resolution (LLMNR) is to make name resolution work in situations where normal DNS name resolution just isn't possible 🧚 LLMNR supports all current and future DNS formats, types, and classes, but it runs on its own separate port away from DNS and keeps its own resolver cache 🫶 Since LLMNR only works on the local link, it is NOT a replacement for DNS, periodt 💅
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 ................................................291. Introduction ✨
Okay so this doc is all about Link-Local Multicast Name Resolution (LLMNR) 🎀 It's based on the DNS packet format and supports all current and future DNS formats, types, and classes. LLMNR runs on a separate port from the Domain Name System (DNS), with its own 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 stop LLMNR traffic from getting propagated across routers, so it doesn't flood the whole network 🌊 LLMNR queries can also be sent to a unicast address, which is covered in Section 2.4 🦋
Propagating LLMNR packets on the local link is considered enough to make name resolution work in small networks 🧚 In those networks, if there's a gateway, the network can usually provide DNS server configuration too. Configuration issues are discussed in Section 3.1 📝
Looking ahead, it might be worth thinking about multicast name resolution with multicast scopes beyond the link-scope 👀 That could happen if LLMNR deployment goes well, if there's a real need for multicast name resolution beyond the link-scope, or if multicast routing becomes ubiquitous. For example, expanded multicast name resolution support might be needed for mobile ad-hoc networks 🛸
Once there's experience with LLMNR deployment (administrative issues, usability, and impact on the network), it will be possible to re-evaluate which multicast scopes are appropriate for multicast name resolution 🔥 IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365] 💜
Service discovery in general, discovery of DNS servers using LLMNR in particular, and name resolution over non-multicast capable media are all OUT of scope for this document 🙈
1.1. Requirements 📏
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🫶
1.2. Terminology 📖
This document assumes you're already familiar with the DNS terminology defined in [RFC1035] 🤓 Other terminology used in this document includes:
- Routable Address: An address other than a link-local address. This includes globally routable addresses, as well as private addresses. 🌍
- Reachable: An LLMNR responder considers one of its addresses reachable over a link if it will respond to an Address Resolution Protocol (ARP) or Neighbor Discovery query for that address received on that 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. 💌
- UNIQUE: Some scenarios allow multiple responders to respond to the same query, and other scenarios only allow one responder to respond. Names for which only a single responder is anticipated are referred to as UNIQUE. Name uniqueness is configured on the responder, so uniqueness verification is the responder's responsibility 🔐
2. Name Resolution Using LLMNR 🎀
LLMNR queries are sent to and received on port 5355 📮 The IPv4 link-scope multicast address that a given responder listens to, and that a sender sends queries to, is 224.0.0.252 🌸 The IPv6 link-scope multicast address that a given responder listens to, and that a sender sends all queries to, is FF02:0:0:0:0:0:1:3 ✨
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, if only to verify the uniqueness of names as described in Section 4 🫶 This document does not specify how names are chosen or configured. It may happen via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315] 🧚
Here's the typical sequence of events for LLMNR usage 🦋
(a) An LLMNR sender sends an LLMNR query to the link-scope multicast address(es), unless a unicast query is indicated, as specified in Section 2.4.
(b) A responder responds to this query only if it is authoritative for the 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.
(c) Once the response arrives, the sender processes it. 📬
The sections that follow give more details on sender and responder behavior 💖
2.1. LLMNR Packet Format 📦
LLMNR is based on 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 is 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 the smaller of the link MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 octets for the header, VLAN tag and Cyclic Redundancy Check (CRC)) 🔥
To be continued... 🌈💖
2.1.1. LLMNR Header Format
okay so LLMNR queries and responses borrow the DNS header format from [RFC1035] 💅, with a few exceptions that I'm gonna flag as we go 🎀
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 | C|TC| T| Z| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+okay here's what each piece is doing 🦋
ID 🆔 This is a 16-bit identifier assigned by whatever program generates any kind of query. It gets copied from the query into the response, so the sender can use it to match responses to the queries it still has outstanding. The ID field in a query SHOULD be set to a pseudo-random value. For tips on generating pseudo-random values, check out [RFC4086].
QR 🌸 Query/Response. This is a 1-bit field. If it's set, the message is an LLMNR response. If it's clear, the message is an LLMNR query.
OPCODE 🧚 This is a 4-bit field that says what kind of query the message is. The originator of the query sets it, and it gets copied into the response. This spec only defines the behaviour of standard queries and responses (opcode value of zero). Future specs might use 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. no notes, we're doing the basics 💜
C ⚠️ Conflict! When it's set in a query, the 'C'onflict bit means the sender has already gotten multiple LLMNR responses to that query. In an LLMNR response, if the name is considered UNIQUE, the 'C' bit is clear. Otherwise it's set. LLMNR senders do not retransmit queries with the 'C' bit set. Responders MUST NOT respond to LLMNR queries with the 'C' bit set, but they may start the uniqueness verification process, as described in Section 4.2. this one is giving drama and I'm here for it 🔥
TC ✂️ TrunCation. The 'TC' bit says this message got truncated because it was longer than the transmission channel allows. The 'TC' bit MUST NOT be set in an LLMNR query and, if it is set, an LLMNR responder ignores it. If the 'TC' bit is set in an LLMNR response, the sender SHOULD resend the LLMNR query over TCP, using the responder's unicast address as the destination address. If the sender gets a response to that TCP query, it SHOULD discard the UDP response with the TC bit set. For more on the 'TC' bit, see [RFC2181] and Section 2.4 of this specification. periodt 💅
T 🌈 Tentative! The 'T'entative bit gets set in a response if the responder is authoritative for the name but hasn't verified that the name is unique yet. A responder MUST ignore the 'T' bit in a query, if it's set. A response with the 'T' bit set is silently discarded by the sender, except when it's a uniqueness query. In that case a conflict has been detected, and a responder MUST resolve the conflict as described in Section 4.1. plot twist 👀
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 an LLMNR query or response, implementations of this specification MUST ignore them. Since reserved bits could conceivably be used for different purposes than in DNS, implementers are advised not to enable processing of these bits in an LLMNR implementation starting from a DNS code base. be careful with this one, bestie ⚠️
RCODE 🎯 Response code. This 4-bit field is set as part of LLMNR responses. In an LLMNR query, the sender MUST set RCODE to zero, and the responder ignores the RCODE and assumes it to be zero. 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 that was sent in response to a multicast query.
If an LLMNR responder is authoritative for the name in a multicast query but runs into an error, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. That makes the query get resent over TCP, which lets a non-zero RCODE show up in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response at all, since it makes errors diagnosable 🔍 This might be needed, for example, when an LLMNR query has a TSIG RR in the additional section and the responder hits a problem that requires returning a non-zero RCODE. The TSIG error conditions defined in [RFC2845] include a TSIG RR in an unacceptable position (RCODE=1), or a TSIG RR that doesn't validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
Since LLMNR responders only respond to LLMNR queries for names they're authoritative for, 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 that gives 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 that gives the number of resource records in the answer section. LLMNR responders MUST silently discard LLMNR queries with ANCOUNT not equal to zero.
NSCOUNT 🗂️ An unsigned 16-bit integer that gives the number of name server resource records in the authority records section. Authority record section processing is described in Section 2.9. LLMNR responders MUST silently discard LLMNR queries with NSCOUNT not equal to zero.
ARCOUNT 🎁 An unsigned 16-bit integer that gives the number of resource records in the additional records section. Additional record section processing is described in Section 2.9.
2.2. Sender Behavior
okay sender energy 📣 A sender MAY send an LLMNR query for any legal resource record type (e.g., A, AAAA, PTR, SRV) to the link-scope multicast address. As described in Section 2.4, a sender MAY also send a unicast query. ✨
The sender MUST anticipate receiving no responses to some LLMNR queries, in case no responders are available within the link-scope. If no response comes back, a resolver treats it as a response saying the name does not exist (RCODE=3 is returned). 🫠 A sender can handle duplicate responses by discarding any response whose source IP address and ID field duplicate a response it already received.
When multiple valid LLMNR responses come in with the 'C' bit set, they SHOULD be concatenated and treated the same way multiple RRs from the same DNS server would be. However, responses with the 'C' bit set SHOULD NOT be concatenated with responses with the 'C' bit clear. Instead, only the responses with the 'C' bit set SHOULD be returned. If valid LLMNR response(s) arrive along with error response(s), the error responses are silently discarded. 🧹
Since the responder may order the RRs in the response to indicate preference, the sender SHOULD preserve that ordering in the response it hands to the querying application. 💖
2.3. Responder Behavior ✨
okay so an LLMNR response MUST be sent back to the sender via unicast 📮 no multicast replies, just a direct message to the person who asked 💌
once a responder has an IP address configured, it usually synthesizes the matching A, AAAA, and PTR RRs so it can answer LLMNR queries for them 🧚 an SOA RR only gets synthesized when the responder has some other RR too, because the SOA RR MUST NOT be the only RR a responder has 🙅♀️ whether the RRs are made manually or automatically is up to the implementation tbh 💅
for example, say a host has the computer name "host1", belongs to the "example.com" domain, and has IPv4 address 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6. it might be authoritative for these records:
host1. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
host1.example.com. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
1.2.0.192.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. (line split for formatting reasons)
IN PTR host1.example.com.a responder could also be manually set up with the name of a local mail server, with an MX RR included in the "host1." and "host1.example.com." records 📫
now for how responders handle queries 🫶
(a) responders MUST listen on UDP port 5355 on the link-scope multicast address(es) defined in Section 2, and on TCP port 5355 on the unicast address(es) that could be set as the source address(es) when the responder answers an LLMNR query. 👂
(b) responders MUST send replies to the port the query came from. for queries that come in over TCP, this is just part of how TCP works anyway 🧦 for queries that come in over UDP, the responder MUST note the source port and use it as the destination port in the response. responses MUST always be sent from the port they were directed to. no port drama allowed 🎀
(c) responders MUST answer LLMNR queries for names and addresses they're authoritative for. this covers both forward and reverse lookups, except for queries with the C bit set, because those don't get a response at all 🤐
(d) responders MUST NOT answer LLMNR queries for names they're not authoritative for. not your business, bestie 🙅♀️
(e) responders MUST NOT answer using data from the LLMNR or DNS resolver cache. fresh answers only, no leftovers 🍓
(f) if a responder is authoritative for a name, it MUST reply with RCODE=0 and an empty answer section when the type of query doesn't match any RR the responder has 🫙
as an example, a host set up to answer LLMNR queries for "foo.example.com." is authoritative for the name "foo.example.com.". when it gets an LLMNR query for an A RR with the name "foo.example.com.", it authoritatively responds with A RR(s) holding IP address(es) in the RDATA. but if the responder has an AAAA RR and no A RR, then an A RR query gets RCODE=0 and an empty answer section 🌸
in conventional DNS terms, a DNS server that's authoritative for a zone is authoritative for all the domain names under the zone apex, except for branches that got delegated into separate zones 🌳 but LLMNR is different from that. an LLMNR responder is only authoritative for the zone apex 🧚♀️
for example, the host "foo.example.com." is NOT authoritative for "child.foo.example.com." unless the host is configured with multiple names, including both "foo.example.com." and "child.foo.example.com.". so "foo.example.com." can't answer an LLMNR query for "child.foo.example.com." with RCODE=3 (authoritative name error). the whole point of limiting a responder's authority like this is to avoid chaos when two hosts have names that represent child and parent (or grandparent) nodes in the DNS tree, like "foo.example.com." and "child.foo.example.com." 🙃
without that restriction on authority, an LLMNR query for an A resource record for "child.foo.example.com." could get two authoritative responses at once: an RCODE=3 (authoritative name error) from "foo.example.com.", and the actual A record from "child.foo.example.com.". 😱 that's the ambiguity we're dodging here.
LLMNR-enabled hosts could fix this by dynamically updating the parent (or grandparent) zone with a delegation to a child zone. for example, a host "child.foo.example.com." could send a dynamic update for the NS and glue A record to "foo.example.com.". however, that approach makes LLMNR way more complicated to implement, and it wouldn't be acceptable for lightweight hosts 🪶 nope, not doing that
2.4. Unicast Queries and Responses ✨
unicast queries SHOULD be sent when:
(a) a sender repeats a query after it got 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. 🔍
unicast LLMNR queries MUST be done using TCP, and the responses MUST be sent over the same TCP connection as the query 🧵 senders MUST support sending TCP queries, and responders MUST support listening for TCP queries 🫶 and if the sender of a TCP query gets a response to that query that didn't come over TCP, the response MUST be silently discarded 🗑️
unicast UDP queries MUST be silently discarded. no UDP unicast tea, sorry 🍵
a unicast PTR RR query for an off-link address won't get a response. instead, an ICMP Time to Live (TTL) or Hop Limit exceeded message comes back 💀 an implementation that gets an ICMP message in response to a TCP connection setup attempt can return right away and treat it as a response saying no such name exists (RCODE=3 is returned) ⚡ an implementation that can't process ICMP messages MAY send multicast UDP queries for PTR RRs instead 🦋 and since TCP implementations won't retransmit before RTOmin, a long time passes before TCP retransmits several times, which means a really long timeout for TCP PTR RR queries sent to an off-link destination 😭 the wait is real
2.5. "Off-Link" Detection ✨
a sender MUST choose a source address for LLMNR queries that's assigned on the interface the query goes out on. the destination address of an LLMNR query MUST be a link-scope multicast address or a unicast address 📍
a responder MUST choose a source address for responses that's assigned on the interface where the query came in. the destination address of an LLMNR response MUST be a unicast address 💌
when a responder gets an LLMNR query, it MUST check whether the query was sent to one of the LLMNR multicast addresses defined in Section 2. if it was sent to some other multicast address, the query MUST be silently discarded 🚫
Section 2.4 talks about using TCP for LLMNR queries and responses. when composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header, and the TTL field in the IPv4 header of the response, to one (1) 1️⃣ the responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1), so SYN-ACK packets come out with TTL (IPv4) or Hop Limit (IPv6) set to one (1). this stops an incoming connection from off-link, since the sender won't get a SYN-ACK from the responder 🛡️ clever, right?
for UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. however, it is RECOMMENDED that the value 255 be used for compatibility with early implementations of [RFC3927] 🧸
Implementation note:
in the sockets API for IPv4 [POSIX], theIP_TTLandIP_MULTICAST_TTLsocket options are used to set the TTL of outgoing unicast and multicast packets. theIP_RECVTTLsocket option is available on some platforms to retrieve the IPv4 TTL of received packets withrecvmsg(). [RFC3542] specifies similar options for setting and retrieving the IPv6 Hop Limit. 🛠️
2.6. Responder Responsibilities ✨
it's the responder's job to make sure the RRs it returns in LLMNR responses MUST only include values that are valid on the local interface, like IPv4 or IPv6 addresses valid on the local link, or names defended using the mechanism described in Section 4 🏠 IPv4 Link-Local addresses are defined in [RFC3927], and IPv6 Link-Local addresses are defined in [RFC4291]. specifically:
(a) if a link-scope IPv6 address is returned in an AAAA RR, that address MUST be valid on the local link where LLMNR is used. 🔗
(b) if an IPv4 address is returned, it MUST be reachable through the link where 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 where LLMNR is used. 🏷️
when there are multiple addresses that are valid responses to a query, the order they get returned in goes like this:
(d) if the source address of the query is a link-scope address, the responder SHOULD include a link-scope address first in the response, if one is available. 🥇
(e) if the source address of the query is a routable address, the responder MUST include a routable address first in the response, if one is available. 🌍
2.7. Retransmission and Jitter ✨
an LLMNR sender uses the timeout interval LLMNR_TIMEOUT to decide when to retransmit an LLMNR query ⏱️ an LLMNR sender SHOULD either estimate the LLMNR_TIMEOUT for each interface, or set a reasonably high initial timeout. suggested constants are described in Section 7 📋
if an LLMNR query sent over UDP isn't resolved within LLMNR_TIMEOUT, the sender SHOULD repeat the transmission so it can be sure a host that can answer actually got it 🔄 but an LLMNR query SHOULD NOT be sent more than three times. three is the limit, bestie 🛑
when LLMNR queries go over TCP, the transport layer handles retransmission 🧦 queries with the C bit set MUST be sent using multicast UDP and MUST NOT be retransmitted 🚫🔁
an LLMNR sender can't know ahead of time whether a multicast query will get no response, one response, or more than one response 🤷♀️ so an LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it needs to collect all the potential responses, like when a uniqueness verification query is being made 🧐 otherwise, an LLMNR sender SHOULD consider a multicast query answered after the first response arrives, as long as that response has the C bit clear ✅
however, if the first response has the C bit set, the sender SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL to collect all possible responses ⏳ when multiple valid answers come in, they may be concatenated first, and then treated the same way multiple RRs from the same DNS server would be 🧩 a unicast query sender considers the query answered after the first response is received 💅
since a response with the C bit clear can be followed by a response with the C bit set, an LLMNR sender SHOULD be ready to process additional responses for conflict detection, even after it has considered a query answered 🕵️♀️
to avoid synchronization, the transmission of each LLMNR query and response SHOULD be delayed by a time randomly picked from the interval 0 to JITTER_INTERVAL 🎲 this delay MAY be skipped by responders that respond with names they've already determined to be UNIQUE (see Section 4 for details) 🦄 main character energy, but make it a protocol ✨
2.8. RR TTL ✨
okay so the responder is supposed to stick a pre-configured TTL value on the records it sends back in an LLMNR response 🎀 A default of 30 seconds is RECOMMENDED 💖 In super dynamic places like mobile ad-hoc networks 🦋 the TTL might need to be turned down.
bestie, this part matters: because of the TTL minimalization that happens when an RRset gets cached, every TTL in an RRset MUST be set to the same value 💅🔥
2.9. Use of the Authority and Additional Sections 🫶
Unlike the DNS, LLMNR is peer-to-peer and has no concept of delegation 🙅♀️ The NS record type can be stored and queried like any other type, but it has none of the special delegation semantics it gets in the DNS. Responders MAY have NS records for the names they're authoritative for, but they SHOULD NOT put those NS records in the authority sections of their responses.
Responders SHOULD insert an SOA record into the authority section of a negative response, so negative caching works as described in [RFC2308] 🧁 The TTL of that record is the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and it tells a resolver how long it can cache the negative answer ⏳ The owner name of the SOA record (MNAME) MUST be set to the query name. The RNAME, SERIAL, REFRESH, RETRY, and EXPIRE values MUST be ignored by senders. Negative responses without SOA records SHOULD NOT be cached 🙈
the additional section is mainly meant for EDNS0, TSIG, and SIG(0) 🍓 So, unless the 'C' bit is set, senders MAY only include pseudo RR-types in the additional section of a query. Unless the 'C' bit is set, responders MUST ignore the additional section of queries that contain other RR types.
When the 'C' bit is set, the sender SHOULD include the conflicting RRs in the additional section. Conflict notifications are only advisory, so responders SHOULD log the info from the additional section, but otherwise MUST ignore it 👀
Senders MUST NOT cache RRs from the authority or additional section of a response as answers 🚫 They can still be used for other purposes, like negative caching 🧠
3. Usage Model 🌈
okay so by default, an LLMNR sender SHOULD only send queries for single-label names 🎀 Stub resolvers that support both DNS and LLMNR SHOULD avoid sending DNS queries for single-label names, so they don't create unnecessary DNS traffic 🫶 An LLMNR sender SHOULD NOT be enabled to send a query for any name, except where security mechanisms (described in Section 5.3) can be used 🔐 An LLMNR query SHOULD only be sent for the originally requested name. A searchlist is not used to build extra LLMNR queries, bestie 💅
LLMNR is a peer-to-peer name resolution protocol, and it is NOT meant to replace DNS. Its whole purpose is to enable name resolution in situations where regular DNS name resolution isn't possible 🦋 If LLMNR security isn't enabled as described in Section 5.3, and LLMNR is given higher priority than DNS among the enabled name resolution mechanisms, the LLMNR cache could be poisoned and then take precedence over the DNS cache 😭 That's why using LLMNR as a primary name resolution mechanism is NOT RECOMMENDED 🙅♀️
Instead, it is recommended that LLMNR be used as a secondary name resolution mechanism 🧚 It's for situations where hosts aren't configured with the address of a DNS server, where the DNS server is unavailable or unreachable, where there is no DNS server authoritative for a host's name, or where the authoritative DNS server doesn't have the RRs you want 💖
When LLMNR is configured as a secondary name resolution mechanism, LLMNR queries SHOULD only be sent when all of the following conditions are met:
- No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, a host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, before sending LLMNR queries. For dual-stack hosts that are configured with DNS server address(es) for one protocol but not another, this means DNS queries SHOULD be sent over the protocol that has a DNS server configured, before sending LLMNR queries 🧩
- All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can happen because DNS servers didn't respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0 and an empty answer section 🙃 Where a single resolver call generates DNS queries for A and AAAA RRs, an implementation MAY choose not to send LLMNR queries if any of the DNS queries is successful ✨
When LLMNR is used as a secondary name resolution mechanism, how often it gets used depends partly on how DNS resolver implementations behave. Robust resolver implementations are more likely to avoid unnecessary LLMNR queries 💅
[RFC1536] describes common DNS implementation errors and their fixes 📚 If the proposed fixes are implemented, unnecessary LLMNR queries will drop a lot, so implementing [RFC1536] is recommended 🌸
For example, [RFC1536] Section 1 talks about issues with retransmission and recommends a retransmission policy based on round trip estimates, with exponential back-off ⏱️ [RFC1536] Section 4 talks about failover and recommends that resolvers try another server when they don't get a response to a query. These policies are likely to avoid unnecessary LLMNR queries 🫶
[RFC1536] Section 3 describes zero answer bugs. Fixing those will also cut down on unnecessary LLMNR queries 🍓
[RFC1536] Section 6 describes name error bugs and a recommended searchlist processing approach that reduces unnecessary RCODE=3 (authoritative name) errors, which also reduces unnecessary LLMNR queries 🎀
As noted in [DNSPerf], a big chunk of DNS queries either get no response or come back negative because of missing inverse mappings, or because NS records point to nonexistent or inappropriate hosts 😩 So cutting down on missing records can prevent a lot of unnecessary LLMNR queries 💜
3.1. LLMNR Configuration 🔧
LLMNR usage MAY be configured manually or automatically on a per-interface basis 🦋 By default, LLMNR responders SHOULD be enabled on all interfaces, at all times. If that's considered undesirable, LLMNR SHOULD be disabled, so hosts won't listen on the link-scope multicast address and won't send queries to that address either 🙈
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 LLMNR on an interface 🎀 The LLMNR Enable Option doesn't decide whether DNS itself gets used for name resolution, or in what order. The order that the various name resolution mechanisms should be used in can be set with the Name Service Search Option (NSSO) for DHCP [RFC2937], using the LLMNR Enable Option code carried in the NSSO data 🧩
When LLMNR is configured as a secondary name resolution protocol on a dual-stack host, the behavior is governed by both the IPv4 and IPv6 configuration mechanisms. Since IPv4 and IPv6 use different configuration mechanisms, a dual-stack host can be configured with the address of a DNS server over IPv4 while still not having a DNS server that's suitable for IPv6 🌈
In those situations, a dual-stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host that isn't configured with a DNS server suitable for IPv6 won't be able to resolve names using DNS 😭 Automatic IPv6 DNS configuration mechanisms (such as [RFC3315] and [DNSDisc]) aren't widely deployed yet, and not all DNS servers support IPv6 🥺 So a lack of IPv6 DNS configuration may be a common problem in the short term, and LLMNR may be useful for link-local name resolution over IPv6 🫶
Where a DHCPv4 server is available but a DHCPv6 server [RFC3315] isn't, IPv6-only hosts may not be configured with a DNS server. If there's no DNS server authoritative for a host's name, or the authoritative DNS server doesn't support dynamic client update over IPv6 or DHCPv6-based dynamic update, then an IPv6-only host won't be able to do DNS dynamic update, and other hosts won't be able to resolve its name 💀
For example, if the configured DNS server responds to an AAAA RR query sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), or with RCODE=0 and an empty answer section, then an AAAA RR query sent using LLMNR over IPv6 may succeed in resolving the name of an IPv6-only host on the local link 🧚
Similarly, if a DHCPv4 server is available that provides DNS server 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) don't support dynamic update, then LLMNR enables link-local name resolution over IPv4 🦋
DNS configuration mechanisms can go in and out of service. When that happens, hosts within an administrative domain can end up inconsistent in their DNS configuration 🌀
For example, when DHCP is used to configure DNS servers, one or more DHCP servers can fail. As a result, hosts that were configured before the outage will have a DNS server, while hosts configured after the outage won't. Or the DNS configuration mechanism might keep working while the configured DNS servers fail 😩
An outage in the DNS configuration mechanism may leave hosts continuing to use LLMNR even after the outage is fixed. Since LLMNR only enables link-local name resolution, that's a degradation in capabilities 📉 So hosts without a configured DNS server may want to periodically try to get DNS configuration, if the configuration mechanism in use allows it. Without other guidance, a default retry interval of one (1) minute is RECOMMENDED ⏰
4. Conflict Resolution 💅
By default, a responder SHOULD be configured to behave as though its name is UNIQUE on each interface where LLMNR is enabled 🎀 It's also possible to configure multiple responders to be authoritative for the same name. For example, multiple responders MAY respond to a query for an A or AAAA type record for a cluster name (one assigned to multiple hosts in the cluster) 🫶
To detect duplicate use of a name, an administrator can use a name resolution utility that uses LLMNR and lists both the responses and the responders 🔍 That lets the admin diagnose what's going on and, if needed, step in and reconfigure any LLMNR responders that shouldn't be set up to answer for the same name 🧚 iykyk, it's a whole vibe 💜
4.1. Uniqueness Verification ✨
okay bestie, before a responder sends an LLMNR response with the 'T' bit clear, a responder that's configured with a UNIQUE name MUST verify that no other host within the scope of LLMNR query propagation is authoritative for that same name on that interface. main character energy means nobody else gets to claim your name 🫶
once a responder has verified that its name is UNIQUE, and it gets an LLMNR query for that name with the 'C' bit clear, it MUST respond with the 'T' bit clear. but before it's verified that its name is UNIQUE, a responder MUST set the 'T' bit in its responses. it's like, not yet, wait your turn 🦋
uniqueness verification happens when the host:
- starts up or is rebooted 🔄
- wakes from sleep (if the network interface was inactive during sleep) 😴
- is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional UNIQUE resource records
- verifies the acquisition of a new IP address and configuration on an interface
to verify, a responder MUST send an LLMNR query with the 'C' bit clear, over all protocols it responds to LLMNR queries on (IPv4 and/or IPv6). it is RECOMMENDED that responders verify uniqueness by sending a query for the name with type='ANY' 🌸
if no response comes back, the sender retransmits the query, as specified in Section 2.7. if a response does come back, the sender MUST check whether the source address matches the address of any of its interfaces. if it does, the response isn't a conflict, since it came from the sender itself. to avoid triggering conflict detection, a responder that detects it's connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses 🙈
if a response comes back with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). if a response comes back with the 'T' bit set, the responder MUST check whether the source IP address in the response is lexicographically smaller than the source IP address in the query. if it is, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). for uniqueness verification, what's in the answer section of a response doesn't matter at all 💀
periodically checking for uniqueness to catch name conflicts is not necessary, wastes network bandwidth, and may actually be harmful. for example, if network links are only briefly joined and then separated again before any new communication starts, temporary conflicts are harmless and no forced reconfiguration is needed. so LLMNR responders SHOULD NOT periodically attempt uniqueness verification 🙅
4.2. Conflict Detection and Defense 🛡️
hosts on disjoint network links may configure the same name for use with LLMNR. if those separate links are later joined or bridged together, there may end up being multiple hosts on the same link trying to use the same name 😬
so to keep detecting name conflicts over time, when an LLMNR sender gets multiple LLMNR responses to a query, it MUST check whether the 'C' bit is clear in any of them. if it is, the sender SHOULD send another query for the same name, type, and class, this time with the 'C' bit set, and with the potentially conflicting resource records included in the additional section 🔍
queries with the 'C' bit set are considered advisory, so responders MUST verify that a conflict actually exists before acting on it. a responder that receives a query with the 'C' bit set MUST NOT respond 🤫
if the query is for a UNIQUE name, the responder MUST send its own query for the same name, type, and class, with the 'C' bit clear. if a response comes back, the sender MUST check whether the source address matches the address of any of its interfaces. if it does, the response isn't a conflict, since it came from the sender. to avoid triggering conflict detection, a responder that detects it's connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses 🫣
an LLMNR responder MUST NOT ignore conflicts once they're detected, and SHOULD log them. upon detecting a conflict, an LLMNR responder MUST immediately stop using the conflicting name in response to LLMNR queries received over any supported protocol, if the source IP address in the response is lexicographically smaller than the source IP address in the uniqueness verification query 🚫
after stopping use of a name, the responder MAY elect to configure a new name. however, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available. a host that has stopped using a name may attempt uniqueness verification again after the expiration of the TTL of the conflicting response ⏳
4.3. Considerations for Multiple Interfaces 🧭
a multi-homed host may elect to configure LLMNR on only one of its active interfaces. in lots of situations, that's totally adequate. however, if a host needs LLMNR on more than one of its active interfaces, there are some extra precautions it MUST take. implementers who aren't planning to support LLMNR on multiple interfaces at the same time may skip this section 🫶
where a host is configured to issue LLMNR queries on more than one interface, each interface keeps its own independent LLMNR resolver cache, containing the responses to LLMNR queries 📦
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 conflictin this case, 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 won't 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 queries over multiple interfaces and gets responses 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 conflictif 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 can't tell apart the situation shown in Figure 2 from the one shown in Figure 3, where no conflict exists.
[A]
| |
----- -----
| |
[myhost]
Figure 3. Multiple paths to same hostthis shows 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 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.4. API Issues 🛠️
[RFC3493] provides an API that 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 queries will be sent from both interfaces, and the resolver library will return a list containing multiple addrinfo structures, each with an associated sockaddr_in6 structure. this list will thus contain the IPv4 and IPv6 addresses of both hosts responding to the name 'A'. link-local addresses will have a sin6_scope_id value that tells apart which interface is used to reach the address. of course, to the application, Figures 2 and 3 are still indistinguishable, but this API lets the application communicate successfully with any address in the list 🎀
5. Security Considerations 🔐
LLMNR is a peer-to-peer name resolution protocol designed for use on the local link. while LLMNR limits the vulnerability of responders to off-link senders, it is still possible for an off-link responder to reach a sender 👀
in scenarios such as public "hotspots", attackers can be present on the same link. these threats are most serious in wireless networks, such as IEEE 802.11, since attackers on a wired network will require physical access to the network, while wireless attackers may mount attacks from a distance. link-layer security, such as [IEEE-802.11i], can be of assistance against these threats if it is available 📶
this section details security measures available to mitigate threats from on and off-link attackers 🛡️
5.1. Denial of Service 💀
attackers may take advantage of LLMNR conflict detection by allocating the same name, denying service to other LLMNR responders, and possibly allowing an attacker to receive packets destined for other hosts. by logging conflicts, LLMNR responders can provide forensic evidence of these attacks 🚨
an attacker may spoof LLMNR queries from a victim's address in order to mount a denial of service attack. responders setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may be able to reach the victim across the Internet 😱
while LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, an LLMNR response may be larger than the query, and an attacker can generate multiple responses to a query for a name used by multiple responders. a sender may protect itself against unsolicited responses by silently discarding them 🛑
5.2. Spoofing 🎭
okay so LLMNR is designed to stop an off-link attacker from even receiving your queries 🙅♀️ Responders that get UDP queries are required to check that those queries were sent to a link-scope multicast address. BUT ngl, some routers might not implement link-scope multicast properly, and link-scope multicast addresses might leak into the multicast routing system 😬 So to block an off-link sender from successfully setting up TCP connections, responders that receive a TCP SYN reply with a TCP SYN-ACK whose TTL is set to one (1).
it's hard for an off-link attacker to send an LLMNR query to a responder, but they can spoof a response to a query (like an A or AAAA query for a popular Internet host) 👀 And if they use a TTL or Hop Limit field bigger than one (1), the forged response can actually reach the LLMNR sender. The forged response only gets accepted if it has a matching ID field, so picking a pseudo-random ID field in queries gives some protection against off-link responders 🔐
when LLMNR is used as a secondary name resolution service, queries can be sent when the DNS server(s) don't respond 🫠 An attacker can DoS the DNS server(s) and then poison the LLMNR cache by answering an LLMNR query with incorrect info. As noted in "Threat Analysis of the Domain Name System (DNS)" [RFC3833], these threats exist with DNS too, since DNS-response spoofing tools are available that let an attacker respond to a query faster than a distant DNS server ⚡ However, switched networks or link-layer security may make it hard for an on-link attacker to snoop unicast DNS queries. Multicast LLMNR queries go to all hosts on the link, though, so an on-link attacker can spoof LLMNR responses without having to guess the value of the ID field in the query 💀
since LLMNR queries are sent and answered on the local link, an attacker has to respond quicker than the legitimate responder to get their own response in first 🏃♀️ If an LLMNR query is sent for an off-link host, spoofing a response in a timely way isn't difficult, because a legitimate response will never be received 😭
this vulnerability can be reduced by limiting LLMNR to resolution of single-label names, as described in Section 3, or by implementing authentication (see Section 5.3) 🛡️
5.3. Authentication 🔑
LLMNR is a peer-to-peer name resolution protocol, so it's often deployed in situations where no trust model can be assumed 🤷♀️ Where a pre-arranged security configuration is possible, the following security mechanisms may be used:
- (a) LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) [RFC2931] security mechanisms. "DNS Name Service based on Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG to secure LLMNR, based on group keys. While group keys can be used to demonstrate membership in a group, they do not protect against forgery by an attacker that is a member of the group. 🫣
- (b) IPsec Encapsulating Security Payload (ESP) with a NULL encryption algorithm MAY be used to authenticate unicast LLMNR queries and responses, or LLMNR responses to multicast queries. 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. As with TSIG, this does not protect against forgery by an attacker with access to the group pre-shared key 🗝️
- (c) LLMNR implementations MAY support DNSSEC [RFC4033]. In order to support DNSSEC, LLMNR implementations MAY be configured with trust anchors, or they MAY make use of keys obtained from DNS queries. Since LLMNR does not support "delegated trust" (CD or AD bits), LLMNR implementations cannot make use of DNSSEC unless they are DNSSEC-aware and support validation. Unlike approaches [a] or [b], DNSSEC permits a responder to demonstrate ownership of a name, not just membership within a trusted group. As a result, it enables protection against forgery 👑
5.4. Cache and Port Separation 🧹
okay this part is about keeping things separate 💅 In order to stop responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. LLMNR also runs on a separate port from DNS, which reduces the likelihood that a DNS server will unintentionally respond to an LLMNR query 🎀
if a DNS server is running on a host that supports LLMNR, the LLMNR responder on that host MUST respond to LLMNR queries only for the RRSets relating to the host the server is running on, but it MUST NOT respond for other records the DNS server is authoritative for 🙅♀️ And DNS servers MUST NOT send LLMNR queries in order to resolve DNS queries. no crossing the streams, bestie 🫶
6. IANA Considerations 📋
this specification creates a brand new namespace: the LLMNR namespace ✨
to avoid creating any new administrative procedures, administration of the LLMNR namespace piggybacks on the administration of the DNS namespace 🧠
the rights to use a fully qualified domain name (FQDN) within LLMNR are obtained by acquiring the rights to use that name within DNS. So anyone wanting to use an FQDN within LLMNR should first acquire the rights to use the corresponding FQDN within DNS. Using an FQDN within LLMNR without owning the matching name in DNS creates the possibility of conflict, so it's discouraged 🙅♀️
LLMNR responders may self-allocate a name within the single-label namespace first defined in [RFC1001]. Since single-label names aren't unique, no registration process is required 🌸
7. Constants 🧮
these timing constants are used in this protocol. They're not meant to be user configurable, so hands off 🙈
JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
100 ms (IEEE 802 media, including IEEE 802.11)8. References 📚
8.1. Normative References
[RFC1001] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-
to-End Services Task Force, "Protocol standard for a
NetBIOS service on a TCP/UDP transport: Concepts and
methods", STD 19, RFC 1001, March 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.8.2. Informative References
[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", Work in Progress, October
2002.
[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security",
IEEE 802.11i, July 2004.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Work in
Progress, April 2002.
[LLMNRSec] Jeong, J., Park, J. and H. Kim, "DNS Name Service
based on Secure Multicast DNS for IPv6 Mobile Ad Hoc
Networks", ICACT 2004, Phoenix Park, Korea, February
9-11, 2004.
[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
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and
Suggested Fixes", RFC 1536, October 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2937] Smith, C., "The Name Service Search Option for DHCP",
RFC 2937, September 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and
W. Stevens, "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API)
for IPv6", RFC 3542, May 2003.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.9. Acknowledgments 🫶
this work builds on the original multicast DNS work done 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 also came in from Mark Andrews, Rob Austein, Randy Bush, Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike St. Johns, Sander van Valkenburg, and Brian Zill. the people who made this protocol better 🙌✨
Authors' Addresses 💖
okay so the three bestie-level brains behind this doc are all at Microsoft, based in Redmond 🍓. here's where you can find them ✨
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
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.comFull Copyright Statement 🎀
the IETF Trust holds the copyright for this one, dated 2007 🌸 this document is subject to the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 💜
the document and everything in it is provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 🙈
Intellectual Property 🔥
the IETF doesn't take a position on whether any IPR or other rights that someone might claim over the tech in here are valid or how far they reach, or whether any license for them is available 💅 it also doesn't claim it has searched for those rights on its own. if you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 🦋
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🌈
the IETF also invites anyone to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🫶
the RFC Editor function is currently funded by the Internet Society ✨ thank you to the folks keeping the lights on, bestie 👑
📦 where this page comes from
- ietf: rfc4795 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms