DynDNS

On IPv6 and Dynamic Hosts (and PowerDNS Express in particular)

So yesterday I wrote about my tests on bypassing an hostile NAT that left me with a public-accessible dynamic IPv6. This helps me a whole lot, but it ’s almost unusable for more than a couple of days as I cannot know the IP address (unless that is I mail it to myself each time it change). The idea of using Mobile IPv6 to get a stable address for the box left away because of the complexity, I came back on my steps to my original, possibly easy, option: dynamic hostnames.

Dynamic hostnames are a very old technology to work around the issue of dynamic IPs (which was much more common years ago), it seemed obvious to me that the solution was the easiest to implement: I get a stable address (in form of hostname) to the router, then I can get to the remaining hosts through a SSH jump (or some kind of limited-scope IPv6 routing).

Unfortunately the first obvious choice (DynDNS) is a failure: it does not support using IPv6 for dynamic hostnames as far as I can see, and that makes it useless for my aim here. The second option for me was using the OVH system for DynHOSTs — it’s a service I pay, so I was expecting it to have the needed features, unfortunately they also don’t allow using IPv6 for their hosts. There used to be a service that supported this kind of feature, called DNS6, but that seems to be now dead. Hurricane Electric is planning on supporting dynamic hosts at some point, but right now there is no support for it.

Then I started looking at some more complex solutions, including paid-for solutions and custom solutions. One of my first ideas was UltraDNS but no public pricing seems to be available and that is not something I’m very fond of; plus it’s based in the United States which gives me trouble with taxes and payments, an European solution would have been better for my requests.

After discarding this solution as well, I started down the most complex road for this kind of situations, at least that’s what I thought at that point: writing my own dynamic DNS system. Luckily, a job I took earlier this year gave me a bit of expertise with PowerDNS (the software) so I only had to write some CGI application in Ruby to modify a PostgreSQL database on this very server, and serve it from there. I started looking into the pieces of the puzzle for what concerned the CGI script, and found a number of other problems, mostly related to SSL and certificates (but that’s, again, something for another post), and then I looked at PowerDNS itself, starting from looking at the latest version available on the site.

When I looked at the homepage (which is the one I linked earlier), I noted two more interesting things: the first is that the developers offer a paid-for custom DNS service, the second that the company is in the Netherlands, so it’s within the European Union, which is good for my taxes. Also, the price for a single domain (which is what I’d be needing at first) is low enough that it looked acceptable ($2 per domain, $0.50 for the transaction, less than €1.90 total). Beside the usual user-friendly operation interface to set the DNS records, their service has the one thing that was important to me: API access based on the SOAP protocol (and a WSDL description), that allowed updating records via scripts.

While on paper the service is great – and cheap too! – there are way too many shortcomings in their approach:

  • Authentication shautentication: the SOAP interface is only available in simple HTTP, there is no proper authentication, but it’s all left to the single API key that is provider per user; this means that if you deploy this on a non-trusted network (and, well, do you really trust the rest of the Internet?), and somebody is able to get your API key, not only they can mess with the records you’re messing at a given time, but they can mess with any of your zones and domains.
  • API keys and WSDL: beside the fact that it’s the one and only authentication mechanism, the API key is not passed as part of the SOAP request; instead it is passed as a query parameter on the POST request, as part of the uri. Unfortunately, the WSDL that is reported by the interface is not fixed to use the API key. As their documentation only speaks about PHP and VB.NET, I assume that those two libraries ignore the endpoint URL provided by the WSDL response (as soap:address); Ruby on the other hand respects what the response tells it to use, and it turns out it does not include the API key back, resulting in receiving “Invalid User” messages back at any request.
  • No advanced editing: while the PowerDNS express user interface for assisted editing of zones is one of the best I’ve seen among various DNS services, including the ability to automatically add Google Mail records (which would have been nice given that I actually have them on a number of domains already), they don’t have an “advanced” mode, which would allow you to either edit the zone manually, or at least add any kind of records in a free-form way; the SOAP interface also doesn’t allow you to add all kind of records either, which is a bad thing. It gets even worse when you add the fact that you don’t have SSHFP as a record type that you can use to set the fingerprint of a SSH server — this was actually a half decent idea to provide some extra safety that the lack of real authentication didn’t give me.

I’m seriously disappointed by the bad quality of the service PowerDNS Express provides, even though their software (pdns) seems pretty good and their basic interface is one of the best, as I said. As it is, it’s definitely not an option.

Luckily, Robin (robbat2) saved me from writing and deploying my own custom solution, so I’ll be working on deploying that in the next few days, taking most definitely less time than it would require me to waste for writing all the code myself. In most recent Bind version, support for Dynamic DNS entries is supported via the nsupdate tool; this means that if I set up a standard bind instance on my server (which might be harder to configure, but requires less than half the dependencies of pdns, most importantly it doesn’t need boost, and does not require a database behind it), then I can simply use that (which provides a strong authentication system, and a complete authorization system) to provide dynamic host names, exactly like I intended to originally.

