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

[Ted Lemon <[e-mail]>]

On Sun, Jun 19, 2022 at 6:04 AM Esko Dijk <[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.)
>
> <https://www.ietf.org/mailman/listinfo/dnssd>
>
> 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.