Server 2012R2 DNS server mengembalikan SERVFAIL untuk beberapa permintaan AAAA


17

(Menulis ulang sebagian besar pertanyaan ini karena banyak tes asli saya tidak relevan mengingat informasi baru)

Saya mengalami masalah dengan Server DNS Server 2012R2. Efek samping terbesar dari masalah ini adalah email Exchange tidak melalui. Tukar pertanyaan untuk catatan AAAA sebelum mencoba catatan A. Ketika ia melihat SERVFAIL untuk catatan AAAA, ia bahkan tidak mencoba catatan A, itu hanya menyerah.

Untuk beberapa domain, saat melakukan kueri terhadap server DNS direktori aktif saya, saya mendapatkan SERVFAIL alih-alih NOERROR tanpa hasil.

Saya telah mencoba ini dari beberapa pengontrol domain Server 2012R2 berbeda yang menjalankan DNS. Salah satunya adalah domain yang sepenuhnya terpisah, pada jaringan yang berbeda di belakang firewall dan koneksi internet yang berbeda.

Dua alamat yang saya tahu penyebab masalah ini adalah smtpgw1.gov.on.cadanmxmta.owm.bell.net

Saya telah menggunakan digpada mesin linux untuk menguji ini (192.168.5.5 adalah pengontrol domain saya):

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

Tetapi pertanyaan terhadap pekerjaan pengontrol domain publik seperti yang diharapkan:

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

Seperti yang saya katakan, saya sudah mencoba ini di dua jaringan dan domain yang berbeda. Salah satunya adalah domain baru, yang pasti memiliki semua pengaturan default untuk DNS. Yang lain telah dimigrasi ke Server 2012, sehingga beberapa pengaturan lama dari 2003/2008 mungkin telah terbawa. Saya mendapatkan hasil yang sama pada keduanya.

Menonaktifkan EDNS dengan dmscnd /config /enableednsprobes 0memperbaikinya. Saya melihat banyak hasil pencarian tentang EDNS menjadi masalah di Server 2003, tetapi tidak banyak yang cocok dengan apa yang saya lihat di Server 2012. Firewall tidak memiliki masalah dengan EDNS. Menonaktifkan EDNS seharusnya hanya solusi sementara - ini mencegah penggunaan DNSSEC, dan dapat menyebabkan masalah lain.

Saya juga telah melihat beberapa posting tentang masalah dengan Server 2008R2 dan EDNS, tetapi posting yang sama mengatakan hal-hal yang diperbaiki di Server 2012, jadi itu harus berfungsi dengan baik.

Saya juga telah mencoba mengaktifkan log debug untuk DNS. Saya dapat melihat paket-paket yang saya harapkan, tetapi itu tidak memberi saya banyak wawasan tentang mengapa ia mengembalikan SERVFAIL. Berikut adalah bagian yang relevan dari log debug server DNS:

Paket pertama - permintaan dari klien ke server DNS saya

10/16/2015 9:42:29 PAKET 0974 PAKET 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) pada (2) ca (0)
Info pertanyaan UDP di 000000EFF1BF01A0
  Soket = 508
  Addr jauh 172.16.0.254, port 50764
  Kueri Waktu = 4556080, Antri = 0, Kedaluwarsa = 0
  Panjang Buf = 0x0fa0 (4000)
  Panjang Msg = 0x002e (46)
  Pesan:
    XID 0xa61e
    Panji 0x0120
      QR 0 (PERTANYAAN)
      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
    BAGIAN PERTANYAAN:
    Offset = 0x000c, jumlah RR = 0
    Nama "(7) smtpgw1 (3) gov (2) pada (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    BAGIAN JAWABAN:
      kosong
    BAGIAN OTORITAS:
      kosong
    BAGIAN TAMBAHAN:
    Offset = 0x0023, jumlah RR = 0
    Nama "(0)"
      TIPE OPT (41)
      KELAS 4096
      TTL 0
      DLEN 0
      DATA   
        Ukuran Buffer = 4096
        Rcode Ext = 0
        Kode Penuh = 0
        Versi = 0
        Bendera = 0

Paket kedua - permintaan dari server DNS saya ke server DNS mereka

10/16/2015 9:42:29 0974 PAKET 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) pada (2) ca (0)
Info pertanyaan UDP di 000000EFF0A22160
  Soket = 9812
  Addr jarak jauh 204.41.8.237, port 53
  Kueri Waktu = 0, Diantri = 0, Kedaluwarsa = 0
  Panjang Buf = 0x0fa0 (4000)
  Panjang Msg = 0x0023 (35)
  Pesan:
    XID 0x3e6c
    Panji 0x0000
      QR 0 (PERTANYAAN)
      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
    BAGIAN PERTANYAAN:
    Offset = 0x000c, jumlah RR = 0
    Nama "(7) smtpgw1 (3) gov (2) pada (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    BAGIAN JAWABAN:
      kosong
    BAGIAN OTORITAS:
      kosong
    BAGIAN TAMBAHAN:
      kosong

Paket ketiga - respons dari server DNS mereka (NOERROR)

