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

[Ted Lemon <[e-mail]>]

I wanted to check with Stuart before answering. RFC6762 is somewhat
ambiguous on this topic: Section 8.1 says:

It also allows a host to verify exclusive ownership of a name for all
> rrtypes, which is desirable in most cases.  It would be confusing, for
> example, if one host owned the "A" record for "myhost.local.", but a
> different host owned the "AAAA" record for that name.


However, section 9 says:

A conflict occurs when a Multicast DNS responder has a unique record for
> which it is currently authoritative, and it receives a Multicast DNS
> response message containing a record with the same name, rrtype and
> rrclass, but inconsistent rdata.


So as you said, when the probe goes out, it queries for ANY, and if it sees
a KEY record, even if its goal is to advertise an A record, it will take
that as "ownership of the name" and not advertise the A record on that
name. Simultaneous probe resolution will also do the right thing. On the
other hand, in theory at least,  if two servers have already decided to
advertise the same data, and later on one gets a response containing only a
KEY record on a name on which it is advertising an A record, it won't see a
conflict (late conflict detection) at least according to the RFC.

In practice, what I see with mDNSResponder is that it detects all of these
events as conflicts, even the late conflict. I think maybe an update to
RFC6762 is in order to clarify this—I think the spec ought to be clear on
this, and it doesn't make sense that only in the late conflict case do we
not care that two hosts are advertising different records on the same owner
name.

So, back to the use of the KEY record, I think that your description of the
behavior for address and KEY records is right. However, the KEY record is
actually supposed to be used to hold not only the hostname but also the
service instance name(s), so you would see a KEY record on the service
instance names in a unicast DNS key query. You would not see them in mDNS,
because it's hard to make that work, and not worth the effort, since in any
non-SRP use case that produces a conflict, which I think is what we'd be
concerned about, the instance name is nearly always going to be the same as
the hostname plus the service type and transport type labels.

On Thu, Jun 16, 2022 at 1:24 PM Ted Lemon <[e-mail]> wrote:

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