Come fare in modo che il DNS di Windows Server utilizzi il file hosts per risolvere nomi host specifici

[NOTA: la soluzione di questa domanda è perfetta, per qualcosa che si allontana da ciò che indica il titolo.]

Sto affrontando un piccolo problema con Windows Server 2003 DNS service. Nella mia 172.16.0.12azienda , sto eseguendo il server DNS Microsoft ( ) per eseguire la risoluzione dei nomi nella mia intranet aziendale (il nome del dominio termina in dev.nls. Risolvendosi in IP 172.16 .. ) Ed è anche configurato come server d' inoltro DNS per inoltrare altri nomi di dominio ( ad es. * .google.com, * .sf.net) a Internet real DNS servers. Questo server DNS interno non tende mai a servire utenti da paesi esterni.

Inoltre, stiamo eseguendo un server di posta (che serve posta in arrivo per un vero dominio Internet @nlscan.com) all'interno del firewall aziendale a cui è possibile accedere in entrambi i modi:

1. connettendosi a 172.16.0.10dall'interno della Intranet.
2. connettendosi a mail.nlscan.com(risolto in 202.101.116.9) da Internet.

Si noti che 172.16.0.10e 202.101.116.9non è la stessa macchina fisica. L' 202uno è una macchina firewall che fanno port forwarding del porto 25e 110per l'indirizzo intranet 172.16.0.10.

Ora la mia domanda: se gli utenti all'interno della LAN aziendale vogliono risolvere mail.nlscan.com, si risolve 202.101.116.9. È corretto e fattibile, MA NON BUONO, perché il traffico di posta viene indirizzato alla macchina firewall per poi rimbalzare 172.16.0.10. Spero che il nostro internal DNS serverpossa intercettare il nome mail.nlscan.come risolverlo in 172.16.0.10. Quindi, spero di poter scrivere una voce nel file "hosts" 172.16.0.12per farlo. Ma come Microsoft DNS serverriconoscere questo file "hosts"?

Forse suggerisci, perché non utilizzare un utente Intranet 172.16.0.10per accedere al mio server di posta? Devo dire che è scomodo, supponiamo che un utente (dipendente) lavori sul suo laptop, di giorno in ufficio e di notte a casa. Quando è a casa, non può usare 172.16.0.10.

La creazione di una zona per nlscan.comil nostro interno DNS servernon è fattibile, poiché il server dei nomi per il nlscan.comdominio si trova sul nostro ISP ed è responsabile della risoluzione di altri nomi host e sottodomini in nlscan.com.

[MODIFICARE]

Come WesleyDavidsuggerito, seguo la soluzione di creare semplicemente una zona denominata mailserver.nlscan.come posizionare un record A senza nome in quella zona . Il tempo dimostra che funziona bene.

L'ultima parte di questo post è sbagliata. Ho avuto l'impressione, sulla base di alcune cose che avevo letto sul web (se è sul web, deve essere vero!) Che parte delle attività del servizio server DNS di Windows per la creazione della sua cache era di caricare anche il suo file host in cache insieme ai dati della sua zona locale. Ho cercato in giro e non sono riuscito a trovare prove concrete di ciò. Ho testato la teoria sul mio computer Server 2008 R2 e ho scoperto che il file hosts non è stato utilizzato per creare la cache del server DNS.

Tuttavia, credo di avere una soluzione leggermente più elegante di Massimo. Invece di creare una zona autorevole per l'intera zona nlscan.com, è sufficiente creare una zona denominata mailserver.nlscan.com e inserire un record A senza nome in quella zona. Il record A senza nome avrà lo stesso nome della zona stessa e puoi assegnargli l'indirizzo IP che desideri. Tutti gli altri domini sotto nlscan.com e nlscan.com si risolveranno tramite DNS pubblico.

Ho appena provato questo sul mio server DNS Server 2008 R2 e sono riuscito a far risolvere il sito Web del mio amico (nessus.nl) tramite server DNS pubblici ma il sottodominio specifico (blog.nessus.nl) si è risolto in un indirizzo IP di Apple.com . Provalo e vedi se funziona per te.

Inizio post più vecchio e sbagliato:

Se la mia comprensione è corretta (EDIT: e non lo è), quando la cache DNS è costruita nella macchina Server 2003, estrae le voci dal file hosts così come i suoi dati di zona. Inserire 172.16.0.10 mailserver.nlscan.comil file hosts della macchina Server 2003 dovrebbe risolvere il problema. Riavvia i servizi DNS dopo aver modificato il file hosts.

Utilizzare ipconfig / displaydns su qualsiasi macchina Windows (in particolare, la macchina DNS Server 2003) per visualizzare le voci del file host. Inoltre, tieni presente che le risposte negative vengono memorizzate nella cache dei tuoi client, quindi esegui sempre ipconfig / flushdns sui client con cui stai sperimentando. Altrimenti finirai per abusare di te contro vari oggetti duri mentre ti chiedi perché i tuoi clienti non riescano a risolvere un nome che hai appena inserito in un file di zona / host. =)

Hai provato questo e fallito?

