Server server 2012R2 DNS che restituisce SERVFAIL per alcune query AAAA

(Rivedere la maggior parte di questa domanda poiché molti dei miei test originali sono irrilevanti alla luce di nuove informazioni)

Ho problemi con i server DNS Server 2012R2. L'effetto collaterale più grande di questi problemi è che i messaggi di posta elettronica di Exchange non passano. Le query di scambio per i record AAAA prima di provare un record. Quando vede SERVFAIL per il record AAAA, non prova nemless i record A, ma solo rinuncia.

  • Strategia di hosting DNS ad alta disponibilità?
  • SPF registra chiarimenti sull'utilizzo di un meccanismo
  • Configurazione centrale per DHCP, DNS e Firewall
  • PHP ha lanciato errori del server dopo che Ubuntu ha eseguito una session di aggiornamenti automatici - qualunque modo per determinare la causa?
  • Qual è la differenza tra mx: e include: in record SPF?
  • Perché i nostri record DNS non si propagano in Internet?
  • Per alcuni domini, quando si interroga sui server DNS di directory attivi, ottengo SERVFAIL invece di NOERROR senza risultati.

    Ho provato questo da diversi controller di dominio Server 2012R2 che eseguono DNS. Uno di essi è un dominio completamente separato, su una networking diversa dietro un diverso firewall e una connessione a Internet.

    Due indirizzi che conosco causa questo problema sono smtpgw1.gov.on.ca e mxmta.owm.bell.net

    Ho usato dig su una macchina di linux per provare questo (192.168.5.5 è il mio controller di dominio):

     grant@linuxbox:~$ dig @192.168.5.5 smtpgw1.gov.on.ca -t AAAA ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.5.5 smtpgw1.gov.on.ca -t AAAA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56328 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;smtpgw1.gov.on.ca. IN AAAA ;; Query time: 90 msec ;; SERVER: 192.168.5.5#53(192.168.5.5) ;; WHEN: Wed Oct 21 14:09:10 EDT 2015 ;; MSG SIZE rcvd: 46 

    Ma le query contro un controllore di dominio pubblico funzionano come previsto:

     grant@home-ssh:~$ dig @4.2.2.1 smtpgw1.gov.on.ca -t AAAA ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @4.2.2.1 smtpgw1.gov.on.ca -t AAAA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 8192 ;; QUESTION SECTION: ;smtpgw1.gov.on.ca. IN AAAA ;; Query time: 136 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Wed Oct 21 14:11:19 EDT 2015 ;; MSG SIZE rcvd: 46 

    Come ho detto, ho provato questo su due diverse reti e domini. Uno è un dominio brandnew, che ha sicuramente tutte le impostazioni predefinite per il DNS. L'altra è stata migrata a Server 2012, quindi alcune impostazioni precedenti dal 2003/2008 possono essere riportte. Ottengo gli stessi risultati su entrambi.

    Distriggersre EDNS con dmscnd /config /enableednsprobes 0 corregge. Vedo molti risultati di ricerca circa EDNS che è un problema in Server 2003, ma non molto corrisponde a quello che vedo in Server 2012. Né il firewall ha un problema con EDNS. La distriggerszione di EDNS dovrebbe essere solo una soluzione temporanea però – impedisce l'utilizzo di DNSSEC e potrebbe causare altri problemi.

    Ho anche visto alcuni post su problemi con Server 2008R2 e EDNS, ma questi stessi messaggi dicono che le cose sono fisse in Server 2012, quindi dovrebbe funzionare correttamente.

    Ho anche cercato di abilitare il registro di debug per DNS. Posso vedere i pacchetti che mi aspettavo, ma non mi dà molta comprensione del motivo per cui sta tornando SERVFAIL. Ecco le parti rilevanti del registro di debug del server DNS:

    Primo pacchetto – query dal client al mio server DNS

     10/16/2015 9:42:29 AM 0974 PACKET 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) su (2) ca (0)
     Le informazioni sulla domanda UDP a 000000EFF1BF01A0
       Socket = 508
       Remote addr 172.16.0.254, port 50764
       Time Query = 4556080, In coda = 0, Scadenza = 0
       Lunghezza barra = 0x0fa0 (4000)
       Msg length = 0x002e (46)
       Messaggio:
         XID 0xa61e
         Bandiere 0x0120
           QR 0 (QUESTIONE)
           OPCODE 0 (QUERY)
           AA 0
           TC 0
           RD 1
           RA 0
           Z 0
           CD 0
           AD 1
           RCODE 0 (NOERROR)
         QCOUNT 1
         ACOUNT 0
         NSCOUNT 0
         ARCOUNT 1
         SEZIONE QUESTIONE:
         Offset = 0x000c, count RR = 0
         Nome "(7) smtpgw1 (3) gov (2) su (2) ca (0)"
           QTYPE AAAA (28)
           QCLASS 1
         SEZIONE RISPOSTA:
           vuoto
         SEZIONE AUTORITÀ:
           vuoto
         SEZIONE ADDIZIONALE:
         Offset = 0x0023, count RR = 0
         Nome "(0)"
           TIPO OPT (41)
           CLASSE 4096
           TTL 0
           DLEN 0
           DATI   
             Dimensione del buffer = 4096
             Rcode Ext = 0
             Rcode pieno = 0
             Versione = 0
             Bandiere = 0
    

    Secondo pacchetto – query dal mio server DNS al loro server DNS

     10/16/2015 9:42:29 AM 0974 PACKET 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) su (2) ca (0)
     Le informazioni sulla domanda UDP a 000000EFF0A22160
       Socket = 9812
       Remote addr 204.41.8.237, port 53
       Time Query = 0, In coda = 0, scadenza = 0
       Lunghezza barra = 0x0fa0 (4000)
       Msg length = 0x0023 (35)
       Messaggio:
         XID 0x3e6c
         Bandiere 0x0000
           QR 0 (QUESTIONE)
           OPCODE 0 (QUERY)
           AA 0
           TC 0
           RD 0
           RA 0
           Z 0
           CD 0
           AD 0
           RCODE 0 (NOERROR)
         QCOUNT 1
         ACOUNT 0
         NSCOUNT 0
         ARCOUNT 0
         SEZIONE QUESTIONE:
         Offset = 0x000c, count RR = 0
         Nome "(7) smtpgw1 (3) gov (2) su (2) ca (0)"
           QTYPE AAAA (28)
           QCLASS 1
         SEZIONE RISPOSTA:
           vuoto
         SEZIONE AUTORITÀ:
           vuoto
         SEZIONE ADDIZIONALE:
           vuoto
    

    Terza risposta a pacchetto dal loro server DNS (NOERROR)

     10/16/2015 9:42:29 AM 0974 PACKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ AAAA (7) smtpgw1 (3) gov (2) su (2) ca (0)
     Informazioni sulla risposta UDP a 000000EFF2188100
       Socket = 9812
       Remote addr 204.41.8.237, port 53
       Time Query = 4556080, In coda = 0, Scadenza = 0
       Lunghezza barra = 0x0fa0 (4000)
       Msg length = 0x0023 (35)
       Messaggio:
         XID 0x3e6c
         Bandiere 0x8400
           QR 1 (RESPONSE)
           OPCODE 0 (QUERY)
           AA 1
           TC 0
           RD 0
           RA 0
           Z 0
           CD 0
           AD 0
           RCODE 0 (NOERROR)
         QCOUNT 1
         ACOUNT 0
         NSCOUNT 0
         ARCOUNT 0
         SEZIONE QUESTIONE:
         Offset = 0x000c, count RR = 0
         Nome "(7) smtpgw1 (3) gov (2) su (2) ca (0)"
           QTYPE AAAA (28)
           QCLASS 1
         SEZIONE RISPOSTA:
           vuoto
         SEZIONE AUTORITÀ:
           vuoto
         SEZIONE ADDIZIONALE:
           vuoto
    

    Quattro pacchetti – risposta dal mio server DNS al client (SERVFAIL)

     10/16/2015 9:42:29 AM 0974 PACKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) su (2) ca (0)
     Informazioni sulla risposta UDP a 000000EFF1BF01A0
       Socket = 508
       Remote addr 172.16.0.254, port 50764
       Time Query = 4556080, in coda = 4556080, scadenza = 4556083
       Lunghezza barra = 0x0fa0 (4000)
       Msg length = 0x002e (46)
       Messaggio:
         XID 0xa61e
         Bandiere 0x8182
           QR 1 (RESPONSE)
           OPCODE 0 (QUERY)
           AA 0
           TC 0
           RD 1
           RA 1
           Z 0
           CD 0
           AD 0
           RCODE 2 (SERVFAIL)
         QCOUNT 1
         ACOUNT 0
         NSCOUNT 0
         ARCOUNT 1
         SEZIONE QUESTIONE:
         Offset = 0x000c, count RR = 0
         Nome "(7) smtpgw1 (3) gov (2) su (2) ca (0)"
           QTYPE AAAA (28)
           QCLASS 1
         SEZIONE RISPOSTA:
           vuoto
         SEZIONE AUTORITÀ:
           vuoto
         SEZIONE ADDIZIONALE:
         Offset = 0x0023, count RR = 0
         Nome "(0)"
           TIPO OPT (41)
           CLASSE 4000
           TTL 0
           DLEN 0
           DATI   
             Dimensione del buffer = 4000
             Rcode Ext = 0
             Rcode pieno = 2
             Versione = 0
             Bandiere = 0
    

    Altre cose da notare:

    • Una delle reti ha accesso a Internet IPv6 nativo, l'altro non (ma lo stack IPv6 è abilitato sui server con impostazioni predefinite). Non sembra essere un problema di networking IPv6
    • Non riguarda tutti i domini. Ad esempio dig @192.168.5.5 -t AAAA serverfault.com restituisce NOERROR e nessun risultato. La stessa cosa per google.com restituisce correttamente gli indirizzi IPv6 di google.
    • Provato a installare la correzione da KB3014171 , non ha fatto alcuna differenza.
    • L'aggiornamento da KB3004539 è già installato.

    Modifica il 7 novembre 2015

    Ho installato un'altra macchina non server di dominio collegata a Server 2012R2 e installato il ruolo del server DNS e testato con il command nslookup -type=aaaa smtpgw1.gov.on.ca localhost . NON ha le stesse problematiche.

    Entrambi i VM sono sullo stesso host e la stessa networking, in modo da eliminare eventuali problemi di networking / firewall. Ora è giù a livello di patch o essere un controller di dominio / dominio di dominio che fa la differenza.

    Modifica 8 Novembre 2015

    Applicato tutti gli aggiornamenti, non ha fatto differenza. È passato per verificare se esistevano differenze di configuration tra il mio nuovo server di prova e le impostazioni DNS del controller di dominio, e ci sono: il controller di dominio ha configurato gli invenditori.

    Ora, sono sicuro che ho provato con spedizionieri e senza nei miei primi test, ma ho provato solo utilizzando dig da una macchina Linux. Ottengo risultati leggermente diversi con e senza forwarder setup (provato con Google, OpenDNS, 4.2.2.1 e i miei server ISP DNS) quando utilizzo nslookup su una macchina Windows.

    Con un set di spedizioniere, ottengo Server failed .

    Senza un forwarder (quindi utilizza i server DNS radice), non No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca .

    Ma questo non è ancora lo stesso di quello che ottengo per altri domini che non dispongono di record IPv6 – nslookup sulle windows non restituisce alcun risultato per altri domini.

    Con o senza spedizionieri, dig visualizza ancora SERVFAIL per quel nome quando si interroga sul server DNS delle windows.

    C'è una piccola differenza tra il dominio del problema e altri che sembrano rilevanti, anche quando non coinvolgo il mio server DNS di windows:

    dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca non ha risposte e non ha alcuna sezione di autorità.

    dig -t aaaa @8.8.8.8 serverfault.com non restituisce alcuna risposte, ma ha una sezione di autorità. Quindi fa la maggior parte degli altri domini che cerco, non import quale resolver io utilizzo.

    Allora, perché la sezione dell'autorità manca e perché il server DNS di Windows lo tratti come un errore quando altri server DNS non lo fanno?

    2 Solutions collect form web for “Server server 2012R2 DNS che restituisce SERVFAIL per alcune query AAAA”

    Ho esaminato la networking per tacere di più e ho fatto qualche lettura. Il reqest per il record AAAA, quando inesistente, restituisce una SOA. Scopri che l'SOA è per un dominio diverso da quello richiesto. Sospetto che sia per questo che Windows rifiuta la risposta. Richiedere AAAA per mx.atomwide.com. Risposta SOA per lgfl.org.uk Vedrò se possiamo fare qualche progresso con queste informazioni. EDIT: solo per un futuro riferimento, temporaneamente spegnimento "Secure cache contro l'inquinamento" consentirà la query di avere successo. Non è ideale, ma dimostra che il problema è con un record DNS debole. RFC4074 è anche un buon riferimento – Intro e Sezione.

    Secondo KB832223

    Causa

    Questo problema si verifica a causa del meccanismo di estensione per la funzionalità DNS (EDNS0) supportto in Windows Server DNS.

    EDNS0 consente le size dei pacchetti UDP (User Datagram Protocol) più grandi. Tuttavia, alcuni programmi firewall potrebbero non consentire i pacchetti UDP più grandi di 512 byte. Pertanto, questi pacchetti DNS possono essere bloccati dal firewall.

    Microsoft ha la seguente risoluzione:

    Risoluzione

    Per risolvere questo problema, aggiornare il programma firewall per riconoscere e consentire pacchetti UDP che sono più grandi di 512 byte. Per ulteriori informazioni su come eseguire questa operazione, contattare il produttore del programma firewall.

    Microsoft ha il seguente suggerimento per aggirare il problema:

    Soluzione

    Per aggirare questo problema, distriggersre la funzionalità EDNS0 sui server DNS basati su Windows. A tale scopo, attenersi alla seguente procedura:

    Al prompt dei comandi digitare il seguente command e quindi premere Invio:

    dnscmd /config /enableednsprobes 0

    Nota Digitare 0 (zero) e non la lettera "O" dopo "enableednsprobes" in questo command.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.