Назад | Перейти на главную страницу

Почему не рекомендуется использовать несколько записей PTR в DNS?

я довольно часто читать что использование нескольких записей 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, который соответствует прямой записи