Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option

1.1. Current Behavior

When a new service is to be advertised, the registrant (the entity requesting the registration) typically registers the service with a central mDNS registrar on the host on which it is running. This mDNS registrar may have an internal database of services already registered, and may detect a conflict with one of those services. This can be true whether the conflicting database entry is data for which the mDNS registrar is authoritative, or data it has received via mDNS and cached.¶

In the case of such a conflict, no network transaction is required: the mDNS registrar detects it locally. It addresses the conflict in one of two ways. The first alternative is that the mDNS registrar will report the conflict to the registrant as an error, which it must fix. Alternatively, if the registrant has indicated that the mDNS registrar should automatically choose a new name for it in case of conflict, the mDNS registrar does so automatically, without notifying the registrant.¶

Once any locally-detectable conflicts have been resolved, the mDNS registrar probes (see Section 8.1 of [RFC6762]) local network to see if any other host has already registered a service the conflicts with the proposed new service. If such a service is present on the network, the mDNS registrar follows the same process previously described, either reporting the error to the registrant or automatically choosing a new name.¶

The effect of this approach is that generally whichever registrant first registers a service under a particular name wins. If a registrant comes along later and registers the same service with conflicting information, the newcomer’s information is rejected.¶

1.2. Problem Statement

The current behavior works well for registrants registering on their own behalf. However, for example in the case of an SRP registrar, it works poorly: an SRP registrar acting as an advertising proxy publishes the contents of its DNS zone using mDNS. The sources of truth for this information are the SRP requesters, not the SRP registrar itself. The SRP registrar in this case acts as a proxy for the SRP requesters.¶

In the case of an advertising proxy publishing records originating from an SRP Update, what we want to see published is not the oldest information, but the newest. When the SRP requester is able to continue registering with the same SRP registrar, this works well: stale data is automatically removed and replaced with current data. However, if more than one SRP registrar is available, the SRP requester may wind up sending its SRP Updates to a different SRP registrar. This can happen as a result of a network partition, or in cases where the SRP registrar is advertised on a anycast address.¶

When the SRP requester registers with a different SRP registrar, the behavior we get with the current mDNS conflict resolution approach is that the SRP requester will be given a new name, and both the old (stale) advertisement (A) and the new (more recent) advertisement (A’) will be discoverable as separate services.¶

This creates a new burden on consumers of such services: they need to parse through the whole list of services of their type, using metadata from the TXT record in the service instance data, if possible, to determine that service A and service A’ are the same service. If no such information is present in the TXT record, the only way to determine that one of these two registrations is stale is to attempt to use the advertised service, which may no longer be reachable if, for example, the change that produced the conflict was an IP address change. When the SRP lease for the stale service expires, that service's advertisement will be removed, and the service will no longer be discoverable under the original name, even if the IP address hasn't changed.¶

This document proposes an enhancement to the current conflict resolution algorithm for mDNS, which allows an mDNS proxy to report the time at which it received the registration for DNS records it is newly advertising, and the source from which it was received. This is done using a new Time Since Received (TSR) EDNS(0) ([RFC6891]) option, of which there must be exactly one per name being advertised by the mDNS proxy.¶

1.3. Conventions, Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

absolute time

a node-local timestamp that is derived from a local monotonic clock. This clock is not required to be synchronized with any other clock, nor is it an absolute time in the sense of UTC. The clock may restart upon boot of the node but not during regular operation.¶

mDNS registrar

an mDNS [RFC6762] implementation on a host that accepts local requests for advertising/registering DNS records from one or more registrants. This could for example be an mDNS daemon process running in an operating system, accepting API calls from local processes to register or update DNS records for that process.¶

mDNS registrant

an entity or software process requesting a DNS name to be advertised by the (local) mDNS registrar.¶

mDNS proxy

a host that runs an mDNS registrar and at least one mDNS registrant acting as a proxy. That is, it needs to advertise mDNS records on behalf of one or more entities not located on the host itself. The advertising proxy [I-D.ietf-dnssd-advertising-proxy] is an example of an mDNS proxy.¶

SRP requester

