Serwer 2012R2 Serwer DNS zwraca SERVFAIL dla niektórych zapytań AAAA


17

(Przepisanie większości tego pytania, ponieważ wiele moich oryginalnych testów nie ma znaczenia w świetle nowych informacji)

Mam problemy z serwerami DNS Server 2012R2. Największy efekt uboczny tych problemów polega na tym, że wiadomości e-mail Exchange nie przechodzą. Wymieniaj zapytania dotyczące rekordów AAAA przed wypróbowaniem rekordów A. Kiedy widzi SERVFAIL dla rekordu AAAA, nawet nie próbuje rekordów A, po prostu się poddaje.

W przypadku niektórych domen podczas wysyłania zapytań do moich serwerów DNS usługi Active Directory otrzymuję SERVFAIL zamiast NOERROR bez żadnych wyników.

Próbowałem tego na kilku różnych kontrolerach domeny Server 2012R2 z systemem DNS. Jedna z nich to zupełnie odrębna domena, w innej sieci za inną zaporą ogniową i połączeniem internetowym.

Dwa adresy, które znam, powodują ten problem to smtpgw1.gov.on.caimxmta.owm.bell.net

Używam digna komputerze z systemem Linux, aby przetestować ten (192.168.5.5 jest mój kontroler domeny):

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

Ale zapytania dotyczące publicznego kontrolera domeny działają zgodnie z oczekiwaniami:

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

Jak powiedziałem, wypróbowałem to w dwóch różnych sieciach i domenach. Jedna to zupełnie nowa domena, która zdecydowanie ma wszystkie domyślne ustawienia dla DNS. Drugi został przeniesiony do Server 2012, więc niektóre stare ustawienia z 2003/2008 mogły zostać przeniesione. Otrzymuję takie same wyniki na obu z nich.

Wyłączenie EDNS z dmscnd /config /enableednsprobes 0naprawia to. Widzę wiele wyników wyszukiwania dotyczących EDNS stanowiących problem w Server 2003, ale niewiele, które pasują do tego, co widzę w Server 2012. Żadna zapora nie ma problemu z EDNS. Wyłączenie EDNS powinno być jednak tylko tymczasowym obejściem - uniemożliwia korzystanie z DNSSEC i może powodować inne problemy.

Widziałem także kilka postów na temat problemów z Server 2008R2 i EDNS, ale te same posty mówią, że wszystko zostało naprawione w Server 2012, więc powinno działać poprawnie.

Próbowałem również włączyć dziennik debugowania dla DNS. Widzę pakiety, których się spodziewałem, ale nie daje mi to wglądu, dlaczego zwraca SERVFAIL. Oto odpowiednie części dziennika debugowania serwera DNS:

Pierwszy pakiet - zapytanie od klienta do mojego serwera 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) on (2) ca (0)
Informacje o pytaniu UDP o 000000EFF1BF01A0
  Gniazdo = 508
  Adres zdalny 172.16.0.254, port 50764
  Zapytanie o czas = 4556080, w kolejce = 0, wygasa = 0
  Długość bufora = 0x0fa0 (4000)
  Długość ms = 0x002e (46)
  Wiadomość:
    XID 0xa61e
    Flagi 0x0120
      QR 0 (PYTANIE)
      OPCODE 0 (QUERY)
      AA 0
      TC 0
      RD 1
      RA 0
      Z 0
      CD 0
      AD 1
      RCODE 0 (NOERROR)
    QCOUNT 1
    KONTO 0
    NSCOUNT 0
    KONTO 1
    SEKCJA PYTANIA:
    Przesunięcie = 0x000c, liczba RR = 0
    Nazwa "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      KLASA 1
    SEKCJA ODPOWIEDZI:
      pusty
    SEKCJA ORGANU:
      pusty
    SEKCJA DODATKOWA:
    Przesunięcie = 0x0023, liczba RR = 0
    Nazwa „(0)”
      TYP OPCJI (41)
      KLASA 4096
      TTL 0
      DLEN 0
      DANE   
        Rozmiar bufora = 4096
        Rcode Ext = 0
        Rcode Full = 0
        Wersja = 0
        Flagi = 0

Drugi pakiet - zapytanie z mojego serwera DNS do ich serwera 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) on (2) ca (0)
Informacje o pytaniu UDP pod 000000EFF0A22160
  Gniazdo = 9812
  Adres zdalny 204.41.8.237, port 53
  Zapytanie o czas = 0, w kolejce = 0, wygasa = 0
  Długość bufora = 0x0fa0 (4000)
  Długość ms = 0x0023 (35)
  Wiadomość:
    XID 0x3e6c
    Flagi 0x0000
      QR 0 (PYTANIE)
      OPCODE 0 (QUERY)
      AA 0
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      RCODE 0 (NOERROR)
    QCOUNT 1
    KONTO 0
    NSCOUNT 0
    KONTO 0
    SEKCJA PYTANIA:
    Przesunięcie = 0x000c, liczba RR = 0
    Nazwa "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      KLASA 1
    SEKCJA ODPOWIEDZI:
      pusty
    SEKCJA ORGANU:
      pusty
    SEKCJA DODATKOWA:
      pusty

