none
Come aggiungere un server dns secondario RRS feed

  • Domanda

  • Ciao a tutti,
    se voglio aggiungere un dns secondario su un server distinto dal primo dove ho già installato un server con Controller di dominio, Active Directory, DNS e DHCP, devo aggiungere il ruolo dns se questo server secondario ? Oppure devo aggiungere anche un controller di dominio e Actove directory sempre sul secondo server ?
    domenica 18 settembre 2011 15:15

Risposte

  • oncordo al 100% sebbene non sia obbligatorio installare i ruoli DNS/DHCP su un DC, è comunque una buona idea farlo; come hai correttamente evidenziato, avere DC multipli (non solo due, possono essere anche di più !) garantisce continuità di servizio e maggior robustezza per l'infrastuttura AD

    Già che ci siamo... sarebbe un'ottima idea implementare l'infrastuttura DHCP in modo ridondante ad esempio implementando servers multipli ed usando la "regola 80/20" oppure seguendo le guidelines per l'implementazione di un DHCP failover o, se possibile, implementando sia un failover sia un DHCP 100/100 (si ok, è un "coso" non documentato ma, per esperienza diretta, funziona piuttosto bene)... dicevamo ... ah si, l'infrastuttura DHCP ed anche quella ActiveDirectory e DNS; per quanto riguarda AD, bisogna tener presente che il DNS è, a tutti gli effetti, la "spina dorsale" di AD, quindi avere dei DC multipli ED ANCHE dei DNS multipli è senza dubbio un'idea sana; in questo ambito, avendone le risorse, sarebbe anche opportuno valutare la messa in opera di un'infrastuttura DNS che permetta anche altre possibilità; per capirci

    Supponiamo di avere un dominio AD di nome "example.com" e diciamo anche che, in tale dominio, abbiamo due DC (che fungono anche da DNS e DHCP) di nome "ns1.example.com" ed "ns2.example.com"; sin qui, nulla di diverso da quanto detto sino ad ora... ma... a questo punto, installiamo un altro server (può tranquillamente  essere una virtual machine, nessun problema) configurandolo come semplice "member" (ossia niente DC) ed aggiungiamo a tale server il ruolo DNS (chiamiamolo "res1.example.com"); a questo punto avremo un server DNS aggiuntivo ma... assicuriamoci che tale server NON venga usato come resolver da alcun client o host della rete; in pratica sarà un DNS che, in questo momento nessuno usa

    Ora, ci si chiederà a cosa possa servire... semplice; iniziamo configurando "ns1" ed "ns2" (come sopra) in modo da usare "res1.example.com" come "dns forwarder"; in tal modo, tutte le queries indirizzate ad "ns1" o "ns2" e relative a domini esterni (es. "microsoft.com") verranno inoltrate da "ns1" o "ns2" al nostro "res1"; quest'ultimo dovrà essere configurato in modo da usare la ricorsione e NON usare alcun forwarder (server di inoltro); una volta che la config di cui sopra sia funzionante, dovremo inoltre configurare il firewall di rete in modo che tutto il traffico diretto alle porte 53/udp e 53/tcp venga permesso solo ed unicamente al nostro "res1.example.com", in tal modo tutta la risoluzione esterna passerà da tale box

    A questo punto qualcuno potrebbe iniziare a chiedersi per quale motivo abbiamo messo in piedi tutto questo "ambaradan" ... semplice, in questo modo avremo massimizzato la velocità di risoluzione dei nomi grazie al fatto che la cache di "res1" verrà rapidamente popolata con le queries provenienti dall'intera rete; avremo evitato problemi (sia di configurazione che relativi a bots/malware), dato che "res1" sarà l'unico DNS in grado di effettuare queries "esterne" ed avremo inoltre un punto di controllo unico, dato che abilitando i logs su "res1" saremo in grado di sapere "cosa viene richiesto al DNS" dai vari hosts della rete

    Ora, qualcuno potrebbe storcere il naso ed obiettare che una tale configurazione ha un "single point of failure" ... corretto, ma sino ad un certo punto, prima di tutto (ammesso che il gioco valga la candela) il DNS resolver (res1) potrebbe anche essere un "cluster"; in secondo luogo, un sistema del genere, implementato come VirtualMachine (VM) potrebbe essere ripristinato nel giro di pochi minuti dato che anche un backup risalente a qualche tempo prima sarebbe utile al ripristino (tutto sommato non c'è nulla di "vitale" su tale sistema)

    Ma veniamo ad un "trucco" interessante che è possibile con una tale configurazione; quello di cui sto parlando è il cosiddetto "DNS filtering"; se si considera che "res1" è l'unico host sul quale si basa la risoluzione "esterna" è facile capire come, agendo su tale host, sia possibile "reindirizzare" o "modificare" le risposte; ad esempio, volendo impedire agli utenti della propria rete l'accesso a (esempio a caso) "astalavista.com" (e parlo di qualsiasi host su quel dominio) sarà sufficiente creare su "res1" una zona primaria standard di nome "astalavista.com", inserire nella zona un record "jolly" (nome = "*") e farlo puntare ad un IP "fasullo" (es. 127.100.100.100) per bloccare a tutti gli effetti qualsiasi accesso a tale dominio

    L'idea di cui sopra non è nuova, anzi, esistono da tempo delle "liste di blocco" in formato "windows DNS" che permettono di attivare rapidamente il bloccaggio per tutta una serie di hosts/domini; ad esempio quella reperibile qui; questa lista permette di bloccare sia gli "ads" (popups, pubblicità indesiderata...) sia diversi siti "non esattemente consigliabili"; per usarla basta scaricarla in formato "windows DNS" (si tratta di un file da inserire nel registry) ed installarla seguendo le istruzioni (bisognerà creare una zona DNS "di blocco"); il bello di quanto sopra è che, una volta afferrato il concetto, sarà semplice ed immediato aggiornare il DNS allo scopo di bloccare ulteriori hosts/domini ed il tutto... senza dover usare alcun software aggiuntivo :)


    lunedì 19 settembre 2011 12:49
  • Non  entro qui in dettaglio sul funzionamento della ricorsione e sul come un server DNS risolva le queries

    Uff... mi contraddico ma... credo sia necessario

    Supponiamo di avere un nostro server DNS configurato per usare la ricorsione (nessun forwarders, root hints al loro posto) e diciamo che tale DNS sia stato appena acceso... ora, diciamo di inviare al nostro DNS una query di tipo "A" per ottenere l'indirizzo IP di "ftp.cisco.com"; date le premesse il nostro DNS non avrà nulla in cache, quindi gli unici indirizzi noti saranno quelli dei root servers, ossia (es.)

    .                       327533  IN      NS      g.root-servers.net.
    .                       327533  IN      NS      h.root-servers.net.
    .                       327533  IN      NS      k.root-servers.net.
    .                       327533  IN      NS      j.root-servers.net.
    .                       327533  IN      NS      f.root-servers.net.
    .                       327533  IN      NS      l.root-servers.net.
    .                       327533  IN      NS      b.root-servers.net.
    .                       327533  IN      NS      i.root-servers.net.
    .                       327533  IN      NS      d.root-servers.net.
    .                       327533  IN      NS      e.root-servers.net.
    .                       327533  IN      NS      a.root-servers.net.
    .                       327533  IN      NS      m.root-servers.net.
    .                       327533  IN      NS      c.root-servers.net.
    
    


    il nostro DNS a questo punto, prenderà uno degli indirizzi di cui sopra (a caso) ed invierà al root server una query iterativa (il flag "rd" ossia recursion desired sarà disattivato) chiedendo allo stesso l'indirizzo di "ftp.cisco.com" (nota: nel caso in cui la query verso il DNS selezionato fallisse, il nostro DNS ritenterebbe con il successivo e così via sino ad esaurire la lista dei DNS o a ricevere una risposta, sia questa positiva o negativa)

    Il root server a questo punto risponderà con i cosiddetti "glue" records, ossia con qualcosa di questo tipo

    com.                    172800  IN      NS      d.gtld-servers.net.
    com.                    172800  IN      NS      g.gtld-servers.net.
    com.                    172800  IN      NS      a.gtld-servers.net.
    com.                    172800  IN      NS      k.gtld-servers.net.
    com.                    172800  IN      NS      e.gtld-servers.net.
    com.                    172800  IN      NS      h.gtld-servers.net.
    com.                    172800  IN      NS      m.gtld-servers.net.
    com.                    172800  IN      NS      i.gtld-servers.net.
    com.                    172800  IN      NS      b.gtld-servers.net.
    com.                    172800  IN      NS      c.gtld-servers.net.
    com.                    172800  IN      NS      j.gtld-servers.net.
    com.                    172800  IN      NS      l.gtld-servers.net.
    com.                    172800  IN      NS      f.gtld-servers.net.
    
    

    tale risposta del root server potrebbe essere tradotta in termini umani come "non so quale sia l'indirizzo IP di ftp.cisco.com, ma ho l'elenco dei DNS autoritativi per il dominio "com" eccoli qui, prova a chiedere a loro"

    A questo punto, il nostro bravo DNS, ricevuta la risposta di cui sopra (e dopo aver memorizzato la stessa nella propria cache) selezionerà uno dei servers gTLD (quelli autoritativi per "com" come visto sopra) e, di nuovo invierà a tale server la richiesta per conoscere l'indirizzo IP di "ftp.cisco.com"

    Il server gTLD, di nuovo, non essendo autoritativo per il dominio "cisco.com" ritornerà una serie di "glue" records, ossia

    cisco.com.              172800  IN      NS      ns1.cisco.com.
    cisco.com.              172800  IN      NS      ns2.cisco.com.
    
    

    che, in termini umani, significano "non ho idea dell'IP di ftp.cisco.com, però so che quelli sopra sono i servers autoritativi relativi al dominio cisco.com, prova a chiedere a loro"

    Di nuovo, il nostro bravo DNS memorizzerà in cache le risposte, selezionerà uno dei servers e ripeterà la query verso uno di questi e, siccome tali servers sono autoritativi per il dominio "cisco.com" e conoscono l'IP di "ftp.cisco.com" la risposta stavolta sarà

    ftp.cisco.com.          86400   IN      CNAME   download-rcdn1.cisco.com.
    download-rcdn1.cisco.com. 86400 IN      A       72.163.7.54
    
    

    a questo punto il nostro DNS, dopo aver memorizzato in cache quanto sopra, ritornerà il risultato della nostra query dicendoci che l'indirizzo IP di ftp.cisco.com è 72.163.7.54

    Ora, supponiamo di inviare al nostro DNS una nuova query per (es.) www.cisco.com in questo caso, siccome il nostro DNS ha già in cache le informazioni relative ai DNS autoritativi per "cisco.com", invece di ripartire dai root-servers (come sopra) non farà altro che richiedere informazioni direttamente ad uno dei DNS autoritativi per "cisco.com" che già conosce; la stessa cosa accadrà nel caso un cui richiedessimo la risoluzione di "www.microsoft.com" in questo caso, il nostro DNS pur non sapendo quali siano i DNS autoritativi per "microsoft.com" saprà quali sono quelli per "com" quindi, di nuovo, invece di passare dai root servers, inizierà la query ricorsiva direttamente dai "gTLD" servers (visti sopra)

    Riguardo il meccanismo di caching; se fai caso ai records nell'esempio visto sopra, ciascun record ha un "numero", tale numero detto TTL (Time To Live) viene ritornato dal DNS autoritativo per un dato dominio (root, gTLD... qualsiasi altro...) e rappresenta il tempo in secondi per il quale un dato record DNS può essere considerato valido; scaduto tale tempo il record andrà rimosso dalla cache e, se richiesto nuovamente, causerà una nuova query verso il server autoritativo per quel dato dominio; questo meccanismo serve sia ad evitare che la cache del nostro resolver cresca indefinitamente, sia a permettere ai record DNS di cambiare nel tempo, ad esempio, un host potrebbe avere un record A con un TTL di 120 secondi e che punta (in questo momento) a 192.0.2.100; allo scadere del TTL il record in cache verrà rimosso ed una nuova query per lo stesso host potrà ritornare un altro record, con lo stesso TTL ma con IP 192.0.2.101

    Ok, credo di aver fatto abbastanza confusione, la smetto

    ciao

     

    martedì 20 settembre 2011 14:33
  • puoi tranquillamente aggiungere i ruoli di DNS Server e di DHCP Server anche ad un server che sia un semplice server membro di dominio.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    lunedì 19 settembre 2011 07:23
    Moderatore
  • Una osservazione però : avere due domain controller ti darebbe alcune garanzie di continuità che con un solo server D.C. non hai.

    Valuta la possibilità di implementare anche questa funzionalità, non come obbligo ma come "valore aggiunto".


    Fabrizio Volpe
    MVP Directory Services
    MCSE (NT4)(2000)(2003) - MCSA (2003)
    MCTS (SQL 2005)(Exchange 2007)(Windows 2008)
    VMware Certified Professional on vSphere 4
    Fortinet Certified Network Security Professional (FCNSP)
    Fabrizio[_dot_]Volpe[_at_]GMX[_dot_]com
    lunedì 19 settembre 2011 09:02
  • Ciao ObiWan, io di solito uso i Forwarders. Per usare la ricursione basta non indicare nessun forwarders e NON disabilitare la recursion?

    Lui utilizzerà i server root impostati dunque? Mi puoi spiegare se ho detto male?


    No, hai scritto tutto correttamente; l'idea di base è quella di lasciare che il DNS (o i DNS) che vuoi usare come "resolvers" utilizzino il meccanismo standard (ossia facciano ciò che sono stati scritti per fare) allo scopo di risolvere le queries indirizzate a domini "esterni"; a tale scopo, basta configurare il DNS senza specificare alcun forwarder ma assicurandosi che i "root hints" ("parametri principali" nella pessima traduzione italiana) siano correttamente popolati, accertandosi inoltre che il firewall posto "di fronte" al DNS permetta all'IP dello stesso di inviare queries verso l'esterno alle porte 53/udp e 53/tcp; il resto... viene da solo

    Non  entro qui in dettaglio sul funzionamento della ricorsione e sul come un server DNS risolva le queries (se vuoi lo faccio, ma... finiremmo del tutto off-topic :D) ; ti lascio soltanto qualche link che, spero, ti permetterà di comprendere meglio tutto quanto

    * DNS for rocket scientists

    * How DNS works

    * How to configure DNS for Internet access

    * EDNS0 explained

    * How to troubleshoot EDNS0 issues

    * Windows hostname resolution

    ciao e... buona lettura :)

     


    martedì 20 settembre 2011 12:54

Tutte le risposte

  • puoi tranquillamente aggiungere i ruoli di DNS Server e di DHCP Server anche ad un server che sia un semplice server membro di dominio.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    lunedì 19 settembre 2011 07:23
    Moderatore
  • Una osservazione però : avere due domain controller ti darebbe alcune garanzie di continuità che con un solo server D.C. non hai.

    Valuta la possibilità di implementare anche questa funzionalità, non come obbligo ma come "valore aggiunto".


    Fabrizio Volpe
    MVP Directory Services
    MCSE (NT4)(2000)(2003) - MCSA (2003)
    MCTS (SQL 2005)(Exchange 2007)(Windows 2008)
    VMware Certified Professional on vSphere 4
    Fortinet Certified Network Security Professional (FCNSP)
    Fabrizio[_dot_]Volpe[_at_]GMX[_dot_]com
    lunedì 19 settembre 2011 09:02
  • Una osservazione però : avere due domain controller ti darebbe alcune garanzie di continuità che con un solo server D.C. non hai.


    +1
    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    lunedì 19 settembre 2011 09:05
    Moderatore
  • Una osservazione però : avere due domain controller ti darebbe alcune garanzie di continuità che con un solo server D.C. non hai.

    Valuta la possibilità di implementare anche questa funzionalità, non come obbligo ma come "valore aggiunto". 

    Concordo al 100% sebbene non sia obbligatorio installare i ruoli DNS/DHCP su un DC, è comunque una buona idea farlo; come hai correttamente evidenziato, avere DC multipli (non solo due, possono essere anche di più !) garantisce continuità di servizio e maggior robustezza per l'infrastuttura AD

     

    lunedì 19 settembre 2011 11:10
  • oncordo al 100% sebbene non sia obbligatorio installare i ruoli DNS/DHCP su un DC, è comunque una buona idea farlo; come hai correttamente evidenziato, avere DC multipli (non solo due, possono essere anche di più !) garantisce continuità di servizio e maggior robustezza per l'infrastuttura AD

    Già che ci siamo... sarebbe un'ottima idea implementare l'infrastuttura DHCP in modo ridondante ad esempio implementando servers multipli ed usando la "regola 80/20" oppure seguendo le guidelines per l'implementazione di un DHCP failover o, se possibile, implementando sia un failover sia un DHCP 100/100 (si ok, è un "coso" non documentato ma, per esperienza diretta, funziona piuttosto bene)... dicevamo ... ah si, l'infrastuttura DHCP ed anche quella ActiveDirectory e DNS; per quanto riguarda AD, bisogna tener presente che il DNS è, a tutti gli effetti, la "spina dorsale" di AD, quindi avere dei DC multipli ED ANCHE dei DNS multipli è senza dubbio un'idea sana; in questo ambito, avendone le risorse, sarebbe anche opportuno valutare la messa in opera di un'infrastuttura DNS che permetta anche altre possibilità; per capirci

    Supponiamo di avere un dominio AD di nome "example.com" e diciamo anche che, in tale dominio, abbiamo due DC (che fungono anche da DNS e DHCP) di nome "ns1.example.com" ed "ns2.example.com"; sin qui, nulla di diverso da quanto detto sino ad ora... ma... a questo punto, installiamo un altro server (può tranquillamente  essere una virtual machine, nessun problema) configurandolo come semplice "member" (ossia niente DC) ed aggiungiamo a tale server il ruolo DNS (chiamiamolo "res1.example.com"); a questo punto avremo un server DNS aggiuntivo ma... assicuriamoci che tale server NON venga usato come resolver da alcun client o host della rete; in pratica sarà un DNS che, in questo momento nessuno usa

    Ora, ci si chiederà a cosa possa servire... semplice; iniziamo configurando "ns1" ed "ns2" (come sopra) in modo da usare "res1.example.com" come "dns forwarder"; in tal modo, tutte le queries indirizzate ad "ns1" o "ns2" e relative a domini esterni (es. "microsoft.com") verranno inoltrate da "ns1" o "ns2" al nostro "res1"; quest'ultimo dovrà essere configurato in modo da usare la ricorsione e NON usare alcun forwarder (server di inoltro); una volta che la config di cui sopra sia funzionante, dovremo inoltre configurare il firewall di rete in modo che tutto il traffico diretto alle porte 53/udp e 53/tcp venga permesso solo ed unicamente al nostro "res1.example.com", in tal modo tutta la risoluzione esterna passerà da tale box

    A questo punto qualcuno potrebbe iniziare a chiedersi per quale motivo abbiamo messo in piedi tutto questo "ambaradan" ... semplice, in questo modo avremo massimizzato la velocità di risoluzione dei nomi grazie al fatto che la cache di "res1" verrà rapidamente popolata con le queries provenienti dall'intera rete; avremo evitato problemi (sia di configurazione che relativi a bots/malware), dato che "res1" sarà l'unico DNS in grado di effettuare queries "esterne" ed avremo inoltre un punto di controllo unico, dato che abilitando i logs su "res1" saremo in grado di sapere "cosa viene richiesto al DNS" dai vari hosts della rete

    Ora, qualcuno potrebbe storcere il naso ed obiettare che una tale configurazione ha un "single point of failure" ... corretto, ma sino ad un certo punto, prima di tutto (ammesso che il gioco valga la candela) il DNS resolver (res1) potrebbe anche essere un "cluster"; in secondo luogo, un sistema del genere, implementato come VirtualMachine (VM) potrebbe essere ripristinato nel giro di pochi minuti dato che anche un backup risalente a qualche tempo prima sarebbe utile al ripristino (tutto sommato non c'è nulla di "vitale" su tale sistema)

    Ma veniamo ad un "trucco" interessante che è possibile con una tale configurazione; quello di cui sto parlando è il cosiddetto "DNS filtering"; se si considera che "res1" è l'unico host sul quale si basa la risoluzione "esterna" è facile capire come, agendo su tale host, sia possibile "reindirizzare" o "modificare" le risposte; ad esempio, volendo impedire agli utenti della propria rete l'accesso a (esempio a caso) "astalavista.com" (e parlo di qualsiasi host su quel dominio) sarà sufficiente creare su "res1" una zona primaria standard di nome "astalavista.com", inserire nella zona un record "jolly" (nome = "*") e farlo puntare ad un IP "fasullo" (es. 127.100.100.100) per bloccare a tutti gli effetti qualsiasi accesso a tale dominio

    L'idea di cui sopra non è nuova, anzi, esistono da tempo delle "liste di blocco" in formato "windows DNS" che permettono di attivare rapidamente il bloccaggio per tutta una serie di hosts/domini; ad esempio quella reperibile qui; questa lista permette di bloccare sia gli "ads" (popups, pubblicità indesiderata...) sia diversi siti "non esattemente consigliabili"; per usarla basta scaricarla in formato "windows DNS" (si tratta di un file da inserire nel registry) ed installarla seguendo le istruzioni (bisognerà creare una zona DNS "di blocco"); il bello di quanto sopra è che, una volta afferrato il concetto, sarà semplice ed immediato aggiornare il DNS allo scopo di bloccare ulteriori hosts/domini ed il tutto... senza dover usare alcun software aggiuntivo :)


    lunedì 19 settembre 2011 12:49
  • Ciao ObiWan, io di solito uso i Forwarders. Per usare la ricursione basta non indicare nessun forwarders e NON disabilitare la recursion?

    Lui utilizzerà i server root impostati dunque? Mi puoi spiegare se ho detto male?

    Grazie

    martedì 20 settembre 2011 12:04
  • Ciao ObiWan, io di solito uso i Forwarders. Per usare la ricursione basta non indicare nessun forwarders e NON disabilitare la recursion?

    Lui utilizzerà i server root impostati dunque? Mi puoi spiegare se ho detto male?


    No, hai scritto tutto correttamente; l'idea di base è quella di lasciare che il DNS (o i DNS) che vuoi usare come "resolvers" utilizzino il meccanismo standard (ossia facciano ciò che sono stati scritti per fare) allo scopo di risolvere le queries indirizzate a domini "esterni"; a tale scopo, basta configurare il DNS senza specificare alcun forwarder ma assicurandosi che i "root hints" ("parametri principali" nella pessima traduzione italiana) siano correttamente popolati, accertandosi inoltre che il firewall posto "di fronte" al DNS permetta all'IP dello stesso di inviare queries verso l'esterno alle porte 53/udp e 53/tcp; il resto... viene da solo

    Non  entro qui in dettaglio sul funzionamento della ricorsione e sul come un server DNS risolva le queries (se vuoi lo faccio, ma... finiremmo del tutto off-topic :D) ; ti lascio soltanto qualche link che, spero, ti permetterà di comprendere meglio tutto quanto

    * DNS for rocket scientists

    * How DNS works

    * How to configure DNS for Internet access

    * EDNS0 explained

    * How to troubleshoot EDNS0 issues

    * Windows hostname resolution

    ciao e... buona lettura :)

     


    martedì 20 settembre 2011 12:54
  • In questo modo io posso evitare dunque di impostare gli indirizzi ip dei server dns di Google oppure di OpenDns?

    Immagino che il tutto funzioni meglio?

    martedì 20 settembre 2011 13:02
  • Già che ci siamo... sarebbe un'ottima idea implementare l'infrastuttura DHCP in modo ridondante ad esempio implementando servers multipli ed usando la "regola 80/20" oppure seguendo le guidelines per l'implementazione di un DHCP failover o, se possibile, implementando sia un failover sia un DHCP 100/100 (si ok, è un "coso" non documentato ma, per esperienza diretta, funziona piuttosto bene)... dicevamo ... ah si, l'infrastuttura DHCP ed anche quella ActiveDirectory e DNS; per quanto riguarda AD, bisogna tener presente che il DNS è, a tutti gli effetti, la "spina dorsale" di AD, quindi avere dei DC multipli ED ANCHE dei DNS multipli è senza dubbio un'idea sana; in questo ambito, avendone le risorse, sarebbe anche opportuno valutare la messa in opera di un'infrastuttura DNS che permetta anche altre possibilità; per capirci

    Supponiamo di avere un dominio AD di nome "example.com" e diciamo anche che, in tale dominio, abbiamo due DC (che fungono anche da DNS e DHCP) di nome "ns1.example.com" ed "ns2.example.com"; sin qui, nulla di diverso da quanto detto sino ad ora... ma... a questo punto, installiamo un altro server (può tranquillamente  essere una virtual machine, nessun problema) configurandolo come semplice "member" (ossia niente DC) ed aggiungiamo a tale server il ruolo DNS (chiamiamolo "res1.example.com"); a questo punto avremo un server DNS aggiuntivo ma... assicuriamoci che tale server NON venga usato come resolver da alcun client o host della rete; in pratica sarà un DNS che, in questo momento nessuno usa

    Ora, ci si chiederà a cosa possa servire... semplice; iniziamo configurando "ns1" ed "ns2" (come sopra) in modo da usare "res1.example.com" come "dns forwarder"; in tal modo, tutte le queries indirizzate ad "ns1" o "ns2" e relative a domini esterni (es. "microsoft.com") verranno inoltrate da "ns1" o "ns2" al nostro "res1"; quest'ultimo dovrà essere configurato in modo da usare la ricorsione e NON usare alcun forwarder (server di inoltro); una volta che la config di cui sopra sia funzionante, dovremo inoltre configurare il firewall di rete in modo che tutto il traffico diretto alle porte 53/udp e 53/tcp venga permesso solo ed unicamente al nostro "res1.example.com", in tal modo tutta la risoluzione esterna passerà da tale box

    A questo punto qualcuno potrebbe iniziare a chiedersi per quale motivo abbiamo messo in piedi tutto questo "ambaradan" ... semplice, in questo modo avremo massimizzato la velocità di risoluzione dei nomi grazie al fatto che la cache di "res1" verrà rapidamente popolata con le queries provenienti dall'intera rete; avremo evitato problemi (sia di configurazione che relativi a bots/malware), dato che "res1" sarà l'unico DNS in grado di effettuare queries "esterne" ed avremo inoltre un punto di controllo unico, dato che abilitando i logs su "res1" saremo in grado di sapere "cosa viene richiesto al DNS" dai vari hosts della rete

    Ora, qualcuno potrebbe storcere il naso ed obiettare che una tale configurazione ha un "single point of failure" ... corretto, ma sino ad un certo punto, prima di tutto (ammesso che il gioco valga la candela) il DNS resolver (res1) potrebbe anche essere un "cluster"; in secondo luogo, un sistema del genere, implementato come VirtualMachine (VM) potrebbe essere ripristinato nel giro di pochi minuti dato che anche un backup risalente a qualche tempo prima sarebbe utile al ripristino (tutto sommato non c'è nulla di "vitale" su tale sistema)

    Ma veniamo ad un "trucco" interessante che è possibile con una tale configurazione; quello di cui sto parlando è il cosiddetto "DNS filtering"; se si considera che "res1" è l'unico host sul quale si basa la risoluzione "esterna" è facile capire come, agendo su tale host, sia possibile "reindirizzare" o "modificare" le risposte; ad esempio, volendo impedire agli utenti della propria rete l'accesso a (esempio a caso) "astalavista.com" (e parlo di qualsiasi host su quel dominio) sarà sufficiente creare su "res1" una zona primaria standard di nome "astalavista.com", inserire nella zona un record "jolly" (nome = "*") e farlo puntare ad un IP "fasullo" (es. 127.100.100.100) per bloccare a tutti gli effetti qualsiasi accesso a tale dominio

    L'idea di cui sopra non è nuova, anzi, esistono da tempo delle "liste di blocco" in formato "windows DNS" che permettono di attivare rapidamente il bloccaggio per tutta una serie di hosts/domini; ad esempio quella reperibile qui; questa lista permette di bloccare sia gli "ads" (popups, pubblicità indesiderata...) sia diversi siti "non esattemente consigliabili"; per usarla basta scaricarla in formato "windows DNS" (si tratta di un file da inserire nel registry) ed installarla seguendo le istruzioni (bisognerà creare una zona DNS "di blocco"); il bello di quanto sopra è che, una volta afferrato il concetto, sarà semplice ed immediato aggiornare il DNS allo scopo di bloccare ulteriori hosts/domini ed il tutto... senza dover usare alcun software aggiuntivo :)



    Ciao,

    Voto di utilita' guadagnato :-)

    Un saluto,


    Anca Popa Follow ForumTechNetIt on Twitter

    Come inserire immagini nei post

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda

    martedì 20 settembre 2011 13:05
  • In questo modo io posso evitare dunque di impostare gli indirizzi ip dei server dns di Google oppure di OpenDns?

    Direi proprio di si; fatti una domanda: secondo te, se tu configuri il tuo DNS per usare i servers di opendns/google/... come forwarders, come fanno secondo te questi servers a risolvere le tue queries :D ?

    Immagino che il tutto funzioni meglio?

    Diciamo che avrai maggior controllo sulle queries DNS e diciamo anche che, nel caso il tuo (i tuoi) DNS venga usato anche da un mailserver che ha la necessità di interrogare delle blacklists, usando la ricorsione diretta invece di ODNS/Google/... eviterai un tot di problemi (ad esempio, questo) :)

     


    • Modificato ObiWan martedì 20 settembre 2011 15:12
    martedì 20 settembre 2011 14:10
  • Non  entro qui in dettaglio sul funzionamento della ricorsione e sul come un server DNS risolva le queries

    Uff... mi contraddico ma... credo sia necessario

    Supponiamo di avere un nostro server DNS configurato per usare la ricorsione (nessun forwarders, root hints al loro posto) e diciamo che tale DNS sia stato appena acceso... ora, diciamo di inviare al nostro DNS una query di tipo "A" per ottenere l'indirizzo IP di "ftp.cisco.com"; date le premesse il nostro DNS non avrà nulla in cache, quindi gli unici indirizzi noti saranno quelli dei root servers, ossia (es.)

    .                       327533  IN      NS      g.root-servers.net.
    .                       327533  IN      NS      h.root-servers.net.
    .                       327533  IN      NS      k.root-servers.net.
    .                       327533  IN      NS      j.root-servers.net.
    .                       327533  IN      NS      f.root-servers.net.
    .                       327533  IN      NS      l.root-servers.net.
    .                       327533  IN      NS      b.root-servers.net.
    .                       327533  IN      NS      i.root-servers.net.
    .                       327533  IN      NS      d.root-servers.net.
    .                       327533  IN      NS      e.root-servers.net.
    .                       327533  IN      NS      a.root-servers.net.
    .                       327533  IN      NS      m.root-servers.net.
    .                       327533  IN      NS      c.root-servers.net.
    
    


    il nostro DNS a questo punto, prenderà uno degli indirizzi di cui sopra (a caso) ed invierà al root server una query iterativa (il flag "rd" ossia recursion desired sarà disattivato) chiedendo allo stesso l'indirizzo di "ftp.cisco.com" (nota: nel caso in cui la query verso il DNS selezionato fallisse, il nostro DNS ritenterebbe con il successivo e così via sino ad esaurire la lista dei DNS o a ricevere una risposta, sia questa positiva o negativa)

    Il root server a questo punto risponderà con i cosiddetti "glue" records, ossia con qualcosa di questo tipo

    com.                    172800  IN      NS      d.gtld-servers.net.
    com.                    172800  IN      NS      g.gtld-servers.net.
    com.                    172800  IN      NS      a.gtld-servers.net.
    com.                    172800  IN      NS      k.gtld-servers.net.
    com.                    172800  IN      NS      e.gtld-servers.net.
    com.                    172800  IN      NS      h.gtld-servers.net.
    com.                    172800  IN      NS      m.gtld-servers.net.
    com.                    172800  IN      NS      i.gtld-servers.net.
    com.                    172800  IN      NS      b.gtld-servers.net.
    com.                    172800  IN      NS      c.gtld-servers.net.
    com.                    172800  IN      NS      j.gtld-servers.net.
    com.                    172800  IN      NS      l.gtld-servers.net.
    com.                    172800  IN      NS      f.gtld-servers.net.
    
    

    tale risposta del root server potrebbe essere tradotta in termini umani come "non so quale sia l'indirizzo IP di ftp.cisco.com, ma ho l'elenco dei DNS autoritativi per il dominio "com" eccoli qui, prova a chiedere a loro"

    A questo punto, il nostro bravo DNS, ricevuta la risposta di cui sopra (e dopo aver memorizzato la stessa nella propria cache) selezionerà uno dei servers gTLD (quelli autoritativi per "com" come visto sopra) e, di nuovo invierà a tale server la richiesta per conoscere l'indirizzo IP di "ftp.cisco.com"

    Il server gTLD, di nuovo, non essendo autoritativo per il dominio "cisco.com" ritornerà una serie di "glue" records, ossia

    cisco.com.              172800  IN      NS      ns1.cisco.com.
    cisco.com.              172800  IN      NS      ns2.cisco.com.
    
    

    che, in termini umani, significano "non ho idea dell'IP di ftp.cisco.com, però so che quelli sopra sono i servers autoritativi relativi al dominio cisco.com, prova a chiedere a loro"

    Di nuovo, il nostro bravo DNS memorizzerà in cache le risposte, selezionerà uno dei servers e ripeterà la query verso uno di questi e, siccome tali servers sono autoritativi per il dominio "cisco.com" e conoscono l'IP di "ftp.cisco.com" la risposta stavolta sarà

    ftp.cisco.com.          86400   IN      CNAME   download-rcdn1.cisco.com.
    download-rcdn1.cisco.com. 86400 IN      A       72.163.7.54
    
    

    a questo punto il nostro DNS, dopo aver memorizzato in cache quanto sopra, ritornerà il risultato della nostra query dicendoci che l'indirizzo IP di ftp.cisco.com è 72.163.7.54

    Ora, supponiamo di inviare al nostro DNS una nuova query per (es.) www.cisco.com in questo caso, siccome il nostro DNS ha già in cache le informazioni relative ai DNS autoritativi per "cisco.com", invece di ripartire dai root-servers (come sopra) non farà altro che richiedere informazioni direttamente ad uno dei DNS autoritativi per "cisco.com" che già conosce; la stessa cosa accadrà nel caso un cui richiedessimo la risoluzione di "www.microsoft.com" in questo caso, il nostro DNS pur non sapendo quali siano i DNS autoritativi per "microsoft.com" saprà quali sono quelli per "com" quindi, di nuovo, invece di passare dai root servers, inizierà la query ricorsiva direttamente dai "gTLD" servers (visti sopra)

    Riguardo il meccanismo di caching; se fai caso ai records nell'esempio visto sopra, ciascun record ha un "numero", tale numero detto TTL (Time To Live) viene ritornato dal DNS autoritativo per un dato dominio (root, gTLD... qualsiasi altro...) e rappresenta il tempo in secondi per il quale un dato record DNS può essere considerato valido; scaduto tale tempo il record andrà rimosso dalla cache e, se richiesto nuovamente, causerà una nuova query verso il server autoritativo per quel dato dominio; questo meccanismo serve sia ad evitare che la cache del nostro resolver cresca indefinitamente, sia a permettere ai record DNS di cambiare nel tempo, ad esempio, un host potrebbe avere un record A con un TTL di 120 secondi e che punta (in questo momento) a 192.0.2.100; allo scadere del TTL il record in cache verrà rimosso ed una nuova query per lo stesso host potrà ritornare un altro record, con lo stesso TTL ma con IP 192.0.2.101

    Ok, credo di aver fatto abbastanza confusione, la smetto

    ciao

     

    martedì 20 settembre 2011 14:33
  • solo un voto utilità e un voto risposta perchè di più non posso dare.

    senti, ma percè non scrivi un libro ?

    ah, no, di questo abbiamo già parlato :-D


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    martedì 20 settembre 2011 14:48
    Moderatore
  • senti, ma perchè non scrivi un libro ?

    Beh, un libro lo leggerebbero in pochi e poi, visto che una volta si parla di SMTP/Email, un'altra volta di DNS, poi di FTP, firewalls... come dovrei intitolarlo il libro "Come far saltare in aria la propria rete facendo esperimenti" :D ?

    Seriamente, credo che un post qui abbia maggiore utilità; per lo meno potrà servire (anche come link) a chiunque abbia gli stessi problemi

     

    martedì 20 settembre 2011 14:58
  • Ipotiziamo di fare come dici tu, ho due server ns1.example.com e ns2.example.com con forwarders verso res1.example.com, il quale risolve direttamente.

    Ipotiziamo di non voler creare un cluster per res1.example.com ma di volere un minimo di affidabilità nel caso quest'ultimo server non funzioni.

    Imposto un server dns esterno (8.8.8.8 ad esempio) al secondo posto e al terzo come ordine di forwarders sui server ns1.example.com e ns2.example.com?

    Cosa succede in questo caso? Vengono interpellati solamente se res1.example.com non risponde?

    martedì 20 settembre 2011 18:37
  • Ipotizziamo di fare come dici tu, ho due server ns1.example.com e ns2.example.com con forwarders verso res1.example.com, il quale risolve direttamente.

    Ipotizziamo di non voler creare un cluster per res1.example.com ma di volere un minimo di affidabilità nel caso quest'ultimo server non funzioni.

    Anche non creando un cluster, si potrebbero mettere in piedi più resolvers (es. res1 e res2) e far puntare i DNS AD (ns1 ed ns2) ad entrambi tali resolvers; oppure, come ho già scritto, basterebbe che res1 fosse una VirtualMachine; una volta installata e configurata la stessa, basterebbe farne una copia ed in caso di problemi ci vorrebbe pochissimo tempo per ripristinare la copia e rimettere in funzione il resolver... di nuovo, tutto dipende dal livello di fault-tolerance che si desidera ottenere e dalle risorse disponibili

    Imposto un server dns esterno (8.8.8.8 ad esempio) al secondo posto e al terzo come ordine di forwarders sui server ns1.example.com e ns2.example.com?

    Cosa succede in questo caso? Vengono interpellati solamente se res1.example.com non risponde?

    I forwarders vengono interpellati comunque... e viene accettata la prima risposta da uno qualunque degli stessi (diverso è il meccanismo usato dal client resolver che utilizza i timeouts deifiniti nel registry alla voce DnsQueryTimeouts ma... in questo contesto la cosa non ci interessa); tra l'altro, come ho già scritto, sconsiglio l'uso di "open resolvers" come quelli di google, opendns o level3 dato che sono spesso causa di problemi (ad esempio, come ho già scritto, nel caso di DNS blacklists... ma non solo, ci sono anche problemi di sicurezza ed affidabilità); che c'entra, l'uso di public resolver è ancora accettabile nel caso di installazioni domestiche o piccoli uffici ma, ripeto, ne sconsiglio l'uso in un'infrastuttura di rete che abbia i propri DNS; in tale ambito è sufficiente lasciare che i DNS svolgano il proprio lavoro così come sono progettati per fare.
    mercoledì 21 settembre 2011 07:14