a client that uses the Service Registration Protocol (SRP) [RFC9665] to send an SRP Update to an SRP registrar.¶

SRP registrar

a server that accepts SRP Updates sent by SRP requesters using the SRP [RFC9665]. DNS records registered via SRP to an SRP registrar may then be advertised by mDNS using an advertising proxy [I-D.ietf-dnssd-advertising-proxy] located on the same host. In that case, the SRP registrar process acts as an mDNS registrant towards its local mDNS registrar process.¶

TSR data

locally stored data, associated with a single DNS owner name, that keeps track of the absolute time when a set of resource records were last updated and includes a key checksum to identify the owner of these records.¶

TSR option

an EDNS0 Time Since Received (TSR) option as defined by this specification.¶

TSR time

the (node-local) absolute time indicated by a particular TSR data.¶

3.1. Validating requested local RR registrations that include a TSR option

When an mDNS registrant asks an mDNS registrar to register one or more records on an owner name, and provides TSR data for that name, the mDNS registrar first checks to see if there are any records either in cache or from other local registrations on that owner name. If no such data exists, the mDNS registrar puts the record(s) in this registration in the probing state.¶

When such data exists, the registrar MUST check to see if it has TSR data for that owner name. If it does not, or if there is TSR data on that name but the key checksum does not match, the registrar MUST treat this registration as a conflict and return an appropriate error to the registrant.¶

If such data exists and the key checksums match, there are three possibilities based on the known TSR time (from the existing data) and the proposed TSR time (from the TSR data in the registration request):¶

Known TSR time is more recent

In this case, the registrar MUST treat the new registration as stale, and return an indication to the registrant that its registration is stale. This indication must be distinct from the "appropriate error" indication of conflict that was defined above.¶

Both TSR times are the same

In this case, the new record is added to the local registration database and put in the probing state.¶

Proposed TSR time is more recent

In this case, all cached data on the owner name is discarded. The registrant for any existing locally-registered data is notified that the data they had previously registered is stale, and the stale data is removed from the local registration database. The new data is added and put in the probing state, and the TSR data is updated with the proposed TSR data.¶

It is in principle possible for two different mDNS registrants to ask the same mDNS registrar to publish different RRs on the same name, some of which are shared and some of which are unique (see Section 2 of [RFC6762]). If an mDNS registrant registers an RR on a name for which the registrar already has data, cached or authoritative, on the same name, whether of the same RR type or a different RR type, for which there is no TSR data, or for which the key checksum in the TSR data being registered does not match what is already known, the registrar MUST treat this as an immediate conflict, and MUST NOT probe.¶

As with any local mDNS registration, the mDNS registrar treats all of the records in the registration as tentative (that is, in the probing state) until they have been probed and no conflicting answers have been received.¶

3.2. Probing resource records on names for which TSR data has been proposed

Section 8.1 of [RFC6762] describes how an mDNS registrar probes to ensure that there is no conflicting data for records in the probing state. The behavior for records that are in the probing state with owner names to which no TSR data applies remains unchanged. When there is TSR data on a name for which records are being probed, the mDNS registar MUST include TSR options for each such name as described in Section 2. Handling of responses is described in Section 3.4.¶

3.3. Processing questions for which TSR data exists

When processing a question for which local TSR data is present, the mDNS registrar MUST first check to see if there is corresponding data in the mDNS message being processed. In this case, before constructing a response, the mDNS registrar MUST process the non-question records in the packet, since this could result in stale data being flushed. Processing is performed as described in Section 3.4.¶

Once all non-question records have been processed, the responder MUST respond to any questions that match locally-registered resource records for which a known answer is not present in the query. Responses are constructed as described in Section 2.¶

3.4. Processing messages containing TSR options

For each TSR option in an mDNS message, the mDNS registrar first determines the owner name of the TSR option by assigning an index to each non-question resource record in the mDNS message. The 'RR Index' value of each TSR option is then matched to the index of a resource record, and the owner name for that resource record is applied to the TSR option. The time on the TSR option is then computed by taking the current local clock time and subtracting from it the 'Time Offset' value in the TSR option.¶

