Webmonkey: backend: Dynamic DNS Basics

Dynamic DNS Basics
by Paul Adams

Now that everybody* has a home broadband connection, the need for IP addresses is a growing concern. With the rollout of IPv6 still pending, IP addresses are a limited resource. ISPs are understandably reluctant to hand a static IP address to every US$50/month subscriber. Some ISPs do, and some allow you to pay extra for one. For the most part, though, they're a bit of a pain to get.
* not everybody
This is not a problem for the majority of home broadband users. Their needs - efficient Web browsing, quick downloading of large files, "always-on" service, productive hours spent on EverQuest or AIM - are met admirably by the service that is provided. Giving them a static IP address, if they even noticed, would just result in increased security headaches as their insecure Windows machines suddenly had fixed addresses, making them easier to break into.
So why would a home user want a static IP address? Well, for hosting things. Without a static IP, nobody knows where to find you, so you can't run a Web server or an FTP server or an email server. Here is a bit of the science behind it.
The bond between a static IP address and a domain name is fixed, and nothing shall come between it unless the host wants it to. 209.202.192.25 will always equal lycos.com, and vice versa. This is mandated in the DNS record, which basically says, "until you hear otherwise, the domain lycos.com is found on the machine 209.202.192.25." (This is a simplification, but will suffice for our needs here today.)
Contrariwise, dynamic IP addresses are assigned to users on a rotating basis. Every time a DSL (or dialup) user connects to the Internet, he or she is automatically assigned a temporary IP address, on a short-term DHCP lease. These addresses resolve to hosts on the network of the ISP that provides them, like sdn-ap-001mantriP0371.isp.net - not to the home machine that is using the address at the moment.
Thus, a machine on a DSL or cable line without a static IP is connected to the Internet, but only one way. People from the outside can't initiate communication with that machine except through an intermediary, because they simply can't find it! This makes hosting from home impossible ... except through trickery. For there is a solution, a clever one. It is called dynamic DNS.

How It Works

Dynamic DNS makes use of a feature of DNS called Time-To-Live, or TTL. The TTL is the field in a DNS record that specifies how long the record is valid. That is to say, it tells querying servers how soon to check back with the host of that record to see if the record has changed. A typical setting is 12 or 24 hours, which is sufficient for standard DNS usage, because server information just doesn't change that often.
The fundamental principle of dynamic DNS is to create a DNS record with a TTL setting of five minutes or so. By thus imparting to the world that the address of the machine in question changes frequently, it is possible to allow that machine to serve as an Internet host. Dynamically updating the DNS information keeps the domain name you choose pointing to your machine, whatever its IP address may be at the moment. It works like this:
Say you have a dynamically DNSed Web server running yourdomain.com out of your bedroom. I type "yourdomain.com" into my browser. My computer asks its ISP's nameserver, "How do I resolve yourdomain.com"? The nameserver looks at its cache and finds no answer, so it starts the querying process.
First it asks one of the Web's 13 root servers. The root server only knows the rightmost part of the answer: the .com part. It refers the query to the specific DNS servers that handle .com queries.
So the nameserver asks one of those about yourdomain.com. It receives the answer that DNS info for yourdomain.com is handled by nameserver.yourdnshost.com. The fact-finding mission continues.
My nameserver asks the question again. Finally, nameserver.yourdnshost.com reveals the information - the specific IP address that yourdomain.com resolves to. It also passes along the TTL information for that DNS record: namely, that the address should be cached for no more than five minutes. My browser connects to that IP address and sees your lovely flying kittens or whatever. This whole process takes just a second or so.
If another user of my ISP should want to visit the same page within five minutes, they can use the information that the ISP's nameserver has cached. After five minutes, though, the data will expire and the whole querying process will be repeated. Because the next time the query is run, the IP address that yourdomain resolves to may well be a different one, depending on the whim of your broadband provider.

How To Get It

To keep up the fast-change routine of frequently refreshing DNS records, you need a couple of things. First, a provider. This is "yourdnshost.com" in the above example. You could maintain your own dynamic DNS record, but you don't even have a static IP address. Chances are you're looking for less expense and hassle, not more. Fortunately, there are a number of providers out there willing to do the upkeep for you. Their fees range from free, to free with a one-time charge, to a monthly or yearly fee. Most charge more if you want your own domain name, such as yourdomain.com, as opposed to a subdomain like yourdomain.yourdnshost.com.
There are a lot of providers of dynamic DNS to choose among. Personally, I have had great luck with DNSMadeEasy.com, but others recommend different providers.
In addition to a provider, the other thing you need is a client. The client is a small piece of software that runs on your local hosting machine. It detects the machine's current IP address and, when that changes, sends a notification to the DNS provider. Detecting the IP address is a simple matter if your computer is connected directly to the broadband line, but if you have a router or NAT in your setup, and several computers sharing your connection, then the process becomes a little sniffier, and the client has to be clever enough to get the IP address that the router or NAT machine is using.
A few different attempts to standardize the process have been made. This means that you have to get a client that's compatible with your particular provider, and, when you change providers, you may have to change clients as well. I have argued before in these pages for standardization of various things, and I still think it is a wonderful thing, despite the initial hassle. But, last time I checked, we still live in the real world. A given provider's site should tell you what clients you can run.
So download the correct client for your platform and provider, configure it, run it, choose your domain name, pay your dues, and you're up and running! Now you can pick up anything! Check out Webmonkey's tutorials on Web hosting and email hosting. Be aware, though, that many ISPs don't approve of you running a server on their hookup. Check your terms of service beforehand. And if you get caught violating any of them, remember: This conversation never happened.

Paul Adams is Webmonkey's resident acronympho, covering the likes of PHP, DNS, and SOAP with startling aplomb.


webmonkey/backend/