net: dns-sd: additional rfc6733 features

cfriedt commented 2 years ago

Is your enhancement proposal related to a problem? Please describe. Currently, dns-sd does not support

domain enumeration (chapter 11)
sub-types (chapter 7.2)
service domains (chapter 7.2)

Items 2 and 3 deal with fully-qualified names (FQN's). Examples of FQN's that are unsupported are of the form:

<sub>._sub.<sn>._tcp.<servicedomain>.<parentdomain>.

or anything other than "local" for a <domain>, where

<domain> := <servicedomain>.<parentdomain>.

The struct dns_sd_rec actually has insufficient fields to represent all types of names.

Describe the solution you'd like

1 additional local "service domain", either configured from e.g. DHCP or via Kconfig
remove the proto, service, and instance fields of struct dns_sd_rec
use only a name field and name_size, domain field and domain_size, and text and text_size
use accessor methods to extract the above values into callee-provided storage
support domain enumeration via kconfig switch (ch 11)
support all fully-qualified names described in ch 7.2
an additional pass of helpful features from RFC 6763

Describe alternatives you've considered

Additional context https://datatracker.ietf.org/doc/html/rfc6763

ghost commented 2 years ago

The driver seems to not initiate device-side announcements or probing at startup as described in section 8: https://datatracker.ietf.org/doc/html/rfc6762#section-8. This causes my device to remain undiscovered when the server has avahi-daemon running.

cfriedt commented 2 years ago

The driver seems to not initiate device-side announcements or probing at startup as described in section 8: https://datatracker.ietf.org/doc/html/rfc6762#section-8. This causes my device to remain undiscovered when the server has avahi-daemon running.

Thanks for finding this! I see that it's part of the greater mdns picture (rfc6762) so I might create a separate issue for general mdns improvements.

cfriedt commented 2 years ago

Pushing this back, as I have no actual dedicated hours to work on this at the moment (most of my upstream work is still unfortunately evenings and weekends).

cfriedt commented 1 year ago

@pdgendt - in case you have bandwidth to make additional improvements. Feel free to ping me on Discord for any clarification. In particular, accessor methods would be the preferred way to extract fields.

pdgendt commented 1 year ago

@pdgendt - in case you have bandwidth to make additional improvements. Feel free to ping me on Discord for any clarification. In particular, accessor methods would be the preferred way to extract fields.

@cfriedt thanks, it could be something for the long run though. We're currently more focused on RFC6762, and filling some gaps there.

zephyrbot commented 7 months ago

Hi @rlubos, @jukkar,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@cfriedt you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

cfriedt commented 7 months ago

DNS SD should be much easier to test and maintain with this change.

I'll assign it to myself and will try to carve out some time to implement it soon.

zephyrproject-rtos / zephyr

net: dns-sd: additional rfc6733 features #38846