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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
