Discovery Proxy for Multicast DNS-Based Service Discovery
Extracted elements (27)
DNSSEC offline signing is not applicable to the Discovery Proxy because the content of delegated zones is dynamically generated from Multicast DNS responses at query time. The Discovery Proxy must possess zone signing keys and perform online signing.
Link-local multicast was a conscious design choice for Multicast DNS because multicast traffic is more expensive than unicast (impacts many devices), and on Wi-Fi is less efficient and unreliable due to lower data rates and lack of acknowledgment. The Discovery Proxy avoids forwarding multicast across links by acting as a proxy that issues local queries on behalf of remote clients.
Protocol designers are advised to avoid placing link-local names or link-local IP addresses in TXT record key values when translation would be required for off-link operation. Instead, host names should appear only in well-defined places (owner names, SRV target fields) where the Discovery Proxy expects to find and translate them.
The Discovery Proxy uses a 'pull' model rather than a 'push' model. Multicast DNS devices remain silent until queried, making it impractical to discover all names by passive listening; a push-based proxy would need to query every possible name and would generate continuous network load even when no clients are interested.
The ten-second TTL cap is chosen based on user-experience: a device that is powered on should become discoverable within approximately ten seconds, and negative cache entries should expire quickly enough that newly available devices are usable without excessive delay.
A Discovery Proxy performs no translation between Punycode encoding and UTF-8 encoding, in either owner names or RDATA. All bytes are treated as-is. DNS-SD clients use UTF-8 for unicast queries, which the proxy passes through without modification.
Because a Discovery Proxy cannot enumerate all existing names, it synthesizes per-name NSEC records asserting nonexistence of only the specific name queried. This makes NSEC3 unnecessary (no zone walking risk) but means traditional broad-range NSEC/NSEC3 denial-of-existence records cannot be generated.
A Discovery Proxy MUST NOT be restricted to support only a letter-digit-hyphen subdomain, because that results in an unnecessarily poor user experience for service instance names that require rich text.
A Discovery Proxy SHOULD offer a configurable option, enabled by default, to suppress Unicast DNS answers for records not useful outside the local link, including IPv4/IPv6 link-local addresses, private addresses when the client is in a different address realm, and IPv6 Unique Local Addresses.
A Discovery Proxy SHOULD support having two separate subdomains delegated to it for each link: one allowing arbitrary Net-Unicode text for service instance names, and a second restricted to letters, digits, and hyphens for host name (A and AAAA) records.
Clients supporting unicast DNS-based Service Discovery SHOULD implement DNS Push Notifications (RFC 8765) for improved user experience over standard DNS queries.
For a standard DNS query with no cache entry, if after six seconds no relevant Multicast DNS answers have been received, the Discovery Proxy MUST cancel the mDNS query and return a negative response. DNS TTLs in responses MUST be capped to at most ten seconds.
For any query for the zone apex name, the Discovery Proxy MUST generate appropriate immediate answers; for any query below the zone apex for RRTYPEs SOA, NS, or DS, the Discovery Proxy MUST generate an immediate negative answer, since the mDNS spec prohibits delegation (subdomains) within '.local'.
For queries using LLQ or DNS Push Notifications, the Multicast DNS record's TTL SHOULD be returned unmodified, because the notification channel exists to inform the remote client as records come and go.
For traditional Unicast DNS queries (not using LLQ or DNS Push Notifications), DNS TTLs in responses MUST be capped to at most ten seconds. This is because remote clients cannot participate in Multicast DNS cache coherency mechanisms.
If a Discovery Proxy implements DNS Push Notifications (RFC 8765), it MUST positively respond to '_dns-push-tls._tcp.<zone>' SRV queries; otherwise it MUST return an immediate negative answer. It MUST also return immediate negative answers for DNS Update SRV queries since DNS Update cannot modify dynamically generated zones.
It is RECOMMENDED that a Discovery Proxy be configured with a single domain name for both the IPv4 and IPv6 '.local.' zones on the local link, issuing both IPv4 and IPv6 mDNS queries when a unicast query is received and combining the results.
Multicast DNS NSEC records received on the local link MUST NOT be forwarded unmodified to a unicast querier, because mDNS NSEC records do not have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do.
The DNS subdomain for host name records SHOULD be limited to letters, digits, and hyphens to facilitate convenient use of host names in command-line interfaces.
The SOA SERIAL field MUST be zero for Discovery Proxy zones. The MINIMUM field (negative cache TTL) SHOULD be 10. MNAME SHOULD be the Discovery Proxy's host name, RNAME SHOULD be the responsible mailbox.
The target host name in the RDATA of an NS record MUST NOT reference a name that falls within any zone delegated to a Discovery Proxy, to avoid inadvertent conflict with Multicast DNS host names owned by devices on the local link.
Records made visible via the Discovery Proxy are queryable from anywhere in the world, potentially leaking device presence and location (e.g., a mobile device appearing/disappearing in 'My House.example.com'). The IPv4/IPv6 reverse zones are especially sensitive, allowing attackers to enumerate hosts and infer network activity.
A Discovery Proxy is configured as authoritative for four or more DNS subdomains: one for DNS-SD service discovery records (rich-text UTF-8), one for LDH host name records, one or more for IPv4 reverse mapping (in-addr.arpa), and one or more for IPv6 reverse mapping (ip6.arpa). Authority is delegated via NS records from the parent domain.
Data translation rules map between the Unicast DNS delegated subdomain and the Multicast DNS '.local' namespace. Owner names and RDATA names ending in '.local' are translated: host names (targets of A/AAAA records) go to the LDH subdomain; all other names go to the rich-text subdomain.
A Discovery Proxy proves service presence only by the ability to answer link-local multicast queries on a link, providing no strong authentication. If stronger security is required, authenticated secure DNS Update (RFC 2136, RFC 3007) should be used instead.
A remote attacker can issue rapid unique unicast queries to force the Discovery Proxy to generate a high rate of Multicast DNS queries on local links. To mitigate this, the Discovery Proxy MUST implement mDNS query rate limiting; a limit of 20 mDNS query packets per second is RECOMMENDED for 802.11b/g/n/ac Wi-Fi links.
Answer aggregation has five cases based on query type (standard DNS, LLQ, Push Notification) and cache state (answer present or absent). Standard DNS with no cache: issue mDNS query, wait up to 6 seconds, return first answer or negative; standard DNS with cache: return immediately; LLQ: return cached immediately then keep subscription active; Push Notification: acknowledge immediately, send cached answers, keep subscription active indefinitely.