Если я правильно понимаю раздел 2.1 RFC1912 , эти правила применяются к записям PTR:

1) Каждый работающий IP должен иметь запись PTR

2) Должны совпадать записи PTR и A (хотя обычно это не проверяется)

Теперь, что если у меня есть рабочий IP (в моем случае, IPv6) и хочет , чтобы установить правильную запись PTR (что - то мой провайдер может сделать), но IP не имеет A или AAAA записи? Это просто клиент, подключенный к Интернету без собственного домена, а не сервер (но он не стоит за NAT, я говорю об IPv6 здесь)

У него есть рабочий IP, поэтому он должен иметь определенную запись PTR (1), но на что он должен указывать (2)?

3 ответа3

2

Вы написали в комментарии:

У меня нет ни записей A, ни AAAA - просто клиент полностью без имени хоста. Тем не менее, это все еще рабочий IP-адрес и должен иметь запись PTR в соответствии со стандартом.

Во-первых, обратите внимание, что RFC 1912, "Распространенные ошибки в работе и конфигурации DNS", носит информационный характер. Таким образом, он предоставляет информацию и руководство, но не пытается определить стандарт или систематизировать требования. Другие категории RFC предъявляют реальные требования к тому, как все делается; например, вы не можете написать сервер HTTP/1.1, а затем дать коду ответа 301 любое значение, отличное от указанного в разделе 10.3.2 RFC 2616 ; если вы это сделаете, вы не реализуете HTTP/1.1, а скорее что-то другое, возможно, по шаблону после него.

Поскольку RFC 1912 примерно на год старше, чем RFC 2119 ("Ключевые слова для использования в RFC для указания уровней требований"), мы не можем использовать последний, чтобы применять его конкретно к RFC 1912, но RFC 2119 все же может дать некоторую информацию о том, как интерпретировать такие термины, как "должен", "должен" и так далее. В частности, в RFC 2119 говорится, что мы должны толковать следующее:

ДОЛЖНО Это слово или термины "ОБЯЗАТЕЛЬНО" или "ДОЛЖНО" означают, что определение является абсолютным требованием спецификации.

СЛЕДУЕТ Это слово или прилагательное "РЕКОМЕНДУЕТСЯ" означают, что могут существовать веские причины в определенных обстоятельствах игнорировать конкретный элемент, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбрать другой курс.

RFC 1912, раздел 2.1, частично утверждает (мой акцент):

Каждый хост, доступный через Интернет, должен иметь имя. Последствия этого становятся все более очевидными. Многие службы, доступные в Интернете, не будут общаться с вами, если вы не правильно зарегистрированы в DNS.

Убедитесь, что ваши записи PTR и A совпадают. Для каждого IP-адреса должна быть соответствующая запись PTR в домене in-addr.arpa. Если хост является многодомным (более одного IP-адреса), убедитесь, что все IP-адреса имеют соответствующую запись PTR (а не только первую). Отсутствие соответствующих записей PTR и A может привести к потере интернет-услуг, аналогично тому, что они вообще не будут зарегистрированы в DNS. Кроме того, записи PTR должны указывать на действительную запись A, а не на псевдоним, определенный CNAME.

Во-первых, первое утверждение - "должен", что сразу подразумевает, что это не абсолютное требование. Это может быть требование в некоторых конкретных случаях, и именно поэтому оно упоминается, но это не требование в общем случае.

Я бы взял второй абзац, который начинается с "убедиться", чтобы установить более строгие требования к администратору. Обратите внимание, что в следующем предложении снова говорится « должен, а не должен», или любое его изменение.

Суть здесь в два раза:

  1. Если вам не нужно глобально уникальное имя хоста, которое сопоставляется с вашим IP-адресом, нет необходимости добавлять его в DNS. (Если это система только для клиентов, которая не предоставляет никаких сервисов и не имеет проблем с использованием желаемых сервисов, то вам, очевидно, в этом нет необходимости, по крайней мере, на данный момент.)
  2. Если в DNS нет имени хоста, которое сопоставляется с вашим IP-адресом, для записи PTR для вашего IP-адреса ничего не указывается, и, следовательно, вам не разрешено добавлять или добавлять запись PTR для вашего IP-адреса. (Это следует из требования, что запись PTR указывает на имя хоста с соответствующей записью адреса.)

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

0

RFC1912 устарел и информативен ... он никогда не переходил на Standard, поэтому его не нужно внедрять, поэтому никто не беспокоился об этом вообще. Вы обнаружите, что большинство все чаще игнорируют этот совет, за исключением почтовых серверов и защищенных FTP-серверов. Это также не распространяется на записи AAAA.

Итог, вам не нужно беспокоиться об этом.

0

Там нет строгих правил, по которым записи для создания. Может быть много записей A и / или AAAA, указывающих на один и тот же IP-адрес, или их не может быть. Для адреса может существовать обратная запись (PTR), а может и не быть. Ни в одном из этих случаев нет ничего действительного или недействительного, так как нет настоящих правил.

Однако есть определенные ожидания. Одним из них является то, что если вы запускаете почтовый сервер, то IP-адрес, который почтовый сервер использует для подключения к другим почтовым серверам, должен иметь запись PTR, которая указывает на имя хоста, которое, в свою очередь, имеет запись A или AAAA для этого IP-адреса.

Давайте посмотрим на пример:

  • Ваш почтовый сервер имеет адрес IPv4 192.0.2.1
  • Существует запись PTR для 1.2.0.192.in-addr.arpa указывающая на blabla.example.com
  • На Blabla.example.com есть запись A, указывающая на 192.0.2.1

Таким образом, запись PTR может использоваться для фильтрации на основе репутации на основе домена, поскольку владелец домена не создал бы правильную запись A в своей зоне, если имя было поддельным.

Из-за этой стратегии проверки будет меньше доверия, если ваша запись PTR не соответствует записи A или AAAA. Каждый может создать записи PTR, указывающие на something.important.google.com но только Google создаст соответствующую запись A/AAAA для этого имени, если она действительно существует. Отсутствие записи A/AAAA не доказывает, что адрес не от Google, но и не подтверждает это.

То же самое касается всех таких записей: это хорошая обычная практика для создания соответствующих записей A/AAAA и PTR, но это не является обязательным требованием. В основном это будут серверы, получающие почту с этого IP-адреса, которые будут обеспечивать соответствие записей.

RFC1912 - это информационный RFC, который описывает обычную практику, а не Интернет-стандарт. Ваша запись PTR технически может указывать куда угодно, но если вы укажете на доменное имя, которое не ваше, было бы плохо. Если вы действительно хотите иметь запись PTR и не хотите создавать совпадающую запись A/AAAA (не представляю, почему, но все в порядке), укажите ее на несуществующее имя в одном из ваших собственных доменов. Если у вас нет собственного домена, то вам, вероятно, следует спросить кого-то, кто имеет, можете ли вы указать на его домен.

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