Posts Tagged ‘DNS’

On our new DNS infrastructure (and DNSSEC)

Thursday, August 15th, 2013

Recently we’ve been busy implementing a new DNS infrastructure for our resolvers as well as our authoritative servers. We wanted to be ready for future developments like DNSSEC and we wanted to re-new this important part of our infrastructure for a while. This blog-post gives an overview of our new setup.


Publishing EC2 scripts on GitHub

Friday, April 29th, 2011

We’re glad to announce that we’ve published our set of EC2 scripts on GitHub! The kuminami repository contains current versions of the code described in these two blog posts:

In addition, the repository also contains the infrastructure to package the instance spawn script and the DNS syncer as a Debian package.

Automatically creating entries in PowerDNS for Amazon EC2 instances

Monday, April 18th, 2011

By default, instances created on Amazon EC2 will have a randomly assigned IPv4 address. It is however possible to pin instances to a preallocated IP address. These IP addresses are called Elastic IPs. Because IPv4 addresses are becoming very scarce, Amazon only allows a customer to allocate up to five Elastic IPs. Even though Elastic IPs are free to use when attached to a running instance, they come at a cost of $0.01 per hour unused.

Because of these two limitations, we have decided to simply use the randomly assigned addresses, which is why we’ve written a script to automatically create DNS entries in PowerDNS for instances managed through EC2. (more…)

Monitoring DNS server synchronicity

Monday, April 4th, 2011

We, along with some customers, have our authoritative DNS setup with 1 PowerDNS master (which is unreachable over the internet), running poweradmin, and 2 BIND9 slaves (which are ns1 and ns2). This setup works great, but there is a bug in (older versions of) PowerAdmin and one in BIND that together can cause some havoc.

PowerAdmin does not validate input. For instance it is possible to have a CNAME and an A record for the same hostname. When BIND sees that there is a CNAME and A record for the same hostname, it stops serving the entire zone the hostname is in (you can see where this is going right?).

This, along with our need to check if the master and slaves are in sync (or not out of sync for too long during an {I,A}XFR), gave us the idea of making a nagios-check for it. So without further ado, the help: