Ci sono diversi casi in cui un dominio viene registrato presso un fornitore mentre l’hosting (o un altro servizio) è altrove; i casi più comuni che mi vengono in mente sono i blog su Blogger e i Tumblr che desiderano utilizzare un proprio nome a dominio mantenendo la comodità di una piattaforma pubblica, oppure quando il dominio di primo livello che avete scelto non è gestito dall’hoster: un caso molto comune sono i domini .it su un provider statunitense. In quest’ultimo caso, poiché non sono supportati i .it, è necessario registrare il dominio altrove e poi intervenire sul DNS in modo da “puntare” il dominio sui server corretti.

Tanto per fare chiarezza sui termini: il “registrar” è l’entità presso la quale avete registrato e pagato il nome a dominio, l’”hoster” è il fornitore di servizi che vi fornisce i server (o parti di essi) sui quali “girano” i servizi legati al dominio. Di solito coincidono, ma quando non è così è necessario intervenire sui DNS.

Gestire le funzioni di base di un DNS non è difficile, ma presuppone la conoscenza di alcuni concetti che vanno capiti prima di effettuare modifiche; normalmente è difficile fare danni irreparabili, ma se si fanno pasticci si rischia di rendere irraggiungibile il proprio sito per diverse ore. Il tutto è reso ancora più scomodo dal tempo di propagazione: prima che le modifiche vengano “recepite” da tutto internet è necessario attendere alcune ore, in certi casi anche 24/36.

Se desiderate una breve spiegazione a proposito del DNS, ne avevo scritto tempo fa; in questo post vorrei parlare delle poche cose da sapere nel caso si voglia gestire il proprio dominio.

Ciascun registrar, l’entità presso la quale avete “comprato” il nome a dominio, gestisce uno o più server DNS. Questi server usano un database nel quale ai nomi a dominio (detti anche “zone”) sono associati diversi record; quelli ai quali siamo interessati sono i record NS, A, CNAME e MX. (Ce ne sono molti altri, ma per i nostri scopi basta gestire questi). Una zona (dominio) comprende uno o più host che erogano i servizi. (In realtà quello che viene chiamato “database” è un semplice file di testo che contiene le diverse righe dei record).

La modifica dei record si fa generalmente tramite il pannello di controllo del registrar, con modalità che cambiano di volta in volta, ma in genere si tratta di interfacce abbastanza intuitive.

Uno dei record più importanti con il quale si ha a che fare è NS. Esso stabilisce chi sono i server DNS per la zona; viene indicato nella forma:

NS	nome.delserver.com.

Si possono specificare piu’ DNS per una singola zona, ma non è possibile sapere quale sarà usato dai resolver: dipende dall’implementazione del resolver stesso, quindi tutti vanno tenuti aggiornati.

In alcuni casi, la modifica di questo record è tutto quello che ci serve. Facciamo un esempio abbastanza comune: un dominio .it registrato in Italia e hostato presso un provider statunitense, per esempio Dreamhost. Una volta che il pannello di DH è pronto per “accogliere” il dominio, è sufficiente modificare i record NS sul registrar in modo che puntino ai DNS americani. In questo modo, la registrazione rimane in Italia, tutto il resto passa a Dreamhost, che diventa responsabile pubblicamente per tutti gli host di quel dominio. Modificando NS, la palla passa a DH che è già pronto per ospitare il nuovo dominio nei suoi DNS; tempo della propagazione e tutto funzionerà alla perfezione.

State attenti: il nome del server va scritto con il punto in fondo, per indicare che è proprio quello e non è un host di quel dominio. Se manca il punto il record verrà interpretato come nome.delserver.com.miodominio.it, e non funzionerà più nulla.

Nel caso non si dovesse e/o potesse modificare il nameserver è necessario intervenire su altri tipi di record. E’ il caso, per esempio, di Tumbr associato a un proprio dominio. Tumblr non fornisce server DNS, quindi dovrò modificare un record A.

Un record A traduce un nome host in un indirizzo IP:

nome IN A    12.34.56.78

dato che la zona è quella del dominio miodominio.it, la riga qui sopra dice che l’host nome.miodominio.it risponde all’indirizzo 12.34.56.78.

Se la riga fosse:

