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

Если записи вершины (или корня зоны) имеют соответствующую запись PTR / указателя

Я знаю, что записи вершины (записи в зоне «корень») могут иметь записи PTR, но часто я вижу, что записи корня зоны не имеют соответствующего PTR или указывают на другое место, чем связанная запись хоста.

Пример:

dig umich.edu @8.8.8.8; dig -x 141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
umich.edu.              709     IN      A       141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
251.243.211.141.in-addr.arpa. 1800 IN   PTR     www.umich.edu.

(truncated for brevity)

Причины не иметь PTR:

  1. Причина, по которой не следует добавлять PTR, заключается в том, что вы в любом случае не отвечаете за адресные зоны. Например. Я делаю рекордную ставку для поставщика облачных услуг, и Я не могу использовать CNAME, потому что это корень зоны.
  2. Еще одна причина, по которой я могу понять, заключается в том, что вы используете anycast для своих служб DNS и можете не получать тот же ответ (географический) от места к месту. Google.com, кажется, делает это.

Но есть ли причина, по которой следует «никогда» или «всегда» делать это помимо исключения, подобного приведенному выше? Я думаю, что по умолчанию всегда должен быть правильный PTR.

Я понимаю точку зрения Майкла, поскольку я думаю, что он имеет в виду домены в пространстве имен для обработки обратного сопоставления: in-addr.arpa и ip6.arpa. Тем не менее, я понимаю, к чему вы клоните.

Обратный поиск в DNS (rDNS) домена не обязательно должен совпадать с прямым поиском. У меня есть домен на виртуальном хостинге. Я получаю тот же IP-адрес в результате прямого просмотра моего доменного имени и www. Поиск RDNS этого IP-адреса возвращает общий сервер:

23.168.192.in-addr.arpa. 14400 IN PTR foo.bar.example.com.

Поскольку вы ищете передовой опыт, взгляните на IETF черновой вариант Соображения по использованию обратного сопоставления DNS. Стоит прочитать весь документ. Вот особенно важный момент:

Приложения не должны полагаться на обратное сопоставление для правильной работы, хотя функции, которые зависят от обратного сопоставления, очевидно, не будут
работать в его отсутствие. Напоминаем операторам и пользователям, что использование
обратного дерева, иногда в сочетании с поиском
имя, полученное из записи PTR, не обеспечивает реальной безопасности, может
приводит к ошибочным результатам и, как правило, просто увеличивает нагрузку на DNS
серверы. Кроме того, в случаях, когда держатели адресных блоков не могут
правильно настроить обратное отображение, пользователи этих блоков
оштрафован.

И это:

Рекомендуя приложениям, избегайте использования обратного сопоставления в качестве
механизм безопасности в этом документе указывается, что эта практика,
несмотря на его использование во многих приложениях, это неэффективная форма
безопасность. Приложения должны использовать более совершенные механизмы
аутентификация.

Надеюсь, это поможет.