dnsdb / dnsdbq Goto Github PK

When a query fails with a 404, should the exit failure code really be 0 as shown below?:

$ dnsdbq -r www.farsightsecurity.com/A -A 2015-08-25 -c
libcurl: 404 (https://api.dnsdb.info/lookup/rrset/name/www.farsightsecurity.com/A?time_first_after=1440478500)
please note: 404 usually just means that no records matched the search criteria
API: Error: no results found for query.
$ echo $?
0

Additionally, there are multiple messages in that output, libcurl's low level response, the query sent, a note about what 404 means, and then "API: Error". Kind of confusing? Can we make it more clear?

There's a compile error from a warning in netio.c:

netio.c:349:4: error: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Werror=unused-result]
  349 |    asprintf(&temp, "%s%*.*s\n",
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  350 |      or_else(writer->ps_buf, ""),
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  351 |      (int)pre_len, (int)pre_len, fetch->buf);
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:60: netio.o] Error 1

It can be solved explicitly ignoring the return value with a void cast:

index ea559a5..3054c91 100644
--- a/netio.c
+++ b/netio.c
@@ -346,7 +346,7 @@ writer_func(char *ptr, size_t size, size_t nmemb, void *blob) {
                        /* concatenate this fragment (with \n) to info_buf. */
                        char *temp = NULL;
 
-                       asprintf(&temp, "%s%*.*s\n",
+                       (void) !asprintf(&temp, "%s%*.*s\n",
                                 or_else(writer->ps_buf, ""),
                                 (int)pre_len, (int)pre_len, fetch->buf);
                        DESTROY(writer->ps_buf);

The batch input format currently copies the batch input lines into a URL.
Example: $ echo foo/bar | dnsdbq -f -d
generates a invalid URL https://api.dnsdb.info/lookup/foo/bar?swclient=dnsdbq&version=1.5

I think dnsdbq should fully parse and error check its batch input lines before forming the URLs.

Additionally there is no way to specify time fencing in in the batch lines:

You might think you could add time fencing parameters to the batch line:
$ echo 'foo/bar?time_last_after=1546300800' | dnsdbq -f -d
But it generates an invalid URL https://api.dnsdb.info/lookup/foo/bar?time_last_after=1546300800?swclient=dnsdbq&version=1.5
dnsdbq: libcurl: [Error: unable to parse request]

The only thing that works now is to specify one time fence on the dnsdbq command line:
$ echo rrset/name/bbn.com | dnsdbq -f -A 2019-01-01 -d -l 1
which sends URL https://api.dnsdb.info/lookup/rrset/name/bbn.com?swclient=dnsdbq&version=1.5&limit=1&time_last_after=1546300800

That does not work if the batch inputs need to have individual time fencing values.

If the -f option is present, then dnsdb_query will read commands from stdin (not from a batch file name).

The man page has synopsis:

 [-dfhjv] [-A timestamp] [-B timestamp] [-b bailiwick] [-i ip] [-l limit] [-n name] [-p output_type]
     [-r rdata] [-t type] [batch_filename]

The [batch_filename] part should be removed.

The documentation for the -f command should be changed from in a file to in stdin.

1. Add an example to the FILES section. It doesn't say if you need "APIKEY abcdef.." or "APIKEY=abcdef...".
2. It doesn't say if comments are allowed.
3. Allowing # comments would be nice.
4. It doesn't document the circla or circls keyworks.
5. The code says the option names are actually "apikey" and "server" (lower case only), not as shown in the man page, APIKEY and DNSDB_SERVER.
6. I think these option names should be the same as the environment variable names, DNSDB_API_KEY and DNSDB_SERVER, for consistency.

FILES
     ~/.isc-dnsdb-query.conf, ~/.dnsdb-query.conf, /etc/isc-dnsdb-query.conf, or /etc/dnsdb-query.conf: configuration file which should contain the user's apikey and server URL.

     APIKEY: contains the user's apikey (no default)
     DNSDB_SERVER: contains the URL of the DNSDB API server (default is https://api.dnsdb.info)

I had a mistake for -l value and noticed it didn't error out on a non-number string.

dnsdbq outputs human readable times like: 2018-09-06 22:48:00
It was suggested to use ISO8601 / RFC3339 format, which would look like 2018-09-06T22:48:00Z

To implement, change the format string from "%F %T" to "%FT%TZ".

The -A and -B timestamp input arguments expect YYYY-MM-DD[HH:MM:SS] or the relative form: %dw%dd%dh%dm%ds. Of the three output forms, json outputs timestamps in Unix epoch format. I suggest adding an option to have json output human readable timestamp format too.

csv:

"2017-02-14 23:15:53","2017-03-01 23:16:09",,,11,,"106.119.53.92.in-addr.arpa.","PTR","bbn.com."

json:

{"count":11,"time_first":1487114153,"time_last":1488410169,"rrname":"106.119.53.92.in-addr.arpa.","rrtype":"PTR","rdata":"bbn.com."}

dns:

;; record times: 2017-02-14 23:15:53 .. 2017-03-01 23:16:09
;; count: 11
106.119.53.92.in-addr.arpa.  PTR  bbn.com.

If you run dnsdbq with a bad DNSDB_SERVER environment variable, it may silently exit, with status 0. It should display an error message and fail with a non-zero status.

$ DNSDB_SERVER=https://api-pao.dnsdb.infoFOFOFO dnsdbq -i 128.89.0.1
$ echo $?
0

You need three -d flags to get to see an error message:

$ DNSDB_SERVER=https://api-pao.dnsdb.infoFOFOFO dnsdbq -i 128.89.0.1 -d -d -d
... 14 lines deleted ...
* Could not resolve host: api-pao.dnsdb.infoFOFOFO
* Closing connection 0
about to call exit(0)

-b in manpage says "If bailiwick is
specified, but rrtype is not specified, then a default rrtype of ANY
will be used."

But that default rrtype is same regardless if -b is set or not.
It does set it in the REST URI simply because the DNSDB API requires it when bailiwick is set.
Document about default rrtype elsewhere in this manual.

curl_escape(3) man page says "Since 7.15.4, curl_easy_escape(3) should be used. This function will be removed in a future release."
Only complication to switching functions is the need to do CURL *curl = curl_easy_init();
and then free that (which is not shown in the curl_easy_escape man page).

document if not using -c for strict while using both -A and -B
that is will do two query runs and sort and deduplicate results.

Some pDNS systems may require search inputs are 7-bit clean ASCII.
Fail or warn if a -r or -n parameter is not clean.

dnsdbq cannot generate rdata raw queries, even though the man page implies it can:

-t type
     specify type of rdata query and how value specifies how the target value should be interpreted.
     Should be one of the following:
    ...
    3.   raw: The value is an even number of hexadecimal digits specifying a raw octet string.

But the source code has no concept of "raw". The value of -t parameter is passed unchecked in the URL:

$ dnsdbq -n 00000185046c646170 -t foo -j
libcurl: 400 (https://api.dnsdb.info/lookup/rdata/name/00000185046c646170/foo)
API: Error: unable to parse request.

Here is a URL for a valid form of that query:

curl -k -H 'Host: api.dnsdb.info' -H 'Accept: application/json' -H "X-API-Key: $APIKEY" "https://api.dnsdb.info//lookup/rdata/raw/00000185046c646170"

Add to man page: "If input_file is "-" then standard input (stdin) will be read." as in:

     -J input_file
          opens input_file and reads newline-separated JSON objects therefrom, in preference to -f (batch
          mode) or -r, -n, or -i (query mode). This can be used to reprocess the output from a prior invoca-
          tion which used -j (-p json).  If input_file is "-" then standard input (stdin) will be read.

cc -g -W -Wall -Wcast-qual -Wpointer-arith -Wwrite-strings -Wmissing-prototypes  -Wbad-function-cast -Wnested-externs -Wunused -Wshadow -Wmissing-noreturn -Wswitch-enum -Wformat-nonliteral -Werror `curl-config --cflags`  -I/usr/local/include -c ns_ttl.c
ns_ttl.c:54:24: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
                case 'W':  tmp *= 7; __attribute__ ((fallthrough));
                                     ^
ns_ttl.c:55:25: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
                case 'D':  tmp *= 24; __attribute__ ((fallthrough));
                                      ^
ns_ttl.c:56:25: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
                case 'H':  tmp *= 60; __attribute__ ((fallthrough));
                                      ^
ns_ttl.c:57:25: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
                case 'M':  tmp *= 60; __attribute__ ((fallthrough));
                                      ^

A solution was to comment out the __attribute__ half of those four lines.

$ DNSDB_SERVER=https://api-fmt.dnsdb.info dnsdbq ...
works, but
$ DNSDB_SERVER=api-fmt.dnsdb.info dnsdbq ...
fails with

libcurl: 301 (http://api-fmt.dnsdb.info/lookup/...)
API: <html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.2.1</center>
</body>
</html>

because bare hostname is built into a http: URL, not https:.
Maybe the DNSDB_SERVER parsing code should fail if the value is not a URL?

Manual for -A documents time_first_after but -A is time_last_after
so change manual to "Only results last seen"
(assuming code is correct).

Since dnsdbq already fails on some wrong command-line option combinations, consider some more for -J:

1. dnsdbq allows -t with -J mode, but -t is ignored
   fail if -t is also set

2. dnsdbq allows -V summarize with -J mode, but -V summarize is ignored
   (also -M is allowed with -J)
   fail if -V is also set

3. please better document dnsdbq -J mode. It can be sorted for example.
   It can be limitted with -l and -L and -A and -B (that is surprising to me). what else?

4. Does allowing -J with -g make sense? it cannot change aggregation

5. dnsdbq -O is allowed with -J and -O does nothing.

6. dnsdbq -J shouldn't allow -u since does nothing

Looking at server logs, I see .. and . are squashed. Even .. makes it so previous parameter in URL is removed (like name/.. or ANY/.. disappears). (I have no need for .. but it shows the problem.) My problem was seen trying to use find bailiwick of . (-b .) was not sent to the DNSDB API server.

It appears that the problem began in libcurl version 7.32.0 which introduced Curl_dedotdotify().
dnsdbq requires curl_multi_wait introduced in curl 7.28.0 which works fine for . and .. by not removing them.
libcurl 7.42.0 introduces CURLOPT_PATH_AS_IS option.
So for 7.42.0 and newer this worked for me:
+++ b/dnsdbq.c
@@ -1412,6 +1412,8 @@ launch_one(writer_t writer, char *url) {
curl_easy_setopt(reader->easy, CURLOPT_HTTPHEADER, reader->hdrs);
curl_easy_setopt(reader->easy, CURLOPT_WRITEFUNCTION, writer_func);
curl_easy_setopt(reader->easy, CURLOPT_WRITEDATA, reader);

•    /* don't squash "/../" or "/./" especially for dot */
  

•   curl_easy_setopt(reader->easy, CURLOPT_PATH_AS_IS, 1L);
  

(The logging also showed the literal .. and .)
Should check for CURLOPT_PATH_AS_IS defined and use it? Require at least that version?
(Create a new metadomain DNSDB_DOTDOT and DNSDB_DOT for example that is used by the client and known by the DNSDB API server? It could be used by other internal client that also loses dot.)

The "NULL;" statement on line 1542 of https://github.com/dnsdb/dnsdbq/blob/info/dnsdbq.c should be removed. It caused a compilation failure "dnsdbq.c:1542:3: error: statement with no effect [-Werror=unused-value]". It apparently predates the if statement that is now there.

while (curl_multi_info_read(multi, &still) != NULL) {
  if (debuglev > 3)
    fprintf(stderr, "...info read (still %d)\n", still);
  NULL;
}

dnsdbq -I allows -s and -S switches but makes no sense

(I'd ignore this but code already has many command-line switches checks.)

I have 47 dnsdbq tests (out of my ~133 DNSDB API tests). I introduced a new test today which confused me. I tried to use -A for five minutes ago, but kept getting 404 on an active server. The dnsdbq output is clear about the problem but I also looked at code and added some debugging to confirm it.

mktime(3) used tm_isdst which made it one hour in the future (so per my query was 55 minutes in the future). I see this on both Linux and NetBSD.

For example:
$ date -d "5 minutes ago" +"%Y-%m-%d %H:%M:%S"
2018-10-03 17:08:44

$ ./dnsdbq -A "2018-10-03 17:08:44" -r net/ANY

libcurl: 404 (https://api.dnsdb.info/lookup/rrset/name/net/ANY?time_last_after=1
538608124)
please note: 404 usually just means that no records matched the search criteria
API: Error: no results found for query.

So check out the epoch in the libcurl line above...
t1:dnsdbq$ date -r 1538608124
Wed Oct 3 18:08:44 CDT 2018

My goal was after 17:08 which would have worked:

t1:dnsdbq$ date
Wed Oct 3 17:15:33 CDT 2018

Using the epoch works and using the ns_parse_ttl() way works too, for example this works great:
dnsdbq -A "5m" -r net/ANY

By the way, I don't get any additional timezone adjustment on Linux or NetBSD (I am at CDT) so here.tz_minuteswest is 0. (I added debugging to confirm.)

I'd suggest:

• documenting in the man page to say that DNSDB timestamps are in UTC timezone, but this tool uses local time which converts to UTC.

• or document for the user to use UTC and don't adjust for that.

• fix the off by 3600 seconds issue. My hack was to set
  tt.tm_isdst = 0; /* don't adjust for daylight savings time */
  before the mktime() use. I don't think that is the right way. Maybe mktime() is the wrong function to use for this. (Then tm_isdst gets reset to 1.)

• let's also document that the Unix epoch time is acceptable input (an example does show it)

• and document the ns_parse_ttl() format which is the (weeks, days, hours, minutes, seconds) time before the current time.

if the uri path for a dnsdb server is not /lookup, it must be made part of the DNSDB_SERVER name. this is supposed to be detected, so that the /lookup term will not be auto-generated. used to work, but was broken after the most recent major release.

-A 0 -B 0 -c
results in:
error: -c without -A or -B makes no sense.
Using either -A or -B without -c is just silently ignored.
Looking at manual it requires a positive number when in that format. And code checks for != 0.
0 could be valid is as in show all first seen since epoch but not really important.
Its just the error output is misleading.
This is low priority.

The dnsdbq man page should document a bit more about raw data queries.
The man page does not mention that raw rrset (LHS) queries are supported, at least in batch mode.
Nor does it explain that the octet strings (which are called hex-pairs in one place and octet strings in a different place) are DNS wire-encoded format.

The dnsdbq man page mentions raw queries in three places
under batch mode option:
Rdata (raw) query: rdata/raw/HEX-PAIRS[/RRTYPE]
stand alone option:

-R raw-data
          specify raw rdata data ("right-hand side") query.  The value is an even number of hexadecimal digits specifying a raw octet string.

and in a batch mode example:
rdata/raw/0b763d73706631202d616c6c

Here is an example of using the wdns library and a raw rrset query:

$ python
>>> import wdns
>>> import binascii
>>> print (binascii.hexlify(wdns.str_to_name("bbn.com")))
0362626e03636f6d00

$ echo rrset/raw/0362626e03636f6d00 | dnsdbq -f -j -l 1
{"count":544,"time_first":1571820084,"time_last":1574434733,"rrname":"bbn.com.","rrtype":"A","bailiwick":"bbn.com.","rdata":["192.1.122.24"]}
--

The "raw" wire-format encodings are standardized. The embedding of these in dnstable is documented in the dnstable-encoding manual page .

$ dnsdbq -V summarize -l 1 -r foo
error: only 'lookup' understands output limits

older version of dnsdbq works fine.

Have dnsdbq check if -V summarize with -O to not send offset on to server since will get 416 error:

libcurl: Error: offset not allowed for this type of query

So consider failing at dnsdbq client first (don't send query).

manual documents: dns, json, csv but not "text" for -p

-I mentions -I -p text

usage error shows: error: -p must specify json, text, or csv

usage output shows [-p dns|json|csv]

code has both for present_text

Suggest manual mention both and have error output, and usage output and documentation be consistent.

For manual, please add more documentation or examples for sort -k sorting keys.
Especially for "data".

This hit me. Please document it. Or just always set to /lookup?

/* if there's a /path after the host, don't add /lookup here. */
x = 0;
for (p = dnsdb_server; *p != '\0'; p++)
x += (*p == '/');
lookup = (x < 3) ? "/lookup" : "";

this is from "$ dnsdbq -u dnsdb -i 101.99.64.0-101.99.95.255 -A '-86400' -c -j" and so makes no sense.

in batch mode (-f), the time for relative time ranges is calculated once, based upon the time dnsdbq starts. If batch mode runs for a long time, that time will become stale.
Example, when running "dnsdbq -f -A30d -klast -S -L1 -j" the time_last_after value is set at start-time, and never changes for the running life of the process.

The alternative would be to calculate the relative time for each line of batch mode input. Perhaps have this be a command-line option.
This behavior can be achieved with the existing code by not using batch mode, or using batch mode with a small list of inputs, submitted in a short time interval, and then exiting and restarting dnsdbq for the next time slot.

The recommended fix is simply documenting the existing behavior.

this is what happens when using only the environment, with no dot-file. should default to "dnsdb".

dnsdbq has high CPU usage while waiting for curl.
an strace on debian 9.4 shows:

rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_RESTORER, 0x7f7c515cb1a0}, NULL, 8) = 0
poll([{fd=3, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1890211, 429542592}) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f7c515cb1a0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7f7c515cb1a0}, NULL, 8) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1890211, 429709728}) = 0
clock_gettime(CLOCK_MONOTONIC, {1890211, 429749857}) = 0
clock_gettime(CLOCK_MONOTONIC, {1890211, 429853999}) = 0
rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_RESTORER, 0x7f7c515cb1a0}, NULL, 8) = 0
poll([{fd=3, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1890211, 429998273}) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f7c515cb1a0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7f7c515cb1a0}, NULL, 8) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
...

