Risolvere i nomi a casa propria

by Paul MasonOgni server che ho installato da che ci sono le connessioni fisse a Internet ha sempre avuto un DNS server locale senza inoltro al DNS del provider.

Il DNS è spesso visto come una bestia nera da parte di molti tecnici, secondo forse solamente al subnetting delle classi IP. Su Linux uno dei problemi di BIND è che nelle prime versioni non era esattamente verboso in merito ai messaggi di errore, anzi era del tutto ermetico, quasi binario: o partiva o non partiva e forse ti faceva la grazia di dire qual era la zona con l’errore, ma poi erano affari tuoi.

Questo ha fatto in modo che, negli anni, molti tecnici abbiano sempre evitato di aver a che fare con la bestia e preferivano delegare ad altri la (ri)soluzione del problema.

La risoluzione di un nome a dominio è una faccenda troppo delicata per essere lasciata in mano a terzi, specialmente da quando sono iniziati gli attacchi ai DNS.

Le buone ragioni per avere un DNS locale sono molteplici e sono di gran lunga maggiori di quelle che consigliano di non averlo:

  • se qualcuno aggiorna una zona, i server DNS che hanno quella zona nella cache non recepiscono l’aggiornamento finché non scade il TTL (fenomeno detto anche “propagazione”); un reload o la pulizia della cache del DNS server che viene utilizzato permette di forzare il caricamento della nuova zona senza attendere la scadenza del TTL;
  • i client dei domini Active Directory utilizzano il DNS per cercare i domain controller e altri tipi di risorse di rete; se un client ha configurato i DNS del provider potrebbe non riuscire ad accedere in rete, se ha configurato sia il DNS di AD sia quello del provider potrebbe avere dei ritardi, senza contare il fatto che vengono rivelati al provider i FQDN dei computer di AD;
  • un down del DNS del provider (ci sono, ci sono…) tira giù tutti i clienti che hanno configurato quel server;
  • gli oscuramenti o le censure di alcuni siti vengono spesso attuati creando una finta zona primaria nei DNS dei provider: un DNS server proprio aggira questo blocco; la fotografia di questo articolo è un esempio;
  • una cache locale dei nomi da risolvere riduce di un pochino il traffico di rete sul canale Internet.

L’installazione di un DNS server locale è più semplice di quello che sembra.

Su Linux è sufficiente installare BIND, di norma la configurazione di default è già sufficiente per far funzionare il demone come server DNS in modalità cache, bisogna solamente verificare le impostazioni del firewall e di BIND per consentire query ricorsive solamente agli host della LAN. A livello client è necessario verificare le impostazioni di /etc/resolv.conf per controllare quale DNS server si sta utilizzando. Alcuni tool come NetworkManager modificano quel file, quindi bisogna verificare che le modifiche non vengono sovrascritte.

DNS MicrosoftWindows Server ha il proprio servizio DNS, che viene installato automaticamente assieme ad Active Directory.

Aprire la finestra delle proprietà del server DNS e controllare la linguetta Server d’inoltro che deve mostrare una lista vuota. Se sono elencati dei server, il servizio DNS inoltra a loro tutte le richieste che non riesce a soddisfare; se uno o più server indicati in questa lista non dovesse funzionare, la risoluzione dei nomi potrebbe essere rallentata o smettere del tutto di funzionare.

Un’altra linguetta da controllare è Parametri radice, che contiene l’elenco dei root DNS utilizzati dal servizio.

Se si riavvia il servizio DNS, la cache viene ripulita e eventuali zone aggiornate di recente vengono ricaricate con le ultime modifiche disponibili.

I firewall e i router di norma funzionano solamente da server di inoltro e non hanno dei server locali. Su pfSense è possibile installare il pacchetto opzionale Tinydns per avere un DNS server vero e proprio.

Se non si dispone di un server è possibile installare BIND su un Windows client, anche se in alcuni casi bisogna lavorarci un po’.

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

