[Feature Request] mDNS Service Discovery

[george-palmsens]

I want to be able to do automatic service discovery using DNS-SD over mDNS.

---

I would like to be able to use a more advanced hook than xApplicationDNSQueryHook to be able to describe a more comprehensive set of DNS queries to provide responses to. Then DNS-SD could be supported on top of that.

---

For example:

/* Records necessary for DNS-SD */
const DNSRecordTable_t records[] = {
    {dnsTYPE_PTR, .name ="service._udp.local", .domain="myname.service._udp.local"},
    {dnsTYPE_SRV, .name ="myname.service._udp.local", .port = 5353, target="myname.local"},
    {dnsTYPE_HOST_A, .name = "myname.local"}
};

BaseType_t xApplicationDNSQueryHook(DNSRecordTable_t const ** out_records, size_t* out_records_len) {
    *out_records = records
    *out_records_len = LEN(records);
    return pdTRUE;
}

I am also happy to help deliver this feature.

This would serve LLMNR through the same mechanism.

[george-palmsens]

I have a working proof of concept where the user facing API is as follows:

static const DNSRecord_t s_records[] = {
    {.record_type = dnsTYPE_PTR, .name="\x7service\x4_udp\x5local", .data.ptr_record = "\x8hostname\x7service\x4_udp\x5local"},
    {.record_type = dnsTYPE_SRV, .name="\x8hostname\x7service\x4_udp\x5local", .data.srv_record = {.target="\x8hostname\x5local", .port=5353}},
    {.record_type = dnsTYPE_A_HOST, .name="\x8hostname\x5local"}
};

BaseType_t xApplicationDNSQueryHook( const DNSRecord_t ** outRecords, size_t * outLen ) {
    *outRecords = s_records;
    *outLen = 3;
    return pdTRUE;
}

Obviously defining record names with the path lengths pre-included is gross, but it was easy just for getting things moving. This then responds correctly to DNS-SD service resolvers (such as mdns-sd).

[david-sawatzke]

I'm also interested in this feature. As far as I can tell, there's no way to listen to multicast mDNS requests as a user of the FreeRTOS plus TCP stack (implementing it outside, without using the integrated mDNS feature).

[moninom1]

Thank you for raising this feature request. I’ll review it with the team and follow up soon.

[george-palmsens]

I'm also interested in this feature. As far as I can tell, there's no way to listen to multicast mDNS requests as a user of the FreeRTOS plus TCP stack (implementing it outside, without using the integrated mDNS feature).

This would require FreeRTOS to support multicast listeners, and raw sockets. That would be very cool, but a big change.

I hope that this is a much smaller code difference.

[tony-josi-aws]

@george-palmsens We have a multicast support PR that is in progress - #1019
Since it's already in progress, I'm wondering if this feature can be implemented better with multicast support.

[george-palmsens]

@george-palmsens We have a multicast support PR that is in progress - #1019 Since it's already in progress, I'm wondering if this feature can be implemented better with multicast support.

That would certainly work - My proposition was mainly to keep the delta as small as possible, for the sake of implementation speed.

[htibosch]

@george-palmsens, you proposal sounds good!

@evpopov, what is your feeling about the above proposals? Any comments, recommendations?

  // Current signature
  BaseType_t xApplicationDNSQueryHook_Multi( NetworkEndPoint_t *pxEndPoint, const char *pcName )
  // Desired signature
  BaseType_t xApplicationDNSQueryHook( const DNSRecord_t ** outRecords, size_t * outLen )

We used to have a application hook called xApplicationDNSQueryHook(), which is now renamed to xApplicationDNSQueryHook_Multi(), provided that ipconfigIPv4_BACKWARD_COMPATIBLE is not enabled.

Can we have a new config macro that tells if the new DNSRecord_t feature is in use?

I hope that after adding this feature none of the existing sources have to change.

[george-palmsens]

@george-palmsens, you proposal sounds good!

@evpopov, what is your feeling about the above proposals? Any comments, recommendations?

// Current signature
BaseType_t xApplicationDNSQueryHook_Multi( NetworkEndPoint_t *pxEndPoint, const char *pcName )
// Desired signature
BaseType_t xApplicationDNSQueryHook( const DNSRecord_t ** outRecords, size_t * outLen )

