Is there a prime number whose…

Is there a prime number whose binary representation looks like a giraffe?

Yes!

like another prime number?

Yes!

like a prime number of giraffes?

YES!

like Squidward Tentacles?

Heck Yeah!

You’ve probably understood the mechanism by now. Converting a binary image into a number, its nearest upper prime generally only differ in the lesser significant bits, hence most of the image pattern stays the same. So finding a prime number whose binary representation looks like a specific image is relatively easy. I say relatively, because in a computer sens it is quite really complex.

I just wrote a program to do just that. It is written in C and uses GMP. It is around 1k SLOC. It could probably have been much shorter, and even less so in another language. But I wanted something that went a little further than just of simple proof of concept.

I must admit, it’s pretty useless. But still there it is. And there is still much room for improvement. So patches are welcome on GitHub.

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.