[fpc-pascal] netdb and DNS queries for MX, TXT, and other resource types

[Michael Van Canneyt]

On Wed, 16 Sep 2020, Noel Duffy via fpc-pascal wrote:

> On 16/09/20 8:43 pm, Michael Van Canneyt via fpc-pascal wrote:
>> 
>> 
>> On Wed, 16 Sep 2020, Noel Duffy via fpc-pascal wrote:
>> 
>>> I'm in need of a library to perform DNS lookups for a range of different 
> resource types such as MX, TXT, PTR and so on. At first I thought that netdb 
> would do the job, but it turns out that it only supports direct A and AAA 
> lookups. However, the code actually has the ability to query all resource 
> types, but the module's API doesn't expose this functionality. The functions 
> Query and BuildQuery, and the types TQueryData and TRRData are not made 
> available to callers.
>>>
>>> cnetdb is similar in that it exposes just a subset of what libresolv 
> provides. There's no interface to things like res_nquery, for instance. While 
> it's theoretically possible for me to interface directly to libresolv, in 
> reality the API is a horrible hairball of C macros and pointers and this is 
> not a path I want to go down.
>>>
>>> Is it intended that netdb will be capable of querying all resource types? 
> It appears that most of the work is already done, with the only major pieces 
> missing the parsing of the additional resource records and the exposure of 
> additional functions for the public API.
>> 
>> It was intended, but in practice I just added the records I needed.
>> If you feel like adding new records, I'll gladly accept patches.
>> 
>
> I can certainly do that. The first question, though, is what should the API 
> look like? From my initial reading of the code the simplest path might be to 
> expose Query and BuildQuery publicly, so that users can compose queries for 
> arbitrary resource types similarly to libresolv, but there will still need to 
> be new methods to parse the RR data. Such an API is low-level but offers the 
> most flexibility. That's what a number of other languages do.

Sure.

I would just add some 'comfort' methods to execute simple queries.

> I'll need to do a close read of RFC 1035 to get a clearer idea of the RR data 
> parsing requirements before I can suggest anything useful there.

Indeed, reading the RFC is always a good starting point :-)

Michael.