With the more or less imminent introduction of IPv6
throughout the Internet, network interfaces will get IP addresses that are
even harder to remember for humans than the ones we have now in IPv4 (128 bits
to remember instead of 32). The Domain Name Service
(DNS) is supposed to solve
the human nature of this problem and can do quite well for IPv6 as it has done
for IPv4 since the early 80s.
To my disappointment, I could not easily find a nice provider for dynamic dns
(which is especially useful for mobile devices) that supports both IPv4 and
IPv6 records. I stumbled over 6dns.org, but that
service seems to only be reachable over IPv6, rendering it pretty much useless
if you are switching networks.
Starting the development of my own dynamic dns service proved to be more or
less easy, because I already run a DNS service and http hosting at
www.majimoto.net. Being able to rely on an
existing infrastructure (and having root priviledges) simplified quite some
things ;-) The only minor issue to be noted here is that I had to decide
wether I wanted to patch djbdns for IPv6 support or use the tinydns generic
data format for arbitrary data. I decided to patch it using Fefe's
patches.
So here is the concept:
- provide a public interface over http/https through which authenticated users can update the IP of their hostname(s)
- updates don't have to occur in real-time (DNS is full of caches and time-to-live anyway)
- updates must not require account credentials (username and password), because the update requests will most likely go through an untrusted environment and we don't want people in the local WiFi to see our passwords, right?
- the update interface should be mostly modelled after the one from dyndns.org, to allow existing client software to be compatible
- the update protocol must not differentiate between A (IPv4) and AAAA (IPv6) records, to allow transparent migration/network switching
- from the backend point-of-view (djbdns), it must be possible to run it aside/together with a normal, non-dynamic dns service
- an end-user frontend through a webpage must be available to enable users to manage their hostnames independently
I did the implementation like this:
- I defined a database layout for storing dns records in SQL. The layout is loosely based on the layout used by VegaDNS, an administration tool for tinydns.
- I created a PHP website with login/account capabilities for managing hostnames in that database (I really only chose PHP, because it's straightforward for small pages, otherwise I despise PHP)
- then I created the above mentioned http interface for update clients, re-using the code from the website and implemented more or less accurately what the dyndns.org specification says (which is crap in terms of semantics, but hey).
- Now, all that's needed is to tie the database to the actual tinydns service. I did that by writing a small shell-script that is supervised by DJBs daemontools and regularly checks to see if the dyndns-database got changed and eventually dumping it into tinydns format and compiling it.
- In the end, I realized I don't like any of the existing dyndns clients. Sometimes the code is a complete mess, someimes they are even closed source. In any case, I also wrote a client in Python which supposedly is extensible for other update protocols and efficient on network resources.
The result so far is visible at
dyndns.majimoto.net. It has an automated
subscription and I invite you to create an account and test it! If things go
well and if there is any interest in the software itself (apart from the
client, which can be found there), I will consider open-sourcing it / giving
access to others. But for that to happen, I need feedback!
thanx for your attention