RFC 1912, раздел 2.1 заявляет следующее:
Убедитесь, что ваши записи PTR и A совпадают. Для каждого IP-адреса должна быть соответствующая запись PTR в домене in-addr.arpa. Если хост является многосетевым (более одного IP-адреса), убедитесь, что все IP-адреса имеют соответствующую запись PTR (а не только первую). Отсутствие совпадающих записей PTR и A может привести к потере интернет-сервисов, как и отсутствие регистрации в DNS вообще. Кроме того, записи PTR должны указывать на действительную запись A, а не на псевдоним, определенный CNAME. Настоятельно рекомендуется использовать программное обеспечение, которое автоматизирует эту проверку, или сгенерировать данные DNS из базы данных, которая автоматически создает согласованные данные.
Для меня это не имеет никакого смысла, должен ли интернет-провайдер согласовывать записи A для каждой записи PTR? Мне кажется, это важно только в том случае, если IP-адрес, который описывает запись PTR, является хостингом службы, чувствительной к несоответствию DNS (например, хостинга электронной почты). В этом случае зона пересылки будет настроена под доменным именем (примеры следуют формату «зона -> запись»):
domain.tld -> mail IN A 1.2.3.4
И запись PTR будет настроена так, чтобы соответствовать:
3.2.1.in-addr.arpa -> 4 IN PTR mail.domain.tld.
Будет ли у интернет-провайдера какая-либо причина размещать прямой поиск IP-адреса в своей сети, как это ?:
ispdomain.tld -> broadband-ip-1 IN A 1.2.3.4
Будет ли у интернет-провайдера какая-либо причина для проведения прямого поиска IP-адреса в своей сети, как это?
В первую очередь, последовательность и полнота. Хотя вам, возможно, трудно представить, почему это важно, RFC были написаны по одной веской причине: чтобы у всех в Интернете было последовательное базовое понимание того, как все остальные будут с ними взаимодействовать. Без этой базы Интернет был бы беспорядочным набором протоколов, реализованных так, как хотелось бы, без каких-либо ожиданий от документации, совместимости, взаимодействия или согласованности.
Известно, что службы, зависящие от этих методов прямого и обратного просмотра, не должны быть специальными службами, которые требуют надлежащей обработки RFC. Следует предположить, что если вы собираетесь участвовать с остальными из нас, вы будете играть на том же уровне, что и все мы.
Сопоставление записей PTR и A позволяет проверить утверждение, сделанное в записи PTR. автоматическими средствами.
Если запись A не предоставлена, необходимо перейти к записям whois, чтобы убедиться, что запись PTR точно представляет объект, контролирующий IP-адрес, - утомительный ручной процесс, который трудно автоматизировать, часто он неверен или устарел.
Это важно по соображениям безопасности во многих контекстах. Один из них, с которым я знаком и приведу вам пример:
Допустим, вы запускаете веб-сайт и публикуете уникальный контент, но обнаружили, что ваш контент копируется на другие веб-сайты, и, что еще хуже, они занимают более высокое место в поисковых системах, чем вы!
После нескольких часов просмотра журналов и размышлений о том, как вообще кто-то ускользнул от вашей защиты, вы наконец замечаете сотни запросов от робота Googlebot. Но когда вы в конечном итоге просматриваете один из IP-адресов, вы обнаруживаете, что он зарегистрирован на веб-хостинге Bulletproof Ukraine, а не в Google. Вы думали, что вас индексируют, но вместо этого вас сыграли.
Как решить эту проблему? Легко, вы сравниваете запись PTR с записью A. Google даже рекомендует такой подход.
Это можно автоматизировать во многих языках веб-программирования (заметным исключением является PHP; ты не может сделать это надежно в PHP), чтобы веб-приложение могло проверить IP-адрес, убедитесь, что PTR *.google.com а затем использует запись A, чтобы подтвердить, что *.google.com соответствует тому же IP-адресу. Если где-то есть несоответствие, вы обнаружили поддельного робота Googlebot.