(Переписывающий большую часть этого вопроса, так как много моих исходных тестов не важно в свете новой информации),
У меня есть проблемы с Сервером 2012R2 серверы DNS. Самый большой побочный эффект этих проблем, обмениваются электронными сообщениями, не проходящими. Exchange запрашивает для записей AAAA прежде, чем попробовать записи. Когда это видит SERVFAIL для записи AAAA, это даже не пробует записи, это просто сдается.
Для некоторых доменов, при запросах против моих активных серверов каталога DNS, я получаю SERVFAIL вместо NOERROR без результатов.
Я попробовал это с нескольких других Серверов 2012R2 контроллеры домена, которые выполняют DNS. Один из них является совершенно отдельным доменом в другой сети позади другого брандмауэра и интернет-соединения.
Два адреса, что я знаю причину эта проблема, smtpgw1.gov.on.ca
и mxmta.owm.bell.net
Я использовал dig
на машине Linux для тестирования этого (192.168.5.5 мой контроллер домена):
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
Но запросы против контроллера общественного достояния работают как ожидалось:
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
Как я сказал, я попробовал это в двух различных сетях и доменах. Каждый - совершенно новый домен, который определенно имеет все настройки по умолчанию для DNS. Другой был перемещен в Server 2012, таким образом, некоторые старые настройки от 2003/2008, возможно, перенесли. Я получаю те же результаты на них обоих.
Отключение EDNS с dmscnd /config /enableednsprobes 0
фиксирует его. Я вижу много результатов поиска о EDNS быть проблемой в Server 2003, но не очень, который соответствует тому, что я вижу в Сервере 2012. Никакой брандмауэр не имеет проблему с EDNS. EDNS отключения должен просто быть временным обходным решением, хотя - он предотвращает использование DNSSEC и мог бы вызвать другие проблемы.
Я также видел некоторые сообщения о проблемах с Сервером 2008R2 и EDNS, но в тех тех же сообщениях говорится, что вещи починены в Server 2012, таким образом, он должен работать правильно.
Я также попытался включить журнал отладки для DNS. Я вижу пакеты, которые я ожидал, но это не дает мне много понимания относительно того, почему это возвращает SERVFAIL. Вот соответствующие части журнала серверной отладки DNS:
Первый пакет - запрашивает от клиента к моему серверу 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) UDP question info at 000000EFF1BF01A0 Socket = 508 Remote addr 172.16.0.254, port 50764 Time Query=4556080, Queued=0, Expire=0 Buf length = 0x0fa0 (4000) Msg length = 0x002e (46) Message: XID 0xa61e Flags 0x0120 QR 0 (QUESTION) 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 QUESTION SECTION: Offset = 0x000c, RR count = 0 Name "(7)smtpgw1(3)gov(2)on(2)ca(0)" QTYPE AAAA (28) QCLASS 1 ANSWER SECTION: empty AUTHORITY SECTION: empty ADDITIONAL SECTION: Offset = 0x0023, RR count = 0 Name "(0)" TYPE OPT (41) CLASS 4096 TTL 0 DLEN 0 DATA Buffer Size = 4096 Rcode Ext = 0 Rcode Full = 0 Version = 0 Flags = 0
Второй пакет - запрашивает с моего сервера DNS на их сервер 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) UDP question info at 000000EFF0A22160 Socket = 9812 Remote addr 204.41.8.237, port 53 Time Query=0, Queued=0, Expire=0 Buf length = 0x0fa0 (4000) Msg length = 0x0023 (35) Message: XID 0x3e6c Flags 0x0000 QR 0 (QUESTION) 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 QUESTION SECTION: Offset = 0x000c, RR count = 0 Name "(7)smtpgw1(3)gov(2)on(2)ca(0)" QTYPE AAAA (28) QCLASS 1 ANSWER SECTION: empty AUTHORITY SECTION: empty ADDITIONAL SECTION: empty
Третий пакет - ответ с их сервера DNS (NOERROR)
10/16/2015 9:42:29 AM 0974 PACKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c R Q [0084 A NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0) UDP response info at 000000EFF2188100 Socket = 9812 Remote addr 204.41.8.237, port 53 Time Query=4556080, Queued=0, Expire=0 Buf length = 0x0fa0 (4000) Msg length = 0x0023 (35) Message: XID 0x3e6c Flags 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 QUESTION SECTION: Offset = 0x000c, RR count = 0 Name "(7)smtpgw1(3)gov(2)on(2)ca(0)" QTYPE AAAA (28) QCLASS 1 ANSWER SECTION: empty AUTHORITY SECTION: empty ADDITIONAL SECTION: empty
Четвертый пакет - ответ от моего сервера DNS до клиента (SERVFAIL)
10/16/2015 9:42:29 AM 0974 PACKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e R Q [8281 DR SERVFAIL] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0) UDP response info at 000000EFF1BF01A0 Socket = 508 Remote addr 172.16.0.254, port 50764 Time Query=4556080, Queued=4556080, Expire=4556083 Buf length = 0x0fa0 (4000) Msg length = 0x002e (46) Message: XID 0xa61e 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 1 QUESTION SECTION: Offset = 0x000c, RR count = 0 Name "(7)smtpgw1(3)gov(2)on(2)ca(0)" QTYPE AAAA (28) QCLASS 1 ANSWER SECTION: empty AUTHORITY SECTION: empty ADDITIONAL SECTION: Offset = 0x0023, RR count = 0 Name "(0)" TYPE OPT (41) CLASS 4000 TTL 0 DLEN 0 DATA Buffer Size = 4000 Rcode Ext = 0 Rcode Full = 2 Version = 0 Flags = 0
Другие знаменитые вещи:
dig @192.168.5.5 -t AAAA serverfault.com
возвраты NOERROR и никакие результаты. То же самое для google.com
Google возвратов IPv6 обращается правильно.Я имею, устанавливают другой недомен, присоединился к Серверу 2012R2 машина, и установил роль сервера DNS и протестировал с командой nslookup -type=aaaa smtpgw1.gov.on.ca localhost
. Это НЕ имеет тех же проблем.
И VMs находятся на том же хосте и той же сети, так, чтобы устранил любые проблемы сети/брандмауэра. Теперь или до уровня установки патча или до быть доменным участником/контроллером домена имеет значение.
Примененный все обновления, имевшие никакое значение. Пошел до двойной проверки, если были какие-либо различия в конфигурации между моим новым тестовым сервером и настройками DNS моего контроллера домена, и существует - контроллер домена имел установку средств передачи.
Теперь, я уверен, что попробовал средствами передачи и без в моих начальных тестах, но я только попробовал его использование dig
от машины Linux. Я действительно получаю немного отличающиеся результаты с и без установки средств передачи (попробованный Google, OpenDNS, 4.2.2.1, и моими серверами DNS ISP), когда я использую nslookup на машине окон.
С набором средства передачи я добираюсь Server failed
.
Без средства передачи (таким образом, это использует корневые серверы DNS), я добираюсь No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca
.
Но это все еще не то же как, что я получаю для других доменов, которые не имеют записей IPv6 - nslookup на окнах, просто не возвращает результатов для других доменов.
С или без средств передачи, dig
все еще шоу SERVFAIL
для того имени при запросах моего сервера окон DNS.
СУЩЕСТВУЕТ небольшая разница между проблемной областью и другими, который кажется релевантным, даже когда я не включаю свой сервер окон DNS:
dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca
не имеет никаких ответов и не имеет раздела полномочий.
dig -t aaaa @8.8.8.8 serverfault.com
не дает ответов, но действительно имеет раздел полномочий. Также - большинство других доменов, которые я пробую, какой сопоставитель я использую.
Итак, почему тот раздел полномочий отсутствует, и почему сервер Windows DNS рассматривает его как отказ, когда другие серверы DNS не делают?
Согласно KB832223
Причина
Эта проблема возникает из-за функциональных возможностей механизмов расширения для DNS (EDNS0), которые поддерживаются в Windows Server DNS.
EDNS0 допускает больший размер пакетов протокола дейтаграмм пользователя (UDP). Однако некоторые программы брандмауэра могут не разрешать пакеты UDP, размер которых превышает 512 байт. Следовательно, эти DNS-пакеты могут быть заблокированы брандмауэром.
Microsoft предлагает следующее решение:
Решение
Чтобы решить эту проблему, обновите программу брандмауэра, чтобы она распознавала и разрешала UDP-пакеты размером более 512 байт. Для получения дополнительных сведений о том, как это сделать, обратитесь к производителю вашего брандмауэра.
Microsoft предлагает следующее решение проблемы:
Временное решение
Чтобы обойти эту проблему, отключите функцию EDNS0 на DNS-серверах Windows. Для этого выполните следующие действия:
В командной строке введите следующую команду и нажмите Enter:
dnscmd / config / enableednsprobes 0
Примечание. Введите 0 (ноль), а не букву «O» после «enableednsprobes» в этой команде.
Я еще немного изучил сетевой интерфейс и кое-что прочитал. Запрос на запись AAAA, если она не существует, возвращает SOA. Оказывается, SOA предназначена для другого домена, который запрашивается. Я подозреваю, что именно поэтому Windows отклоняет ответ. Запросите AAAA для mx.atomwide.com. Ответ SOA для lgfl.org.uk. Я посмотрю, сможем ли мы добиться прогресса с этой информацией. РЕДАКТИРОВАТЬ: Для справки в будущем, временное отключение «Защищенного кеша от загрязнения» позволит выполнить запрос. Не идеально, но доказывает, что проблема в хитрой DNS-записи. RFC4074 также является хорошей справочной информацией - Введение и Раздел