IPv6 representation in NSD

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.

Today’s movie: They Live

I thought you understood. It's business, that's all it is.

I thought you understood. It’s business, that’s all it is.

I’ve been confronted to a lot of 80s synth music lately so this prompted me to watch some John Carpenter classic, and here it is directly from 1988, They Live. Full of catchy lines, is it an allegory, a fantasy or just a documentary?

What do parrots and BGP routers have in common?


David Hauweele, Bruno Quoitin, Cristel Pelsser, Randy Bush


The Border Gateway Protocol propagates routing information accross the Internet in an incremental manner. It only advertises to its peers changes in routing. However, as early as 1998, observations have been made of BGP announcing the same route multiple times, causing router CPU load, memory usage and convergence time higher than expected.

In this paper, by performing controlled experiments, we pinpoint multiple causes of duplicates, ranging from the lack of full RIB-Outs to the discrete processing of update messages. To mitigate these duplicates, we insert a cache at the output of the routers. We test it on public BGP traces and discuss the relation of the cache performance with the existence of bursts of updates in the trace.

See the article on CCR online

Download the full article