Требуют ли интернет-стандарты обратного DNS для каждого устройства?

Требования, связанные с обратным 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 не имеет четкой маркировки и имеет официальное обозначение UNKNOWN , что означает, что он настолько старый, что его не следует рассматривать ни для чего . Они не определяют Стандарты и не могут использоваться для официального дополнения стандарта. Они никогда не должны цитироваться в контексте, который подразумевает, что они определяют стандарт.

Думайте об информационных предложениях RFC как о хорошем совете и общепринятой передовой практике. Обратные рекомендации DNS имеют смысл с первого взгляда: следуя этим рекомендациям, вы снизите риск оказаться в ситуациях, когда приложение не работает, поскольку обратный DNS был необходим и не планировался. Вы, конечно, не можете ожидать, что администратор DNS будет знать каждое приложение / протокол, который требует его, и, к сожалению, то же самое имеет место для владельцев служб, запрашивающих эти записи.

Тем не менее, помимо очень хорошей автоматизации , обязательные политики создания записей PTR также создают загрязнение.

• Очень часто PTRзаписи не синхронизируются с соответствующими записями A/ AAAAзаписями, поскольку устройства выводятся из эксплуатации, что PTRсо временем приводит к ползучести поддельных данных. Эти данные служат только для того, чтобы ввести в заблуждение тех, кто пытается рассматривать эту информацию как достоверную. Некоторые владельцы приложений стремятся запрыгнуть на него, когда ищут причину фантомной проблемы. Проблема будет только усугубляться, так как внедрение IPv6 становится все более распространенным явлением, особенно для администраторов DNS, отвечающих за размер IP-пространства несущей.
• Наличие нескольких записей PTR для одного и того же IP-адреса довольно бесполезно, и следование рекомендациям информационных RFC неизбежно приведет к этому. См .: Почему не рекомендуется использовать несколько записей PTR в DNS?

Что хуже: отсутствие записи PTR или неточной записи PTR? Если протокол нарушается из-за того, что его стандарт требует допустимого DNS, оба являются плохими, а последний может быть и хуже . Помимо этого, у каждого свое мнение по этому вопросу. Это нормально: вы можете собрать политики и инструменты, которые лучше всего подходят для вашей команды и компании. Просто убедитесь, что они масштабируются и дают последовательные результаты, и помните, что обратный DNS будет точен только так, как это нужно времени и дисциплине членов вашей команды.

Но пропущенные записи PTR приводят к зависанию sshd!

Тоже не правда. Люди часто путают границу между отсутствием записи PTR (NXDOMAIN) и неработающей обратной DNS.

Ответ на NXDOMAINвызов вызовет проблему только в том случае, если вы обмениваетесь информацией со службой, для которой требуется прямой подтвержденный обратный DNS (FCrDNS). Почтовые серверы, Kerberos, Oracle, сканирование VIP, и т. Д.

Сломанный обратный DNS - это когда вы не можете NXDOMAINсвоевременно получить ответ. Многие приложения (наиболее известные sshd) будут блокировать обратный поиск DNS, если возникнут проблемы со своевременным получением ответа от вышестоящих источников, что приведет к задержкам в приложении.