10 pensieri riguardo “Risolvere i nomi a casa propria”

  1. In effetti trovo che sia un’ottima idea quella di NON usare i server DNS del proprio provider. Oltre al citato tyny bisogodns e all’omnipresente Bind, ci sono anche altri sofware che si possono usare. Io uso spesso DnsMasq, che integra un comodo DHCP server (con risoluzione dinamica dei nomi degli host assegnati dal DHCP) ma che purtroppo non e` un resolver vero a proprio: esso infatti richiede di avere a monte un DNS che gli risolva i nomi. Una buona soluzione potrebbe essere accoppiare il comodo DnsMasq con un resolver completo come Unbound. Questo va bene se non dovete pubblicare zone, ovvero se non avete bisogno di essere autoritativi per delle vostre zone. Altrimenti si torna sempre a Bind.

  2. Ho seguito il tuo consiglio e nel mio ufficio ho provato a togliere dal 2008 server i server di inoltro (quelli della tin).
    Però il funzionamento adesso mi da qualche problema. Ogni tanto le richieste dns vanno in timeout (visto dal browser e provato poi con nslookup), spesso non posso accedere ad alcuni siti per qualche minuto. Poi ad un certo punto si risveglia e riparte.
    Ho provato a cercare soluzioni in giro senza troppa fortuna.

    1. Se e’ TIN hai una connessione cellulare e probabilmente sei dietro al NAT di TIN, nel qual caso potrebbe non essere una buona idea.
      Il consiglio vale per connessioni fisse costanti con IP pubblico.

    2. Premesso che non conosco le caratteristiche (timeout, uso di udp o tcp, ecc) del DNS di windows, qualche volta e` capitato anche a me con bind sotto linux. Alla prima richiesta non risolve, se rifaccio la richiesta risolve. Nei casi che ho debuggato a fondo ho sempre trovato una lentezza del DNS autoritativo a rispondermi. Quindi in pratica l’applicazione richiedente (tipicamente il browser) andava in timeout aspettando la risposta, la quale poi arrivava comunque al mio bind, con il risultato che alla seconda query avevo la risposta in cache ed era immediata.

      Solo in un paio di casi ho verificato che il DNS autoritativo proprio mi ignorava e non mi rispondeva mai. Facendo ulteriori indagini ho scoperto che per qualche motivo che sanno solo loro, i gestori del DNS in questione avevano evidentemente blacklistato il mio IP (veramente i miei IP, e credo tutta la /24) visto che da altre macchine su altre numerazioni riuscivo tranquillamente a fare le query.

      Morale: se vuoi una struttura veramente robusta e` meglio che tu usi DUE DNS tutti e due tuoi, uno sulla tua LAN e uno su altra rete (magari dall’altro capo del mondo). Uno dei due dovra` ben farcela a risolvere…

  3. sono su adsl telecom italia con ip fisso tra l’altro.
    Comunque rimetterò i forward, evidentemente c’è qualche inghippo nella configurazione del servizio dns che lo fa funzionare solo a tratti.

    1. Chiedo scusa, mi confondo sempre tra TIN e TIM…
      Se non funziona e’ sicuramente meglio mettere i forward sugli IP del provider. Un onesto tentativo potrebbe essere un test mettendo 8.8.8.8 e 8.8.4.4 per capire se il problema e’ nell’uso di un DNS diverso da quello del provider o nel fatto che il tuo server DNS locale non gradisce essere usato come caching DNS.
      Se l’IP del server e’ lo stesso di quello da cui stai scrivendo i commenti, non dovrebbe essere un problema perche’ ho clienti con il tuo stesso tipo di connessione che usano DNS propri.

      1. Vedo con piacere che non sono il solo che ogni volta deve rifarsi i conti sugli acronimi TIN e TIM per non confonderli 🙂

  4. Utilizzare il proprio dns server locale puntando direttamente ai root server come indicato in questa guida potrebbe rallentare la prima risoluzione di 100-150 ms se la connessione adsl ha una latenza alta (modalità interleaved, il default di quasi tutti i provider).

    Se il DNS inoltra al provider o a google (forwarder) le richieste, queste viaggeranno una sola volta attraverso l’adsl (supponiamo 50ms di latenza), mentre se il DNS contatta i root servers, i quali comunicano dove trovare il TLD, il dns chiede al TLD dove trovare il dominio (altri 50ms), il dns dovrà ora chiedere al dominio dove trovare il record WWW (altri 50ms, siamo a 150). Il tutto nel caso le risposte non si trovino già in cache.

    Nonostante questo ritardo aggiunto, comunque, configuro sempre in tutte le reti che progetto (eccetto connessioni satellitari da 600-700ms di latenza) il dns senza forwarder per i vantaggi descritti in questo articolo.

Spazio per un commento