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

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

Например, SRV типа mx2.comcast.com не будет работать при поиске на DNS-сервере Windows 2008 R2, указывающем на BIND в качестве сервера пересылки, но тип SRV bat.comcast.com работает просто отлично.

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

mx2.comcast.com SRV - локальный запрос BIND

; <<>> 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 с сервером BIND в качестве сервера пересылки:

; <<>> 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

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

  • SOA
  • RRSIG - SOA
  • NSEC
  • RRSIG - НСЕК

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

  • RRSIG - НСЕК
  • NSEC
  • SOA
  • RRSIG - SOA

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

  • SOA
  • RRSIG - SOA
  • NSEC
  • RRSIG - НСЕК

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

  • SOA
  • RRSIG - SOA
  • RRSIG - НСЕК
  • NSEC

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

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

    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 и RR NSEC в ответе), хотя я бы предпочел оставьте EDNS включенным для его эффективности по UDP.

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

Любые комментарии будут с благодарностью!

|источник

1 ответ1

0

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

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

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

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

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

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

Мне кажется, что если причиной проблемы является порядок, в MSDNS или BIND есть ошибка.

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .