Чому не можна використовувати запис CNAME у вершині (aka root) домену?

Це канонічне запитання про CNAMEs в апліках (або коренях) зон

Відносно загальновідомо, що CNAMEзаписи на вершині домену - це табу.

Приклад: example.com. IN CNAME ithurts.example.net.

У кращому випадку програмне забезпечення серверів імен може відмовитись у завантаженні конфігурації, а в гіршому випадку може прийняти цю конфігурацію та визнати недійсною конфігурацію для example.com.

Нещодавно у мене компанія, що розмістила веб-хостинг, передала інструкції бізнес-підрозділу, який нам потрібен для того, щоб CNAME вершину нашого домену підписати на новий запис. Знаючи, що це буде конфігурація самогубства, коли його подають у BIND, я порадив їм, що ми не зможемо їх виконати, і що це загальна рада. Компанія, що розмістила веб-хостинг, виступила з позицією, що це прямо не заборонено стандартним визначенням RFC і що їх програмне забезпечення підтримує це. Якби ми не змогли CNAME вершини, їхня порада полягала в тому, щоб взагалі не було записано верхівку, і вони не нададуть веб-сервер для перенаправлення. ...Що?

Більшість з нас знає, що RFC1912 наполягає на цьому A CNAME record is not allowed to coexist with any other data., але давайте бути чесними з собою тут, що RFC є лише Інформаційним. Найближчий я знаю до думки, що забороняє практикуватися з RFC1034 :

Якщо RAME CNAME присутній у вузлі, інших даних не повинно бути; це гарантує, що дані для канонічного імені та його псевдонімів не можуть бути різними.

На жаль, я досить довго працював у цій галузі, щоб знати, що "не слід" - це не те саме, що "не повинен", і цього достатньо канату для більшості розробників програмного забезпечення. Знаючи, що все, що є коротким, ніж стисле посилання на каламбур, буде марною тратою мого часу, я в кінцевому підсумку дозволив компанії піти з лаяння за рекомендації конфігурацій, які можуть зламати часто використовуване програмне забезпечення без належного розкриття.

Це приводить нас до запитання. Колись я хотів би, щоб ми по- справжньому дізналися про божевілля вершин CNAME, а не спідниці навколо проблеми, як це ми зазвичай робимо, коли хтось публікує цю тему. RFC1912 поза межами, як і будь-яка інша інформаційна RFC, застосована тут, про яку я не думав. Давайте закриємо цю дитину.

CNAMEзаписи спочатку були створені, щоб дозволити декілька імен, які забезпечують один і той же ресурс, бути псевдонімом одному "канонічному імені" для ресурсу. З появою віртуального хостингу на основі імен, натомість стало звичним використовувати їх як загальну форму псевдоніму IP-адрес. На жаль, більшість людей, які походять з фонового веб-хостингу, очікують, що CNAMEзаписи вказують на еквівалентність у DNS , що ніколи не було наміром. В вершині містяться типи записів, які явно не використовуються для ідентифікації канонічного ресурсу хоста ( NS, SOA), який не можна відчути без порушення стандарту на фундаментальному рівні. (особливо що стосується скорочень зон )

На жаль, початковий стандарт DNS був написаний ще до того, як керівні органи зі стандартів зрозуміли, що для визначення послідовної поведінки необхідна явна багатослівність ( RFC 2119 ). Необхідно було створити RFC 2181 для уточнення декількох кутових випадків через розпливчасті формулювання, а оновлений словес чіткіше пояснює, що CNAME не можна використовувати для згладження вершини, не порушуючи стандарт.

6.1. Зонова влада

Авторитетні сервери для зони перераховані в записах NS для походження зони, які поряд із записом Start of Authority (SOA) є обов'язковими записами у кожній зоні. Такий сервер є авторитетним для всіх записів ресурсів у зоні, яка не знаходиться в іншій зоні. Записи NS, які вказують на розріз зони, є властивістю створеної дочірньої зони, як і будь-які інші записи про походження цієї дочірньої зони або будь-які її піддомени. Сервер для зони не повинен повертати авторитетні відповіді на запити, пов’язані з іменами в іншій зоні, що включає НС і, можливо, записи А в розрізі зони, за винятком випадків, коли це також є сервером для іншої зони.

Це встановлює, що SOAі NSзаписи є обов'язковими, але це нічого не говорить про Aабо інші види, що з’являються тут. Може здатися зайвим, що я це тоді цитую, але це стане більш актуальним через мить.

