Il DNS è un servizio di per se’ leggero ma fondamentale per il funzionamento dei domini (e a cascata di molti altri servizi).
La necessità di concentrare la gestione del DNS di un dominio e non delegarlo al pannello del registrar è abbastanza intuibile: molti registrar = molti pannelli da amministrare, quindi dispersione di energie, tempo e risorse.

Sistema-di-DNS-secondario-esterno-(cloud)

Portarsi il DNS in “casa” d’altronde vorrebbe dire costruirci intorno una serie di ridondanze che evitino ogni tipo di blackout o interruzione di servizio e può essere considerato in molti casi un overkill.

Quello che propongo in questo piccolo “draft” (ingrandisci l’immagine) è un approccio “misto” che consiste nel costruirsi un DNS primario (Master) da gestire in proprio e che vada a popolare un DNS slave (o meglio ancora un cloud di DNS slave).
Ovviamente il master DNS in questo scenario NON può essere autoritativo per ovvi motivi (non è cioè raggiungibile 24/24 proprio per “design”).
Il trucco è quello di promuovere come autoritativo il DNS slave (configurato su un gestore terzo con una buona struttura).
Per farlo basta designarlo come tale nel pannello del nostro registrar quando andiamo a gestire i DNS del dominio (la nomenclatura dell’operazione varia da registrar a registrar ).

Questo approccio ci consente molteplici vantaggi a fronte di una piccola scomodità.
Vantaggi:
– Il master DNS  può stare ovunque ed essere messo offline quando vogliamo in quanto le zone secondarie (slaves), una volta popolate nel cloud, continueranno ad esistere e funzionare indipendentemente dalla raggiungibilità del nostro master DNS.
– Ciononostante ogni volta che vorremo fare una modifica a una zona presente nel nostro DNS potremo farla comodamente nel nostro master il quale automaticamente andrà ad eseguire le modifiche sui DNS slaves esterni.
– Un altro vantaggio considerevole è che il DNS “interno” che è il primario (ma appunto non autoritativo) può essere protetto e reso inaccessibile dall’esterno in modo semplice, con una regoletta nel firewall,  in quando dovrà accettare connessioni solo e soltanto dai DNS secondari.
– Di conseguenza non sarà neanche necessario provvedere a una infrastruttura per il DNS primario complessa ed estesa, come vedremo.
Svantaggi:
– Avremo a che fare con DUE pannelli/sistemi di gestione (se escludiamo quello dei vari registrars nei quali dobbiamo soltanto impostare i nameservers nel momento di registrarlo), e cioè quello del master DNS e quello dei DNS slaves nei quali dovremo definire comunque la prima volta il nome della zona e l’IP del DNS primario che abbiamo in casa, questo comporta anche che se una zona viene cancellata nel Master, essa dovrà comunque essere cancellata a mano anche nello slave. [continua…].

Esempio pratico:

La creazione di un server master DNS  per la gestione delle zone va al di là delle intenzioni di questo articolo; per un progetto del genere il mio scopo era avere un oggetto consultabile e funzionale in modo “facile” che mi permettesse di delegare parte di questo lavoro anche a terzi.
Ho scelto l’accoppiata PowerDNS+PowerAdmin che mi consente di lavorare con un comodo pannello web sulle zone del mio DNS con in più la comodità di un backend in MySQL.
E’ veramente semplice, potete seguire questa comoda guida su HowToForge per CentOS o Debian.
Le risorse necessarie in termini di RAM e disco, sono piuttosto esigue anche per centinaia di zone (il vostro DNS non viene in alcun modo interrogato da nessun client) e si può quindi  tranquillamente virtualizzare il tutto.

Per la gestione dei DNS slaves esistono svariati provider, molti dei quali consentono la gestione del DNS in modo totalmente gratuito.
Alcuni esempi: Afraid.org, OpenProvider, CloudDNS, Hurricane, Xname, ecc.
Nel momento in cui scrivo tutti quanti consentono la creazione di zone slaves (oltre che primarie) in modo del tutto gratuito.
Consiglio di verificare di persona le eventuali modifiche alle politiche commerciali.
Io mi sono affidato a OpenProvider che ha un pannello piuttosto veloce, risulta rapido nei vari cambiamenti sulle zone e ha distribuito i suoi DNS a livello geografico in Europa  (ns1.openprovider.nl,  ns2.openprovider.be,  ns3.openprovider.eu).

La domanda che sorge spontanea è (immagino) “perchè non gestire direttamente le zone primarie presso questi provider?”.
La risposta per me è che dovremo aprire un account per ogni cliente che voglia o abbia bisogno di gestirsi in autonomia i propri DNS.
Invece disponendo del proprio Master  il problema si può agevolmente aggirare in quanto il master DNS con PowerAdmin prevede una gestione multiutente. L’unico lavoro manuale (che potrebbe essere comunque essere anch’esso automatizzabile nel caso il provider del DNS slave fornisca API di accesso) rimane solo quello di predisporre la zona sui DNS slaves che come vedremo, è un lavoro molto semplice.

Quindi in definitiva i passaggi sono:

1. Creare ed impostare la zona nel proprio master DNS
2. Creare la zona slave e aspettare che si popoli con i record della master
3. Registrare il dominio di cui abbiamo impostato le zone e indicare come autoritativi i nameservers che funzionano da slaves

Ecco alcuni screenshot dei vari passaggi (cliccare per una descrizione approfondita):