Назад | Перейти на главную страницу

Windows DNS Server 2008 R2 ошибочно возвращает SERVFAIL

У меня есть контроллер домена Windows 2008 R2, который также является DNS-сервером. При разрешении определенных TLD он возвращает SERVFAIL:

$ dig bogus.              

; <<>> DiG 9.8.1 <<>> bogus.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bogus.             IN  A

Я получаю тот же результат для настоящего TLD, например com. при запросе DC, как показано выше. Сравните с сервером BIND, который работает должным образом:

$ dig bogus. @128.59.59.70

; <<>> DiG 9.8.1 <<>> bogus. @128.59.59.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;bogus.             IN  A

;; AUTHORITY SECTION:
.           10800   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2012012501 1800 900 604800 86400

;; Query time: 18 msec
;; SERVER: 128.59.59.70#53(128.59.59.70)
;; WHEN: Wed Jan 25 14:09:14 2012
;; MSG SIZE  rcvd: 98

Точно так же, когда я запрашиваю свой DNS-сервер Windows с dig . any, Я получаю SERVFAIL, но серверы BIND возвращают корневую зону, как и ожидалось.

Это похоже на проблему, описанную в http://support.microsoft.com/kb/968372 за исключением того, что я использую два пересылки (128.59.59.70 сверху, а также 128.59.62.10) и возвращаюсь к корневым подсказкам, поэтому предварительные условия для выявления проблемы не совпадают. Тем не менее, я также применил MaxCacheTTL исправление реестра, как описано, и перезапуск DNS и всего сервера, но проблема не устранена. Проблема возникает на всех контроллерах домена в этом домене и возникла с полгода назад, несмотря на то, что серверы получают автоматические обновления Windows.

РЕДАКТИРОВАТЬ

Вот журнал отладки. Клиент - 160.39.114.110, это моя рабочая станция.

1/25/2012 2:16:01 PM 0E08 PACKET  000000001EA6BFD0 UDP Rcv 160.39.114.110  2e94   Q [0001   D   NOERROR] A      (5)bogus(0)
UDP question info at 000000001EA6BFD0
  Socket = 508
  Remote addr 160.39.114.110, port 49710
  Time Query=1077016, Queued=0, Expire=0
  Buf length = 0x0fa0 (4000)
  Msg length = 0x0017 (23)
  Message:
    XID       0x2e94
    Flags     0x0100
      QR        0 (QUESTION)
      OPCODE    0 (QUERY)
      AA        0
      TC        0
      RD        1
      RA        0
      Z         0
      CD        0
      AD        0
      RCODE     0 (NOERROR)
    QCOUNT    1
    ACOUNT    0
    NSCOUNT   0
    ARCOUNT   0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name      "(5)bogus(0)"
      QTYPE   A (1)
      QCLASS  1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
      empty

1/25/2012 2:16:01 PM 0E08 PACKET  000000001EA6BFD0 UDP Snd 160.39.114.110  2e94 R Q [8281   DR SERVFAIL] A      (5)bogus(0)
UDP response info at 000000001EA6BFD0
  Socket = 508
  Remote addr 160.39.114.110, port 49710
  Time Query=1077016, Queued=0, Expire=0
  Buf length = 0x0fa0 (4000)
  Msg length = 0x0017 (23)
  Message:
    XID       0x2e94
    Flags     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   0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name      "(5)bogus(0)"
      QTYPE   A (1)
      QCLASS  1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
      empty

Были отмечены все опции в журнале отладки, кроме «фильтра по IP». Напротив, когда я запрашиваю, скажем, accounts.google.com, я вижу, что DNS-сервер выходит на свой сервер пересылки (например, 128.59.59.70). В этом случае я не видел пакетов, исходящих с моего DNS-сервера, хотя bogus. не было в кеше (журнал отладки уже был запущен, и я впервые запросил этот сервер для bogus. или любой TLD). Он просто вернул SERVFAIL, не обращаясь к любому другому DNS-серверу, как в статье Microsoft KB, указанной выше.

У нас была аналогичная проблема на DNS-серверах Microsoft без настроенных серверов пересылки. Похоже, это исправление связано: http://support.microsoft.com/kb/2508835 . Я бы не сказал, что использование пересылки сводит на нет применимость.