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 locally stores services that have already been registered, and may detect a conflict with one of those registered services. This can be true whether the conflicting service entry is data for which the mDNS registrar is authoritative (stored in its local registration database), or an entry it has received via mDNS (stored in its cache).¶

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 the service in case of conflict, the mDNS registrar does so automatically, without necessarily notifying the registrant.¶

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

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

1.2. Problem Statement

The current behavior works well for registrants registering services 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, the most recent information is correct; the older information is simply stale, and not competing. 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 event, or in cases where the SRP registrar is contacted using an anycast address.¶

When the SRP requester sends its SRP Update to a different SRP registrar, the behavior of the mDNS conflict resolution approach without TSR is that the SRP requester's service will be given a new name, and both the old (stale) service advertisement (A) and the new (more recent) service 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 advertised services 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 mDNS advertisement will be removed, and the service will no longer be discoverable under the original name, even if its 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 advertising, and the source from which these records were 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.¶

authoritative data

DNS records stored in the local registration database, for which an mDNS registrar is authoritative (as defined by [RFC6762]).¶

cache

each mDNS registrar maintains a cache of DNS records received from hosts on the local network, as described in [RFC6762]. Information in the cache represents the mDNS registrar's current understanding of what records are advertised on the network. Authoritative data may be present in the cache, but the presence of data in the cache does not in itself indicate that the mDNS registrar is authoritative for that data.¶

local registration database

a database of DNS records maintained by the mDNS registrar. Records in this database are registered locally with the mDNS registrar. The mDNS registrar is authoritative for all DNS records in this database. When the mDNS registrar receives queries that match records in this database, the mDNS registrar can respond to these queries with the matching records.¶

mDNS registrar

an mDNS [RFC6762] implementation on a host that accepts local requests for querying, advertising and registering DNS records from one or more requesters and/or 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. It stores the locally-registered records in its local registration database.¶

mDNS registrant

an entity or software process that is attempting to register records for advertisement to a (local) mDNS registrar.¶

mDNS requester

an entity or software process that issues mDNS queries to a local mDNS registrar, via an API call. The mDNS registrar is responsible for executing these queries and notifying the mDNS requester about the answer(s).¶

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 a local 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 that none of the records are marked shared. If any record is marked shared, the mDNS registrar MUST respond with an error indicating that the registration is invalid.¶

It then checks to see if there are any records either in cache or in its local registration database on that owner name. If no such data exists, the mDNS registrar stores the record(s) in this registration in its local registration database and puts them 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 requested data 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, cached data (if any) on the owner name is discarded first. Then, the requested records are added to the local registration database, updating existing records (if any). Since the requested records are considered identical to the known records, based on TSR time, no probing or announcing is performed for these records.¶

Proposed TSR time is more recent

In this case, cached data (if any) on the owner name is discarded first. 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 requested records are added to the local registration database and put in the probing state, and the TSR data is replaced by 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 tries to register 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 add the data to its local registration database and MUST NOT probe.¶

For the third case, as with any local mDNS registration, the mDNS registrar treats all of the records in the registration request as tentative (that is, they are put in the probing state) until they have been probed and no conflicting answers from other mDNS hosts 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.5.¶

3.3. Processing mDNS 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.5.¶

Once all non-question records have been processed, the registrar 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. Receiving mDNS messages that may contain TSR options

mDNS registrars that support TSR need to compute an absolute time based on a time offset. This means that registrars need to know when the packet was received. A naive implementation might assume that the time that the packet is read off the input queue by the registrar is close enough. However, in practice it can be the case on a heavily loaded system that the time of receipt and the time of processing are far enough apart to create the appearance of staleness.¶

To avoid this, mDNS registrars that have an API available to get the actual time of receipt of a packet should make use of that API. For example, the SO_TIMESTAMP_CONTINUOUS socket option is available on Linux and BSD Unix platforms, including MacOS. When such APIs are not available, another option is to receive such packets on a high priority thread and queue them for later processing.¶

3.5. Processing mDNS messages thay may contain TSR options

