Tag Archives: nsd

IPv6 rDNS stub-zone on unbound

Posted on by
Reply

We have stub-zones configured on our gateway for reverse IPv6. Our ISP doesn’t delegate rDNS but we still want to lookup addresses (at least on the local side). To do so I configured a stub-zone from unbound, our local caching DNS, to our own rDNS authoritative server. Apparently unbound wants an IPv6 for its IPv6 rDNS queries to the stub-zone. Since IPv6 is not always working I solved that using the local interface. That is, the rDNS authoritative listen on localhost:5353 and unbound uses this as its stub-zone addresses.

On the authoritative (here NSD):

 ip-address: ::1@5353
 ip-address: 127.0.0.1@5353
 do-ip6: yes

On unbound, note that we need do-not-query-localhost: no to allow queries on localhost:

 do-not-query-localhost: no

stub-zone:
 name: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 stub-addr: ::1@5353
 stub-addr: 127.0.0.1@5353

IPv6 representation in NSD

Posted on by
Reply

I use NSD as my authoritative DNS. Today I made a mistake while entering new AAAA records. Actually it was a bug in one of the scripts we use to manage our zones. Take the following representation, 2001:aaaa:bbbb:cccc::1111:2222:3333:4444, it is not a valid representation for an IPv6 address. According to the RFC4291, the double-colon symbol (::) indicates one or more groups of 16 bits of zeros. Since 8 groups of 16 bits are explicitly written in the preceding representation, the 128 bits of the IPv6 address are already detailed so there can be no extra group of zeros. The reason I made this mistake is that if you often work with /48 prefixes and you don’t care about your 65k subnets, all your IPv6 addresses will have zeros between the prefix and the interface ID.

Most programs will detect this as invalid, probably because they use inet_pton() to translate the address into its binary representation. Some others, such as ipv6calc parse the address manually and do not consider this as a buggy representation. In the latter case, the group is considered empty, and the double-colon implicitly translated to a single colon.

If you use this kind of invalid representation in a AAAA record, NSD will not reload your zone correctly, but on the other hand, neither will it complain and the queries will be made on a database that still contains your old zone. Of course this would not happen if you used nsd-checkzone to check your zone before reloading it.