dnsdbq slash quoting issue
djw1149 opened this issue · 3 comments
I was having trouble searching for a value that contains a slash.
My conclusions:
- We should, at least, document that the "-t RRTYPE" option should appear on the command-line before a -n or -r switch.
- It would be better, but not backwards compatible, to require that (and fail the command).
- 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.
An additional bug in this area.
The following is correct:
$ dnsdbq -r a.b.c.d/AAAA -t A
error: can only specify rrtype one way
try dnsdbq -h for a short description of program usage.
The following "obviously" should trigger an error like the first dnsdbq gets:
$ dnsdbq -t A -r a.b.c.d/AAAA
libcurl: 404 (https://api.dnsdb.info/lookup/rrset/name/a.b.c.d%2FAAAA/A?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.
I think that the bug is that if either the -b BAILIWICK or -t RRTYPE options are specified then the -r option should not allow / in its value. (Already, -i, -R, and -n fail if -b is specified, which is good.)