Trzeci pakiet - odpowiedź z ich serwera DNS (NOERROR)

10/16/2015 9:42:29 AM 0974 PACKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) on (2) ca (0)
Informacje o odpowiedzi UDP na 000000EFF2188100
  Gniazdo = 9812
  Adres zdalny 204.41.8.237, port 53
  Zapytanie o czas = 4556080, w kolejce = 0, wygasa = 0
  Długość bufora = 0x0fa0 (4000)
  Długość ms = 0x0023 (35)
  Wiadomość:
    XID 0x3e6c
    Flagi 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
    KONTO 0
    NSCOUNT 0
    KONTO 0
    SEKCJA PYTANIA:
    Przesunięcie = 0x000c, liczba RR = 0
    Nazwa "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      KLASA 1
    SEKCJA ODPOWIEDZI:
      pusty
    SEKCJA ORGANU:
      pusty
    SEKCJA DODATKOWA:
      pusty

Czwarty pakiet - odpowiedź z mojego serwera DNS do klienta (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) on (2) ca (0)
Informacje o odpowiedzi UDP pod adresem 000000EFF1BF01A0
  Gniazdo = 508
  Adres zdalny 172.16.0.254, port 50764
  Zapytanie o czas = 4556080, w kolejce = 4556080, wygasa = 4556083
  Długość bufora = 0x0fa0 (4000)
  Długość ms = 0x002e (46)
  Wiadomość:
    XID 0xa61e
    Flagi 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
    KONTO 0
    NSCOUNT 0
    KONTO 1
    SEKCJA PYTANIA:
    Przesunięcie = 0x000c, liczba RR = 0
    Nazwa "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      KLASA 1
    SEKCJA ODPOWIEDZI:
      pusty
    SEKCJA ORGANU:
      pusty
    SEKCJA DODATKOWA:
    Przesunięcie = 0x0023, liczba RR = 0
    Nazwa „(0)”
      TYP OPCJI (41)
      KLASA 4000
      TTL 0
      DLEN 0
      DANE   
        Rozmiar bufora = 4000
        Rcode Ext = 0
        Rcode Full = 2
        Wersja = 0
        Flagi = 0

Inne ważne uwagi:

  • Jedna z sieci ma natywny dostęp do Internetu IPv6, druga nie (ale stos IPv6 jest włączony na serwerach z ustawieniami domyślnymi). Wydaje się, że nie jest to problem z siecią IPv6
  • Nie wpływa na wszystkie domeny. Na przykład dig @192.168.5.5 -t AAAA serverfault.comzwraca NOERROR i brak wyników. To samo google.comdotyczy poprawnego zwracania adresów IPv6 Google'a.
  • Próbowałem zainstalować poprawkę z KB3014171 , ale nie zrobiło to różnicy.
  • Aktualizacja z KB3004539 jest już zainstalowana.

Edytuj 7 listopada 2015 r

Skonfigurowałem inną maszynę inną niż domena, która dołączyła do serwera 2012R2, zainstalowałem rolę serwera DNS i przetestowałem za pomocą polecenia nslookup -type=aaaa smtpgw1.gov.on.ca localhost. NIE ma takich samych problemów.

Obie maszyny wirtualne znajdują się na tym samym hoście i tej samej sieci, co eliminuje wszelkie problemy z siecią / zaporą. Teraz jest to albo poziom łatki, albo bycie członkiem domeny / kontrolerem domeny, co robi różnicę.

Edytuj 8 listopada 2015 r

Zastosowałem wszystkie aktualizacje, bez różnicy. Przeszedłem do podwójnego sprawdzenia, czy są jakieś różnice w konfiguracji między moim nowym serwerem testowym a ustawieniami DNS mojego kontrolera domeny, i są - kontroler domeny miał skonfigurowane usługi przesyłania dalej.

Teraz jestem pewien, że próbowałem z forwarderami i bez w moich początkowych testach, ale próbowałem tylko przy użyciu digLinuxa. Otrzymuję nieco inne wyniki z konfiguracją usług przesyłania dalej i bez niej (wypróbowałem z Google, OpenDNS, 4.2.2.1 i moimi serwerami DNS ISP), gdy używam nslookup na komputerze z systemem Windows.

Z zestawem forwardera dostaję Server failed.

Bez usługi przesyłania dalej (więc korzysta z głównych serwerów DNS) No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Ale to wciąż nie to samo, co otrzymuję dla innych domen, które nie mają rekordów IPv6 - nslookup w systemie Windows po prostu nie zwraca wyników dla innych domen.

Z digprogramami SERVFAILdo przesyłania dalej lub bez nich, nadal wyświetla się dla tej nazwy podczas zapytania do serwera DNS systemu Windows.

Istnieje niewielka różnica między domeną problemową a innymi, która wydaje się istotna, nawet gdy nie używam serwera DNS systemu Windows:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca nie ma odpowiedzi i nie ma sekcji autorytetu.

dig -t aaaa @8.8.8.8 serverfault.comnie zwraca odpowiedzi, ale ma sekcję uprawnień. Podobnie jak większość innych domen, których próbuję, bez względu na to, z którego resolwera korzystam.