As mentioned in issue #92 raw LHS (RRset, really owner) queries are only supported in batch mode. Example: $ echo rrset/raw/0362626e03636f6d00 | dnsdbq -f -j -l 1

Raw rdata queries are supported by the -R option and batch mode.
Maybe add an option that does a LHS raw query? -L is already in use.
I suggest changing -R to be the raw form of -r and adding -N as the raw form of -n. This is not backwards compatible, but -R is only from November 2018.

dnsdbq's use of libcurl means that it supports the environment variable and HTTPS_PROXY. Document that support

As observed by Nate Meyer: Sorting with a limit fetches default amount of rows, sorts, then applies the specified limit.

$ dnsdbq -S -k last -n ns5.dnsmadeeasy.com -l 1000000 -t ns

will not return enough answers; instead it will return dnstli's configured default limit, normally 10K, instead of the 1M rows requested.

There is a strong benefit with the current behavior since it is closer to what the user might want.
Two possible changes:

1. Apply the -l limit in the dnsdb query, then sort.
2. Do # 1 plus add a new option, -L, which is a limit to apply post-sorting.

If JSON format results are desired, then change # 2 could be done using a head or tail command on the output from change # 1.

Sorting with jq is possible too:

$ dnsdbq -l xxx -j .... | jq -s 'sort_by((.zone_time_first,.zone_time_last) ? // (.time_first,.time_last))'

