Perché il server DNS non può risolvere alcun dominio che termina in .io?

Ho due controller di dominio Windows.

10.10.10.10 Primario (vittoria 2008 r2)
10.10.10.20 Replica (vittoria 2012 r2)

Il secondo è configurato come una replica del primo.

Circa una volta alla settimana, il controller di dominio primario memorizzerà nella cache negativamente la maggior parte dei .io domini. Questo rende così nessuno in azienda può accedere a siti come:

chef.io
packer.io
yahoo.io
github.io

Stranamente posso ancora accedere ad alcune pagine .io, come quelle su github.io

spuder.github.io/

La soluzione è eseguire RDP nel server DNS ed eseguirlo dnscmd /clearcache. Ciò risolve il problema da 7 a 10 giorni.

Ulteriori sintomi

Colpisce solo il controller di dominio primario (il controller di dominio secondario e altri possono risolvere questi siti bene)
Anche i server DNS di Google funzionano
Di solito succede intorno alle 11 di mercoledì.

Non ho molta familiarità con Windows, ma ecco le cose che ho provato

Guarda i log, vedo solo le seguenti righe che sembrano interessanti

8:15AM
The DNS server wrote version 4638 of zone 254.10.in-addr.arpa to file 254.10.in-addr.arpa.dns..in-addr.arpa to file 254.10.in-addr.arpa.dns.

8:16AM
A more recent version, version 4639 of zone 254.10.in-addr.arpa was found at the DNS server at 10.254.40.51. Zone transfer is in progress.ic replication between domain controllers in a common domain or forest. By installing multiple domain controllers in a domain running DNS Server, you can ensure that DNS will continue to work when a domain co

Verificare che non vi siano zone di ricerca diretta o inversa per il dominio .io
Assicurarsi che non vi sia nulla nel file hosts che blocchi il dominio .io
Confronta l'output di ipconfig /displaydnssu tutti i controller di dominio

C'è qualcos'altro che posso indagare per scoprire perché la cache DNS continua a essere corrotta in modo così prevedibile? Esiste un'impostazione di Windows DNS che può svuotare forzatamente la cache quando si esegue il trasferimento di zona

Aggiornamento L'
ho ridotto al fatto che spesso passo dal wireless al wireless proprio prima della riunione di mercoledì. Il wireless ha 1 server Windows 2008 dns e 1 server Windows 2012 dns. Quando il server 2008 è selezionato come primario, il problema ritorna. La soluzione è eseguire questo dnscmd /clearcache. Dal momento che il server 2008 sta andando via, sono sicuro che questo problema si risolverà da solo.

domain-name-system windows-server-2008-r2 internal-dns

— spuder
fonte

È terribilmente specifico. È come se i dati del nameserver per il ioTLD venissero bloccati o un dispositivo di rete a monte che non è condiviso con il controller di dominio secondario andasse in tilt a causa di politiche di ispezione di pacchetti profondi. Assicurarsi che non vi siano zone sul controller di dominio primario che potrebbero interferire con i nameserver a monte per quel TLD. ( ., io, net, ac, uk, co.uk, ns13.net, nic.io, nic.ac, icb.co.uk, communitydns.net) Sembra stupido, ma la gente a volte fanno cose molto Braindead quando si tenta di utilizzare il loro DC come una soluzione firewall DNS.

— Andrew B,

Un'altra cosa da fare è controllare come i server DNS eseguono ricerche non locali. Per ciascuno dei tuoi server DNS controlla le impostazioni per Forwarder e Suggerimenti di root. Se uno utilizza un server di inoltro filtrato e l'altro no, questo potrebbe essere il tuo problema. In alternativa, se hai un solo spedizioniere e un insieme incompleto di suggerimenti per la radice, potresti avere problemi di ricerca.

— Mark,

Cos'altro succede nel tuo sistema alle 11 di mercoledì, che potrebbe impedire a quel server di cercare quei domini (e memorizzare nella cache l'errore)?

— Calle Dybedahl,

quindi il problema è sul client, alcuni domini * .io non vengono risolti fino a quando non si cancella la cache? Se vai sulla console DNS, la GUI della console mostra gli IP corretti per quei nomi nella cache?

— strongline

Il tuo server DNS è configurato per utilizzare i server d'inoltro?

— Mike Marseglia,

Prendi in considerazione l'aggiornamento del file root.hints. Forse sta indicando alcuni vecchi server dei nomi di root che (per qualche ragione) non stanno restituendo domini .io.

Forse hai un problema di routing che impedisce di accedervi (ad esempio: stai modificando in modo nero l'intervallo IP su cui vengono eseguiti) che impedisce di cercare i domini al suo interno. Questa è la mia scommessa, forse hai una regola firewall contro un paese o un blocco IP. Usa i miei risultati qui sotto per controllare il tuo firewall o fare un dig / nslookup per i server TLD .io (puoi scaricare un binario per Windows da http://www.isc.org/downloads/

# dig +trace +identify git.io
...
io.                     172800  IN      NS      b0.nic.io.
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      a2.nic.io.
io.                     172800  IN      NS      ns-a1.io.
io.                     172800  IN      NS      ns-a3.io.
io.                     172800  IN      NS      c0.nic.io.
...

Riesci a raggiungere tutti questi server DNS direttamente? Ad esempio, il tuo server DNS può utilizzare ripetutamente il primo nell'elenco. Tieni presente che questo elenco è in un determinato momento (in questo momento) e cambia, ma dovrebbe darti un punto iniziale per vedere se riesci a raggiungere i server dei nomi radice .io.

# for i in b0.nic.io a0.nic.io a2.nic.io ns-a1.io ns-a3.io c0.nic.io; do host $i; done
b0.nic.io has address 65.22.161.17
b0.nic.io has IPv6 address 2a01:8840:9f::17
a0.nic.io has address 65.22.160.17
a0.nic.io has IPv6 address 2a01:8840:9e::17
a2.nic.io has address 65.22.163.17
a2.nic.io has IPv6 address 2a01:8840:a1::17
ns-a1.io has address 194.0.1.1
ns-a1.io has IPv6 address 2001:678:4::1
ns-a3.io has address 74.116.178.1
c0.nic.io has address 65.22.162.17
c0.nic.io has IPv6 address 2a01:8840:a0::17

Se stai utilizzando gli spedizionieri, prova direttamente un nslookup per quegli spedizionieri. Se non ritorna, contatta la persona che li gestisce (il tuo ISP).

==== Aggiornamento: dato l'aggiornamento, in cui si nota che succede quando si cambiano gli ISP, immagino che una delle tue connessioni stia utilizzando IPv6 e l'altra sia compatibile solo con IPv4? Potrebbe essere che sta memorizzando nella cache l'indirizzo di ritorno IPv6, ma ciò non è raggiungibile una volta cambiate le connessioni.

— michaelkrieger
fonte