We used to have a application hook called xApplicationDNSQueryHook(), which is now renamed to xApplicationDNSQueryHook_Multi(), provided that ipconfigIPv4_BACKWARD_COMPATIBLE is not enabled.

Can we have a new config macro that tells if the new DNSRecord_t feature is in use?

I hope that after adding this feature none of the existing sources have to change.

Yeah we can do that. I only named it the same as a sort of comparison to what we have already.

But it would be perfectly easy to name it something else and have it switched in via config.

[evpopov]

@george-palmsens We have a multicast support PR that is in progress - #1019 Since it's already in progress, I'm wondering if this feature can be implemented better with multicast support.

@tony-josi-aws I don't know exactly what @george-palmsens code looks like, but #1019 doesn't really do anything with mDNS or the APIs. There is only a small change to FreeRTOS_DNS_Parser.c that will probably not overlap with the proposal here. My personal opinion is that this proposal should not be attached or dependent on #1019 to avoid complications.

@htibosch Sounds great to me. Sadly I can't speak from experience about DNS-SD, but I also have general interest in the subject, so yeah, service discovery support sounds great.

I'm personally very curious to see the proposed code and maybe give it a try and learn more about service discovery.
@george-palmsens could you please share your proof-of-concept so we could try it out? Whether it's in the form of a draft PR or just a link to your repo. I'd like to get a better feel for the complexity that this adds to xApplicationDNSQueryHook_Multi()

[george-palmsens]

Yep, I'll make it available today.

Do note that I didn't keep xApplicationDNSQueryHook_Multi, I replaced it with a new hook in the manner mentioned in the Issue description. But I hope it's still useful to see.

[george-palmsens]

Okay, you can find my fork at https://github.com/george-palmsens/FreeRTOS-Plus-TCP/tree/dns_sd_support

It is very rough, just to prove the idea. It is compiled with ipconfigUSE_LLMNR and ipconfigUSE_MDNS.

It also uses ipconfigIPv4_BACKWARD_COMPATIBLE, because that's what I was using in the project I demo'd this in.

It changes the signature of the DNS hook to:

BaseType_t xApplicationDNSQueryHook( const DNSRecord_t ** outRecords, size_t * outLen )

so the application code must implement something like the following:

static const DNSRecord_t s_records[] = {
    {.record_type = dnsTYPE_PTR, .name="\x9myservice\x4_udp\x5local", .data.ptr_record = "\x6myname\x9myservice\x4_udp\x5local"},
    {.record_type = dnsTYPE_SRV, .name="\x6myname\x9myservice\x4_udp\x5local", .data.srv_record = {.target="\x6myname\x5local", .port=5353}},
    {.record_type = dnsTYPE_A_HOST, .name="\x6myname\x5local"}
};


BaseType_t xApplicationDNSQueryHook( const DNSRecord_t ** outRecords, size_t * outLen ) {
    *outRecords = s_records;
    *outLen = 3;
    return pdTRUE;
}

---

I hope that's enough to get the idea across! Let me know if I can clear anything up.

[evpopov]

@george-palmsens I tried your code but couldn't get it to work. The only way I know to query for services is to use avahi-browse --all --terminate and that seems to generate the two-question query from the attached wireshark trace
dns-sd-two-questions.zip
DNS_ParseDNSReply() failed after parsing the first question.
I limited the questions loop to only parse the first question and finally got the xApplicationDNSQueryHook() to get called.
I used your sample callback code but still couldn't see a response. I'm struggling because I do not know what should and should not happen in DNS_ParseDNSReply() due to my inexperience with DNS-SD

I was finally able to get some response by modirying my records definition to

	static const DNSRecord_t s_records[] = {
		{.record_type = dnsTYPE_PTR, .name="\xa_myservice\x4_udp\x5local", .data.ptr_record = "\x6myname\x9myservice\x4_udp\x5local"},
		{.record_type = dnsTYPE_SRV, .name="\x7_myname\x9myservice\x4_udp\x5local", .data.srv_record = {.target="\x6myname\x5local", .port=5353}},
		{.record_type = dnsTYPE_A_HOST, .name="\x7_myname\x5local"}
	};