For now, I’ll like the two reference pages that Robin gave me, if I’ll encounter problems implementing it that way, I might post again about it:

I’m a Geek!

The title, by itself, is pretty obvious; I’m a geek, otherwise I wouldn’t be doing what I’m doing, even with the bile refluxes I end up having, just for the gratitude of a few dozens users (which I’ll thank once again from my heart; you make at least part of the insults I receive bearable). But it’s more a reminder for those who follow me since a long time ago, and who could remember that I started this blog over four years ago, using Rails 1.1 and a Gentoo/FreeBSD install.

Well, at the time my domain wasn’t “flameeyes.eu”, which I only bought two years ago but rather the more tongue-in-cheek Farragut.Flameeyes.Is-A-Geek.org where Farragut was the name of the box (which was contributed by Christoph Brill and served Gentoo/FreeBSD as main testing and stagebuilding box until PSU/MB gave up).

At any rate, I’ve been keeping the hostname, hoping one day to be able to totally phase it out and get rid of it; this because while at the start it was easy to keep it updated, DynDNS has been pressing more and more for free users to register for the “pro” version. Up to now, I’ve been just refreshing it whenever it was on the verge of expiring, but.. since the latest changes will not allow me to properly re-register the same hostname if it failed, and a lot of websites still link to my old addresses, I decided to avoid problems and scams, and I registered the hostname with DynDNS Pro, for two years, which means it won’t risk expiration.

Given that situation, I decided to change the Apache (and AWStats) configuration so that the old URLs for the blog and the site won’t redirect straight to the new sites, but rather accept the request and show the page normally. Obviously, I’d still prefer if the new canonical name is used. Hopefully, at some point in time, browsers and other software will support the extended metadata provided by OpenGraph which not only breaks down the title in site and page title (rather than the current mess of different separators between the two in the <title> element!), but also provides a “canonical URL” value that can solve the problem of multiple-hostnames as well (yes that means that if you were to link one post of mine on Facebook with the old URLs it’ll be automatically translated to the new, canonical URLs).

But it’s not all stopping here; for the spirit of old times, I also ended up looking at some of the articles I wrote around that time, or actually before that time, for NewsForge/Linux.com (as I said in my previous post noted). At the time, I wasn’t even paid for them, but the only requirement was a one year exclusive; last one was in December 2005, so the exclusive definitely expired a long time ago. So, since their own website (now only Linux.com, and changed owner as well) is degrading (broken links, comments with different text formatting functions, spam, …) I decided to re-publish them on my own website in the newly refurbished articles section and, wait for it…

I decided to re-license all three of the articles I wrote in 2005 under CreativeCommons Attribution-ShareAlike license.

Update (2017-04-21): as it happens my articles section is now gone and instead the articles are available as part of the blog itself.

Okay, nothing exceptional I guess, but given there was some doubts about my choices of licenses, this actually makes available a good chunk of my work under a totally free license. I could probably ask Jonathan whether I could do something like that to the articles I wrote for LWN, but since that site is still well maintained I see no urgency.

I should also be converting from PDF/TeX to HTML the rest of the articles on that index page, but they are also not high on my priority list.

Finally, I’m still waiting on FSF to give me an answer regarding the FSWS licensing — Matija helped me adapt the Autoconf exception into something usable for the web… unfortunately the license of the exception itself is quite strict, and so I had to ask FSF for permission of using that.. the request has been logged into their RT, I hope it’ll get me an answer soon… who knows, FSWS might be my last “gift” before I throw the towel.

Why didn’t I use a Linksys DSL router?

So, I have now a Linksys WRT54GL v1.1 router here that links the DSL router via WiFi with the cabled LAN connected to the 8-port switch. I had to flash it with OpenWRT firmware from day one, as the routing I needed wasn’t available from original LinkSys interface (as it wasn’t on the Belkin and in any other WAN router I found); I followed this HowTo when I set it up, but this way I actually had the 4-ports switch as an extension of the 8-port one, too, creating a 10-ports switch, not something I wanted. What I would have liked was having the 4-ports switch as an extension of the WLAN network, for external laptops that I need to connect wiredly.

So last night, after having set up dnsmasq to act as my main DNS server, and after writing a dyndns-updater with web IP detection and cache support in SH (extending this one) and configuring it, I decided to change the interfaces so that I could use the WAN port of the router to connect this LAN and bridge the wireless with the other four ports. Bad idea, it simply disabled the client mode for wireless, but when I was reconfiguring it to work again without the bridge, I’ve unfortunately typed the wrong command, and committed to nvram both lan and wan on the WLAN port 🙁