RFC 1034 був дещо розпливчастим щодо проблем, які можуть виникнути, коли CNAMEіснує поряд з іншими типами записів. RFC 2181 усуває неоднозначність і чітко заявляє типи записів, які можуть існувати поряд з ними:

10.1. Записи ресурсів CNAME

Існує запис DNS CNAME ("канонічне ім'я") для надання канонічного імені, пов'язаного з ім'ям псевдоніма. Для будь-якого псевдоніма може бути лише одна така канонічна назва. Це ім'я, як правило, має бути ім'ям, яке існує в іншому місці DNS, хоча є деякі рідкісні програми для псевдонімів із супровідним канонічним іменем, визначеним у DNS. Псевдонім ім'я (мітка запису CNAME), якщо DNSSEC використовується, може мати SIG, NXT та KEY RR, але може не мати інших даних. Тобто, для будь-якої мітки в DNS (будь-яке доменне ім’я) справедливо одне з наступних:

• існує один запис CNAME, необов'язково супроводжуваний SIG, NXT та KEY RR,
• існує одна або декілька записів, жодна з яких не є записами CNAME,
• ім’я існує, але не має пов'язаних RR будь-якого типу,
• назва взагалі не існує.

"псевдонім ім'я" в цьому контексті посилається на ліву частину CNAMEзапису. Позначений список чітко пояснює, що a SOA, NSта Aзаписи не можна побачити на вузлі, де CNAMEтакож з'являється a . Коли ми поєднуємо це з розділом 6.1, неможливо CNAMEіснувати на вершині, оскільки воно повинно жити поряд із обов'язковими SOAта NSзаписами.

(Здається, це виконує роботу, але якщо у когось коротший шлях до доказів, будь ласка, дайте тріщину на це.)

Оновлення:

Складається враження, що остання плутанина походить від нещодавнього рішення Cloudflare про дозвіл визначення незаконного запису CNAME на вершині доменів, для якого вони будуть синтезувати записи A. "RFC-сумісний", як описано у зв'язаній статті, відноситься до того, що записи, синтезовані Cloudflare, будуть добре грати з DNS. Це не змінює того факту, що це абсолютно індивідуальна поведінка.

На мій погляд, це є причиною для більшої спільноти DNS: це насправді не запис CNAME, і це вводить людей в оману вважати, що інше програмне забезпечення є недостатнім, оскільки це не дозволяє. (як показує моє запитання)

Нещодавно Консорціум Інтернет-систем розмістив підписку на CNAME на вершині зони , чому це обмеження існує, та ряд альтернатив. Це, мабуть, не скоро зміниться, на жаль:

Ми не можемо змінити спосіб використання спеціального запису CNAME, не змінюючи одночасно всі реалізації DNS-сервера у світі. Це тому, що його значення та тлумачення було чітко визначено в протоколі DNS; всі поточні реалізації клієнта та сервера DNS дотримуються цієї специфікації. Спроба "розслабитися", як CNAME використовується на авторитетних серверах, не змінюючи одночасно всі DNS-рішення, які зараз діють, призведе до порушення роздільної здатності імен (а веб-служби та сервіси електронної пошти стають періодично недоступними для тих організацій, які застосовують "розслаблені" авторитетні серверні рішення).

Але є надія:

Інше потенційне рішення, яке зараз обговорюється, додало б новий тип запису ресурсів dns, який браузери шукатимуть, що може існувати на вершині. Це буде ім'я хоста для програми для запитів http (подібно до того, як працює MX).

Плюси: Це повністю відповідає дизайну DNS.
Мінуси: Це ще не доступно, і для цього потрібне оновлення клієнта браузера.

Якщо ви переспрямовуєте всю зону, слід використовувати DNAME. Відповідно до RFC 6672 ,

DNAME RR і CNAME RR [RFC1034] викликають пошук (потенційно) повернення даних, відповідних доменному імені, відмінному від запитуваного доменного імені. Різниця між двома записами ресурсів полягає в тому, що CNR RR спрямовує пошук даних у свого власника до іншого єдиного імені, тоді як DNAME RR спрямовує пошук даних у нащадків імені власника на відповідні імена під іншим (одним) вузлом дерево.

Наприклад, перегляньте зону (див. RFC 1034 [RFC1034], Розділ 4.3.2, крок 3) для доменного імені "foo.example.com", а запис ресурсів DNAME знайдений на "example.com" із зазначенням що всі запити під "example.com" будуть спрямовані на "example.net". Процес пошуку повернеться до кроку 1 з новою назвою запиту "foo.example.net". Якби назва запиту була "www.foo.example.com", нове ім'я запиту було б "www.foo.example.net".