RFC 6804

DISCOVER: Supporting Multicast DNS Queries 🦋

Okay bestie, let's get into RFC 6804 ✨ First the paperwork: it's written by B. Manning (one author, solo queen 👑), it came out in November 2012, and it's an Independent Submission. Its category is Historic, its ISSN is 2070-1721, and its header doesn't list an Obsoletes or Updates line, so it isn't replacing or touching any other RFC 🙈

---

Abstract 💖

So the abstract is giving: this doc describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) that uses multicast queries for resource discovery. It got tested in experiments during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. That project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS 🫶 A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for the historical record.

This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6804.

Copyright Notice ⭐

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

---

1. Introduction ✨

So the TBDS project built extensions into existing network services so that application clients and servers could handle topology changes way better 🌈 They sense changes on their own and switch between client/server and peer-to-peer methods, for both end-system-to-server and server-to-server communication. Iconic behaviour, honestly.

The first existing network service they looked at was the Domain Name System (DNS), which maps symbolic Internet names to numeric Internet addresses. The DNS is built as a hierarchical tree and relies on uninterrupted connectivity from nodes to a special set of static, manually configured root servers. To make DNS more robust and available, TBDS came up with enhancements that let nodes map names to numbers without needing uninterrupted connectivity to the Internet root servers. These techniques are automated, so moving between connected and unconnected operation doesn't need direct human intervention 🤖

These enhancements to the DNS server code are based on the open source BIND, so it can receive and process multicast packets 🎀

Proof-of-concept modifications to BIND 8.1.2 showed that multicast awareness could be added to BIND. The team also analysed the existing DNS code deployment and the schedule for new feature deployment, so they could line TBDS up with a more appropriate code base. Testing turned up a race condition caused by overloading the semantics of the DNS opcode that was used to talk to servers 😭

This race condition was explored within the IETF in relation to using existing DNS opcodes. Discussion within the team and with others in the IETF led to the idea that they needed a new opcode that wouldn't overload the semantics of existing opcodes 💅 The original DNS design specification assumes that few clients exist that would share common DNS data. To fix this, a new opcode was designed to tell TBDS requests apart from normal nameserver requests.

In the standard Domain Name System (DNS) [1] [2], queries are always unicast using the QUERY opcode. The TBDS research project [5], funded under DARPA grant F30602-99-1-0523, explored the use of multicast DNS [1] [2] queries for resource discovery by autonomous, mobile nodes in disconnected networks. The operations model is covered in the TBDS documentation. Multicast queries may return multiple replies, while the standard DNS QUERY operation (see Sections 3.7, 4.3, and 5 of RFC 1034 [1]; and Section 4.1.1 of RFC 1035 [2]) expects a single reply. Instead of extending the QUERY opcode, the project developed and tested a new query operation, DISCOVER, that was designed to accommodate multiple responses from a multicast query. The ability to accept multiple replies gives a basis for telling apart man-in-the-middle attacks, which succeed by being the first to respond 👀 Use of DISCOVER requires caching in the receiver, so the ephemeral nature of stub resolvers is precluded.

This memo documents the processing rules for DISCOVER, for possible incorporation in a future revision of the DNS 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 BCP 14, RFC 2119 [3].

2. DISCOVER Processing Rules 💅

So here's how the requester and responders behave 🧚

A requester will send a DISCOVER query message to a multicast destination address, with some particular multicast scope. The requester must be prepared to receive multiple replies from multiple responders, although we expect that there will be a single reply per responder.

DISCOVER responses (i.e., response messages from DISCOVER queries) have standard Answer, Authority, and Additional sections. For example, the DISCOVER response is the same as the response to a QUERY operation. Zero-content answers should not be sent, to avoid badly formed or unfulfilled requests. Responses should be sent to the unicast address of the requester, and the source address should reflect the unicast address of the responder. DISCOVER responses may echo the request's Question section or leave it blank, just as for QUERY.

DISCOVER works like QUERY, with the following exceptions:

1. The Question section of a DISCOVER operation contains <QNAME=zonename,QTYPE=SOA> tuples, if the section is present.

Within TBDS, this structure was augmented with <QNAME=service,QTYPE=SRV>. While this worked, it would be cleaner to ask the SRV question in a separate pass; any future work should take this into consideration.

