incorrect in-addr.arpa input handling
Closed this issue · 2 comments
echo 123.224.33.199.in-addr.arpa | ./zdns PTR --name-servers 8.8.8.8 | jq
{
"error": "dns: unrecognized address: 123.224.33.199.in-addr.arpa",
"name": "123.224.33.199.in-addr.arpa",
"status": "ILLEGAL_INPUT",
"timestamp": "2023-12-04T17:08:15Z"
}
zdns expects input for PTR lookups to be IP addresses. While conversion from IP address to the DNS name is convenient, the correct input is actually the in-addr.arpa form. Zdns should accept and use it.
Same for IPv6:
echo f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.5.1.8.0.2.0.6.2.ip6.arpa | ./zdns PTR --name-servers 8.8.8.8 | jq
{
"error": "dns: unrecognized address: f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.5.1.8.0.2.0.6.2.ip6.arpa",
"name": "f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.5.1.8.0.2.0.6.2.ip6.arpa",
"status": "ILLEGAL_INPUT",
"timestamp": "2023-12-04T17:10:16Z"
}
Among other problems, this makes it impossible to look up PTR records in other zones. For example:
echo cnameptrtest.dirtside.com | ./zdns PTR --name-servers 8.8.8.8 | jq
{
"error": "dns: unrecognized address: cnameptrtest.dirtside.com",
"name": "cnameptrtest.dirtside.com",
"status": "ILLEGAL_INPUT",
"timestamp": "2023-12-04T17:15:57Z"
}
nslookup -q=PTR cnameptrtest.dirtside.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
cnameptrtest.dirtside.com name = acnamename.dirtside.com.
I would support accepting both inputs for the PTR module, there's no real ambiguity between the two when doing a PTR lookup. I agree that the IP address input should be treated as a "shortcut".
Not sure how to do a pull request associated with somebody else's github, so here's a patch instead: