NID and L64 presentation format in DiG is not RFC compliant
Summary
The presentation format used in DiG for the L64 and NID record types is incorrect, it omits leading zeroes in each hex part.
BIND version used
$ dig -v
DiG 9.16.12
$ named -V
BIND 9.16.12 (Stable Release) <id:aeb943d>
running on Linux x86_64 5.11.1-arch1-1 #1 SMP PREEMPT Tue, 23 Feb 2021 14:05:30 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--enable-dnsrps' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
threads support is enabled
Steps to reproduce
- Create a zone with an L64 or NID record with hex digits that are not padded out, e.g.:
1.foo.example. 3600 IN L64 10 0000:0000:0000:0001
1.foo.example. 3600 IN NID 10 0000:0000:0000:0001
- Use
dig
to query the nameserver
dig +norec @127.0.0.4 -p5300 1.foo.example NID +short
10 0:0:0:1
What is the current bug behavior?
See above, the presentation value is set to 0:0:0:1
.
What is the expected correct behavior?
The presentation format should be 0000:0000:0000:0001
.
RFC 6742 section 2.1.2 on NID records states:
- The NodeID field MUST be represented using the same syntax (i.e.,
groups of 4 hexadecimal digits, with each group separated by a
colon) that is already used for DNS AAAA records (and also used for
IPv6 interface IDs).
- The NodeID value MUST NOT be in the 'compressed' format (e.g.,
using "::") that is defined in RFC 4291, Section 2.2 (2). This
restriction exists to avoid confusion with 128-bit IPv6 addresses,
because the NID is a 64-bit field.
The examples in section 2.1.3 make it clear that leading zeroes are not to be omitted:
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN NID 20 0015:5fff:ff21:ee65
host2.example.com. IN NID 10 0016:6fff:ff22:ee66
As NodeID values use the same syntax as IPv6 interface identifiers,
when displayed for human readership, the NodeID values are presented
in the same hexadecimal format as IPv6 interface identifiers. This
is shown in the example above.
There is similar language in section 2.3.2 and 2.3.3 on L64 records, where the examples also show that leading zeroes are expected in the presentation format.
Relevant configuration files
None really, I tested with DiG against a PowerDNS auth with a zone that had the content shown in the reproduction steps.
Relevant logs and/or screenshots
drill
(version 1.7.1 (ldns version 1.7.1)
) seems to include the leading zeroes:
drill @127.0.0.4 -p5300 1.foo.example NID
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 46417
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.foo.example. IN NID
;; ANSWER SECTION:
1.foo.example. 3600 IN NID 10 0000:0000:0000:0001
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.4
;; WHEN: Mon Mar 1 13:44:14 2021
;; MSG SIZE rcvd: 53
Possible fixes
I don't know the BIND codebase, but probably the place where the conversion from internal to presentation format happens. :)