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

[Ted Lemon <[e-mail]>]

Sorry for not responding quickly to this. You're asking about fairly deep
technical details of the mDNS protocol, and I am not actually an expert, so
I can't say that your understanding is correct or not.

I will try to get Stuart to weigh in on this.

On Thu, Jun 16, 2022 at 9:03 AM Esko Dijk <[e-mail]>
wrote:

> FYI - I’m now assuming the following behavior of an advertising proxy, for
> an incoming mDNS query. This is for the case  there’s only a single
> registered (SRP) service that is expired; and host lease is also expired at
> the same time. And the host’s key-lease is still active:
>
>
>
>    - QTYPE = PTR , QNAME=<service instance name or service type name> :
>    No response
>    - QTYPE = SRV, QNAME=<service instance name or service type name> : No
>    response
>    - QTYPE = ANY, QNAME=<service instance name or service type name> : No
>    response
>    - QTYPE = AAAA, QNAME=<host name> : Response with success (NoError)
>    status and 0 answer records
>    - QTYPE = ANY, QNAME=<host name> : Respond with KEY record for <host
>    name>.local
>    - QTYPE = KEY, QNAME=<host name> : Respond with KEY record for <host
>    name>.local
>
>
>
>
>
> Same case but when using the authoritative DNS server on the same host,
> for an incoming unicast DNS query:
>
>
>
>    - QTYPE = PTR , QNAME=<service instance name or service type name> :
>    Respond NXDOMAIN
>    - QTYPE = SRV, QNAME=<service instance name or service type name> :
>    Respond NXDOMAIN
>    - QTYPE = ANY, QNAME=<service instance name or service type name> :
>    Respond NXDOMAIN
>    - QTYPE = AAAA, QNAME=<host name> : Response with success (NoError)
>    status and 0 answer records
>    - QTYPE = ANY, QNAME=<host name> : Respond with KEY record for <host
>    name>.default.service.arpa
>    - QTYPE = KEY, QNAME=<host name> : Respond with KEY record for <host
>    name>.default.service.arpa
>
>
>
> Esko
>
>
>
> *From:* dnssd <[e-mail]> *On Behalf Of * Esko Dijk
> *Sent:* Thursday, June 9, 2022 12:14
> *To:* Ted Lemon <[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)
>
>
>
> That sounds like a good approach. So a potential competitor would first
> send a probe-query for the hostname with rrtype “ANY”; and then the
> advertising proxy would respond with its answer including the hostname and
> an rrtype “KEY’ record  - is that correct?
>
>
>
> Does this also mean the SRP server will answer DNS unicast queries for
> this hostname and e.g. rrtype ANY, with the KEY record? While the key lease
> is still valid.
>
>
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Wednesday, June 8, 2022 20:45
> *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)
>
>
>
> You are correct. Fortunately, we always have a KEY record that we can
> publish on the owner name. This is what the advertising proxy should do to
> defend the name. If some non-SRP service tries to register the name, it
> will get a hostname conflict.
>
>
>
> On Wed, Jun 8, 2022 at 9:36 AM Esko Dijk <[e-mail]>
> wrote:
>
> Hi all,
>
>
>
> Something that could be added to draft-ietf-dnssd-advertising-proxy-00 is
> the handling of hostname conflicts; and how an advertising proxy would
> “defend” an SRP registration on the mDNS link side. (There was a previous
> thread on this too.)
>
>
>
> In particular, what if a host registration has already expired but the
> key-lease is still active? In SRP, then no-one else can claim this
> hostname. But in mDNS, we don’t seem to have such mechanism i.e. the
> advertising proxy doesn’t “defend” the hostname registration on the mDNS
> link. Or does it?
>
> So it could happen that this hostname is claimed on the mDNS side by an
> mDNS native device, even though a particular SRP client still has the
> key-lease on this name.
>
>
>
> The original name owner (SRP client) could later come back online and it
> may need to claim the name again – conflicting with the mDNS link.
>
>
>
> Best regards
>
> Esko
>
>
>
> *IoTconsultancy.nl*  |  Email/Teams: [e-mail]    |
> [phone]
>
>
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>