[dnssd] Re: mDNS conflict reporting in ULD

[Ted Lemon <[e-mail]>]

The current flow for mDNS is that the caller can say "just rename" or "tell me that it failed." I think it makes sense to preserve that capability. If the on-device library wants to be in charge of renaming, it would do pretty much as you suggest here. If it doesn't care, it could include instructions to the caller to that effect. But what I think you are really struggling with here is that we don't have a way to notify for late conflicts.

For late conflicts, we'd really like the server to be able to notify the client when the late conflict happens, not some time later. Conveniently, the ULD client should have a DSO connection to the ULD server for DNS Push, so we can actually take advantage of this for late notification: send the SRP update over the DSO connection rather than in a separate connection. When you send an SRP update, you get a timely response that says that it succeeded or failed. If it succeeded, but something goes wrong later, you get another response. We can add an EDNS(0) option that says "go ahead and rename on your own" to the ULD server, and in that case the response is actually the answer to a DNS query for the names that got conflicts. In the case of an immediate failure, if a rename happened, we do the same.

As for granularity in the conflict response, I'm struggling to find the value in this. In the matter case obviously we're just hosed, but it's probably a bug anyway. In the "user-comprehensible-name" case, we probably want to rename everything anyway. Consider the current situation with an Apple device that picks a human-comprehensible name like "Ted's Macbook Pro". In this case, the hostname is Teds-Macbook-Pro.local. So we have a service instance name that's semantically identical to the hostname, but expressed in a way that looks good in a UI. If we get a name conflict on the hostname but not the service instance name, we want the new names to match. So in practice we want to rename both. Consequently I don't really see the value in signaling which one got the conflict.

In your discussion here you've gone heavily into the solution space, but it's important to understand what problem you're trying to solve first. I may have missed that. Is there an actual problem that the granularity you're asking for solves, or is this rooted more in the sense that the solution is incomplete if the error signaling isn't this detailed?

> On 24 Sep 2026, at 04:12, Karsten Sperling <ksperling=[e-mail]> wrote:
> 
> Hello everyone,
> 
> One of the open questions for ULD that was briefly mentioned in the presentation at IETF 126 is reporting of mDNS conflicts. I would like to bring this to the list so the arguments can be laid out in more detail than a slide or two can easily cover.
> 
> Just to clarify terms, I’m taking “conflicts” here to mean two different devices / applications attempting to own the same unique (non-shared) name, i.e. generally a host name or service instance name. False conflicts resulting from stale or reflected data from the same device are expected to be handled via TSR. This discussion is purely about “true” conflicts.
> 
> Before going into details, I want to address the question of whether conflicts in mDNS even matter, can’t we just ignore them? This depends on the application. On one end of the spectrum are applications like Matter that use machine-generated names that are effectively guaranteed to be unique by construction, and if a conflict does occur, there is generally no good way to do anything about it. On the other end are applications where a human manually chooses a name for a device or service, maybe “stage-left-light”, and wants to then be able to type that name into a second machine to connect to it. In use cases like this, a conflict should surface as an error and/or any renaming should be visible to the user.
> 
> As outlined in the draft, ULD is intended to be a replacement for mDNS for .local registration and discovery on links and devices that support it, while remaining interoperable with mDNS. The intended adoption path is for DNS-SD libraries to be able to adopt it transparently where available. In general, applications should not need to know or care whether the service registrations and queries they perform are fulfilled by the DNS-SD implementation on the wire using unicast ULD or via mDNS. This means the affordances that DNS-SD libraries offer around conflict handling need to carry across, at least in broad strokes, from mDNS to ULD.
> 
> The specifics differ somewhat between libraries: Most offer the ability for the library to automatically handle renaming on conflict (mDNSResponder, Android, Windows), some also provide APIs that only signal a conflict and let the client application directly choose a new name to try (Avahi, mDNSResponder). However in all cases the client application is able to know the state of the registration, and the name(s) that it actually ended up with. In a scenario where a name is advertised on multiple links, renaming is generally done globally, not on a per-link basis, so that the name(s) that are ultimately held are consistent across links.
> 
> Being able to support these behaviors over ULD points very clearly to where renaming logic should live: This is a job for the DNS-SD library on the ULD client device. It is not something the AdProxy can do well autonomously, because it only deals with a registration targeting a single link, has no way to know how the client would like to choose candidate names, and no way to feed a new name back to the client. When a conflict occurs within the SRP zone, all of this is already solved: The ULD client gets a YXDOMAIN, and the library handles the necessary renaming. Handling mDNS conflicts in the same way keeps the renaming in one place, on the device that owns the name. The gap that exists in the protocol is simply a way for the ULD client to also know the mDNS state of the name(s) it is registering, i.e. whether they have been successfully registered, are still pending, or are in conflict.
> 
> This gap isn’t new, and some variations of dealing with it have been discussed before: Early AdProxy drafts coupled the SRP response to successfully probing on the mDNS side, and feeding back renaming outcomes via CNAMEs was discussed on this list in 2021. My proposal is deliberately not that: Keeping the outcome of the update independent from what happens on the mDNS side is an important property to preserve.
> 
> Given that the granularity of zone conflicts is a YXDOMAIN status covering the whole registration, my proposal is to define an “mDNS Status” EDNS(0) option carrying mDNS feedback at the same whole-registration granularity: An “Any mDNS record pending” bit, and an “Any mDNS record in conflict” bit, i.e. 1 byte payload. (The “pending” bit is necessary because “conflict = 0” would be ambiguous without it.) Support for this option is mandatory for a ULD server. Specifically:
> 
> The client indicates interest by passing an empty mDNS Status option in the request. This adds 4 bytes to the request size.
> If there is a conflict in the zone, the server responds with YXDOMAIN as normal; no mDNS Status option is returned in an error response.
> If the zone registration succeeds and the client requested the option, the server adds the mDNS Status option carrying the aggregate AdProxy pending / conflict status for all names in the registration. This adds 5 bytes to the response size.
> The server does not need to wait for the AdProxy to complete probing before responding to the SRP request.
> The AdProxy component of a ULD server MUST NOT perform automatic renaming. Renaming is a MAY in AdProxy-06, which is fine as far as the generic AdProxy functionality is concerned, but for ULD we should provide clients with predictable behavior: the name that they registered in the zone, or a conflict that can be reported.
> 
> In this proposal, the wire overhead is low in both directions, and the request handling done by the server doesn’t fundamentally change: on successful responses it simply returns 2 bits of extra information that are readily available from the AdProxy component. If SRP zone conflict reporting ever gets made more granular (e.g. via a bitmap indicating which particular names were in conflict), then the same pattern could also be applied to the mDNS Status option, but there is no point in having mDNS conflicts be reported at a finer granularity than zone conflicts, so this proposal represents the baseline of what’s needed for ULD.
> 
> A ULD client that cares about mDNS can read the current mDNS Status at any time by renewing its registration early, ahead of the normal lease refresh schedule. Immediately after an initial registration that means renewing after a short interval (e.g. 2 seconds), to learn whether the AdProxy has successfully acquired the requested names on its behalf. (RFC 9664 section 5.2.1 says a client SHOULD NOT refresh prior to 50% of the lease elapsing, but MAY do so if it needs to; I think we can say that this is such a case.)
> 
> The client SHOULD bound both the length of time it will wait for mDNS to settle, and how many times it renames in response to an mDNS-only conflict. After one or two renames with a randomized suffix, a client that is still seeing a conflict is most likely up against a misbehaving or malicious device on the link, and the right response is to stop chasing the name on mDNS and settle for holding it only in the SRP zone. This approach enables ULD clients to gracefully respond to honest mDNS conflicts in the way applications expect, without inheriting the mDNS failure mode where a device that won’t yield can deny a name outright.
> 
> A client that doesn’t care about mDNS conflicts, e.g. a Matter device using machine-generated names, doesn’t add the option, incurs no overhead on the wire, and its visibility on mDNS stays best-effort.
> 
> This proposal does not directly solve the open problem of “late” conflicts: the ULD server still has no way to inform the client if a previously-owned name has been lost. However, a client that wants to confirm it still holds its names on mDNS can renew early in the same way. Renewals that result in no change of registration state are cheap to process for the server, and infrastructure networks do not have the bandwidth constraints that would make this problematic on e.g. Thread.
> 
> In terms of where we would define the mDNS Status EDNS(0) option, the ULD document is probably the right place: The AdProxy draft and RFC 9665 (SRP) are each scoped specifically to their particular function, whereas ULD specifies how to tie them together. The semantics of the mDNS status bits also rest on the use of .local on both the SRP and mDNS sides combined with the prohibition of autonomous renaming by the AdProxy; taking the mDNS Status option out of this context would make its semantics far less clear. (I don’t see this as precluding it being re-used in a different context at a later time, if that need should arise.)
> 
> Please let me know if you have comments on any aspect of this proposal. Given that variations of this overall issue have been touched on multiple times before, I wanted to discuss this on the list before writing it into the ULD draft. I’d be particularly interested in whether people agree with the underlying premise that handling conflicts and renaming is the job of the client and its DNS-SD library rather than the server, since the rest of the proposal follows from that.
> 
> Thanks, Karsten
> 
> _______________________________________________
> dnssd mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]