Slashdot Mirror
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?"
I'm sorry, but are you discounting MintDNS because it's a Windows application, or because it would cost too much to implement? Only one of those two choices is fiscally responsible...
Compare the total cost of using any software, including Windows-based software, with the cost of rolling your own.
tasks(723) drafts(105) languages(484) examples(29106)
Exactly what do you think runs the bulk of the internet? That is like saying Linux or Solaris or sendmail do not scale well.
I prefer the "u" in honour as it seems to be missing these days.
Why don't you give PowerDNS a try?
.TK TLD.
:)
It has an authoritive component and a recursive one, both work extremely well and are in use by some big companies, as well as the Wikipedia and the
As for flexibility: PowerDNS uses backends to retrieve its zone data, so you can use one that's already available (MySQL, BIND zone files, SQLite, ODBC, etc.) or write one yourself.
Oh and it's opensource
BIND does indeed not scale well. Down, that is.
http://www.powerdns.com/
:/
I used it when I was running an ISP a few years ago. Used a replicated MySQL backend behind three authoritative servers. Also used dnscache for recursors in front of all the customers.
All your zone data is stored in DB tables, so it's easy to hack together a frontend, or integrate with CRM or whatever. I wish Rails had existed back then for all the CRUD that I wrote by hand.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
There is no DNS problem that djbdns cannot solve. None! None I tell you! Don't listen to the heathens....
Microsoft is trying something like this with PNRP (peer name resolution protocol)
. mspx
-> http://www.microsoft.com/technet/network/p2p/pnrp
This might prove a viable way to establish a decentralized DNS in the future. Version 2 of the protocol ships with Vista.
Makes me wonder what Apple will come up with next in that field.
"morning is a state of mind
[snip Rube Goldberg replacement for RFC standards]
There's a reason people hate DJBDNS. Instead of just implementing the mechanism that everyone else in the entire world uses, Dan wanted to be Dan so he wrote an incompatible mess and called it "good". Of course DJBDNS has a decent security record - it doesn't actually do anything. I'd wager large amounts of money that more systems have been compromised due to all the half-assed hackery required to give it half the features of BIND than because of BIND itself.
BIND uses TSIG to let users update specific records that have been assigned to them. Your hack around DJBDNS's shortcomings lets you give out shell accounts to people so they can run shell scripts on your server that are hopefully so well written that they can't possible be fed bad data, then runs some stuff as root to glue it all together.
"Easy as pie," you say, "and all it needs is `ssh` and `cron`." I prefer "easy as pie: it's already included and known to work".
Dewey, what part of this looks like authorities should be involved?
There's a reason people hate DJBDNS. Instead of just implementing the mechanism that everyone else in the entire world uses, Dan wanted to be Dan so he wrote an incompatible mess and called it "good". Of course DJBDNS has a decent security record - it doesn't actually do anything. I'd wager large amounts of money that more systems have been compromised due to all the half-assed hackery required to give it half the features of BIND than because of BIND itself.
:)
I would take that with a very large grain of salt. In fact, most of a salt container.
You've obviously never used tinydns/djbdns. It just works. It serves dns records, and it does that job well, and it's very secure. It doesn't have the poor code quality and 50 gazillion other features that have made Bind the, well, security nightmare that it has been. Admittedly things have been a *lot* better since Bind 9 came out - but wasn't there another security problem with Bind 9 a couple of months ago? I can't even *remember* when there was a security problem with any part of djbdns. 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.
Anyway, back to the topic - I have been running a dyndns-style setup for years now using tinydns. I simply wrote a script that mimics the dyndns web update page, which means it's compatible with any dyndns client out there, provided one can set the server IP address (which most clients support now).
The script updates a database, from which the tinydns files are generated every minute. Of course you could make the script update your tinydns 'zone file' directly; one of the advantages of using tinydns is that its data format is easy to parse - which is about the last thing that can be said of Bind's zone file format...
This setup works like a charm for me and all my customers. It's one of those 'configure once and then forget about it' setups
http://ward.vandewege.net/blog/
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.
Dewey, what part of this looks like authorities should be involved?
I've used djbdns for 2 years serving 4000+ internet domains, caching nameservers on lans, and all that fun stuff that makes DNS so "intresting". Tinydns is a great piece of software if you know what you're doing, but for someone with little or no experience with DNS there is too little proper introduction documentation. Zone transfers between master and slave servers usually have hacky setups as novice admins do really stupid things here making your machine insecure (not djbdns' fault). Google for a couple of tinydns examples and you're bound to hit one that has a major security flaw in it in the first 10 hits.
Bind has the advantage of being mentioned in nearly any book on DNS, used in example configurations, and usually doesn't mean you're stuck with an unreadable log file (unless you know the tools), an obscure startup mechanism (unless you've invested time to get acquainted with the tools), and a syntax for setting records that no tools except DJBs use.
Again, djbdns is a good software package, and I can't really complain about it since it worked so well for me in the past, but I do wish it was a little less obscure in aforementioned areas so I didn't need a perl script to convert my dates in my logfile into a readable format, or need to start thinking differently when adding records.
Again, it's a great tool, if you have reasons enough to stay away from bind.
Not quite. I don't give out shell accounts: clients -- in this case, run by me -- connect to one shell account and authenticate by public key. I trust SSH's ability to authenticate a remote user far more than I do BIND's. The incoming connections don't get to run shell scripts; the
You're right. It's not "standard dynamic DNS". It uses stronger authentication, programs that are already installed on the client machines I'm interested in (embedded systems with 4 MB of flash), and is trivial to set up.
Not that I don't take issue with the way you're phrasing the functionality argument, but I don't feel like wasting time. You have somewhat of a point there, with the large caveat that as far as I know DJB doesn't claim to replace anything at all - he just offers an alternative to Bind in the unix philosophy of writing software that does one thing and does it well.
As for your claims of 'having to run a web server on your dns server' - that's nonsense. If you're running a dynamic dns service, you might perhaps already *have* a web server?
Seriously. You sound like you have not understood the power of modularity - one of the fundamental aspects of unix-like systems that make them the powerful tool they are.
I'm not talking about the majority of people. I think you're reading a bit more in what I wrote than what I intended. I was merely taking objection to your outright dismissal of tinydns as a possible solution to this problem. I think that's not fair. Arguably, I wouldn't want people who are incapable of setting up tinydns in a secure way (it's not *that* hard) in charge of my DNShttp://ward.vandewege.net/blog/
Have you looked at DJB's tinydns with dynamic capabilities wrapped around it? I know for a fact djbdns scales, but I dunno how well scripts wrapped around it work.
"TinyDYN
In a nutshell, TinyDYN consists of a set of scripts that allow you to run your own dynamic dns services (similar to dyndns.org) on your own network. The services use strong authentication via GnuPG, and is designed to work with djbdns's tinydns for name service."
http://www.technocage.com/~caskey/tinydyn/
Here's to the crazy ones
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.
I'm just throwing this out here, but why not contact the people at DynDNS.org and ask about licensing their software (or process, or however they do it) for your internal use. It could solve your problem (and maybe quicker than rolling your own solution), and at the same time potentially create a new revenue stream for them.
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.
Rule of Life Number 2: Remember, it can all go to hell at any minute. --Jimmy Buffet
It tells me there are no results. What is your point, exactly? Who's the rational person here - you for claiming mythical security vulnerabilities that don't seem to exist in your 'resource for rational people' osvdb.org, or me for saying that djbdns is a piece of code that has a history of being very secure, with *no known security problems whatsoever*?
Stop wasting everybody's time.
http://ward.vandewege.net/blog/
http://ward.vandewege.net/blog/
http://www.dns.net/dnsrd/servers/unix.html
http://osvdb.org/searchdb.php?action=search_title& vuln_title=qmail&Search=Search
I was covering all DJB's software, not just $somethingdns. Just because it's written by djb, doesn't mean it's secure.
With Incognito's DNS Commander authoritative server, you can use DDNS to populate millions of records. I think this should solve the scalability issue that you were concerned about. And if you prefer non-windows centric software, DNS Commander also runs on Linux/Solaris. Also, I'm pretty sure it uses a binary database instead of text files, and it doesn't require dbms. Are you integrating this with OSS? DNS Commander offers a CORBA API for 3rd party integration, if necessary.. Have a look at www.incognito.com
I've been using MaraDNS quite happily. Never a problem on FreeBSD, Slackware or OS X. The developer is very responsive, and the documenation is very very good, unlike that for some other alternative DNS daemons *cough*tinydns*cough*
The zone syntax and config file structure is worlds ahead of BIND and actually makes setting up DNS fun (no, I'm not kidding. Well-written software is always a pleasure to use).
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
We too manage a lot of customer sites behind dynamic IP connections. We have the advantage of there being servers at every location where we can run our own code. We have a simple (PERL) program run out of cron once an hour to connect to one of our servers on a high port and pass through some information unique to the site. On the server end is another program (PERL again) that receives the messages, does an in-RAM check (a simple associative array) to see if this IP is any different than the last one we saw for this site, runs nsupdate (yes BIND is working fine for us) to push the new IP into the zone if it has changed.
So now when I want to connect to a particular customer site via ssh, vnc, rdp, whatever.. I just connect to customername.customerstate.customertype and never worry with what the IP is.
Oh, and if BIND has scalability issues, I suspect it's somewhat beyond your "few thousand hostnames" point. We're dynamically updating a few hundred names in a server that is managing a few thousand hostnames without taxing it much at all.
I must have completely missed this outage. According to their status page there were some attacks against their update system, but I never had any issues resolving names, either for my domains hosted with them, or with my free hosts.
DUDE!! take a look at GnuDIP. It's do-it-yourself GPL and free Dynamic DNS system. It interfaces with a standard BIND installation so you basically register a domain, then add hosts to your domain, and they can automatically update from a client installed on remote equipment. Give it a try. http://gnudip2.sourceforge.net/
With simple recipes available that offer an implementation of DNS: http://aspn.activestate.com/ASPN/Cookbook/Python/R ecipe/491264 one could easily plug it into any one of a number of databases. Add a very simple HTTP front end for updating name/IP information in the database, and you are done.
>PNRP... Makes me wonder what Apple will come up with next in that field.
How about Zeroconf (Bonjour)?
You can already use Zeroconf to replace DNS, DHCP, and SMB(NMB) and uPNP... among other things. It's a broadcast discovery and configuration service. Now of course broadcast does not directly run across router links/subnets unless you make it so (on the other hand, any chatty P2P can be routinely blocked by admins).
Zeroconf is not an Apple-only solution.. lots of the tier-one printer companies and consumer-level NAS hardware providers have products or projects which employ zeroconf.
It's funny how work began on PNRP after Bonjour landed in the hands of Apple testers, and almost 4 years after Apple's publication of their working group specs. This is just Microsoft catching up...
Well i own a Macbook Pro since last Saturday, sure i've heard about Bonjour and Zeroconf but from what i have learned about it Microsoft seems to take its PNRP thing one step further, even using it do distribute computing tasks as they say in some introduction video i've seen.
Thats why i wonder how apple will respond to it and if we might be on the verge of a whole new personal computing era where you can contribute parts of your laptops computing power to the local super computing cluster grid.
Btw. avahid has some rather peculiar hard limits on the amount of mdns messages it passes through as a friend found out on a 300 people gathering we ran the network for - there's still much work to do in the field i fear.
"morning is a state of mind
But one of the main *points* of building a system like that, (other than expressing one's personal crabbiness about the rest of the world :-) is that by building components with limited functionality and using pre-existing standard tools to do the things that pre-existing standard tools already do well, you can restrict the security exposure of your new components, and can design them to use only the privileges and powers they need to get their jobs done, generally be small enough to debug, and be small enough to fix bugs in without introducing significant new vulnerabilities. The Unix design philosophy of building small tool components that you can use together as opposed to large monoliths was valuable two decades ago when we were still using Vaxen and Sun-3s, and it's still valuable today.
Most of the time you don't *need* anywhere near 10% of the features of BIND - usually you don't even need 50% of the features of DJBDNS either. BIND isn't quite the Mos Eisely kitchen sink of network protocol applications, because that honor goes to Sendmail, and both of those systems *have* improved a lot in the last few years, but it has justly acquired a reputation of having been a quick hack from two decades ago that's grown into an ancient shambling horror of creeping features.
There are small applications where something simple like DJBDNS is enough. There are a reasonable range of applications where it's not, and for some of them BIND is a good choice, or some of the newer alternatives. And then there are applications that are complex, as opposed to large, where what you need is really a relational database system with some front-ends to provide DNS-lookup interfaces, and for those you might want to roll your own if there aren't good tools available already - otherwise you'll find yourself writing hunks of perl scripts to extract data from the database and turn it into BIND input and vice versa.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks