Чому кілька DTR записів у DNS не рекомендується?

Я часто читаю, що використання декількох записів PTR у конфігурації DNS не рекомендується.

Однак причини називання часто нечіткі або не такі очевидні:

"це може спричинити проблеми",
"може викликати помилки в програмах, які очікують однозначної відповіді": тоді це проблема програмного забезпечення, чи не так ?!
"може зробити пакет відповідей DNS занадто великим": це не виправлено за допомогою EDNS ?

Це вагомі причини? Чи знаєте ви якісь інші (хороші) причини? Все це ніби виглядає як "спадковий страх" ...

— Тотор
джерело

Чому ви хочете мати кілька записів PTR для однієї IP-адреси? Я не можу придумати причину, яка мала б сенс робити.

— Пер фон Цвайгберк

@PervonZweigbergk Це не те, що я запитував, але, наприклад, тому, що у мене є кілька імен, що вказують на один і той же IP, і хочу, щоб реверс відповідав усім їм.

— Тотор

@PervonZweigbergk Уявіть собі поштовий сервер, який обробляє пошту для кількох доменів. Ви можете використовувати ім'я в домені, для якого ви надсилаєте пошту в EHLOкоманді. Деякі приймачі вимагають, щоб PTRу вашій EHLOкоманді була запис, що відповідає домену , інакше вони не прийматимуть пошту від вас. Але якщо у вас є кілька PTRзаписів, вони можуть просто вибрати один з них навмання, і якщо цей не відповідає EHLOкоманді, він відхиляє пошту.

— kasperd

Я знаю, що це не те, що ви запитали, саме тому я запитав це через коментар, а не як відповідь. :-) Ви ніколи не згадували, про яку програму ви говорите. Ви б краще зрозуміти, що ви говорите про контекст вихідної електронної пошти, про що @kasperd міркує.

— Пер фон Цвайгберк

@kasperd Я гадаю, що хтось може захотіти цього зробити, але це нетрадиційно і без потреби викликає проблематичну ситуацію, про яку йдеться. Очікується, що поштовий сервер використовуватиме лише одне ім’я у своїх EHLOкомандах, незалежно від того, скільки доменів обробляє пошту. Ім'я в HELO/ EHLOочікується, що він ідентифікує сам поштовий сервер, а не стосується MAIL FROMабо Fromпоштових адрес.

— Håkan Lindqvist

Відповіді:

Очікується, що 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записів, ви фактично не робите хостингу більш законним, а навпаки, ви ризикуєте провалити деяку перевірку або іншим чином щось зламати.

Як, можливо, дещо екстремальна метафора, вручити п’ять паспортів із вашою фотографією, але з різними іменами в аеропорту, ймовірно, не отримають так само, як якщо ви просто здасте один.

— Хокан Ліндквіст
джерело

Робота над "одним канонічним іменем": у випадках, коли IP-адреса могла бути пов'язана з більш ніж однією сутністю, надається перевагу найбільш конкретному. У випадку веб-сервера з декількома віртуальними хостами, заснованими на іменах, ім'я самого веб-сервера є найбільш підходящим. Це один із тих випадків, коли спроба дотримуватися порад Інформаційних РРС ( PTRзавжди погоджуючись із Aзаписом) є повністю навантаженою.

— Ендрю Б

«Запис PTR , як очікується , щоб визначити»: хто? Це виглядає як фактичне правило, оскільки розробники програмного забезпечення почали вважати, що лише одна PTR є нормою. Чи правий я?

— Тотор

@Totor Додано цитату та посилання на джерело.

— Хокан Ліндквіст

Як анекдот, нещодавно було зазначено, що Apple має кілька записів PTR, на які варто відповісти понад 9 кбайт. Безперечно, вони не єдині. Це досить екстремальний приклад того, до чого можна дійти, коли обов'язкові правила запису PTR не враховують деталей цієї відповіді.

— Ендрю Б

Все зводиться до непередбачуваної поведінки, оскільки RFC не встановлює обмеження чи спосіб обробляти ці записи PTR. Більшість реалізацій вибиратимуть круглобільно, і ви не досягнете бажаного результату (ідеальне відповідність між багатьма іменами до одного IP-адреси).

Детальніше про це можна прочитати тут: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf

Також перевірте цю помилку за допомогою функції getnameinfo Glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ). Як ви можете гарантувати, що цього не відбувається в нескінченній кількості різних систем в Інтернеті (деякі з них дуже старі і неперевершені)?

Щоб підкріпити, як правило, завжди добре уникати невказаної та непередбачуваної поведінки. На жаль, кілька записів PTR для одного ІР підпадають під цю категорію (що стосується RFC).

— Джованні Тірлоні
джерело

Як ви можете гарантувати, що будь-яка проблема не виникає у "нескінченній" кількості різних систем в Інтернеті? Ваша відповідь хороша, але цей аргумент не має значення. Більше того, помилки клієнта не мають значення IMHO, за винятком випадків, коли на них впливає "значна" кількість.

— Тотор

Як ви гарантуєте, що PTR буде відповідати конкретному прямому запису, якщо у вас є кілька PTR?

Це особливо важливо при взаємодіях поштового сервера, де більшість вхідних приймаючих SMTP-серверів перевірять, чи відповідає форвард зворотному

Досить складно - у вас є декілька PTR, і немає жодного способу гарантувати, який PTR обраний і що він відповідає переду, який ви дали під час підключення

Найпростіший спосіб гарантувати ідеальний матч - мати один PTR, який відповідає запису вперед

— user274768
джерело