Требования к обратному DNS сбивают с толку! Люди часто говорят о все взломать, если обратного DNS нет, и это звучит пугающе. Даже в тех случаях, когда приложениям не требуется обратный DNS, RFC часто цитируются в поддержку обязательного создания записей PTR.
Некоторые из этих RFC включают:
RFC1912: Распространенные ошибки работы и конфигурации DNS
У каждого доступного через Интернет хоста должно быть имя. ... Убедитесь, что ваши записи PTR и A совпадают. Для каждого IP-адреса должна быть соответствующая запись PTR в домене in-addr.arpa. Если хост является многосетевым (более одного IP-адреса), убедитесь, что все IP-адреса имеют соответствующую запись PTR (а не только первую). Отсутствие совпадающих записей PTR и A может привести к потере интернет-сервисов, как и отсутствие регистрации в DNS вообще.
RFC1033: РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ ДЛЯ ДОМЕННЫХ АДМИНИСТРАТОРОВ
Добавление хоста.
To add a new host to your zone files: Edit the appropriate zone file for the domain the host is in. Add an entry for each address of the host. Optionally add CNAME, HINFO, WKS, and MX records. Add the reverse IN-ADDR entry for each host address in the appropriate zone files for each network the host in on.
Несмотря на все это, некоторые люди по-прежнему настаивают на том, что создание записей PTR не является требуется стандартами, регулирующими администрирование DNS. Каковы фактические требования?
Требуют ли стандарты, регулирующие работу DNS, чтобы все устройства имели соответствующую запись PTR? Нет.
Требуют ли стандарты для определенных протоколов PTR записи, которые согласуются с соответствующими A или AAAA записи? Да.
Есть ли у некоторых приложений, не регулируемых RFC, такие же требования? Да.
Может ли запись PTR указывать на CNAME? Да, но цель CNAME должна быть уникальным именем рассматриваемого устройства (а не другим CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )
Является ли обязательное создание записи PTR наилучшей практикой? Обычно так считают, но у этого есть свои проблемы.
Эти вопросы и ответы предназначены для того, чтобы помочь развеять распространенное недоразумение.
Трагически процитированный раздел RFC1796 применяется здесь:
К сожалению, широко распространено заблуждение, что публикация в виде RFC обеспечивает определенный уровень признания. Нет, по крайней мере, не больше, чем публикация в обычном журнале. Фактически, каждый RFC имеет статус по отношению к процессу стандартизации Интернета: Информационный, Экспериментальный или Трек стандартов (Предлагаемый стандарт, Проект стандарта, Стандарт Интернета) или Исторический.
RFC1912 носит информационный характер. RFC1033 не имеет четкой маркировки и имеет официальное обозначение НЕИЗВЕСТНО, а это значит, что он настолько старый, что это не должно считаться ссылкой ни на что. Они не определяют стандарты и не могут использоваться для официального дополнения стандарта. Их никогда не следует цитировать в контексте, подразумевающем, что они определяют стандарт.
Думайте о предложениях информационных RFC как о хороших советах и общепринятых передовых методах. Рекомендации обратного DNS имеют смысл с первого взгляда: следование этим рекомендациям снижает риск попадания в ситуации, когда приложение не работает, потому что обратный DNS был необходим и не планировался. Вы, конечно, не можете ожидать, что администратор DNS будет знать все приложения / протоколы, которые этого требуют, и, к сожалению, то же самое можно сказать и о владельцах служб, запрашивающих эти записи.
Тем не менее, за пределами очень хорошая автоматизация, обязательные политики создания записей PTR также создают загрязнение.
PTR записи не должны синхронизироваться с соответствующими A/AAAA записи по мере вывода устройств из эксплуатации, что приводит к ползучести ложных PTR данные с течением времени. Эти данные служат только для того, чтобы ввести в заблуждение тех, кто пытается считать эту информацию достоверной. Некоторые владельцы приложений стремятся к этому, когда ищут причину фантомной проблемы. Проблема будет только усугубляться по мере того, как принятие IPv6 становится все более обычным явлением, особенно для администраторов DNS, ответственных за IP-пространство размера оператора.Что хуже: отсутствие PTR-записи или неточная PTR-запись? Если протокол не работает из-за того, что его стандарт требует действительного DNS, оба плохие, и последний может быть хуже. В остальном у всех разные мнения по этому поводу. Ничего страшного: вы можете сами составлять политики и инструменты, которые лучше всего подходят вашей команде и компании. Просто убедитесь, что они масштабируются и дают стабильные результаты, и помните, что обратный DNS будет настолько точным, насколько это будет время и дисциплина, которые члены вашей команды потратят на это.
Тоже неправда. Люди часто путают грань между отсутствием записи PTR (NXDOMAIN) и сломанный обратный DNS.
Ответ NXDOMAIN вызовет проблему только в том случае, если вы общаетесь со службой, которая требует прямого подтвержденного обратного DNS (FCrDNS). Почтовые серверы, Kerberos, виртуальные IP-адреса сканирования Oracle и т. Д.
Неисправный обратный DNS - это когда вы не можете получить NXDOMAIN своевременный ответ. Многие приложения (самые известные sshd) будет блокироваться при обратном поиске DNS, если есть проблемы с получением ответа из вышестоящих источников своевременно, что вызывает задержки в приложении.