mDNS registrars that support the TSR option MUST check incoming messages for the presence of an EDNS(0) option containing TSR options. mDNS registrars that do not support TSR will not do this check, and will behave as if no TSR options are present. For non-proxy use cases, this should make no difference, since in such cases if multiple devices advertise records on the same owner name, these are actually in conflict. However, for the proxy use case, what this means is that two proxies that are proxying the same data cannot interoperate if one supports TSR and the other doesn't.¶

It is important to note that mDNS messages, particularly in the case of proxies, can contain combined information answering multiple queries that may be outstanding, and as such, it's entirely possible for a mDNS message sent by an mDNS registrar that supports TSR to contain some answers for which there is TSR data, and some answers for which there is not. It's equally possible that such a registrar will send mDNS packets containing no TSR options at all.¶

When an mDNS message contains 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' 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, but no TSR data for that owner name in the mDNS message, the mDNS registrar checks to see if there are any resource records in the local registration database on that name. If there are, all such records are treated as in 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 message, and there are local records on the same owner name for which there is 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 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 registrar MUST compare the key checksums. If these 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, the local data in the cache is flushed. Stale data in the local registration database is removed, and the mDNS registrant is informed that this data is 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.6. Duplicate answer suppression behavior

Section 7.4 of [RFC6762], Duplicate Answer Suppression, describes behavior intended to prevent the redundant transmission of duplicate answers. When an mDNS query is received for which the mDNS registrar has authoritative data, the mDNS registrar will wait for a random amount of time before sending a response. If, during that time, a response is received that contains all the answers it would have sent, it suppresses sending these answers, since they are redundant. Such a response is referred to as a "pre-empting response".¶

In the case where TSR data is present locally or in a pre-empting response, it can be the case that the data in a pre-empting response is stale or conflicting. For this reason, an mDNS registrar MUST NOT suppress duplicate answers when:¶

• the TSR key checksum for the owner name in a pre-empting response does not match the local TSR key checksum for that owner name¶

• TSR data is present locally for that owner name but is not present in the pre-empting response¶

• A TSR option is present for that owner name in the pre-empting response, but local authoritative data for that owner name is present but has no associated TSR data¶

• local authoritative data for that owner name is present and includes TSR data, a TSR option for that owner name is present in the pre-empting response, but the local TSR time for that owner name is more recent than the TSR time for that owner name in the pre-empting response¶

Appendix A shows what this might look like from the perspective of an mDNS requester.¶

3.7. 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.8. Suppression of redundant probing

When mDNS proxies are doing any form of replication of the records they are publishing, it can be the case that one proxy sends its probes for a new set of records first. If this is the case, some or all proxies on the same multicast link that receive the replicated data may already have (at the time of probing) the correct data in their local registration database with matching TSR times, waiting to be probed.¶

In such case, these proxies will determine that the records in the received probe message are identical to the locally-registered set of records, and therefore per Section 8.2.1 of [RFC6762] no conflict is detected and no response to the probe will be sent. An mDNS registrar that receives a probe, for a new set of records that it has just placed in the probing state, MUST suppress sending its own probe messages as this would be redundant: the probing is already being performed on the link.¶

[TBD for WG: for the above, the response to a probe in case of a true conflict (by another mDNS host) will typically be 'fast' with unicast as per RFC 6762. For this reason, the suppression of probing would be dangerous in the above case, as most of the proxies that suppress their probing would not see the actual conflict (if any). Unless the replication algorithm takes care of withdrawing the records on all proxies.]¶

Conversely, it can also be the case that one proxy already sent its mDNS probes and announced the new records before some other proxy on the same multicast link fully completed the replication process for these records. In that case, the announced records will be stored already in the cache of this other proxy at the time that its local mDNS registrant (i.e. the replicating proxy process) performs the registration of these records and the associated probing.¶

To avoid redundant probing for such cases, 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 an equal TSR time, the mDNS registrar MUST skip probing. This requirement follows the second case ("Both TSR times are the same") in Section 3.1.¶

