Чи потрібні стандарти Internet для зворотного DNS для кожного пристрою?

Вимоги, що стосуються зворотного DNS, заплутані! Люди часто говорять про те, що все порушується, якщо зворотного DNS немає, і це звучить страшно. Навіть у випадках, коли для програм не потрібен зворотний DNS, RFC часто цитуються на підтримку обов'язкового створення записів PTR.

Деякі з цих RFC включають:

RFC1912 : Поширені операційні та конфігураційні помилки DNS

Кожен хост, який має доступ до Інтернету, повинен мати ім’я. ... Переконайтеся, що ваші записи PTR та A збігаються. Для кожної IP-адреси в домені in-addr.arpa має бути відповідна запис PTR. Якщо хост є багатодомним, (більш ніж одна IP-адреса) переконайтесь, що всі IP-адреси мають відповідний запис PTR (не лише перший). Відсутність відповідних записів PTR та A може призвести до втрати Інтернет-сервісів, подібних до того, що вони взагалі не були зареєстровані в DNS.

RFC1033 : Керівництво по роботі з адміністраторами домену

Додавання хоста.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

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

Коротка відповідь

Чи вимагають стандарти, що регулюють роботу DNS, щоб усі пристрої мали відповідні записи PTR? Ні.

Чи вимагають стандарти для певних протоколів PTRзаписи, які відповідають відповідним Aчи AAAAзаписам? Так.

Чи мають деякі додатки, які не регулюються RFC, однакові вимоги? Так.

Чи може точка запису PTR на CNAME? Так, але ціль CNAME повинна бути унікальною назвою відповідного пристрою (а не іншим CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

Чи є обов’язкове створення записів PTR? Поширено так вважати, але у нього є свої проблеми.

Довга відповідь

Ця запитання надається з метою допомогти вгамувати поширене непорозуміння.

Тут застосовується трагічно недооцінений розділ RFC1796 :

На жаль, широко поширена помилкова думка, що публікація як RFC забезпечує певний рівень визнання. Це не є, або, принаймні, не більше ніж публікація у звичайному журналі. Насправді, кожен RFC має статус відносно його зв'язку з процесом стандартизації Інтернету: інформаційний, експериментальний або стандартний трек (пропонований стандарт, проект стандарту, Інтернет-стандарт) або історичний.

RFC1912 є інформаційним. RFC1033 не чітко позначений і має офіційне позначення НЕВІДОМО , це означає, що він настільки старий, що його не слід вважати посиланням ні на що . Вони не визначають Стандарти, і їх не можна використовувати для офіційного доповнення стандарту. Їх ніколи не слід цитувати в контексті, що означає, що вони визначають стандарт.

Розгляньте інформаційні пропозиції RFC як гарну пораду та загальновизнану найкращу практику. Зворотні рекомендації DNS мають сенс з першого погляду: дотримуючись цих вказівок, ви знижуєте ризик потрапляння в ситуації, коли програма не працює, оскільки зворотний DNS був необхідний і не планувався. Ви, звичайно, не можете очікувати, що адміністратор DNS буде знати кожну програму / протокол, який цього вимагає, і, на жаль, те саме стосується власників послуг, які вимагають цих записів.

Однак, за межами дуже хорошої автоматизації , обов'язкові політики створення записів PTR також створюють забруднення.

• Це надзвичайно звично, щоб PTRзаписи не синхронізувались із відповідними A/ AAAAзаписами, оскільки пристрої виводяться з експлуатації, що призводить до повного помилкового використання PTRданих. Ці дані служать лише для введення в оману тих, хто намагається сприймати цю інформацію як достовірну. Деякі власники програм охоче стрибають на ньому, коли вони полюють на причину фантомної проблеми. Проблема буде продовжуватись лише після того, як прийняття IPv6 стане більш звичним явищем, особливо для адміністраторів DNS, відповідальних за IP-простір розміру оператора.
• Наявність декількох записів PTR для однієї і тієї ж IP-адреси є досить марним, і дотримання порад інформаційних RFC неминуче призведе до цього. Див.: Чому кілька DTR записів у DNS не рекомендується?

Що гірше: відсутність запису PTR або неточний запис PTR? Якщо протокол виходить з ладу, оскільки його стандарт вимагає дійсного DNS, обидва є поганими, а останній може насправді бути гіршим . Поза тим, кожен має різну думку з цього приводу. Це добре: ви можете скласти політику та інструменти, які найкраще працюють для вашої команди та компанії. Просто переконайтесь, що вони масштабують і дають стійкі результати, і пам’ятайте, що зворотний DNS буде лише таким же точним, скільки часу і дисципліни, які повинні надати ваші члени команди.

Але відсутні записи PTR спричиняють зависання sshd!

Також не вірно. Люди часто плутають межу між відсутністю запису PTR (NXDOMAIN) та порушеним зворотним DNS.

Відповідь NXDOMAINпроблеми спричинить проблему лише в тому випадку, якщо ви спілкуєтесь із службою, яка вимагає прямого підтвердженого зворотного DNS (FCrDNS). Поштові сервери, Kerberos, VIP-сканування Oracle і т.д.

Зламаний зворотний DNS - це неможливо вчасно отримати NXDOMAINвідповідь. Багато додатків (найвідоміше sshd) заблокують зворотний пошук DNS, якщо вчасно виникнуть проблеми з отриманням відповіді з вихідних джерел, що спричинить затримки в програмі.