DNS lookup of other RR types

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DNS lookup of other RR types

Craig McQueen
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?

--
Craig McQueen


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup of other RR types

goldsimon@gmx.de
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.

Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup of other RR types

Craig McQueen
[hidden email] 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


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup of other RR types

Craig McQueen
I wrote:

> [hidden email] 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users