[TBD for WG: the below 'recent' rule text instead of 'equal' as used in above sentence seems to conflict the section 'locval' Section 3.1 3 cases. Only when TSR time is equal, will the probing be suppressed.¶

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 an 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 is sent for RRs that are not removed. If some RRs are added, the probing stage can be skipped because the registrar already knows it is up to date. So the new RRs can simply be announced immediately. One 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.9. 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 registrar has locally-registered resource record(s) 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 registrar 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.¶

8.1. Use of TSR with redundant proxies

Use of TSR is most beneficial in the case of redundant mDNS proxies. The reason for this is that such proxies tend to publish data that could potentially produce name conflicts as a result of updates: when one proxy is publishing an old version of the data and another proxy is publishing a new version of the data, and these data differ, this can appear as a name conflict and result in renaming. So for this use case, the use of TSR is very beneficial.¶

8.2. Use of TSR with multihomed devices

It can also happen that a multihomed device uses SRP to register when connected to one sort of network, and uses mDNS to advertise the same service when connected to another sort of network. For example, the device may have capabilities to connect to a constrained network to reduce power use, but also to occasionally connect to a WiFi network either for backup or for bulk data transfers. In this situation we have two potentially competing mDNS advertisements. The first is that of the mDNS registrar on the multihomed device, which is directly advertising its own service using mDNS. The second is the one or more advertising proxies that are advertising services registered via SRP using mDNS. Both datasets are coming from the same source, and the advertising proxy will use TSR to identify the source. To avoid spurious conflicts, a device that sometimes registers with SRP and sometimes advertises with mDNS SHOULD use TSR when advertising with mDNS.¶

8.3. TSR in networks with non-compliant mDNS caches

Some network infrastructure devices available commercially provide "mDNS cache" services or "mDNS proxy" services that purport to allow mDNS discovery across links that are separate at the IP layer and do not share a multicast domain. These services generally cause mDNS to become unreliable in various ways, and it would be helpful to be able to use TSR to distinguish between stale data advertised by such devices, and fresh data advertised directly from the device that is authoritative for that data.¶

Unfortunately, for the most part these devices do not cache mDNS packets, but rather cache data advertised using mDNS. As a result, if such devices do not support TSR, we get no benefit from TSR.¶

That said, such devices SHOULD support TSR, and if they do this might prevent some of their failure modes. What this would mean would be that any DNS RRs cached or forwarded by such devices would be accompanied by any TSR data applicable to them. When forwarded with no time delay, the TSR data could be copied verbatim (following the rules for generating packets with TSR given in Section 3.9).¶

When such RRs are cached and later resent, they would also be accompanied by their TSR data. The mDNS cache service would need to record the time at which they were received. When retransmitting such cached data, the cache service would need to adjust the time offset in the TSR option, increasing it by the subtracting the time at which the cached RRs were received from the current time, and then increasing the offset in the applicable TSR option by that amount, up to the limit of 7 days.¶

The use of such caches and forwarders is NOT RECOMMENDED. We mention the use of TSR for such use cases because it can mitigate some of the failure modes of such caches and forwarders. However, the use of Discovery Proxy [RFC8766] in such instances is preferred: as the size of the network covered by such caching and forwarding services increases, the amount of mDNS traffic they create increases, and this is often addressed by limiting which services are available for discovery. Discovery Proxy uses unicast DNS, and therefore does not suffer from these limitations.¶

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 are 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, an mDNS registrar implementation that implements 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 a new proxy mDNS registrant to indicate that it is 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 registrar MUST NOT respond to the initial mDNS query for that RR. Only if a second mDNS query retransmission is received within 5 seconds of the initial query reception, should it respond.¶

Note that any change of indication from primary to secondary, or vice versa, while an mDNS registrant already has records registered on the mDNS registrar is out of scope of this specification and an API to indicate such changes is not required on the mDNS registrar.¶

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>.

[RFC8766]

Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, <https://www.rfc-editor.org/rfc/rfc8766>.

[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>.