PTR и запись A должны совпадать?
В разделе 2.1 RFC 1912 говорится следующее:
Убедитесь, что ваши записи 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
2 ответа
Будет ли какая-либо причина для того, чтобы провайдер размещал в сети прямой поиск 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-адресом. Если где-то есть несоответствие, вы обнаружили фальшивый робот Google.