This is a derivative of a bit of Perl glue that I devised as
a reference test while cleaning up my Wide-Area Publishing patches for Project
Avahi, repurposed to address DNS update publishing for ...occasional use.
While running a wide-area aware mDNS daemon is the best solution in the vast majority of cases, there are instances where full-blown mDNS is overkill, the most obvious one being wanting to perform only a one-time wide-area DNS update (likely, in a script). In that context, I have found that embedded devices that use Apple's mDNS implementation for local-link browsing simply give up the option of publishing to a remote domain in the name of simplicity.
The WD Mybook II NAS being the device I have on hand (a favorite of Linux hackers), the WD is specifically targeted by this variant of the script, which can be just configured and dropped in place on such device together with a few Perl modules - you will quickly find out that the difficult part of setting up DNS update is on the server side (BIND configuration), not on the client.
This page is still a work-in-progress. Please forward feedback and corrections to the author. Thank you!
Federico Lucifredi - flucifredi@acm.org
| 0.2 | 2009-06-13 |
| 0.1 | 2009-01-04 |
Starting point: WD Mybook II; ssh access; logged in as root;
Install the modules required as dependencies:
Net::DNS IO::Interface::Simple File::Basename
Unfortunately, it looks like the Mybook does not have
enough memory for the usual "Perl -MCPAN -e shell" way to it
- you may have to download, make, and install the old fashioned
way. You are not a wimp, are you?
Now set up the script with the appropriate configuration information:
# Variables to configure the script's operation my $hostname = 'ooga'; # Device hostname my $domain = 'dynamic.booga.org.'; # Domain name my $nameserver = 'ns1.booga.org'; # Primary nameserver for your zone my $keyname = 'md5key'; # Name of the key my $key = 'se64bAsE64BASE64BasE64=='; # The HMAC-MD5 TSIG key my $interface = 'eth0'; # Interface whose IP is to be published
This is self-explicative enough, especially considering that to do this you need to know your bit of DNS-fu on the server side. Once you have placed wide_area_publish in the directory of your choice, create a symbolic link to it named "wide_area_delete": combining publish and delete functionality in the same script allows the script to perform cleanup before publishing your records, as well as enables you to maintain the configuration and your published records in a single script rather than two (diverging) ones for publish and delete.
If you are unfamiliar with the details of DNS Update, you need
to configure the primary server for your zone to (ideally) serve a
separate subdomain ("bonjour" and "dynamic" are
most popular choices) with very low (1 second) SOA 'minimum' (to avoid
caching of negative NXDOMAIN answers during your testing), and a TSIG
key to sign these updates. Do not mess up your Base64 typing, and get
the key name right. Oh, and TSIG is time-sensitive, so your clocks
better be synchronized or your DNS server be configured for tolerance
(which makes it in turn vulnerable to replay attacks... just sync the clocks with NTP!).
If you are not in friendly speaking terms
with DNS, I recommend a pot of tea and a copy of Cricket Liu and Paul
Albitz's DNS and BIND and a Saturday afternoon to poke at your zone
files - with no rush and good docs available, even BIND configuration
can be fun. Almost.
Here is the example configuration for a dynamic subdomain zone to get you started:
$ORIGIN . $TTL 60 ; 1 minute dynamic.booga.org IN SOA ns1.booga.org. unused-email-refer-whois.dynamic.booga.org. ( 901012106 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 1 ; minimum (1 second) ) NS ns1.booga.org.
Last warning: have Cricket's book and the appropriate RFCs handy, do not make dealing with BIND's zone and configuration files any harder than it needs to be :-P
If you are the paranoid type and the known MD5 weaknesses trouble you, you may want to check the latest revision of Net::DNS for SHA support, or contribute it yourself. Adjustments to the script (and even to the module) should be minor and would be a welcome addition, but I want to focus on getting the Avahi patches done right now, so I am actually hoping for someone to contribute back these improvements while I am busy finishing cleaning up those. For the record, the currently known MD5 vulnerabilities (collisions) are not sufficient to break a keyed hash application like TSIG.
The current version of the script publishes a single, lone A record. It is very simple to revise it to include any DNS-SD records desired as per the user's wishes (and depending on what services your trusty WDMBII is providing).
NOTES:
a) TODO:
revise script and modules to use SHA hashing algorithms in addition to HMAC-MD5. Patches welcome.
*) add an example dynamic zone in BIND syntax.
created 2009-01-04 - last modified 2009-07-23 - http://primates.ximian.com/~flucifredi/mybook/dns-update.html