If there is a TSR option in an mDNS message for which there is no matching resource record in the mDNS message, the mDNS registrar MUST ignore that TSR option. The mDNS registrar MUST NOT use the 'RR Index' value in the TSR option to search across the mDNS packet since such an index can easily be out of bounds.¶

Now, for each record in the mDNS message, the mDNS registrar first determines whether the record is an OPT record, is in the question section, or is a known answer (QD bit = 0 and it's a record in the answer section). For all such records, no special processing is done for TSRs, since no TSR should exist in the mDNS message.¶

For each remaining resource record in the mDNS message, the mDNS registrar MUST check to see if there is a TSR option in the mDNS message for that owner name. If there is not, the mDNS registrar MUST check to see if there is TSR data with that owner name locally. If there is not, the record is processed normally.¶

If there is local TSR data for the record's owner name, the mDNS registrar checks to see if there are any resource records in the local registration database (that is, not just in the cache) on that name. If there are, the record is treated as a conflict. This conflict exists even if the locally registered records are all shared records. In cases where there are records on the name in the cache, those records are all discarded, because they are in conflict with the new data.¶

In the case that there is TSR data for the record in the mDNS packet, and no local TSR data, this always means that any data is in conflict. How that conflict is addressed depends on the data. First, note that resource records in the answer section of an mDNS Query (QR bit in the header is 0) are "known answers" and therefore are not relevant when adding data to the mDNSResponder cache. Such records can never have TSR options associated with them. However, resource records in the authority and additional sections of a query do need to be processed (but in the case of authority records, are not added to the cache).¶

In cases where the TSR data for a particular name is present both locally and in the mDNS message, the mDNS responder MUST compare the key checksums. If they are different, then the records are always in conflict, and are handled according to the context of the conflict, as described in Section 9 of [RFC6762].¶

In cases where the key checksums match, the mDNS registrar MUST compare the times. When the TSR time from the mDNS Message is more recent than the local TSR time, local data in the cache is flushed and registered data is removed and reported to the registrant that registered it as stale.¶

When the TSR times are the same, any resource records on that name in the answer section and additional section are added to the cache.¶

When the local TSR time is more recent, the data in the message is not added to the cache, and no action is taken with respect to any locally-registered data.¶

3.5. Suppression of Goodbye announcements

When authoritative data is removed on an mDNS registrar because an mDNS message has been received with more recent data, the mDNS registrar MUST NOT send a "goodbye" announcement for any RR on that owner name as a result of flushing this stale data.¶

The reason for this is that in the case where an mDNS registrant updates one or more RRsets on an owner name covered by TSR data, and as a result of this some records are removed, but some remain, the mDNS registrar that was directly updated will either send "goodbye" announcement or an announcement with the cache flush bit set as specified in Section 8.4 of [RFC6762]. Since the mDNS registrar with the most current information has already done what is needed, if an mDNS registrar that is flushing locally-registered data were to send a "goodbye" announcement this would at best be redundant and hence wasteful use of multicast, and at worse might cause valid data to be flushed from the cache on some mDNS registrar.¶

3.6. Suppression of redundant probing

When mDNS proxies are doing any form of replication of the data they are publishing, it can be the case that one proxy does its probes first. If this is the case, proxies on the same multicast link that receive replicated data will already have the correct data in cache with matching TSR times. To avoid redundant probing, when an mDNS registrant registers data with an mDNS registrar for which the same data is already cached with the same TSR key checksum and a recent TSR time, the mDNS registrar MUST skip probing. Recent here should take into account network delays: a difference of less than ten seconds between the cached TSR time and the registrant's TSR time should be considered "recent."¶

In addition, when the TSR time for a set of RRs is updated by the mDNS registrant, but nothing else changes, the mDNS registrar MUST NOT re-probe those RRs. In this situation, if some RRs are removed, then a goodbye announcement should be sent for such RRs, but no probe announcement is set for RRs that are not removed. If some RRs are added, the probing stage can be skipped because we already know that we were up to date. So the new RRs can simply be announced immediately. We can assume that updates do not happen frequently enough for there to be competing mDNS updates being probed or announced at the same time.¶

3.7. Constructing a mDNS message with TSR options

For each non-question record that is added to the mDNS message, one of three things must be true:¶

• The mDNS server is has resource records locally registered on that owner name, which may or may not be in the probing state.¶

• It is sending an answer which is either an announcement or a response containing data it has already validated and for which it is authoritative¶

• The message is a query (QD=0) and the record is in the answer section, and is therefore a "known answer."¶

As described in Section 7.1 of [RFC6762], an mDNS registrar asking a question about one or more RRs on a particular name populates the answer section of its mDNS message with the answers it already knows, to avoid unnecessary responses. However, in this case it can't also be probing for records on the same name, because probes are only done for unique (non-shared) records.¶

The requirements in Section 3.1 mean that there can never be an mDNS probe that contains known answers on an owner name for which any RR is being probed to which a TSR option applies.¶

This means that for any particular owner name that might be represented in an mDNS packet, it must be the case either that it is not a known answer, or that it is a known answer and no other records exist in the mDNS packet with the same owner name to which a TSR option would apply. That is, one of two things must be true about the set of all records with a particular owner name being added to the mDNS packet: either a TSR option applies to all of the records, or it applies to none of the records. Furthermore, either a record is a known answer from cache, or it is a locally-registered record.¶

When constructing an mDNS message, the mDNS registrar maintains a set of names and associated TSR data. Initially this set is empty. When the registrar adds a record to the mDNS message, if that record is locally registered, and if the registrar has TSR data for that name, it first checks to see if it has already added TSR data for that name to the set. If not, then it adds a new entry to the set containing the TSR data for the owner name of the RR. The data added consists of the owner name, the index of the record being added (since it is the first), the key checksum, and the time offset.¶

Once the mDNS responder has finished adding resource records to the mDNS message, it adds an OPT record in the additional section. In this OPT record it adds a TSR option for every name in the set that was generated when adding resource records to the message. The time of receipt is subtracted from the current time to produce the value for the 'Time Offset' field, and this value is clamped to a maximum of seven days (604,800 seconds) Section 2.¶

9.1. Removing data that is still valid

In some cases, a proxy may need to stop being a proxy, but may be proxying RRs that is also being proxied by one or more other proxies. In this case, if the proxy sends a "goodbye" announcement for such RRs, they will be removed from the caches of mDNS registrars that receive such announcements.¶

To prevent this, mDNS registrant implementations that implement TSR MUST provide a way for an mDNS registrant to indicate that such data is being withdrawn from publication by that registrant, but is still valid. When the registrant indicates that this is the case, the mDNS registrar MUST NOT send goodbye announcements for such data.¶

9.2. Primary/Secondary indication

When more than one proxy is authoritative for a particular RR, this can generate excessive answer traffic, and also redundant goodbye announcements. mDNS registrar implementations that support TSR MUST provide a way for proxies to indicate that they are primary or secondary. When an RR registered by a secondary proxy is later removed, the mDNS registrant MUST NOT send a goodbye packet for that RR.¶

Similarly, when an RR is registered by a registrant that indicates that it is secondary, the mDNS registrant MUST NOT respond to the initial mDNS query for that RR. Only if a second mDNS query is received should it respond.¶

12.1. Normative References

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6762]

Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/rfc/rfc6762>.

[RFC6891]

Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/rfc/rfc6891>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9665]

Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, June 2025, <https://www.rfc-editor.org/rfc/rfc9665>.

12.2. Informative References

[I-D.ietf-dnssd-advertising-proxy]

Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD Service Registration Protocol", Work in Progress, Internet-Draft, draft-ietf-dnssd-advertising-proxy-04, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-advertising-proxy-04>.

[I-D.ietf-dnssd-srp-replication]

Lemon, T., Keshavarzian, A., and J. Hui, "Automatic Replication of DNS-SD Service Registration Protocol Zones", Work in Progress, Internet-Draft, draft-ietf-dnssd-srp-replication-02, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-replication-02>.