dig IPv6 Simplified Reverse Lookups
Summary
When using -x with IPv6 the only address that is accepted is properly handled is a /128. If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
Correct IPv6 Handling for an IPv6 /128
$ dig +noall +answer +question -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN PTR
8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. 86360 IN PTR msentry1.njwtech.com.
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN NS
Incorrect Handling for an IPv6 /32
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
$ dig -v
DiG 9.10.6
Steps to reproduce
Incorrect Handling for an IPv6 /32
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
What is the current bug behavior?
If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
What is the expected correct behavior?
Dig should recognize an IPv6 address by looking for a colon and convert what is provided to the nibble format. I think the issue would be recognizing IPs like 234::/16. Using the same format as for IPv4 dig would not be able to distinguish between IPv4 and IPv6 as dig NS -x 234 could be 234.in-addr.arpa. or 4.3.2.0.ip6.arpa. I suggest one of the following options for IPv6.
-
Ending a IPv6 address with a colon like 234: for 4.3.2.0.ip6.arpa., 2607:f8b0: for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
-
Using cider notation like 234::/16 for 4.3.2.0.ip6.arpa., 2607::/32 for 0.0.0.0.7.0.6.2.ip6.arpa., 2607:f8b0::/32 for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
-
Having a dedicated option -X (that's a capital X) for simplified IPv6 reverse lookups.
For more clarity on the expected output for IPv6, with IPv4 address the octets needed to represent a class A, B, or C zone can be entered with -x and dig will convert them to the IPv4 dotted-decimal notation. This is very useful if you are looking for zone level records like SOA, NS, DNSSEC, etc. Dig also accepts RFC 2317 zone names with -x which is useful for every RDNS record type. I have provided some examples below for reference.
Class A Example
$ dig +noall +answer +question NS -x 8
;8.in-addr.arpa. IN NS
8.in-addr.arpa. 86400 IN NS x.arin.net.
8.in-addr.arpa. 86400 IN NS z.arin.net.
8.in-addr.arpa. 86400 IN NS u.arin.net.
8.in-addr.arpa. 86400 IN NS r.arin.net.
8.in-addr.arpa. 86400 IN NS y.arin.net.
8.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
Class B Example
$ dig +noall +answer +question NS -x 8.8
;8.8.in-addr.arpa. IN NS
8.8.in-addr.arpa. 3600 IN NS ns2.Level3.net.
8.8.in-addr.arpa. 3600 IN NS ns1.Level3.net.
Class C Example
$ dig +noall +answer +question NS -x 216.139.200
;200.139.216.in-addr.arpa. IN NS
200.139.216.in-addr.arpa. 86172 IN NS ns1.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns4.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns2.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns3.esnet.com.
RFC 2317 NS Example
$ dig +noall +answer +question NS -x 24.96.81.192-28
;192-28.81.96.24.in-addr.arpa. IN NS
192-28.81.96.24.in-addr.arpa. 528 IN NS ns2.tvaoig.gov.
192-28.81.96.24.in-addr.arpa. 528 IN NS ns3.tvaoig.gov.
RFC 2317 PTR Example
$ dig +noall +answer +question -x 24.96.81.192-28.196
;196.192-28.81.96.24.in-addr.arpa. IN PTR
196.192-28.81.96.24.in-addr.arpa. 21586 IN PTR join.tvaoig.gov.
Relevant configuration files
N/A
Relevant logs and/or screenshots
See examples provided above.
Possible fixes
Not sure...