10/16/2015 9:42:29 0974 PAKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) pada (2) ca (0)
Info respons UDP di 000000EFF2188100
  Soket = 9812
  Addr jarak jauh 204.41.8.237, port 53
  Kueri Waktu = 4556080, Antri = 0, Kedaluwarsa = 0
  Panjang Buf = 0x0fa0 (4000)
  Panjang Msg = 0x0023 (35)
  Pesan:
    XID 0x3e6c
    Panji 0x8400
      QR 1 (TANGGAPAN)
      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
    BAGIAN PERTANYAAN:
    Offset = 0x000c, jumlah RR = 0
    Nama "(7) smtpgw1 (3) gov (2) pada (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    BAGIAN JAWABAN:
      kosong
    BAGIAN OTORITAS:
      kosong
    BAGIAN TAMBAHAN:
      kosong

Paket keempat - respons dari server DNS saya ke klien (SERVFAIL)

10/16/2015 9:42:29 0974 PAKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) pada (2) ca (0)
Info respons UDP di 000000EFF1BF01A0
  Soket = 508
  Addr jauh 172.16.0.254, port 50764
  Kueri Waktu = 4556080, Antri = 4556080, Kedaluwarsa = 4556083
  Panjang Buf = 0x0fa0 (4000)
  Panjang Msg = 0x002e (46)
  Pesan:
    XID 0xa61e
    Panji 0x8182
      QR 1 (TANGGAPAN)
      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
    BAGIAN PERTANYAAN:
    Offset = 0x000c, jumlah RR = 0
    Nama "(7) smtpgw1 (3) gov (2) pada (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    BAGIAN JAWABAN:
      kosong
    BAGIAN OTORITAS:
      kosong
    BAGIAN TAMBAHAN:
    Offset = 0x0023, jumlah RR = 0
    Nama "(0)"
      TIPE OPT (41)
      KELAS 4000
      TTL 0
      DLEN 0
      DATA   
        Ukuran Buffer = 4000
        Rcode Ext = 0
        Kode Penuh = 2
        Versi = 0
        Bendera = 0

Hal-hal lain yang perlu diperhatikan:

  • Salah satu jaringan memiliki akses internet IPv6 asli, yang lain tidak (tetapi tumpukan IPv6 diaktifkan di server dengan pengaturan default). Tampaknya tidak menjadi masalah jaringan IPv6
  • Itu tidak mempengaruhi semua domain. Misalnya dig @192.168.5.5 -t AAAA serverfault.commengembalikan NOERROR, dan tidak ada hasil. Hal yang sama untuk google.commengembalikan alamat IPv6 google dengan benar.
  • Mencoba menginstal perbaikan terbaru dari KB3014171 , tidak ada bedanya.
  • Pembaruan dari KB3004539 sudah diinstal.

Edit 7 Nov 2015

Saya telah menyiapkan non-domain lain yang bergabung dengan mesin Server 2012R2, dan menginstal peran server DNS, dan diuji dengan perintah nslookup -type=aaaa smtpgw1.gov.on.ca localhost. TIDAK memiliki masalah yang sama.

Kedua VM berada di host yang sama, dan jaringan yang sama, sehingga menghilangkan masalah jaringan / firewall. Sekarang turun ke tingkat tambalan atau menjadi anggota domain / pengontrol domain yang membuat perbedaan.

Edit 8 Nov 2015

Menerapkan semua pembaruan, tidak membuat perbedaan. Melalui untuk mengecek apakah ada perbedaan konfigurasi antara server pengujian baru saya dan pengaturan DNS pengontrol domain saya, dan ada - pengontrol domain memiliki pengaturan forwarder.

Sekarang, saya yakin saya sudah mencoba dengan forwarder dan tanpa di tes awal saya, tetapi saya hanya mencobanya menggunakan digmesin linux. Saya mendapatkan hasil yang sedikit berbeda dengan dan tanpa pengaturan forwarder (dicoba dengan Google, OpenDNS, 4.2.2.1, dan server DNS ISP saya) ketika saya menggunakan nslookup pada mesin windows.

Dengan set forwarder, saya mengerti Server failed.

Tanpa forwarder (jadi itu menggunakan root DNS server), saya dapatkan No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Tapi itu masih tidak sama dengan apa yang saya dapatkan untuk domain lain yang tidak memiliki catatan IPv6 - nslookup di windows hanya mengembalikan hasil untuk domain lain.

Dengan atau tanpa penerusan, digmasih menunjukkan SERVFAILnama itu ketika menanyakan server DNS windows saya.

ADA perbedaan kecil antara domain masalah dan yang lain yang tampaknya relevan, bahkan ketika saya tidak melibatkan server DNS windows saya:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca tidak memiliki jawaban, dan tidak memiliki bagian otoritas.

dig -t aaaa @8.8.8.8 serverfault.comtidak mengembalikan jawaban, tetapi memiliki bagian otoritas. Begitu juga sebagian besar domain lain yang saya coba, tidak peduli resolver apa yang saya gunakan.

