Re: [dnssd] New Draft Submission: DNS-Based Multicast Stream Discovery

["Karstens, Nate" <[e-mail]>]

Ted & Tim,

Thanks for taking the time to look at this.

> It would be helpful to not describe this as an extension to DNS-SD, since it's not
Makes sense, I will change the description to be an “application of DNS-SD” instead of an “extension”.

> It would be better if the special-use domain were "mcast.arpa" or something like that rather than ".mcast," because that's easier for the IETF to arrange
Good to know! “mcast.arpa” seems fine to me. RFC 6762 also mentions mcast.net, and there appears to have been an effort at some point to move that into an mcast.arpa domain (see https://datatracker.ietf.org/doc/id/draft-ietf-mboned-mcast-arpa-03.html), but that doesn’t seem to have happened (see https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml).

> It would be good to talk about this use case: why ".mcast" specifically? Suppose I'm a big online video provider and I'm advertising a multicast stream. Wouldn't I just use a subdomain of my own domain?
This originally came out of a need to identify multicast services available on a local network. That being said, it may make sense to allow for some flexibility in the domain name. Organizations publishing these records in their own networks could use a subdomain, and devices offering multicast streams on the local network could use “mcast.arpa”. It might also be worth considering using .local directly, though there is a benefit to being able to easily recognize multicast streams by their hostname. Probably the main thing is to normalize the practice of using multicast addresses in A and AAAA records. I didn’t see this discussed much elsewhere, though it was mentioned in https://www.ietf.org/archive/id/draft-jabley-multicast-ptr-00.xml.

> It would help to say why [users will not use the "mcast." domain directly]
The thought was that users would be provided with a mechanism to select the chosen stream. In thinking about it again, there is no reason why users could not use it directly, so I will rework this section accordingly.

> Which applications? Does ssh need to recognize the domain?
On second thought, it is probably not necessary for applications to recognize the domain and reject its use. This would happen in the network stack if, for example, ssh attempted to contact a multicast address.

> How [do name resolution APIs and libraries resolve the "mcast." domain]? Can we use the local resolver?
Based on the change above to allow flexibility in the domain name, either the configured unicast DNS server can be used, or if the service is using “mcast.arpa” then mDNS.

> Why [should DNS server operators be aware of the "mcast." domain's use in resolving multicast services]? What should they do differently?
I think DNS server operators would want to handle that the same way they would handle the .local domain.

Cheers,

Nate

From: Tim Wicinski <[e-mail]>
Sent: Friday, February 24, 2023 01:49
To: Ted Lemon <[e-mail]>
Cc: Michael McBride <[e-mail]>; Karstens, Nate <[e-mail]>; [e-mail]
Subject: Re: [dnssd] New Draft Submission: DNS-Based Multicast Stream Discovery

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.





Michael

Agree with Ted on mcast.arpa.   This is a easier ask.

Also, take a look at https://www.rfc-editor.org/rfc/rfc8552.html<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8552.html__;!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7CJvssyhU$> which discusses the bits
on creating records with underscores and the registry
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names<https://urldefense.com/v3/__https:/www.iana.org/assignments/dns-parameters/dns-parameters.xhtml*underscored-globally-scoped-dns-node-names__;Iw!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7Cjtlpz6M$>

tim



On Tue, Feb 21, 2023 at 8:37 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
It would be helpful to not describe this as an extension to DNS-SD, since it's not—it's just giving a specific and constrained example of how to use existing DNS-SD functionality. That is, you are just using the protocol, not extending it. Which answers any question about where to do it—since you're not extending the protocol, the main reason to bring it up here is for us to look at it and see if there's any issue with its use of the protocol.

It would be better if the special-use domain were "mcast.arpa" or something like that rather than ".mcast," because that's easier for the IETF to arrange. See the home.arpa (RFC8375) and default.service.arpa (draft-ietf-dnssd-srp) examples.

It would be good to talk about this use case: why ".mcast" specifically? Suppose I'm a big online video provider and I'm advertising a multicast stream. Wouldn't I just use a subdomain of my own domain?

The section on the special-use domain is a bit problematic:

Users will not use the "mcast." domain directly.

It would help to say why—this is a complete mystery to the reader at this point.

Applications SHOULD recognize the "mcast." domain and reject any use in a unicast context.

Which applications? Does ssh need to recognize the domain?

Name resolution APIs and libraries SHOULD resolve the "mcast." domain to the multicast address that carries the service's data.

How? Can we use the local resolver? Are you proposing to set up a new DNS TLD hierarchy? How do we find the root servers for this hierarchy? Is this a locally-served domain, or are we expecting for there to be a registrar (or registrars) for .mcast?

Caching DNS servers SHOULD NOT recognize the "mcast." domain as special.

Good.

Authoritative DNS servers SHOULD NOT recognize the "mcast." domain as special.

Good.

DNS server operators SHOULD be aware of the "mcast." domain's use in resolving multicast services.

Why? What should they do differently?

DNS registries/registrars MUST NOT allow the "mcast." domain to be registered to any person or entity.

Again, probably better to use mcast.arpa—this is a big ask.


On Mon, Feb 20, 2023 at 10:55 PM Michael McBride <[e-mail]<mailto:[e-mail]>> wrote:
Hi dnssd,

As Nate mentioned, there is a related draft being discussed in the pim wg. If it would be better to also discuss this multicast related dns-sd extension in pim we will do so and coordinate with dnssd. Either way it would probably be good for Nate to present this in dnnsd (and pim) in Yokohama and see how the wg’s feel this may fit within charters. Even better we can discuss on the lists beforehand.

Thanks,
mike

From: dnssd <[e-mail]<mailto:[e-mail]>> On Behalf Of Karstens, Nate
Sent: Thursday, January 12, 2023 10:32 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [dnssd] New Draft Submission: DNS-Based Multicast Stream Discovery

Good afternoon,

I respectfully request your attention to the following draft submission:

https://datatracker.ietf.org/doc/draft-karstens-dnssd-dns-msd/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-karstens-dnssd-dns-msd*2F&data=05*7C01*7Cmichael.mcbride*40futurewei.com*7C6f5f28e48c184cd9d0f408daf4cb70b7*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638091451875788185*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C&sdata=xXsbVcnyvtjc7LDwUglJGmoVg5rN5A21JXuCKA26a28*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7CP7geNH8$>

Abstract:
This document describes an extension to DNS-SD for the advertisement and discovery of multicast streams.  This is especially useful with multicast streams that use a dynamically-assigned multicast address.

This is related to a draft submitted to the [pim] working group to develop a standard for zero-configuration assignment of multicast addresses. See https://datatracker.ietf.org/doc/draft-karstens-pim-ipv6-zeroconf-assignment/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-karstens-pim-ipv6-zeroconf-assignment*2F&data=05*7C01*7Cmichael.mcbride*40futurewei.com*7C6f5f28e48c184cd9d0f408daf4cb70b7*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638091451875788185*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C&sdata=W55Fh*2Fgi9iLSPXa4XUxS07*2FcIp4LIVAPAc77eXIxkUs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7Ct-eh3B8$> for more information.

It would be great if we could allocate some time to discuss at the IETF 116 meeting.

Best Regards,

Nate Karstens

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dnssd__;!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7CS5dUi1g$>
_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dnssd__;!!EJc4YC3iFmQ!UQlzSIM3hTkFVrN41v-AfDIypFpMPl1HJGfI7NXxPKT9Q-fLOH91rvxgDUi1uCI3WztAdKwO_S7CS5dUi1g$>