2. If QDCOUNT equals 0, then only servers willing to do recursion should answer; other servers must silently discard a DISCOVER request with QDCOUNT equals 0.
3. If QDCOUNT is not equal to 0, then only servers that are authoritative for the zones named by some QNAME should answer.

Hence, replies to DISCOVER queries will always be authoritative or else have RA (Recursion Available) set.

3. Using DISCOVER Queries 🧚

3.1. Performing Host Lookups 🏠

To perform a hostname lookup using DISCOVER, a node could:

• Compute the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain.
• DISCOVER whether any in-scope server(s) are authoritative for this zone.
  • If so, query these authoritative servers for local in-addr/ip6 names.
• If not, DISCOVER whether there are recursive servers available.
  • If so, query these recursive servers for local in-addr/ip6 names.

The requester can determine from the replies whether there are any DNS servers that are authoritative (or support recursion) for the zone.

• Once the host's Fully Qualified Domain Name (FQDN) is known, repeat the process to discover the closest enclosing authoritative server for this local name.
• Cache all NS and A data learned in this process, respecting Times To Live (TTLs).

3.2. Performing Service Lookups 🎀

To lookup a service name using DISCOVER, the following steps may be used:

• Use DISCOVER as outlined in Section 3.1 to perform gethostbyaddr() and then gethostbyname() on one's own link-local address. This gives a list of local authoritative servers.
• Assume that the closest enclosing zone for which an authoritative server responds to an in-scope DISCOVER message is this host's "parent domain", and compute the SRV name as:

_service._transport.*.parentdomain.

This is a change to the definition provided in RFC 1034 [1]. A wildcard label ("*") in the QNAME used in a DNS message with the opcode DISCOVER should be evaluated with special rules: the wildcard should match any label for which the DNS server data is authoritative. For example 'x.*.example.com.' would match 'x.y.example.com.' and 'x.yy.example.com.', provided that the server was authoritative for 'example.com.'

• Finally, send an SRV query for this SRV name to the discovered local authoritative servers to complete the getservbyname() call.

This call returns a structure that can be populated by response values, as follows:

• s_name: The name of the service, "_service" without the preceding underscore.
• s_aliases: The names returned in the SRV Resource Records (RRs) in replies to the query.
• s_port: The port number in the SRV RRs replies to the query. If these port numbers do not match, one of the port numbers is chosen, and only those names that correspond are returned.
• s_proto: The transport protocol passed from the DNS process using the "_transport" label, without the preceding underscore.

3.3. Using DISCOVER for Disconnected Names ✨

okay so DISCOVER lets you find a host (like a printer offering LPD services 🖨️) even when its DNS server answers authoritatively for a name that was never delegated to it, but that name is defined within some local scope 🌸 and bestie, this isn't a violation of DNS's coherency principles, because DISCOVER is literally designed to discover undelegated zones for tightly scoped queries 💅 ngl that's so iconic. also, a DISCOVER responder doesn't have to be traditional DNS software. it could be special-purpose software 🧚

if you've got a disconnected network with no authoritative servers at all, DISCOVER can still work if these conditions are met 🎀

• Hosts run a "stub authoritative server" that acts as though its FQDN were a zone name.
• The computed SOA gives the host's FQDN as the MNAME, "." as the ANAME, seconds-since-1Jan2000 as the SERIAL, and low constants for EXPIRE and the other SOA timers.
• NS is used as the host's FQDN.
• The glue is computed as the host's link-local address, or hosts may run a "DNS stub server" that acts as though its FQDN were a zone name.

the rules for this server are giving "one tiny change in how it's used, and zero changes to the current format of DNS packets" 🦋 specifically, this extension lets UDP DNS queries (as documented in RFC 1035, Sections 4.1.1, 4.1.2, and 4.2.1) get addressed to port 53 of the statically assigned relative offset -4 within the multicast range defined as "administratively scoped" by Section 9 of RFC 2365 [6]. across the full /8 of administratively scoped addresses, that's the destination address 239.255.255.251 💜 until the Multicast-Scope Zone Announcement Protocol (MZAP) or something similar is implemented so hosts can figure out how far their local multicast scopes reach, implementations will just use 239.255.255.251 🌈 and queries sent via multicast MUST NOT request recursion 🙅‍♀️

so for DNS servers to actually hear these multicast queries, they MUST listen on the -4 offset of their local scope (and until there's a way to figure out the scope, that's assumed to be relative to the full /8 allocated for administratively scoped multicast use, or 239.255.255.251). they respond via ordinary unicast UDP, but ONLY to queries they have a positive answer for that came from a locally-configured zone file. basically, a server MUST NOT answer a multicasted query with cached info it got from another server, and it can't ask other servers to resolve things on behalf of a multicasted query either 🙃 a multicast-capable server CAN, though, use multicast queries to do further resolution for queries that came in over ordinary unicast. this is called "proxy" operation 🫶 and multicast-enabled DNS servers MUST answer multicasted queries non-authoritatively. so when they reply to a multicast query, they MUST NOT include an NS record that resolves back to their own IP address, and they MUST NOT set the AA bit 🙈

now resolvers, you have to be ready for silence 😭 resolvers MUST anticipate getting no replies to some multicasted queries, either because no multicast-enabled DNS server is active within the local scope, or because there are no positive responses for the query. like, a query for the MX record for host.domain.com would go unanswered if no local server could resolve it, if there's no MX record for host.domain.com, or if no local servers can even receive multicast queries 💀 the resolver that started the query MUST treat that non-response as a non-cacheable negative response. since multicast doesn't give reliable delivery, resolvers MAY repeat the transmission of a query just to make sure it got to any hosts that can answer. BUT any resolver that repeats a query MUST increase the interval by a factor of two between each repetition ⭐ honestly though, repeated queries are more likely to happen because the application driving the query asked for them explicitly, not because the resolver did it on its own.

also, multicast queries often get answers from multiple servers at once 👑 if the multicast query came from a current API like gethostbyname, or as the result of a proxy operation, the first response received has to be passed to the requesting application or host, and everything received after that gets discarded. future multicast-aware APIs that use DISCOVER should expect multiple independent RR sets in response to queries, and use external heuristics to pick the most appropriate RR set 🍓

these servers should answer DISCOVER packets for their zone, and DISCOVER clients will find them through the iterative "discover closest enclosing authority server" step, in either the gethostbyname() or SRV cases described above ✨ and heads up: stub servers only answer with zone names that EXACTLY match QNAME's, not zone names that are owned by QNAME's 💅

---

4. IANA Considerations 🌸

if this idea ever gets considered for a future addition to the DNS protocol, IANA would need to assign a value for the opcode 🎀

5. Security Considerations 💀

okay bestie, this paragraph was written super early in the days of IP multicast, so it's a pretty naive take on the kinds of exploits multicast can enable 🙈 for a much more up-to-date understanding of multicast security, check out RFC 5294 [4].

no new security considerations are known to come with a new DNS query operation 🫶 HOWEVER, using multicast for service discovery has the potential for denial of service through flooding attacks 😱 how to scope multicast isn't part of the DISCOVER processing rules. it may also be possible to deliberately misconfigure clients by running a malicious DNS server that falsely claims to be authoritative for delegations 👀 one possible way to mitigate this threat is to use credentials, like CERT resource records within an RR set. the TBDS project took this approach. TBDS didn't directly use DNS Security (DNSSEC), so possible interactions with DNSSEC-aware/-capable servers are unknown 🧐

6. Acknowledgments 🫶

this material came out of discussions on the mdns mailing list hosted by Zocalo in March 2000, and got updated by discussions in September/October 2003 on a closed mailing list 💜 David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, and Erik Guttman were active contributors. Suzanne Woolf was part of the original implementation team and an invaluable sanity checker 👑 and funding for the RFC Editor function is currently provided by the Internet Society 🌈

7. References ✨

7.1. Normative References

[1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987.

[2] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", STD 13, RFC 1035, November 1987.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[4] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008.

7.2. Informative References

[5] Manning, B., "Topology Based Domain Search (TBDS)", Final Report, June 2002, <http://www.dtic.mil/docs/citations/ADA407598>.

[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.

Authors' Addresses 💖

Bill Manning
PO 12317
Marina del Rey, CA. 90295
United States

EMail: bmanning@sfc.keio.ac.jp