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

Должен ли полномочный DNS-сервер для домена разрешать рекурсию, чтобы разрешить записи CNAME, указывающие на другие домены?

Итак, у меня есть домен, зарегистрированный в Dreamhost, который, по-видимому, не выполняет рекурсивный поиск, и приложение на Heroku. Приложения Heroku всегда настроены на использование записи CNAME для proxy.heroku.com.

Так:

Authoritative DNS:  ns1.dreamhost.com (for foo.com)

CNAME record:       app.foo.com -> proxy.heroku.com

Resolves to:        Set of A records for EC2 IPs

Некоторые люди, пытающиеся подключиться к приложению из-за DNS-сервера Windows Server 2003, сказали мне, что оно по-другому обрабатывает SERVFAIL и не может разрешить DNS. Я пытаюсь понять, действительно ли это проблема конфигурации на моей или их стороне, в частности, по заголовку:

Должен ли полномочный DNS-сервер для домена быть рекурсивным, чтобы записи CNAME указывали на другие домены?

Нет, вам не нужно включать рекурсию для авторитетных DNS-серверов. В зависимости от того, кого вы спрашиваете, хорошей практикой даже считается то, что (если возможно) ваш полномочный сервер не будет рекурсивным, поскольку это линия защиты от некоторых DoS-атак. (Документ Cisco Вот например)

Ниже приведен образец из моего домена (сервер работает с Bind 9 и не является рекурсивным).

; <<>> DiG 9.5.1-P3 <<>> mail.<snip> @<my authoritative master>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1216
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;mail.<snip>.       IN  A

;; ANSWER SECTION:
mail.<snip>.        86400   IN  CNAME   ghs.google.com.
ghs.google.com.     158151  IN  CNAME   ghs.l.google.com.
ghs.l.google.com.   33    IN  A       74.125.47.121

;; AUTHORITY SECTION:
google.com.     153556  IN  NS  ns4.google.com.
google.com.     153556  IN  NS  ns2.google.com.
google.com.     153556  IN  NS  ns3.google.com.
google.com.     153556  IN  NS  ns1.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.     169823  IN  A   216.239.32.10
ns2.google.com.     169823  IN  A   216.239.34.10
ns3.google.com.     169823  IN  A   216.239.36.10
ns4.google.com.     169823  IN  A   216.239.38.10

Это больше похоже на неправильную конфигурацию DNS в Windows 2003 DNS, чем на что-либо еще.

Авторитетные серверы должны НЕ быть настроенным для предложения рекурсивного обслуживания. Даже не для того, чтобы обойти потенциальную ошибку Microsoft.

Я не могу сейчас цитировать главы и стихи (если найду, то обновлю). Однако это в большой степени признанная «лучшая практика» для работы DNS-серверов.

Если какой-то преобразователь в вашей цепочке поиска возвращается SERVFAIL тогда это просто указывает на неправильную конфигурацию или на то, что вы задаете неправильный вопрос (или правильный вопрос с неправильными флагами).

В вашем случае dreamhost.com серверы возвращаются SERVFAIL если вы попросите рекурсивный ответ (что, оказывается, nslookup по умолчанию). У них есть на это полное право, они авторитетные серверы, а не рекурсивные.

В моей системе, если я использую dig вместо этого и специально отключите рекурсию, я получаю:

% dig +norecurse @ns1.dreamhost.com mail.scotchi.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec @ns1.dreamhost.com mail.scotchi.net.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54426
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13

;; QUESTION SECTION:
;mail.scotchi.net.  IN A

;; ANSWER SECTION:
mail.scotchi.net. 14400 IN CNAME ghs.google.com.

Dreamhost использует powerdns (тьфу), так же плохо ... но рекурсивные преобразователи Windows действительно отстой.

Возникает вопрос, почему ящики DNS Windows на ваших клиентских сайтах получают SERVFAIL? Их не должно быть.

И вышеупомянутый плакат правильный - если вы уполномочены на домен, вы можете иметь его cname, A, fail, вы его называете для любого домена / IP (вам не нужно знать, как связан другой домен ).

Возможно, дело в том, что преобразователи DNS, которые запросили вашу запись A (и получили имя cname), застряли, думая, что они также знают клей для heroku.com.

Вы можете проанализировать перечисленные серверы имен для исходного запроса, чтобы увидеть, что происходит, но в «худшем случае» вы могли бы просто обслуживать записи «A» ... это будет просто P-I-T-A.

Если вы хотите опубликовать реальный отказоустойчивый домен, это круто; вы также можете PM или AIM nerdNG: p (я люблю находить первопричину проблем с dns. Идите фиг)

Я искал "похожие" вопросы на свой Вот и, похоже, есть довольно много похожих моментов (например, DNS-серверы Windows2003 и ответ SERVFAIL)

Если у кого-нибудь есть ссылка на «потенциальную ошибку Microsoft» выше, не могли бы они опубликовать подробности.

Очень признателен.