Jadi mengapa bagian otoritas itu hilang, dan mengapa server DNS Windows memperlakukannya sebagai kegagalan ketika server DNS lain tidak?


Apakah Anda melakukan tes ini dari server Exchange? Jika tidak, saya sarankan melakukan itu agar Anda dapat melihatnya dari perspektif Exchange. Anda mungkin ingin mencoba menjalankan SMTPDiag dari server Exchange juga. Saya sarankan menjalankannya saat melakukan penangkapan jaringan di server Exchange sehingga Anda dapat melihat detail aktivitas jaringan / DNS. SMTPDiag adalah alat yang lama, tapi ini adalah alat baris perintah yang tidak memerlukan instalasi apa pun, jadi saya berpikir bahwa itu harus bekerja pada semua versi Exchange. - microsoft.com/en-us/download/details.aspx?id=11393
joeqwerty

Beberapa perangkat jaringan tidak mengenali dan akan menolak paket EDNS. Apakah tim jaringan Anda memperkenalkan perangkat / pengaturan baru baru-baru ini? Untuk menghilangkan kemungkinan ini, cobalah untuk menyelesaikan catatan AAAA google.com, itu harus mengembalikan alamat IPv6.
garis keras

Paket @strongline EDNS datang dengan baik. Rekaman AAAA untuk google berfungsi, seperti halnya beberapa situs lain yang saya tahu IPv6 sedang berjalan. Satu-satunya peluang yang dibuat baru-baru ini adalah menyingkirkan Server 2008R2 DC / DNS server terakhir kami dan menggantikannya dengan 2012R2.
Berikan

Apakah IPv6 dinonaktifkan di lingkungan Anda?
Jim B

@ JimB tidak benar-benar diaktifkan atau dinonaktifkan ... Tumpukan IPv6 berjalan di server, karena diaktifkan secara default, dengan konfigurasi default apa pun yang dimilikinya. Gateway dan koneksi internet tidak memiliki IPv6 sama sekali.
Berikan

Jawaban:


3

Saya telah melihat ke jaringan lagi dan melakukan beberapa bacaan. Reqest untuk catatan AAAA, ketika tidak ada, mengembalikan SOA. Ternyata SOA adalah untuk domain yang berbeda dengan yang diminta. Saya menduga itu sebabnya Windows menolak respons. Minta AAAA untuk mx.atomwide.com. Respons SOA untuk lgfl.org.uk. Saya akan melihat apakah kita dapat membuat beberapa kemajuan dengan informasi ini. EDIT: Hanya untuk referensi di masa mendatang, mematikan "Cache aman terhadap polusi" untuk sementara waktu akan memungkinkan kueri berhasil. Tidak ideal, tetapi membuktikan bahwa masalahnya ada pada catatan DNS yang cerdik. RFC4074 juga merupakan referensi yang bagus - Intro dan Bagian.


Saya akan mencoba menguji ini hari ini di lingkungan saya, tetapi saya pikir Anda mungkin tertarik pada sesuatu!
Grant

Juga saya telah mengedit tautan Anda - tanda tangan dan tautan keluar topik tidak diperbolehkan di sini, dan saya tidak ingin melihat jawaban Anda yang luar biasa terhapus karenanya.
Grant

0

Berdasarkan KB832223

Sebab

Masalah ini terjadi karena fungsionalitas Mekanisme Perpanjangan untuk DNS (EDNS0) yang didukung dalam Windows Server DNS.

EDNS0 memungkinkan ukuran paket User Datagram Protocol (UDP) yang lebih besar. Namun, beberapa program firewall mungkin tidak mengizinkan paket UDP yang lebih besar dari 512 byte. Oleh karena itu, paket DNS ini dapat diblokir oleh firewall.

Microsoft memiliki resolusi berikut:

Resolusi

Untuk mengatasi masalah ini, perbarui program firewall untuk mengenali dan mengizinkan paket UDP yang lebih besar dari 512 byte. Untuk informasi lebih lanjut tentang cara melakukan ini, hubungi produsen program firewall Anda.

Microsoft memiliki saran berikut untuk mengatasi masalah ini:

Penanganan masalah

Untuk mengatasi masalah ini, matikan fitur EDNS0 pada server DNS berbasis Windows. Untuk melakukan ini, lakukan tindakan berikut:

Pada prompt perintah, ketikkan perintah berikut, lalu tekan Enter:

dnscmd /config /enableednsprobes 0

Catatan Ketikkan 0 (nol) dan bukan huruf "O" setelah "enabledednsprobe" dalam perintah ini.


Saya telah melihat artikel ini - firewall yang telah saya uji dengan keduanya melewatkan paket dns besar tanpa masalah, sebagaimana dibuktikan dengan bekerja dengan baik di linux. Menonaktifkan edns mencegah penggunaan DNSSEC, jadi meskipun memperbaiki masalah, itu bukan solusi yang baik.
Berikan

maaf saya tidak menyadari bahwa bimbingan Microsoft akan berlaku untuk Linux juga. Karena penasaran, apakah Anda memiliki apa Microsoft OS yang bekerja melalui firewall?
Tim Penner
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.