and running avahi-browse _myservices._udp --terminate
however I don't think avahi liked the response because the above did not produce any output. I think DNS_ParseDNSReply() is not capable of sending more than 1 response record.
here's the wireshark capture that I finally got:

dns-sd-response-1.zip

It would be nice if you could get this proof of concept a little better implemented with maybe some general service discovery information and sample Windows/Linux usage commands. If I was implementing a printer, I'd surely need this, but other than that, what are other examples of services that can be discovered on the network? I can envision this being used as the basis to "Discover" device IPs and their services without writing custom discovery tools as we often have to do, but I don't see any built-in Windows or Linux commands to tap into this potential. Can you elaborate a bit on sample usage?
I see that printers advertise printing services and configuration web pages which sounds intriguing, but how do you "browse" for these resources with common user tools?

[george-palmsens]

@evpopov Thanks for giving it a go! I appreciate your persistence.

I have personally been using the mdns rust library for my queries, but maybe I should try avahi.

Let me dig in a little and see if I can work out some more about what you're seeing.

---

It's true that there's not tons of user facing discovery tools. But the use case for us, for example, is to allow our software to find our hardware on the network automatically.

[george-palmsens]

@evpopov Okay, think I've made some progress. Avahi seems to want the response to contain only answers, no questions.

If I do that, avahi picks up the service. I'll do some more work to make sure I understand it fully but thanks for pointing this out :)

[george-palmsens]

@evpopov Okay, I now have avahi working.

$ avahi-browse _myservice._udp -r
+   eth2 IPv4 instanceFRTCP                                 _myservice._udp      local
=   eth2 IPv4 instanceFRTCP                                 _myservice._udp      local
   hostname = [instanceFRTCP.local]
   address = [192.168.0.26]
   port = [5353]
   txt = []

Changes needed:

• Service must begin with an underscore. _myservice._udp.local not myservice._udp.local
• mDNS responses must not contain questions, only answers
• Service must serve a TXT record at the service address (I thought this was optional)

Additionally, Avahi (and DNS requests generally) may issue more than one question in a single DNS query. The FreeRTOS DNS reply system currently discards all questions except the last, which is a big problem. If Avahi asks for SRV+TXT, we need to respond with both.

So the necessary work to get this going properly are:

• Add TXT records as an option in the records table
• Change DNS_ParseDNSReply to build a response to all questions in the query, not just the last
  • Oof, this will be quite a big change.
• Change DNS_ParseDNSReply to remove the questions from responses
  • Basically a big memmove of the packet at the end, which is a bit sad. Maybe we can build up the response in a new buffer? I don't know how that works under the hood.
  • I also don't know if this would have implications for the existing mDNS and LLMNR responses. My guess is no...?

---

I have added this to my fork in a very dirty way. Basically if the last DNS question matches any of our records, we serve all of our records.

This is wrong and bad but it is easy to do, and hopefully helps you get it at least working to have a look.

The records I am using for this are:

static const DNSRecord_t s_records[] = {
    {.record_type = dnsTYPE_PTR, .name="\x9_services\x7_dns-sd\x4_udp\x5local", .data.ptr_record = "\xA_myservice\x4_udp\x5local"},
    {.record_type = dnsTYPE_PTR, .name="\xA_myservice\x4_udp\x5local", .data.ptr_record = "\xDinstanceFRTCP\xA_myservice\x4_udp\x5local"},
    {.record_type = dnsTYPE_SRV, .name="\xDinstanceFRTCP\xA_myservice\x4_udp\x5local", .data.srv_record = {.target="\xDinstanceFRTCP\x5local", .port=5353}},
    {.record_type = dnsTYPE_TXT, .name="\xDinstanceFRTCP\xA_myservice\x4_udp\x5local"},
    {.record_type = dnsTYPE_A_HOST, .name="\xDinstanceFRTCP\x5local"}
};

The first record (_services._dns_sd._udp.local) allows avahi-browse -a to find us. The TXT record satisfies Avahi's need for such a record, and makes everything work.