Trying to get it to work, I ended up flashing it back again, and resetting the NVRAM entirely, then I reconfigured it and everything worked, at least 🙂 I also reconfigured dnsmasq, although I still have to do the next step, that is configuring this network on DHCP with fixed addresses.

I’m also wondering if I can use it as VPN server to allow the laptop connected to the Wireless, or to an external network, to connect on the LAN .. but I’m not sure if it has enough power to do that. If somebody ever tried, with bad or good results, I’ll be glad to hear comments 🙂

Update: for who was wondering, I’ve uploaded my modified dyndns-updater script that can use web IP gather method, and that caches the IP so that it does not get updated more than once with the same address.

Facilitare l’accesso ai propri servizi con DynDNS e DJBDNS

Uno dei problemi che si possono avere accedendo ai servizi della propria
LAN casalinga dall’esterno è che IP e hostnames non corrispondono, e
richiedono dei giochi per poter funzionare indistintamente.

Questo articolo darà modo a chi ne avesse bisogno di semplificare
l’accesso ai propri servizi, non richiedendo modifiche alla
configurazione dei programmi per gli accessi interni o esterni.

Introduzione

Avendo a casa una piccola LAN (tre computer in realtà), ho dato ai due
fissi il compito di gestirmi alcuni servizi, come per esempio la posta
@localmailserver o il BNC1.

Ovviamente quando sono collegato alla rete interna, il portatile accede
a questi senza passare dal router (che ha un’interfaccia a 10Mbit e
verrebbe appesantito dalla necessità di effettuare il NAT inverso
sull’interfaccia WAN per poter fornire i servizi alle altre macchine),
ma se usassi gli indirizi IP interni poi dovrei riconfigurare da capo
tutti i programmi quando fossi fuori della mia LAN (per esempio a scuola
o a casa di amici).

In questo articolo voglio provare a dare una piccola soluzione a questo
problema che potrebbe riguardare anche altre persone, utilizzando i
servizi forniti da DynDNS, e il server DNS dnsmasq.

Hostname dinamici: perché e come

La prima cosa da fare se si vuole poter fornire servizi all’esterno
della propria LAN senza avere bisogno di conoscere in continuazione il
proprio IP è utilizzare un hostname dinamico, a meno che non abbiate un
IP fisso.

Gli hostname sono nati apposta per poter fornire un identificativo
mnemonico per le macchine su internet, ma nell’epoca in cui la maggior
parte dei provider forniscono soltanto IP dinamici, i classici hostname
sono inutili.

Per questo divrsi siti offrono servizi di hostname dinamici, ovvero
hostname il cui IP può essere cambiato automaticamente tramite un
client, un nome utente e una password.

Per prima cosa, registriamoci su , fino ad avere un nome utente (che
sarà per noi, appunto, utente), e una password (che sarà per noi,
ancora una volta, password). A questo punto poi potrete registrare un
hostname (che per facilità sarà il mio 2).

Configurazione del client

Ora installiamo un client, io solitamente utilizzo ddclient, che è
disponibile per la maggior parte delle distribuzioni linux e dei sistemi
operativi liberi (tra cui OpenBSD dove lo eseguo).

Modifichiamo quindi il file /etc/ddclient.conf, inserendo le seguenti
righe:

login=utente
password=password

server=members.dyndns.org 
protocol=dyndns2 
flameeyes.homelinux.net 
wildcard=yes

Notate quest’ultima riga, wildcard=yes, perché è molto importante. In
pratica consente di risolvere i domini di quarto livello (come per
esempio pippo.flameeyes.homelinux.net) con lo stesso IP configurato
sull’hostname di terzo livello. Ora vedremo per cosa ci serve questa
opzione.

Una volta che ddclient è configurato, basta semplicemente impostarlo per
l’avvio automatico (questo dipende dalla vostra distribuzione / sistema
operativo).

Configurazione delle macchine

Una volta configurata l’hostname, dobbiamo iniziare a configurare le
macchine. Per fare ciò prima di tutto scegliamo dei nomi per le singole
macchine se già non ne hanno. Seguendo i consigli di DJB@djb-hints, i
nomi delle macchine dovrebbero essere scelti in modo da essere tra loro
simili, e che non vadano ad interferire con le proprie competenze. Io
per esempio utilizzo i nomi di astronavi presi da Star Trek.

Una volta che abbiamo deciso i nomi per le varie macchine, possiamo
unirli al dominio preso da DynDNS per avere il nome completo delle varie
macchine. Per esempio possiamo avere una macchina chiamata defiant che
diventa il nome defiant.flameeyes.homelinux.net .

