я довольно часто читать что использование нескольких записей PTR в конфигурации DNS не рекомендуется.
Однако причины часто туманны или не столь очевидны, названия:
Это веские причины? Вы знаете какие-нибудь другие (веские) причины? Все это вроде как «наследственный страх» ...
В PTR
запись для обратного имени (например, 7.2.0.192.in-addr.arpa
) ожидается идентифицировать каноническое имя связанный с этим IP-адресом.
И указатели шлюза на сетевых узлах, и обычные указатели узлов на узлах с полным адресом используют PTR RR, чтобы указывать обратно на имена основных доменов соответствующих узлов.
Из: http://tools.ietf.org/html/rfc1035#section-3.5
Это ожидание отражено в программном обеспечении, которое выполняет обратный поиск; часто такое программное обеспечение специально ожидает возврата одного имени и ожидает, что оно сможет использовать это имя в качестве канонического имени для этого хоста. Если возвращено несколько имен, обычно выбирают одно наугад, потому что у них нет абсолютно никакого способа узнать, какое из них вы бы предпочли для этого конкретного случая.
Поскольку обычно ожидается, что с IP-адресом связано одно каноническое имя, и именно это имя PTR
должен указывать на то, что добавление нескольких имен обычно не имеет преимуществ (ничто не ожидает случайных A
/AAAA
запись, чтобы иметь соответствие PTR
), но у него есть потенциальный недостаток, так как он может привести к странным результатам, поскольку вы не можете контролировать, какой из ваших PTR
записи будут использоваться, если вы добавили более одной.
По сути, если у вас несколько PTR
записи, которые на самом деле не делают ваш хост более легитимным, а наоборот, вы рискуете не пройти проверку или иным образом что-то сломать.
Как, возможно, несколько крайняя метафора, передача пяти паспортов с вашей фотографией, но с разными именами в аэропорту, вероятно, не будет получена так же хорошо, как если бы вы просто передали один.
Все сводится к непредсказуемому поведению, поскольку RFC не устанавливает ограничений или способа обработки этих записей PTR. Большинство реализаций выбирают циклический перебор, и вы не достигнете желаемого результата (идеальное соответствие между множеством имен и одним IP-адресом).
Подробнее об этом можно прочитать здесь: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf
Также проверьте эту ошибку в функции Glibc getnameinfo (https://sourceware.org/bugzilla/show_bug.cgi?id=5790). Как вы можете гарантировать, что этого не произойдет в бесконечном количестве различных систем в Интернете (некоторые из них очень старые и не имеют исправлений)?
В качестве подкрепления, как показывает практика, всегда полезно избегать неопределенного и непредсказуемого поведения. К сожалению, несколько записей PTR для одного IP попадают в эту категорию (что касается RFC).
Как вы гарантируете, что PTR будет соответствовать конкретной прямой записи, если у вас несколько PTR?
Это особенно важно при взаимодействии с почтовым сервером, где большинство входящих SMTP-серверов будут проверять, совпадает ли пересылка с обратной.
Довольно сложно, если у вас есть несколько PTR и нет возможности гарантировать, какой PTR выбран и соответствует ли он форварду, который вы указали при подключении.
Самый простой способ гарантировать идеальное соответствие - иметь один PTR, который соответствует прямой записи