will use jq to sort, after limit is applied. Or can do 'sort_by(.count)' for sort by count.

But I have not figured out one problem with it: the results using the jq -s option come out inside an array:

$ dnsdbq -l 1  -j -n farsightsecurity.com | jq -s 'sort_by((.zone_time_first,.zone_time_last) ? // (.time_first,.time_last))'
[
  {
    "count": 7,
    "time_first": 1380044973,
    "time_last": 1380141734,
    "rrname": "207.4.20.149.in-addr.fsi.io.",
    "rrtype": "PTR",
    "rdata": "farsightsecurity.com."
  }
]

If I can remove, preferably using jq, the array notation, then this output could be fed back into dnsdbq with the -J option to output non-JSON formats.

See dnsdb_write_info code:
1618 fprintf(stdout, "quota:\n");

The key for -I for default or -p text is "quota" but with -p json it is "rate".
{
"rate": {
...
To be consistent, use "rate:" for default text info output.

Warning: -t option should be before the -R, -r, or -n options

but the manual page synopsis shows -t after them
(and it is not alphabetical order for options)

man page does say it should be before. Why should it be before? Why a warning?

Maybe the fix is only to change order in man page synopsis.

If you specify both -A and -B options on a summarize query, you get two lines of results:

$ dnsdbq -V summarize -r trump.* -j -B 2020-01-01 -A 2018-12-31 -l 10 -d 
...
debug: url [https://api.dnsdb.info/summarize/rrset/name/trump.%2A?swclient=dnsdbq&version=2.1.1&limit=10&time_last_after=1546214400]
debug: url [https://api.dnsdb.info/summarize/rrset/name/trump.%2A?swclient=dnsdbq&version=2.1.1&limit=10&time_first_before=1577836800]
{"count":1264,"num_results":10,"zone_time_first":1565125600,"zone_time_last":1582409370}
{"count":1264,"num_results":10,"zone_time_first":1565125600,"zone_time_last":1582409370}

I was having trouble searching for a value that contains a slash.

My conclusions:

1. We should, at least, document that the "-t RRTYPE" option should appear on the command-line before a -n or -r switch.
2. It would be better, but not backwards compatible, to require that (and fail the command).
3. Otherwise, it would be ok and maybe backwards compatible, to send a warning to stderr if -t appears after -n or -r.

Details:
I tried searching for a p= value from a TXT record which contained a slash in the value. The dnsdbq argument processing logic processes / in -r and -n values specially: If a -t option was given before the -r or -n then slashes are allowed and % encoded properly. Otherwise it fails as shown below. Multiple slashes are never allowed.

Here is a simpler version of the problem than using the TXT record's p= value.

Here is an embedded / which is presented as-is to curl, as if it is the RRTYPE to search for. Note that + is % encoded properly:

$ dnsdbq -n "bar/foo+baz"
libcurl: 400 (https://api.dnsdb.info/lookup/rdata/name/bar/foo%2Bbaz?swclient=dnsdbq&version=1.3)
libcurl: Error: unable to parse request.

I percent encoded the / myself as %2F next, but it was sent to curl as %252F, which is the proper escaping of "%" to %25".

$ dnsdbq -n "bar%2Ffoo+baz"
libcurl: 404 (https://api.dnsdb.info/lookup/rdata/name/bar%252Ffoo%2Bbaz?swclient=dnsdbq&version=1.3)
please note: 404 might just mean that no records matched the search criteria
libcurl: Error: no results found for query.

Without a -t, multiple slashes are disallowed:

$ dnsdbq -n "bar/foo/baz"
error: -n must be NAME[/TYPE] only

try   dnsdbq -h   for a short description of program usage.

With -t after -n, a single slash is disallowed:

$ dnsdbq -n "bar/foo" -t TXT
error: can only specify rrtype one way

try   dnsdbq -h   for a short description of program usage.

With -t after -n, multiple slashes are disallowed:

$ dnsdbq -n "bar/foo/baz" -t TXT
error: -n must be NAME[/TYPE] only

try   dnsdbq -h   for a short description of program usage.

Moving the -t first, the expected, properly %encoded query is sent for one and two slashes:

$ dnsdbq -t TXT -r "bar/foo" 
libcurl: 404 (https://api.dnsdb.info/lookup/rrset/name/bar%2Ffoo/TXT?swclient=dnsdbq&version=1.3)
please note: 404 might just mean that no records matched the search criteria
libcurl: Error: no results found for query.

$ dnsdbq -t TXT -r "bar/foo/baz" 
libcurl: 404 (https://api.dnsdb.info/lookup/rrset/name/bar%2Ffoo%2Fbaz/TXT?swclient=dnsdbq&version=1.3)
please note: 404 might just mean that no records matched the search criteria
libcurl: Error: no results found for query.

dnsdbq -t NS -i 127.0.0.1 -l 1 -d -d
requests URL https://api.dnsdb.info/lookup/rdata/ip/127.0.0.1?limit=1 having ignored the -t NS parameters. -i ip mode should reject -t rrtype being specified.

-O works for specifying an offset if used on the command line, but not if used in a $OPTIONS line of a batch file.

dnsdbq currently disallows -A later than -B:
dnsdbq -r ... -A 200 -B 100 -c
gets error error: -A value must be before -B value (for now)
and
dnsdbq -r ... -A 200 -B 100 also gets that error.

But the second case should be permitted

The README shows "make install". There is no "install" target in the Makefile.

nroff on macOS and debian stretch complains when processing the man page.

nroff -man dnsdbq.man 
mdoc warning: Empty input line #40
mdoc warning: Empty input line #48
mdoc warning: Empty input line #85
mdoc warning: Empty input line #99
mdoc warning: Empty input line #111
mdoc warning: Empty input line #206
mdoc warning: Empty input line #224
mdoc warning: Empty input line #234
mdoc warning: Empty input line #291
mdoc warning: Unknown list type `-offset' (or missing list type)
              in .Bl macro

Usage: .Bl {-hang | -ohang | -tag | -diag | -inset}
             [-width <string>]
             [-offset <string>] [-compact]
       .Bl -column [-offset <string>] <string1> <string2> ...
       .Bl {-item | -enum [-nested] | -bullet | -hyphen | -dash}
             [-offset <string>] [-compact] (#292)
mdoc error: .It without preceding .Bl (#293)
mdoc warning: .It macros in lists of type `'
              require arguments (#293)
mdoc error: .It without preceding .Bl (#296)
mdoc warning: .It macros in lists of type `'
              require arguments (#296)
mdoc warning: extraneous .El call (#299)
mdoc warning: extraneous .El call (#300)
mdoc warning: Empty input line #304
mdoc warning: Unknown list type `-offset' (or missing list type)
              in .Bl macro

Usage: .Bl {-hang | -ohang | -tag | -diag | -inset}
             [-width <string>]
             [-offset <string>] [-compact]
       .Bl -column [-offset <string>] <string1> <string2> ...
       .Bl {-item | -enum [-nested] | -bullet | -hyphen | -dash}
             [-offset <string>] [-compact] (#305)
mdoc error: .It without preceding .Bl (#306)
mdoc warning: .It macros in lists of type `'
              require arguments (#306)
mdoc error: .It without preceding .Bl (#309)
mdoc warning: .It macros in lists of type `'
              require arguments (#309)

dnsdb_query(.py) is expecting:

DNSDB_SERVER="https://api.dnsdb.info"

dnsdbq appears to need the following to function:

DNSDB_SERVER="https://api.dnsdb.info/lookup"

The manpage states:

"DNSDB_SERVER: contains the URL of the DNSDB API server (default is https://api.dnsdb.info)"

Doesn't build without curl_multi_wait support which is introduced in libcurl 7.28.0. (This failure was seen in Jenkins CI.) Debian Wheezy has older libcurl. Maybe some other projects have older libcurl too.

cc  -g -W -Wall -Wextra -Wcast-qual -Wpointer-arith -Wwrite-strings -Wmissing-prototypes  -Wbad-function-cast -Wnested-externs -Wunused -Wshadow -Wmissing-noreturn -Wswitch-enum -Wconversion -Wformat-nonliteral -Werror `curl-config --cflags`  -I/usr/local/include -c dnsdbq.c
dnsdbq.c: In function ‘io_engine’:
dnsdbq.c:1444:3: error: implicit declaration of function ‘curl_multi_wait’ [-Werror=implicit-function-declaration]
dnsdbq.c:1444:3: error: nested extern declaration of ‘curl_multi_wait’ [-Werror=nested-externs]
cc1: all warnings being treated as errors

This debian system has installed
libcurl3:amd64 7.26.0-1+wheezy24
libcurl4-openssl-dev 7.26.0-1+wheezy24