Per configurare le varie macchine abbiamo ora diverse possibilità a
seconda di quale distribuzione linux o sistema operativo si usa. Posso
quindi solo dare alcuni esempi generali.

Gentoo Linux

In Gentoo Linux per la configurazione di hostname e dominio basta
modificare due files.

Il primo è /etc/conf.d/hostname, in cui bisogna semplicemente settare

HOSTNAME="defiant"

Il secondo è /etc/conf.d/domainname, che va modificato in modo da
avere

DNSDOMAINNAME="flameeyes.homelinux.net"

Un riavvio ed è finita.

OpenBSD

In OpenBSD il cambiamento è ancora più semplice, basta eseguire il
comando

echo "defiant.flameeyes.homelinux.net" > /etc/myname

Per finire un riavvio.

Installazione del DNS

A questo punto resta solo la parte più critica: installare e configurare
il server DNS in modo da rispondere alle richieste per il nostro nuovo
dominio flameeyes.homelinux.net.

Il software che consiglio è dnsmasq. Per una semplice rete casalinga, la
sua gestione è semplice ma allo stesso tempo funzionale. Inoltre, è un
programma molto leggero e non consuma risorse di alcun genere.

La sua installazione è praticamente banale. Il consiglio è sempre quello
di controllare se la propria distribuzione mette a disposizione un
pacchetto per dnsmasq, in tal caso, la cosa più semplice è installarlo
tramite questa.

Nel caso non sia presente un pacchetto precompilato o un metodo per
installare dnsmasq direttamente tramite la propria distribuzione, la sua
compilazione e installazione è comunque molto semplice.

Per prima cosa scaricate dal sito l’ultima versione del programma, che
al momento è dnsmasq-2.23.tar.gz. A questo punto, basta estrarre i
sorgenti e lanciare il comando di compilazione e installazione:

    $ tar zxf dnsmasq-2.23.tar.gz
    $ cd dnsmasq-2.23
    $ gmake
    $ su -
    # gmake install

Nota: se si è sotto Linux, è possibile utilizzare make al posto di
gmake; se si è sotto BSD però è necessario utilizzare il make GNU.

Per sistemi basati su RPM, come SuSE e Fedora, è presente nel pacchetto
dei sorgenti anche un file rc.d per l’avvio automatico del servizio. Per
altre distribuzioni, si faccia riferimento ai pacchetti ufficiali e non.

In ogni caso, per avviare il servizio basta, una volta completata la
configurazione spiegata nella prossima sezione, basta eseguire il
comando dnsmasq, che entrerà da solo nello stato di daemon
preparandosi a ricevere richieste.

Configurazione

Anche la configurazione di dnsmasq è molto semplice, un file di
configurazione di esempio è disponibile nel tarball dei sorgenti, ma
quello che viene qui riportato è un esempio di configurazione per una
rete LAN classica.

    server=999.999.999.999      # server DNS del proprio provider
    local=/flameeyes.homelinux.net/ # considera questo dominio locale
    no-resolv           # non cercare su resolv.conf
    no-poll

A questo punto, basta fornire a dnsmasq le coppie di hostname e
indirizzi IP da risolvere. Per fare questo, basta configurarare
/etc/hosts ponendo gli hostname con un indirizzo fisso:

    127.0.0.1   localhost
    192.168.0.1 defiant.flameeyes.homelinux.net
    192.168.0.2 voyager.flameeyes.homelinux.net
    192.168.0.3 northstar.flameeyes.homelinux.net

dnsmasq leggerà il file per risolvere gli hostname locali, e troverà
l’IP a cui risolvere l’hostname fornito. Se l’indirizzo non è locale,
dnsmasq rimanderà la richiesta al server specificato, così che sia
sempre possibile avere una risposta corretta.

Configurare le macchine

Ovviamente perché le macchine della lan possano sfruttare il servizio
offerto da dnsmasq è necessario configurarle per utilizzarlo come server
DNS. Per fare ciò, su macchine Unix o Unix-like, basta configurare
/etc/resolv.conf come segue:

domain flameeyes.homelinux.net
nameserver 192.168.0.1
nameserver 999.999.999.999

tenendo conto che qui è stato scelto 192.168.0.1 come server DNS su cui
gira dnsmasq.

Ora potete provare a pingare l’host voyager, e vedrete che la
richiesta sarà verso 192.168.0.2 (sempre se avete settato il file
/etc/resolv.con come spiegato prima con l’opzione domain).


  1. Una specie di “proxy” per le connessioni IRC, che
    supporta anche i log delle conversazioni private quando non si è
    presenti.

    [return]

  2. Non uso più questo hostname da tempo, e ora è settato
    semplicemente staticamente su 127.0.0.1

    [return]