tumblr IN A    72.32.231.8

avremmo appena creato un dominio di terzo livello tumblr.miodominio.it che punta ai server di Tumblr, dove il nostro tlog, opportunamente configurato, è pronto per servire le pagine. Potete trovare maggiori informazioni in un altro mio post.

E’ possibile assegnare più indirizzi IP allo stesso host; essi verranno restituiti come risultato della query DNS e sta al resolver del client decidere quale usare. E’ un meccanismo che talvolta viene utilizzato per ottenere un rozzo bilanciamento di carico tra server distinti.

Spesso un singolo server ospita diversi servizi, accessibili con un nome diverso. Il caso più comune è il seguente:

www IN A    12.34.56.78
ftp IN A    12.34.56.78

In questo caso il singolo host risponderà sia su www.miodominio.it che su ftp.miodominio.it.

C’è un altro modo di ottenere questo risultato, e questo ci introduce all’uso di un altro tipo di record: CNAME. Questo tipo di record permette, usando le parole di Wikipedia, “di collegare un nome DNS ad un altro. La risoluzione continuerà con il nuovo nome indicato dal record CNAME. Questa funzione è molto utile quando, per esempio, sullo stesso server sono disponibili più servizi come FTP, HTTP ecc operanti su porte differenti. Ciascun servizio potrà avere il suo riferimento DNS (ad esempio ftp.example.com. e www.example.com.“.

L’esempio qui sopra potrà quindi essere configurato anche così:

www IN A      12.34.56.78
ftp IN CNAME  www.miodominio.it.

Attenzione, sempre, al punto finale quando si scrive un nome FQDN completo. In questo caso il server DNS restituirà al client che richiede ftp.miodominio.it non un indirizzo IP, ma un altro nome (www.miodominio.it); verrà quindi effettuata una seconda query, dalla quale otterremo finalmente l’indirizzo desiderato. Si dice che ftp.miodominio.it è un “alias” di www.miodominio.it.

Utilizzando i record descritti fin qui si possono gestire la quasi totalità delle configurazioni dove il registrar è separato dall’hosting. Per completezza vediamo l’ultimo record, MX.

Il record MX è molto importante per il recapito della posta perché contiene il nome del server deputato a ricevere messaggi quel particolare dominio. E’ fatto così:

MX	10	posta.miodominio.it.
MX	20	mail.provider.com.

In questo esempio il dominio ha due mail server. Il primo, più importante, è quello con il campo priorità più basso (10) ed è il primo che verrà contattato. Se esso non risponde si passa all’altro (se c’è) che fa da backup e si incaricherà di inoltrare i messaggi al server principale non appena esso tornerà online; impostando due priorità uguali si può ottenere una specie di bilanciamento di carico. Maggiori informazioni sul recapito della posta, il protocollo SMTP e una breve prova pratica li trovate in un mio vecchio post.

La modifica del record MX è necessaria, per esempio, nel caso si utilizzi Gmail per per proprio dominio; è un servizio fantastico ed è gratuito fino a 50 utenti. In pratica Google vi regala una Gmail personalizzata per il vostro dominio, insieme a calendario, contatti condivisi, Google Docs e Google Site.

Vi ricordo che le modifiche hanno bisogno di 24/36 ore per essere propagate a tutto il mondo: una volta cambiati i parametri sul pannello, il server DNS aggiorna (di solito automaticamente) il serial number del record SOA, che serve per sapere se i dati sono stati modificati e quindi aggiornati su tutto il sistema DNS mondiale.

(Alcuni aspetti sono stati volutamente semplificati: una trattazione rigorosa richiede tempo e sarebbe comunque inutile, vista la quantità di materiale reperibile in rete al riguardo.)

Pare che la moda del momento sia chiedere che i propri dipendenti non usino Facebook e non chattino su MSN. Pur non essendo d’accordo, credo si tratti di una richiesta lecita se fatta da chi paga sia le persone che la banda(*).

I sistemi di content filtering possono essere costosi e/o impegnativi nella manutenzione per aziende di piccole dimensioni che magari dispongono a malapena un firewall. Ci sono un paio di tecniche che permettono di filtrare abbastanza agevolmente senza dover fare alcun investimento. Il principio è controllare le query DNS, intercettando i domini da bloccare e/o utilizzando l’apposito servizio gratuito fornito da OpenDNS. Della situazione speculare, il blocco totale con pochi domini in whitelist avevo già parlato qui.

Come spesso accade, in azienda c’è un piccolo server Windows 200x o Small Business Server che adempie alle solite funzioni (AD controller, file e print server, DNS, DHCP ecc ecc.); concentriamoci sul DNS. In questo esempio mi interessa bloccare il traffico verso Facebook, quindi ne carico una pagina e do una scorsa al sorgente HTML, dal quale mi accorgo che gli unici domini interessati sono Facebook.com e fbcdn.net. Provvedo quindi a creare due nuove zone di ricerca diretta primarie, integrate in AD e replicate su tutti i server DNS proprio per quei due domini (facebook.com e fbcdn.net).

Il risultato di questa operazione sarà che il mio server sarà convinto di essere autoritativo per i domini in questione e non si preoccuperà di recuperare dai suoi forwarder, o dai root server, l’indirizzo IP degli host di quei domini(**). Non avendo alcun record di tipo A definito, restituirà al client un messaggio di host sconosciuto (“www.facebook.com non esiste“); otteniamo così il risultato di rendere Facebook non raggiungibile. (Naturalmente devo attendere che la cache DNS sui client sia scaduta o forzarne il refresh con ipconfig /flushdns)

Per evitare che un utente più smaliziato usi un server DNS pubblico, bisogna bloccare sul firewall tutto il traffico in uscita sulla porta 53 sia TCP che UDP, tranne quello proveniente dai server DNS interni.

Per bloccare Messenger e per un controllo su altre categorie di siti, si può usare il servizio gratuito offerto da OpenDNS, dove basta registrarsi, configurare il proprio server DNS con gli appositi forwarder, registrare e confermare il proprio network seguendo le semplici indicazioni (c’è anche un client per chi non ha un IP pubblico statico) e attivare il content filtering. Questo è un esempio di configurazione che blocca Messenger ed altre categorie di siti.

Queste impostazioni che vedete sono disponibili anche nella versione gratuita, che assolve egregiamente ai suoi scopi. Si possono anche specificare singoli domini da blacklistare. Il servizio offre anche un po’ di statistiche. Le pagine bloccate vengono catturate e viene restituita una pagina con messaggi personalizzabili e logo dell’azienda.

E’ evidente che questi metodi non resistono ad un utente con competenze evolute (non riuscirete a bloccare il traffico a un ufficio di sistemisti), ma per la maggior parte dell’utenza è uno scoglio insormontabile.

Pregi:

• Sono gratuiti.
• Sono molto semplici da implementare.
• Sono facili da spiegare ai clienti.
• Richiedono pochissima manutenzione.
• Sono adatti a aziende piccole o medio-piccole.
• Sono facilmente reversibili alla configurazione “tutto aperto”.

Difetti:

• Pasticciare con le query DNS non è affatto elegante.
• Ci si affida a un servizio esterno con tutto ciò che ne consegue in termini di sicurezza, privacy e continuità del servizio.
• Utilizzare un servizio come OpenDNS che raccoglie un database di query e lucra sul traffico rediretto è comunque un compromesso.
• Non scalano bene nel caso le esigenze di controllo diventino più granulari.
• Non sono adatti ad aziende più grandi con infrastrutture più complesse.

(*)Ulteriori considerazioni sul filtrare i contenuti internet sono al di fuori dello scopo di questo post.

(**)Semplificazione. Per una spiegazione più approfondita, leggimi qui.

Tapullo: “Non esiste parola che si possa paragonare a Tapullo. Trattasi di riparazione di fortuna che spesso dura nel tempo e aggiunge nuove funzionalità (…). I Genovesi, da sempre parsimoniosi, sono abili nei Tapulli. I Tapulli vengono mostrati con fierezza agli amici, alcuni diventano perfino leggendari e spesso i grandi marchi vi si ispirano per migliorare i propri prodotti. A volte viene usato il termine per denigrare una riparazione di fortuna (raro), o per indicare una soluzione temporanea (più comune).” Fonte.

Questo è uno dei nostri server. Sta funzionando ininterrottamente dal 6 maggio del 2004.