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

[Esko Dijk <[e-mail]>]

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

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

Esko

From: Ted Lemon <[e-mail]>
Sent: Saturday, June 18, 2022 02:56
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)

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Esko Dijk
Sent: Thursday, June 9, 2022 12:14
To: Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, June 8, 2022 20:45
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>    |   [phone]

_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd