Проблема BIND9 SERVFAIL с DNS-сервером Windows 2008 R2

Я просматривал странную проблему с BIND 9, когда один из моих экземпляров Windows 2008 R2 указывает на него как на сервер пересылки. В частности, при включении DNSSEC в BIND некоторые доменные имена не удается разрешить при определенных обстоятельствах. Эти проблемы решаются спонтанно при переключении на общедоступный DNS-сервер, например Google 8.8.8.8.

глядя на это дальше, он появляется, когда EDNS включен в Windows 2008 R2 DNS-сервер (по умолчанию, принимая ответы DNSSEC), разрешение иногда не удается с SERVFAIL, когда NODATA возвращается в BIND (т. е. 0 ответов с кодом состояния NOERROR.)

например, mx2.comcast.com тип SRV завершится ошибкой при поиске на DNS-сервере Windows 2008 R2, указанном для привязки в качестве сервера пересылки, но bat.comcast.com тип SRV работает просто отлично.

выполнение запроса локально с dig, я получаю следующие результаты:

mx2.comcast.com СРВ - местные привязки запрос

; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42484
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
mx2.comcast.com.        3600    IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
mx2.comcast.com.        3600    IN      NSEC    mx3.comcast.com. A RRSIG NSEC
comcast.com.            3600    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            3600    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=

тот же запрос, но сделанный с DNS-сервером Google:

; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3537
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1800    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1800    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
mx2.comcast.com.        3600    IN      NSEC    mx3.comcast.com. A RRSIG NSEC
mx2.comcast.com.        3600    IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=

при использовании Windows с сервером привязки в качестве сервера пересылки:

; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57054
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

и с DNS Google в качестве экспедитора:

; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56582
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

сейчас, пытаясь это с bat.comcast.com:

; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2383
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1603    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1603    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 1603 IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=
awrelaypool02.comcast.com. 1603 IN      NSEC    www.bat.comcast.com. A RRSIG NSEC

и распознаватель Google:

; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28253
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1800    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1800    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 3600 IN      NSEC    www.bat.comcast.com. A RRSIG NSEC
awrelaypool02.comcast.com. 3600 IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=

еще раз с Windows (bind Resolver):

; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11140
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

еще раз с Windows (Google Resolver):

; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

глядя на эти результаты, окон неудачи на mx2.comcast.com еще преуспевает в bat.comcast.com и с кодом ошибки, что Windows сообщает (SERVFAIL), может показаться изначально, что DNSSEC проверки не удается, хотя это было не так, поскольку все ответы на запросы были 'объявление' (проверка подлинности пройдена) бит на них. Тем не менее, BIND по-видимому, имеет интригующую тенденцию вмешиваться в порядок, в котором появляется раздел полномочий RRs. Глядя на запрос Google для mx2.comcast.com, мы можем видеть, что раздел authority появляется в этом порядке (это, как авторитетный сервер отвечает тоже):

  • SOA
  • RRSIG-SOA
  • NSEC
  • RRSIG-NSEC

в то время как BIND возвращает ответы в следующем порядке:

  • RRSIG - НС
  • NSEC
  • SOA
  • RRSIG-SOA

для bat.comcast.com, Google отвечает в следующем порядке:

  • SOA
  • RRSIG-SOA
  • NSEC
  • RRSIG-NSEC

и BIND отвечает в следующем порядке:

  • SOA
  • RRSIG-SOA
  • RRSIG-NSEC
  • NSEC

учитывая, что первые запрос не удался в Windows, но второй работает просто отлично, кажется очевидным, что Windows 2008 R2 требует, чтобы запись SOA появилась первой, когда нет ответов и кода возврата = NOERROR. (Обратите внимание, что если удаленный сервер возвратил NXDOMAIN, то порядок этих RRs, кажется, не имеет значения, и Windows возвратит NXDOMAIN соответственно назад клиенту).

глядя на документацию BIND и посмотреть, если есть какие-либо параметры конфигурации, которые контролируют порядок эти RRs, но безрезультатно. Вот что я попробовал:

    rfc2308-type1 yes;
    minimal-responses yes;
    rrset-order {order fixed;};

Я также попытался обновить локальную версию BIND до 9.9.3-P1 с 9.9.2-P1, но поведение, похоже, не изменилось.

наконец, я мог бы теоретически отключить поддержку EDNS в Windows 2008 R2 в качестве обходного пути и заставить эти запросы работать (так как отключение EDNS также подавит флаг DO для DNSSEC, тем самым опуская RRSIG и NSEC RRs в ответе), хотя я бы предпочел оставить EDNS включился для его эффективности по UDP.

кто-нибудь знает что-нибудь, что я здесь не хватает, или столкнулись с подобными ситуациями?

любые комментарии были бы весьма признательны!

20
задан user235909
09.12.2022 20:14 Количество просмотров материала 3578
Распечатать страницу

1 ответ

вы смогли подтвердить свое предположение, что именно порядок записей заставляет MSDNS возвращать SERVFAIL? (Это правдоподобно из того, что вы показываете в вопросе, но мне не ясно, что другие возможности были исключены.)

кроме того, есть ли что-нибудь зарегистрированное на стороне MSDNS, относящееся к сбою?

Я не знаю ни одного параметры привязки это было бы применимо к тому, как RRSIG/NSEC/SOA записи сортируются в этой ситуации.

из настроек, которые вы упомянули,rrset-order является единственным, который должен повлиять на порядок, но, насколько мне известно, он предназначен для сценария, как ответ с несколькими A записи и как они должны быть заказаны, а не это.

в любом случае значение fixed не поддерживается по умолчанию:

в этом выпуске BIND 9 оператор rrset-order по умолчанию не поддерживает "фиксированный" порядок. Фиксированный заказ может быть включено во время компиляции путем указания "--enable-fixed-rrset" в командной строке "configure".

мне кажется, что если заказ является то, что вызывает вашу проблему, либо MSDNS или BIND имеет ошибку.

очевидно, что BIND изменил порядок записей в своем ответе, но не очевидно (для меня в любом случае), почему это будет проблемой.

0
отвечен Håkan Lindqvist 2022-12-11 04:02

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Мы используем cookie. Это позволяет нам анализировать взаимодействие посетителей с сайтом и делать его лучше. Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Политика конфиденциальности
Согласен
Вверх