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

[Craig McQueen]

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?

-- 
Craig McQueen