Re: [dnssd] Strategy of advertising proxy for hostname conflicts during key lease period? (draft-ietf-dnssd-advertising-proxy-00)

[Esko Dijk <[e-mail]>]

One other thing that may be worth mentioning is that while we discussed the scenario that a client lets its service lease expire (and what happens next with queries); there’s also the case where an SRP client explicitly removes a  service.
Such action as described in SRP section 2.2.5.5.2. The key-lease is kept active then for the hostname record. But, the KEY record for the service instance name is deleted by this action -- so won’t be visible any longer in subsequent queries (e.g. for KEY or ANY records for service instance name).

> This might be a bit puzzling because we do see certain IoT frameworks using a different label for the service instance name than for the hostname.
> But this is not the usual behavior, and TBH I think it's a mistake. Not sure there's anything to be done about it. But normally this is what you'd expect to see:

Thanks, this clarifies a lot! I have seen different naming conventions for mDNS; e.g. an IoT stack that encourages API users to set a friendly name as the service instance name but also to select it different from the hostname.
Any my home router that uses “Router Admin Webif” as the instance name which seems unrelated to the hostname that it uses.  And  a smartphone that uses the same user-selected name for host & service-instance.
Appendix C/D of RFC 6763 would encourage a device maker to use a default service instance name say “BrandX Temperature Sensor” but it doesn’t say that this name needs to change as well when only a hostname conflict is detected. It rather says the opposite; to keep the name simple and clean and only once a conflict is detected you can start adding a prefix like “(2)”.

So we cannot 100% rely on a device keeping a strict relation of hostname with service instance name, in case a mDNS device would detect a conflict on the hostname -- but not a conflict on the service instance name.

> In the case of the IoT frameworks that use a different label for the service instance name, we're pretty much relying on collisions being very unlikely. I think this is a safe bet—the service instance name has something like 64
> or 128 bits of randomness (I'm not sure off the top of my head) and is required to be unique on generation, so the chances that the same label would show up on the same network in mDNS for a different service are vanishingly small.

So the issue is effectively not present in the following cases

  1.  mDNS devices where host/service names are kept aligned  (and can be user-configured)
  2.  particular IoT framework devices that include randomness in service/host names ( names aren’t supposed to be used for User Interfaces directly – and there may be many of these devices in a home)

And the only remaining category where it might be an issue is “other”. And for this category the worst that might happen is a temporary co-existence of the same service instance name, which is allowed anyhow by mDNS, followed by a service rename.
The rename case happens when the conflict is detected later on when the original device that had the expired service-lease, registers again via SRP. That SRP Update would then fail due to the AP doing the probe and finding the service name already in use.
The SRP client would then pick a new service name.   All in all this looks like an issue we can ignore for AP for now . (Though it could be mentioned somewhere in the draft.)

Best regards
Esko


From: Ted Lemon <[e-mail]>
Sent: Sunday, June 19, 2022 15:28
To: Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: Re: [dnssd] Strategy of advertising proxy for hostname conflicts during key lease period? (draft-ietf-dnssd-advertising-proxy-00)

On Sun, Jun 19, 2022 at 6:04 AM Esko Dijk <[e-mail]<mailto:[e-mail]>> wrote:
Thanks , I updated my lists based on your response – shown below.  There’s separate Options 1/2 now for the case that the Advertising Proxy (AP) does propagate KEY records for services, and for the case the AP doesn’t do this for services but only for Hosts. (Which you indicated would be sufficient and simpler to implement.)
Option 1) Incoming mDNS query , assuming that KEY records are also propagated via the Advertising Proxy:

  *   QTYPE = PTR , QNAME=<service type name> : No response
  *   QTYPE = SRV, QNAME=<service instance name> : Response with success (NoError) status and 0 answer records
  *   QTYPE = ANY, QNAME=<service instance name> : Respond with KEY record for <service instance name>
  *   QTYPE = KEY, QNAME=<service instance name> : Respond with KEY record for <service instance name>
  *   QTYPE = AAAA, QNAME=<host name>.local : Response with success (NoError) status and 0 answer records
  *   QTYPE = ANY, QNAME=<host name>.local : Respond with KEY record for <host name>.local
  *   QTYPE = KEY, QNAME=<host name>.local : Respond with KEY record for <host name>.local
Option 2) Incoming mDNS query , assuming that KEY records for services are NOT propagated via the Advertising Proxy:

  *   QTYPE = PTR , QNAME=<service type name> : No response
  *   QTYPE = SRV, QNAME=<service instance name> : No response
  *   QTYPE = ANY, QNAME=<service instance name> : No response
  *   QTYPE = KEY, QNAME=<service instance name> : No response
  *   QTYPE = AAAA, QNAME=<host name>.local : Response with success (NoError) status and 0 answer records
  *   QTYPE = ANY, QNAME=<host name>.local : Respond with KEY record for <host name>.local
  *   QTYPE = KEY, QNAME=<host name>.local : Respond with KEY record for <host name>.local
Right.
Incoming unicast DNS query:

  *   QTYPE = PTR , QNAME=<service type name> : Respond NXDOMAIN  (since the pointers for the expired-lease services are removed)
  *   QTYPE = SRV, QNAME=<service instance name> : Response with success (NoError) status and 0 answer records
  *   QTYPE = ANY, QNAME=<service instance name> : Respond with KEY record for <service instance name>
  *   QTYPE = KEY, QNAME=<service instance name> : Respond with KEY record for <service instance name>
  *   QTYPE = AAAA, QNAME=<host name>.default.service.arpa : Response with success (NoError) status and 0 answer records
  *   QTYPE = ANY, QNAME=<host name>.default.service.arpa : Respond with KEY record for <host name>.default.service.arpa
  *   QTYPE = KEY, QNAME=<host name>.default.service.arpa : Respond with KEY record for <host name>.default.service.arpa


Also right.

> the instance name is nearly always going to be the same as the hostname plus the service type and transport type labels.

This part was unclear to me; do you have an example? I thought a mDNS device would typically register something like “My Service._exampletype._udp.local” without including any hostname within the service instance name.
And with Option 2 above this service instance name would not be “defended” for the duration of the key lease which looks like a problem for service consistency within a home. (E.g. a client may have initially selected a particular instance and wants to keep using that specific one even though the service may be ‘absent’ some of the time.)
This might be a bit puzzling because we do see certain IoT frameworks using a different label for the service instance name than for the hostname. But this is not the usual behavior, and TBH I think it's a mistake. Not sure there's anything to be done about it. But normally this is what you'd expect to see:

libretto._ssh._tcp.local.     SRV    IN     0 0 22 libretto.local.

Note that service instance name is libretto._ssh._tcp.local, and the hostname is libretto.local, so the initial label in both cases is the same. This is the behavior that most DNS-SD services exhibit. I'm slightly glossing over one difference, which this HomeKit accessory shows off:

Eve\032Energy\032A02E._hap._udp.local. SRV    IN     0 0 5683 Eve-Energy-A02E.local.

So here the service instance name label and the hostname label are different in that the hostname label has dashes instead of spaces. This is because the service instance name label is not a hostname, and we care more about how it looks to the user in a UI than that the labels are identical. But still the two names clearly map to one another: if the hostname were to change, we'd expect the service instance name to change as well. My laptop's name doesn't exhibit this behavior because there are no spaces in the name. If it were e.g. "Ted Lemon's Laptop" then we would see the same service instance name difference that we see for the HomeKit accessory.

In the case of the IoT frameworks that use a different label for the service instance name, we're pretty much relying on collisions being very unlikely. I think this is a safe bet—the service instance name has something like 64 or 128 bits of randomness (I'm not sure off the top of my head) and is required to be unique on generation, so the chances that the same label would show up on the same network in mDNS for a different service are vanishingly small.

If we really think that's too big a risk to take, I can look into how hard it is to use the KEY record to defend the name, but bearing in mind that I think we ultimately (and hopefully fairly soon!) want to move in the direction of using mostly unicast discovery, it's worth considering how much effort would be worthwhile in pursuit of this goal.