Building a Dynamic DNS Server for Your Enterprise?

Biff98 asks: "We manage thousands of hostnames for field gear with DynDNS.org. It's always been our intention of configuring our own DDNS server and bring it in-house. Given the recent DynDNS outage due to a DDOS attack, resulting in the inability to resolve names for multiple days, there has been 'encouragement' from management to move forward on bringing DDNS in-house. Here's the problem: I can't find any easy-to-use, scalable software to accomplish this task! BIND doesn't scale well, and I don't consider MintDNS an option due to the required platform (Windows Server w/ AD & IIS). Has anyone out there solved this problem before?"

Comments

Re:BIND does not scale???

[Spazmania]

Bind's implementation of dynamic dns is... funky at best. It syncs changes to disk infrequently and unpredictably, and it does so by rewriting the entire zone file in the same format as it uses for secondaried zones so that any comments or other organization in the affected file is lost. The security is also relatively coarse: the tools don't allow a particular security key to apply to a particular name -- the key applies to a whole zone. If you have a large number of devices and want to tightly constrict update access, that poses a scalability problem as you need one zone per device.

Dyndns is likely using Bind at the back end, but they've built another layer of security and management on top of it. Biff98 is looking for software that does the whole job out of the box.

Re:BIND does not scale???

[Just Some Guy]

The security is also relatively coarse: the tools don't allow a particular security key to apply to a particular name -- the key applies to a whole zone.

BIND9 addresses this with update-policy which can map an individual TSIG key to a specific name (or subdomain or wildcard). You can say that "key 'laptop23.example.com.' can update an A record with the same name".

I won't disagree about the dynamic zone file ugliness. I usually put dynamic hosts in their own subdomain so that my main zone file can remain nicely human-friendly. For example, we'd use ".mobile.example.com" and put it in its own zone file. The file for ".example.com" will still be nice, and if every record in ".mobile.example.com" is dynamic, who cares if it's a machine-generated mess?

Re:Use appropriate tools!

[Just Some Guy]

You can say a lot about DJB and his software, but you have to grant him that his code is very, very well written, and very secure.

No, I really don't have to. Since he's never actually released a program that supports more than 10% of the functionality of what it claims to replace, we have no idea whether he's capable of designing a large, secure system.

My BIND-based dynamic DNS depends on BIND not having a hole in the code that looks at the authentication key used to decide which records it can update. The DJBDNS "equivalent" requires that (in the grandparent's setup) DJBDNS, SSH, console access to their DNS server, their update scripts, and the conversion-and-aggregation makefile are all configured and working perfectly. Your "solution" requires the same, but replaces SSH+console with a webserver on your DNS server.

Your contention seems to be that those entire sets of applications are at least as secure as just using BIND in the first place, and frankly, I dismiss that out of hand. Even if you're a security expert and your particular setup is bulletproof, I doubt that the majority of people trying to juggle such a fragile setup are that capable. Ergo, DJBDNS is much less secure for the average person trying to get the same functionality that BIND ships with.

Re:Use appropriate tools!

[fimbulvetr]

DJB's software is "secure" because he can flat out deny vulnerabilities and all of his fans believe him and parrot it around for the rest of their servitude, despite there being realworld exploits for realworld configurations.

For us rational people, places like osvdb.org exist.

This doesn't even take into account the fact that 12 different patches with at least 2 or more of them being mutually exclusive are needed to make his software work. Indeed, these 12 patches are one offs usually written by one or two people and compromise the touted security of "DJB"'s godness.

PS if by "very well written" you mean hardcoded, very ugly code, using every hardware "trick" possible (thereby decreasing portability), you have an interesting perception of reality. I'll compare Postfix's coding style to Qmail's any day.

Consider an Appliance!

[Llama Keeper]

Have you considered an appliance solution?

I have several colleagues that have InfoBlox appliances in production and love the devices. I believe that they do a 30 day free evaul. Their units are reasonably priced and very feature full. Pre-sales engineering is pretty good too from what I've been told.