Dlaczego więc brakuje tej sekcji uprawnień i dlaczego serwer DNS systemu Windows traktuje ją jako awarię, gdy inne serwery DNS tego nie robią?


Czy wykonujesz te testy z serwera Exchange? Jeśli nie, sugeruję zrobienie tego, abyś mógł to zobaczyć z perspektywy Exchange. Możesz także spróbować uruchomić SMTPDiag z serwera Exchange. Sugeruję uruchomienie go podczas przechwytywania sieci na serwerze Exchange, abyś mógł zobaczyć szczegóły działania sieci / DNS. SMTPDiag to stare narzędzie, ale jest to narzędzie wiersza polecenia, które nie wymaga żadnej instalacji, więc myślę, że powinno działać na wszystkich wersjach Exchange. - microsoft.com/en-us/download/details.aspx?id=11393
joeqwerty

Niektóre urządzenia sieciowe nie rozpoznają i odrzucają pakiety EDNS. Czy Twój zespół sieci wprowadził ostatnio nowe urządzenie / ustawienie? Aby wyeliminować tę możliwość, spróbuj rozwiązać problem rekordu AAAA google.com, powinien on zwrócić adres IPv6.
strongline,

@strongline Pakiety EDNS przechodzą dobrze. Rekord AAAA dla Google działa, podobnie jak kilka innych stron, które znam, że mają uruchomioną IPv6. Jedyną szansą, jaką ostatnio poczyniłem, było pozbycie się naszego ostatniego serwera DC / DNS Server 2008R2 i zastąpienie go 2012R2.
Grant

Czy protokół IPv6 jest w jakikolwiek sposób wyłączony w twoim środowisku?
Jim B

@ JimB tak naprawdę nie jest włączony ani wyłączony ... Stos IPv6 działa na serwerach, ponieważ jest domyślnie włączony, niezależnie od domyślnej konfiguracji. Brama i połączenie internetowe nie mają żadnego IPv6.
Grant

Odpowiedzi:


3

Zajrzałem trochę do sieci i przeczytałem trochę. Żądanie rekordu AAAA, jeśli nie istnieje, zwraca SOA. Okazuje się, że SOA dotyczy innej domeny, która jest żądana. Podejrzewam, że właśnie dlatego Windows odrzuca odpowiedź. Poproś o AAAA dla mx.atomwide.com. Odpowiedź SOA dla lgfl.org.uk. Zobaczę, czy możemy poczynić pewne postępy dzięki tym informacjom. EDYCJA: Tylko na przyszłość, tymczasowe wyłączenie „Bezpiecznej pamięci podręcznej przed zanieczyszczeniem” pozwoli na powodzenie zapytania. Nie jest to idealne, ale dowodzi, że problem jest z podejrzanym rekordem DNS. RFC4074 to także dobre referencje - wprowadzenie i sekcja.


Spróbuję dzisiaj przetestować to w moim środowisku, ale myślę, że możesz być na czymś!
Grant

Zredagowałem również twój link - podpisy i linki do innych tematów nie są tutaj dozwolone i nie chcę, aby Twoja skądinąd doskonała odpowiedź została usunięta.
Grant

0

Zgodnie z KB832223

Przyczyna

Ten problem występuje z powodu funkcji Mechanizmy rozszerzeń dla DNS (EDNS0) obsługiwanej przez DNS systemu Windows Server.

EDNS0 pozwala na większe rozmiary pakietów UDP (User Datagram Protocol). Jednak niektóre programy zapory mogą nie zezwalać na pakiety UDP większe niż 512 bajtów. Dlatego te pakiety DNS mogą być blokowane przez zaporę.

Microsoft ma następującą rozdzielczość:

Rozkład

Aby rozwiązać ten problem, zaktualizuj program zapory, aby rozpoznawał i zezwalał na pakiety UDP większe niż 512 bajtów. Aby uzyskać więcej informacji o tym, jak to zrobić, skontaktuj się z producentem programu zapory.

Microsoft ma następującą propozycję obejścia tego problemu:

Obejście

Aby obejść ten problem, wyłącz funkcję EDNS0 na serwerach DNS z systemem Windows. Aby to zrobić, wykonaj następujące czynności:

W wierszu polecenia wpisz następujące polecenie, a następnie naciśnij klawisz Enter:

dnscmd /config /enableednsprobes 0

Uwaga W tym poleceniu wpisz 0 (zero), a nie literę „O” po „enableednsprobes”.


Widziałem ten artykuł - zapory ogniowe, które przetestowałem z obu pakietów bez problemu przekazują duże dns, o czym świadczy doskonale działające na Linuksie. Wyłączenie edns uniemożliwia korzystanie z DNSSEC, więc chociaż rozwiązuje problem, nie jest dobrym rozwiązaniem.
Grant

przepraszam, nie zdawałem sobie sprawy, że wskazówki Microsoftu dotyczą także Linuksa. Z ciekawości, masz żadnego Microsoft OS, który działa przez zaporę?
Tim Penner
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.