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

Not an option?

[Short Circuit]

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.

Re:Not an option?

[Aladrin]

So, you're saying you think it might be cheaper for an completely non-windows shop to set up a windows server solely to run their dynamic DNS and then hire someone that knows how to keep it running rather than find a solution that runs on their current OS of choice?

If they've decided that they don't want Windows machines in their shop at all, it isn't very likely to be cost-effective to have one there.

Re:Not an option?

[Short Circuit]

So, you're saying you think it might be cheaper for an completely non-windows shop to set up a windows server solely to run their dynamic DNS and then hire someone that knows how to keep it running rather than find a solution that runs on their current OS of choice? He didn't say they were a non-Windows shop, though he did say that he wasn't considering MintDNS because it ran on Windows. His original statement read more like a matter of taste, to me.

All I'm saying is that they should compile estimates of actual costs, rather than simply assuming one option would be too expensive.

Re:Not an option?

[Hack'n'Slash]

There's nothing wrong with allowing one's previous experience to influence current decisions.
 
Let's say I've had troubles with a couple of EMC boxes and haven't had much luck with their support. Would you criticize me for excluding EMC products from future storage purchases???

Re:Not an option?

[Just Some Guy]

Compare the total cost of using any software, including Windows-based software, with the cost of rolling your own.

Don't forget to include the cost of getting escrowed access to the source code so that you're not totally screwed if they stop making MintDNS and it can't be made to run on the next version of Windows.

Honestly, F/OSS owns the network infrastructure category. I can see no reason whatsoever to use a proprietary solution when this is already a solved problem.

Re:Not an option?

[Aladrin]

Why would a shop with Windows boxes reject a piece of software on the basis that it runs on Windows?

I suppose it's vaguely possible that they are trying to get rid of the Windows boxes, but that places them back in the category of 'non-Windows shop.'

The only other option I see is that it's his personal preference and not the company's. In that case, you are correct, he might be making a poor decision. I tend to assume people have a modicum of sense until they've proven otherwise, though.

Re:Not an option?

[Short Circuit]

Why would a shop with Windows boxes reject a piece of software on the basis that it runs on Windows? Because they may not have a Windows Server license, or because they may not use Active Directory.

The only other option I see is that it's his personal preference and not the company's. In that case, you are correct, he might be making a poor decision. I tend to assume people have a modicum of sense until they've proven otherwise, though. That's the possibility I was cautioning against. This being Slashdot, and considering the way the question was written, it seemed like an appropriate caution.

Re:Not an option?

[clark0r]

by the sound of it, they don't have the necesarry AD infrastructure to support that solution. implementing AD for this purpose will be expensive and costly in time.

Re:Not an option?

[pyite69]

Windows is not a server platform - it is for desktops only.

Re:Not an option?

[dbIII]

I'm sorry, but are you discounting MintDNS because it's a Windows application, or because it would cost too much to implement?

I would say both if you don't already have some MS Windows servers. Redundancy and licencing alone (licence for the hot or cold spare in addition the the real server) makes it a hassle.

BIND does not scale???

[WindBourne]

Exactly what do you think runs the bulk of the internet? That is like saying Linux or Solaris or sendmail do not scale well.

Re:BIND does not scale???

[fimbulvetr]

That's exactly what I was thinking. There's only one reason this douchebag is asking this question, and that's because he knows fuckall if he thinks reading some DJB rant has made him experienced in the dns.

Bind9 on debian etch with views takes all of 1.5 minutes to set up, and a sub 1ghz/512mb machine could easily serve the domain he's describing.

Re:BIND does not scale???

[pete-classic]

You stole my post.

BIND has been demonstrated to be inherently scalable. If the problem is that some DDNS piece doesn't scale, why not pay someone to fix that?

It'd be nice if you provided such a fix upstream, but it's BSD so you'd never be obligated to do so.

-Peter

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???

[WindBourne]

Actually, ddns does scale nicely. If you have static ips, then the flat file is fast since they are normally sucked in 1 x and then sit in memory. But with DDNS, there are updates. That is where flat files fail. So you add one of the DB options (postgres, mysql, and sqlite are ALL good options; I have seen amazing speed out of sqlite when doing lots of updates), and now it is VERY fast. I believe that a number of the distros (linux and BSD) have compiled bind to use optional DBs.

Re:BIND does not scale???

[Anonymous Coward]

BIND doesn't scale well

I was also incredulous when I read this. This guy does not have long in the business.

Additionally, a dynamic DNS solution is not really necessary from the sound of it, they just need to have their field gear phone home periodically to report their current public IP addresses.

Re:BIND does not scale???

[baadger]

It'd be nice if you provided such a fix upstream, but it's BSD so you'd never be obligated to do so.

Technically even if it was GPL'd you'd never be legally obligated to provide the source (or a patch against it) unless you was distributing your modified version as a binary

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:BIND does not scale???

[pete-classic]

Did you just really point out the difference between "never" and "unless"?

-Peter

Re:BIND does not scale???

[Anonymous Coward]

Did you totally miss the point of the comment you are replying to?

Re:BIND does not scale???

[JFitzsimmons]

He didn't, but you clearly did.

Re:BIND does not scale???

[JFitzsimmons]

... which is exactly how every single dynamic DNS service I've seen works.

Re:BIND does not scale???

[Biff98]

I don't like to think of myself as a douchebag :-). I'm a BIND guy, I just am. I actually picked up the NEWEST edition of O'Reilly's "DNS & BIND" (5th edition now just in case you were curious), and read about just how hard it is to maintain a LARGE number of dynamically updateable host records. You've got key-pairs for each records, and you've got no other way than port 53 to update records.

Roll my own, yeah I know, but remember, I'm not a developer and I'm currently using DynDNS.org which has HTTP updates (required in my case) and a nice web gui that non-nerds can manage. I need a (shudder) "turnkey" solution.

-Steve

Re:BIND does not scale???

[pete-classic]

Thanks for the back up, but I think it is generally better not to encourage ACs.

-Peter

PowerDNS

[PsyQo]

Why don't you give PowerDNS a try?

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 .TK TLD.
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 :)

Re:PowerDNS

[num42]

even better, its GPL.

A better place to point slashdot people to is http://doc.powerdns.com/

the shiny official site does not provide all the geeky information that we hunger for.

Re:PowerDNS

[Miniluv]

I have to say PowerDNS is awesome. I've been using it for a quasi-dynamic DNS deployment of a tens of thousands of A records using the MySQL backend. Its more stable than my traditional BIND servers, and offers better insight into what its doing through both a simple web interface for stats and meaningful logs.

BIND doesn't scale well

[JackHoffman]

BIND does indeed not scale well. Down, that is.

Re:BIND doesn't scale well

[Anonymous Coward]

Explain in 100 words or less why BIND would scale for Dynamic records to more than a 100 or 200 host records? Perhaps the better reply is "Go read about DDNS & BIND (you got your O'Reilly handy right?) and then post."

PowerDNS

[JerkBoB]

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. :/

Use appropriate tools!

[Anonymous Coward]

Use the right tool for the job! That's up there with "measure twice, cut once".

In my opinion, BIND doesn't fit well here primarily because of its zone transfer mechanism, before even getting to scalability, security, or other issues. Look at tinydns. It's a DNS server that makes no assumptions about where your zone data comes from, how it's transferred, or how often it's updated -- all it does is serve requests from a simple flat-file database that can be regenerated from source data and replaced atomically. It does this correctly, securely, and efficiently.

Now, you've got a DNS server that goes out of its way to stay out of yours. All you need to do is feed it data. Pick whatever leverages your existing infrastructure: maybe you build a PHP/PostgreSQL application to deploy to your existing load-balanced web farm, maybe you have all your field equipment make TCP connections to a service you deploy, whatever. `tinydns-data`, the program that builds said flat-file database, would do what you want with data like:

=sensor-a.someclient.ny.us.hyperglobalmegacorp.com :1.2.3.4:60

Feed it a bunch of those on standard input, close, and you're done -- the DNS server will start serving your new data. You could write a script to do this on each of your DNS servers independently, all sourcing directly off your backend, no zone transfers needed.

I've done this on a small scale. It took me about five minutes to set everything up, client and server. I added an account to the clients and the server and set up SSH public key authentication. The clients periodically ssh into the server by cron, the server looks up their public key and runs my updater with the appropriate parameters (e.g. `/home/dyndns/update sensor-a.someclient.ny.us`). The updater reads the $SSH_CLIENT environment variable to find the IP that's it's connected to, writes it to the appropriate file (~/data/hostname), and calls `make`. The makefile there simply `cat`s the data/* together into a single file which gets replicated onto a half dozen nameservers. Easy as pie, and all it needs is `ssh` and `cron`.

Re:Use appropriate tools!

[Anonymous Coward]

Hilarious.

1. clients periodically ssh into the server by cron
2. server runs updater
3. updater writes file and calls `make`
4. makefile `cat`s the data/* together into a single file

Yeah. That will scale much better than bind.

Re:Use appropriate tools!

[Anonymous Coward]

This works fine for a half dozen clients with dynamic IPs. It's not an argument for or against tinydns -- the nameservers were already running it, and again, it took five minutes to set up and have working.

You'll also note that's not at all what I'm suggesting for thousands of dynamic addresses.

Re:Use appropriate tools!

[Just Some Guy]

I've done this on a small scale. It took me about five minutes to set everything up, client and server.

[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".

Re:Use appropriate tools!

[LinuxOnEveryDesktop]

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 :)

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!

[discord5]

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.

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.

Re:Use appropriate tools!

[Anonymous Coward]

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

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 .ssh/authorized_keys looks like:

command="/home/dyndns/update hostname.fqdn.com",no-port-forwarding,no-pty ssh-dss AAAAB3Nza...

This makes SSH call the script and only the script. The shell script consists of:

#!/bin/sh
IP=`echo $SSH_CLIENT | egrep -o '([0-9]{1,3}\.){3}[0-9]{1,3}'`
 
[[ ! -z "$IP" ]] && echo $IP > ~/data/$1

`sshd` sets $SSH_CLIENT, regardless of everything else. If it somehow doesn't contain an IP address, it won't update. Nothing is used from standard in or standard out. SFTP, SCP, and SSH port forwarding are all disabled.

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.

Re:Use appropriate tools!

[Anonymous Coward]

Since he's never actually released a program that supports more than 10% of the functionality of what it claims to replace ...

Really?

• tinydns claims to be an authoritative DNS server
• dnscache claims to be a recursive resolver
• qmail claims to be a "secure, reliable, efficient, simple message transfer agent"
• cdb claims to be a "fast, reliable, simple package for creating and reading constant databases"
• djbfft claims to be "an extremely fast library for floating-point convolution"

Which of these provides only a tenth of the claimed functionality?

The djbdns programs are known to be smaller and simpler than BIND. That's by design. They don't claim to do everything BIND does: they claim to do one thing, and are built to do that one thing very well. Compare to BIND, which tries to do everything by itself. BIND has its own zone transfer protocol and its own notification system, djbdns prefers to use smaller, purpose-built tools to accomplish the tasks that they're good at (e.g. rsyncing zone files instead of IXFR). BIND needlessly mixes authoritative serving with recursive resolving and suffers as a result, djbdns does not. BIND has a list of security issues as long as my arm, djbdns does not.

... 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.

So, you're saying the software is bad because the user can misuse it?

Re:Use appropriate tools!

[LinuxOnEveryDesktop]

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.

You're not listening are you? I'm saying that the software DJB writes is very, very well written and very secure. Period. I'm not claiming anything about 'functionality it claims to replace'.

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.

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.

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 DNS :)

Re:Use appropriate tools!

[Anonymous Coward]

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?

Not on the DNS server, though! For all your talk of the "Unix way", your plan would turn a single-purpose DNS server into a web server, rsync server (if you want to use slave servers for redundancy), SSH server, and so on. I think the GP just wants his DNS server to be a DNS server. That sounds like a pretty good idea and more unix-y.

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.

Re:Use appropriate tools!

[LinuxOnEveryDesktop]

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.

I don't have time for this nonsense. Do a search on osvdb.org for tinydns. Do one for djbdns. Any hits?

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.

Re:Use appropriate tools!

[LinuxOnEveryDesktop]

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?

Not on the DNS server, though! For all your talk of the "Unix way", your plan would turn a single-purpose DNS server into a web server, rsync server (if you want to use slave servers for redundancy), SSH server, and so on. I think the GP just wants his DNS server to be a DNS server. That sounds like a pretty good idea and more unix-y.

That's of course what I meant - you already have a web server, that is *not* running on your dns server.

Re:Use appropriate tools!

[fimbulvetr]

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.

put it differently ...

[Anonymous Coward]

what is x to BIND, that is PHP/Perl/Python/etc. to apache.
seems to be a fillable lucrative void ...

maybe someone can make a "swarm" version of DNS.
they did it for FTP.

Re:put it differently ...

[num42]

Microsoft is trying something like this with PNRP (peer name resolution protocol)

-> http://www.microsoft.com/technet/network/p2p/pnrp. mspx

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.

Raving Fanatism

[mac1235]

There is no DNS problem that djbdns cannot solve. None! None I tell you! Don't listen to the heathens....

Dumb point on your sig.

[WindBourne]

By definition, the 2'nd fattest girl is skinny. Skinny and fat are relative in terms of what we accept. For example, many ppl accept Calista Flockhart as being skinny. But if somebody from Ethiopia say 10 years ago saw her, they would have considered positively FAT.

Does tinyDNS scale?

[flydpnkrtn]

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/

Talk to DynDNS

[b.thompson]

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.

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.

Re:Consider an Appliance!

[billstewart]

InfoBlox is Cricket Liu et al - you'll probably recognize his name as the author of the O'Reilly DNS book. I've generally heard good things about their products, though I haven't used them myself.

DNS.net's "Name Server Software: Unix" page

[CFrankBernard]

http://www.dns.net/dnsrd/servers/unix.html

Building a Dynamic DNS Server for Your Enterprise?

[Anonymous Coward]

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

DynDNS.org protocol server in PHP

[Anonymous Coward]

http://ryanc.org/nic/update.php.txt

I wrote this a while ago, it runs with MyDNS. It works with ddclient and probably other software for updating dyndns hosts.

The software is as-is, but feel free to do whatever you want with it. Enjoy.

- Ryan Castellucci

MaraDNS

[Wabbit Wabbit]

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).

Roll your own

[ArkiMage]

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.

Re:Roll your own

[Biff98]

We use HTTP for dynamic updates now (courtesy of DynDNS.org) and a large percentage of the gear we have in the field (attached to scientific equipment) is embedded equipment that is unable to run "nsupdate" or other types of executables. We're limited to the web GUI presented to us. I really regret not explicitly stating that in my submission to Slashdot.

As far as BIND "not being scalable", I meant that in the context of DDNS only. BIND requires a key-pair for each Dynamically update-able host record. Further, there's no nice web GUI which some of our folks have gotten to a la DynDNS.org -- doable, but is it easy? Not really, is it "scalable" then? Doubtful.

So sure we could "roll our own" w/ bind, supplying a GUI and a HTTP-based auth/update facility, but I was posting because I thought perhaps ISP's or large organizations such as ours had solved this problem already. Don't wanna re-invent the wheel and all the rest.

-Steve

Multi-day outage?

[twobithacker]

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.

Re:Multi-day outage?

[Anonymous Coward]

Me neither, I use DynDNS for DNS management for nearly 50 domains, plus network monitoring, dynamic DNS and more, all from DynDNS and I had no outage.

Re:Multi-day outage?

[Biff98]

How many hosts do you manage in your zone? Like I said we're in the "thousands". DynDNS.org might have offlined the biggest users of the service in favor of keeping the much larger number of "smaller" users online. Believe me, they were offline for at least 2 days from our perspective, and I got to speak with their phone support guys a LOT. It didn't help they didn't have an ETA for when threats and outages would be mitigated. -Steve

GnuDIP

[Roadmaster]

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/

Write your own!

[NNland]

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.

Re:put it differently ... zeroconf

[Sleepy]

>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...

Re:put it differently ... zeroconf

[num42]

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.

DJBDNS: Not having functionality is the *point*

[billstewart]

I haven't looked at DJBDNS for dynamic applications, only for more conventional ones.

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.