È comune il desiderio che gli utenti interni ottengano IP interni per le risorse mentre gli utenti esterni ottengano IP esterni per quelle stesse risorse. Viene definito DNS split brain. Hai un server DNS che si affaccia su Internet e un altro server DNS interno per gli utenti locali. Gli utenti interni utilizzano DHCP sulla rete e su un server DHCP pubblicizzare il server DNS interno. Quando i tuoi utenti sono fuori sede, il loro server DHCP li assegnerà a un server DNS che conoscerà solo la zona esterna.

Sembra che desideri dividere il DNS del cervello senza effettivamente ospitare la zona internamente. Suggerisci che ospitare la zona internamente è problematico perché non vuoi che gli utenti ottengano l'IP interno quando lavorano da casa ma non ha senso perché quando sono in casa ottengono il loro IP da un altro server DHCP che non pubblicizzerà il tuo server DNS interno. Pubblicizzerà il server DNS del proprio ISP che conoscerà solo la tua zona esterna e fornirà quindi solo indirizzi IP esterni.

Infine, non credo che avrai successo nel chiedere a un server DNS di servire i record dal file hosts sul server DNS. Un server DNS serve record dai suoi file di zona. Il file hosts locale su quel server DNS propaga le voci nella cache di risoluzione del client locale che è applicabile solo alle ricerche su quella macchina. Queste voci non sono servite dal server DNS, che è un meccanismo diverso.

Leggi su DNS split brain - è il modo normale di gestire questa situazione.

Wes: Non sono sicuro di chi ti abbia oscurato, ma vorrei chiarire l'uso del file hosts: il file hosts è usato dal componente risolutore client DNS, non dal componente server DNS. Una voce nel file hosts su un server DNS verrà utilizzata dal server DNS quando agisce come client DNS. Ad esempio, una voce nel file hosts del mio server DNS W2K8 in questo modo:

1.1.1.1 test.test.com

viene caricato nella cache del client DNS del server DNS (non nella cache del server). Se eseguo il ping test.test.com dal mio server DNS restituisce 1.1.1.1 come previsto. Se quindi eseguo nslookup sul server DNS e lo chiedo per test.test.com, viene restituito l'indirizzo IP pubblico corretto registrato per test.test.com poiché il componente client DNS sul server DNS richiede ora la risoluzione del componente server DNS (proprio come farebbe qualsiasi altro client DNS). È un'idea confusa avvolgere la testa, ma il server DNS è anche un client DNS e quando il componente client DNS viene messo in azione si comporta come qualsiasi altro client DNS osservando la propria cache del client DNS, comprese tutte le voci pre caricato dal file hosts. Solo quando il componente client DNS utilizza il componente server DNS (eseguendo una query sui server DNS configurati in esso "

Qualsiasi client DNS che esegue una query sul server DNS otterrà sempre la risposta "reale" e non la voce host poiché la cache del client DNS del server DNS viene utilizzata dal server stesso (come client DNS) e non dal componente server DNS.

Per quanto ne so, non è possibile fare in modo che DNS DNS utilizzi il hostsfile per gestire la risoluzione dei nomi; ma questo non è necessario.

È possibile creare in modo sicuro una zona sul server DNS interno con lo stesso nome di una zona Internet pubblica; ciò che accadrà è che il server gestirà le richieste di nomi in quella zona utilizzando i propri dati, invece di inoltrare tali richieste ai server dei nomi autorevoli per quella zona; questo viene talvolta chiamato "shadowing", perché rende la zona pubblica "reale" non disponibile per il client interno, rispondendo invece con dati "falsi".

Quello di cui dovresti stare attento è che dovresti popolare questa zona interna con tutti i nomi di cui avrai bisogno, anche usando gli indirizzi IP pubblici dove necessario; in caso contrario, i client interni non saranno in grado di risolvere tali nomi.

Supponiamo che la tua zona pubblica assomigli a questo:

www.nlscan.com    202.101.116.8
mail.nlscan.com   202.101.116.9

Desideri che i client interni risolvano mail.nlscan.com come 172.16.0.10; va bene, quindi crei una zona "nlscan.com" sul tuo server DNS interno e inserisci "mail.nlscan.com -> 172.16.0.10" in essa.
Ma ora i tuoi client interni non possono risolvere "www.nlscan.com", perché il server ritiene che sia autorevole per quella zona, quindi non risponderà alla query (perché non conosce quell'host), ma anche non lo inoltrerà a nessuno.
Per risolvere questo problema, devi inserire anche "www.nlscan.com" nella tua zona interna; può indicare il suo vero indirizzo IP pubblico se desideri che i tuoi clienti accedano in quel modo, oppure potresti utilizzare lo stesso reindirizzamento che stai utilizzando per "mail.nlscan.com", se "www" viene inoltre inoltrato dal firewall a un server interno.
Lo stesso principio si applica a qualsiasi nome nella zona.

Questa configurazione non avrà alcun impatto sui client esterni o su nessuno dei tuoi utenti temporaneamente al di fuori della tua rete, perché quella zona "ombra" interna non sarà mai visibile da Internet.

Non dimenticare il file host, basta aggiungere una nuova zona nel DNS mail.domain.com e aggiungere un host nella zona. lascia vuoto il nome (utilizzerà automaticamente il nome della zona) e inserisci l'indirizzo IP del server di posta locale ;-)