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:
B
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 mydomain.com '{type slave; masters { 1.1.1.1; }; file "/etc/bind/db.mydomain.com";};'
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 192.168.0.1
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.
Comments are closed