Summary

  • On 3 September 2026, the IESG opened community review of a proposed DNSSD recharter, with comments due 13 September. The IESG explicitly said it had made no determination. The proposed programme includes publishing SRP-registered names through mDNS and resolving competing updates for one name.
  • Its nearest milestone is a November working-group last call for the active draft-ietf-dnssd-tsr-03. TSR can tell redundant proxies that an older advertisement is stale rather than authoritative. It cannot authenticate the requester, make mDNS private or prove that the discovered endpoint works.

The wrong service record can win without anyone stealing a name.

Imagine a device that registered a service through one Service Registration Protocol registrar. That registrar also acts as an advertising proxy, projecting the record onto a local Multicast DNS link. A partition, anycast change or simple failover sends the device’s next SRP Update to a second registrar. The new address is valid. The first proxy is still advertising the old one.

Classic mDNS sees two incompatible claims under one owner name. Its instinct is reasonable: protect the service that was already there. A late claimant should not displace an established printer, display or application merely by speaking last. The normal conflict algorithm therefore tends to let the older advertisement win or forces the newcomer to rename.

But the proxies are not two independent owners. They are carrying different generations of data from the same requester. In that setting, first arrival is not continuity. It is staleness.

This is the concrete authority problem inside the proposed DNSSD recharter. The IESG notice opened review on 3 September and invited comments through 13 September. It said no determination had been made. The charter would extend the group’s work on DNS-Based Service Discovery and mDNS across single and multiple links, including publication of SRP names into mDNS and mechanisms for competing updates to the same name.

The status ladder matters. A proposed charter is not an approved charter. A milestone is not a completed working-group last call. draft-ietf-dnssd-tsr-03 is an active Standards Track Internet-Draft, not an RFC. Its request for an EDNS option does not mean IANA has allocated a final code. None of those institutional states proves implementation, deployment or successful discovery.

The technical lineage starts on one link. RFC 6762 defines Multicast DNS and its probing and conflict behaviour. RFC 6763 defines DNS-Based Service Discovery. Unlike the delegated DNS described by RFC 1034, mDNS has no single authority server for the local namespace. Conflict resolution therefore has to infer which advertisement should survive.

The architecture later acquired bridges. RFC 8766 describes a Discovery Proxy that makes mDNS-discovered services visible through unicast DNS. RFC 9665 defines SRP, in which a requester uses a key-protected update to register a service with a registrar. The current advertising-proxy draft goes the other direction: an SRP registrar can advertise registered data onto mDNS.

That bridge changes what an advertisement means. A self-advertising device can reasonably be treated as the source of its own statement. An advertising proxy is a messenger. The underlying requester remains the source of truth, while the proxy may retain an older copy after topology or registrar choice changes.

The TSR draft addresses exactly that inversion. Its revision 03 wire text proposes a Time Since Received EDNS option. There must be one option for each owner name represented. It identifies the covered record set, carries a checksum derived from the requester’s public key and encodes how long ago the data was received. A registrar converts that offset into a node-local absolute time for comparison.

The checksum separates sources; the time separates generations. When two proxies advertise data associated with the same requester key, a receiver can recognize that the newer update should not lose merely because the stale proxy spoke first. It can suppress redundant probes and answers, avoid a spurious rename and keep one proxy’s withdrawal from erasing data still valid through another.

The design also has explicit operational wrinkles. Redundant proxies may designate primary and secondary behaviour to reduce duplicate answers and goodbye announcements. A multihomed device can advertise directly on one interface while its SRP registration is projected by a proxy on another. Network latency has to be handled when comparing offsets. A reboot, clock discontinuity or lost source association can damage the inference unless the implementation records its basis.

This is why “newer wins” is still an inadequate executive summary. TSR does not create a global clock or a delegated naming authority. It transports evidence about relative freshness and source continuity within a particular conflict process. The key checksum is an association field, not a general certificate that the requester owns a business identity, is permitted to use the name or runs trustworthy software.

The draft’s security section is unusually useful on this point. A malicious host on the same link can still participate in conflict behaviour. Even without TSR, it can announce conflicting data and answer probes to cause denial of service. The document says protocols relying on mDNS must not assume the service is secure or private. Authentication, authorization and secrecy have to come from the application layer or from DNSSEC-based discovery where appropriate.

RFC 8882 adds the privacy warning: service-discovery traffic can reveal devices, services and user activity. Extending discovery across links enlarges the observation surface. A proxy that faithfully republishes the freshest record can still expose too much information to too many listeners. Freshness and privacy move on different axes.

RFC 6891 supplies the extensible EDNS container. That shared syntax makes the option interoperable if standardized; it does not attest to a particular cache, proxy or clock implementation. The minimum common format is valuable precisely because it lets independent systems compare evidence without pretending to settle every future deployment choice.

An auditable implementation therefore needs a receipt chain, not a green “resolved” badge. Preserve the requester identity and key, original SRP Update, registrar and advertising-proxy identity, owner name and complete RRset, receipt time and clock basis, checksum, TSR offset, probe traffic, competing record, conflict result, rename decision and every goodbye. Then record the answer a client actually received, the endpoint it contacted, connection result, application authentication and user-visible outcome.

Each receipt answers one question. An accepted SRP Update proves what one registrar accepted under its policy. It does not prove that all proxies withdrew the prior record. A winning TSR comparison selects a record generation; it does not prove endpoint reachability. A successful TCP or QUIC connection does not authenticate the service. Application authentication does not prove that stale caches have disappeared elsewhere.

Withdrawal needs the reverse chain. Stop the source update, remove the registrar state, observe proxy withdrawal, confirm that valid redundant copies are preserved where intended, inspect client answers after TTL and cache expiry, and test that the former endpoint no longer receives traffic. Declaring the name clean at the control plane while a remote link still serves the old record would repeat the same category error in reverse.

Heng Lu’s minimum-initial-specification principle fits this design. The shared protocol should carry only the coordination facts needed to distinguish copies. His reality-layers argument then prevents a timestamp from becoming identity and a DNS answer from becoming service truth. Running-code primacy keeps the final claim with observed behaviour, not the elegance of the option format.

DNSSD’s recharter review is therefore about more than making discovery scale. It is about correcting an authority assumption that changed when a local speaker became a proxy. The older record should not win merely because it survived longer. The newer record should not win merely because it is newer. A defensible decision joins requester continuity, bounded recency, local conflict policy, application trust and observed service behaviour without allowing any one layer to impersonate the rest.

Sources