Re: [lwip-users] DNS lookup of other RR types

[Craig McQueen]

I wrote:
> address@hidden wrote:
> > On 11.11.2018 23:41, Craig McQueen wrote:
> > > I'd like to do DNS lookups of other RR types, such as SRV, PTR or
> > > TXT
> > records. SRV is my immediate interest, though SRV, PTR and TXT would
> > facilitate doing DNS-SD queries in future. What would be needed to
> > make this possible?
> > >
> > > Looking at core/dns.c, I see the API is purely for getting host
> > > addresses at
> > the moment (A or AAAA records). Would it be best for me to modify
> > core/dns.c, or implement my own separate code?
> >
> > Better to add code to dns.c than add separate code. But please watch
> > out to keep the existing code/memory size unless new features are
> enabled.
> 
> I could make a new function:
> 
> err_t            dns_getrr(const char *name, u8_t dns_rr_type,
> dns_rr_response_t *dns_rr_response,
>                                    dns_rr_found_callback found, void 
> *callback_arg);
> 
> typedef void (*dns_rr_found_callback)(const char *name, u8_t dns_rr_type,
> const dns_rr_response_t *dns_rr, void *callback_arg);
> 
> typedef union {
>     ???
> } dns_rr_response_t;
> 
> 
> dns_rr_type would be e.g. DNS_RRTYPE_SRV. It might be good to turn those
> DNS_RRTYPE_... defines into an enum.
> 
> I'm not sure about dns_rr_response_t, which would have to be a union of all
> the possible data returned from all the possible RRs. I see there is a
> netif_ext_callback_args_t which is a union, which might be a useful
> precedent to follow.
> 
> Does it make sense for dns_rr_response_t *dns_rr to be a parameter to
> dns_getrr()? That relates to questions about caching below. Also, the size of
> dns_rr_response_t would be that of the largest member of the union. But a
> caller might only want to call it with a pointer to a smaller struct that is
> applicable for the particular RR requested.
> 
> I'm also not sure about the handling of multiple returned records. E.g. doing 
> a
> look-up of SRV or NAPTR records, multiple records can be returned, and user
> code really needs to see all of them. Should the callback be called multiple
> times, one for each record? How can the callee know when the list is
> complete? How does lwIP currently handle the possibility of multiple A or
> AAAA records -- does it just take the first one received?
> 
> I'm also not sure about caching. Should SRV, NAPTR, PTR, TXT records etc
> possibly be cached? How could the memory for that be efficiently allocated,
> given RR responses can vary widely in size? How could multiple responses be
> cached?

Another question about this is to do with DNS-SD look-ups over mDNS for 
Zeroconf. If a device wants to look up a service such as web server, it will do 
an mDNS query for PTR records named
_http._tcp.local

Then Zeroconf responders can respond over mDNS with an answer such as
_http._tcp.local; type PTR; httpserverservicename._http._tcp.local

But, responders can also "anticipate" that the original device will want to 
follow up with requests for the associated SRV, TXT and A/AAAA records, so the 
responder can include those answers in the response:
httpserverservicename._http._tcp.local; type TXT; path=/
httpserverservicename._http._tcp.local; type SRV; priority 0; weight 0; port 
80; httpserverhostname.local
httpserverhostname.local; type A; address 192.168.1.100

The device that originates the request might potentially get dozens of 
responses to such a mDNS query, each containing such PTR, TXT, SRV and A/AAAA 
records.

In lwIP, if user code does a DNS query for a PTR record, would it be reasonable 
for it to get a callback for all of these PTR, TXT, SRV and A/AAAA records that 
come back as a result?

-- 
Craig McQueen