Thoughts – revising our DNS Control Panel

Give or take 10 years ago, I wrote a DNS control panel for Bind. We ended up rolling this out a little internally and ultimately it saved us a shedload of time – it’s still just about there 10 years later.

Now that I’m part of something bigger, redesigning this is not something I’d ever do (sadly!) – but it recently it came up in conversation, if I was doing this now, how would I do it, so this post is just some ideas brain stormed out.

The Old System

At the time, Bind-DLZ was a little, ropey (pretty sure its dead now) and I wasn’t convinced, not sure PDNS or certainly PDNS w/MySQL backend existed, so the old system went old school.

Front End – LAMP, which made changes to a central database, with a button named ‘push’ – think of this as commit – this then pushed an entry into a table defining that job:

 mysql> describe job_definititions;
| Field           | Type         | Null | Key | Default | Extra          |
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| hostname        | varchar(254) | NO   |     |         |                |
| type            | varchar(30)  | NO   |     |         |                |
| command         | varchar(30)  | NO   |     |         |                |
| zone_id         | int(11)      | NO   |     | 0       |                |
| status          | int(11)      | YES  |     | NULL    |                |
| updated         | int(11)      | YES  |     | NULL    |                |
| requester_email | varchar(254) | YES  |     | NULL    |                |

So basically, which server (hostname) to run on (primary or secondary), the command (CRUD) and a status.

Backend – cron jobs (PHP scripts)

The 2 DNS servers then polled via CRON the jobs table and actioned as needed – essentially writing out text files – zonedef files (the Bind zone definition) and/or the zone file itself on the primary, relying on AXFR to get to the secondary via an rndc reconfig.

Issues with that design

There’s a couple of design flaws with that – specifically – we have to allow our DNS servers access to the database – don’t like that, yes we’ve got mySQL permissions but I don’t like increasing an attack surface should 1 server be compromised – lets face it, Bind hasn’t had the best history but to be fair, which major deployed bit of software hasn’t.

How would I do this now ?

I don’t claim to know every bit of software out there, but more than likely it’d be hidden master – specifically a PDNS-MySQL master because i) it has its own API and ready-built software such as PowerAdmin to help us get the front end or at least something we can extend.

The ‘live’ servers, I’d try and use 2 vendors, but if we were using bind9, rather than write out zonedefs, I’d generate a quick CI based API which essentially would use rndc

rndc addzone  '{type slave; masters {; }; file "/etc/bind/";};'
rndc reconfig

Using this method we remove (other than open53 and an restricted API) access to any databases – as a secondary test, I’d also add a record to all zones, something like the below:

isp-test in A

Because then we can run scripts to test resolving that record – we always use serials to check zone version, but the above allows us to test a successful resolve.

Might quickly pull something together to test the theory, I do miss doing stuff like this.