I wrote:
> goldsi...@gmx.de 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
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
