Опубліковані записи SRV, які вказують на псевдонім CNAME з порушенням RFC 2782?

У ході деяких робочих обов'язків мені потрібно накопичити записи SRV, і я намагаюся узгодити заяву Вікіпедії з тим, що я бачу в копах DNS.

Відповідно до запису SRV Вікіпедії ,

ціль у записах SRV повинна вказувати на ім'я хоста із записом адреси (запис A або AAAA). Вказівка на ім'я хоста із записом CNAME не є коректною конфігурацією.

але я бачу записи, де digповертає запис SRV, що вказує на ім'я, яке є псевдонімом у записі CNAME.

Тобто, щось подібне:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

Схоже, запис SRV налаштований саме так, як каже запис Вікіпедії, заборонено. Що я нерозумію? Чи не показує, що запис SRV вказує на alias.domain.com, який має запис CNAME, а не запис адреси?

domain-name-system cname-record srv-record

— Скотт
джерело

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

— olivierg

Відповіді:

Стаття у Вікіпедії, яку ви цитуєте, повідомляє про те, що зазначено у RFC 2782 для записів SRV:

Ціль

Ім'я домену цільового хоста. ОБОВ'ЯЗКОВО бути одна або декілька адресних записів для цього імені, НАЗВА НЕ МОЖЕ бути псевдонімом (у значенні RFC 1034 або RFC 2181).

Те, що ви бачите, - це явне порушення правил; однак, це може спрацювати (і зазвичай це робиться), якщо будь-яка програма клієнта шукає, що запис SRV є досить розумним, щоб правильно обробляти запис CNAME, навіть якщо у відповіді слід очікувати лише запису A.

Але це також може не працювати взагалі: він не підтримується і повністю залежить від клієнтської програми; таким чином, цього слід уникати, оскільки це не дотримання належних правил і може призвести до помилкових та / або непередбачуваних результатів.

Це схоже на вказівку запису MX на CNAME, який визначається як просто неправильний не один , а два RFC, і все ж це досить звичайна практика (і, схоже, жоден поштовий сервер не має з цим проблеми).

— Массімо
джерело

Майте на увазі, що "досить розумний" відносний. Деякі розробники програмного забезпечення висловлюють думку, що мислення з реалізацією braindead лише заохочує більше реалізацій того ж самого. RFC 2781 було оновлено лише одним RFC, і мова про те, що очікувати, дуже тверда, тому я не сподівався б на це багато милосердя.

— Андрій Б

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

— Массімо

Додаток не потребує великої розумності, він просто попросить ОС підключитися до "alias.domain.com" на порту 4443 і залишити для нього всі деталі.

— Массімо

Клієнтські додатки та системні бібліотеки не матимуть можливості слідкувати за псевдонімом, якщо рекурсор вище за потоком відхиляє авторитетні дані та відмовиться продовжувати. (що стосується відносної розумності, про яку я мав на увазі) поводження з BIND із NSзаписами та заборонений псевдонім є класичним прикладом цього. Незалежно від того, ми погоджуємось, що це чиясь гра з непередбачуваними результатами.

— Андрій Б

Деякі поштові сервери почали активно ігнорувати MXes до CNAME, наприклад GMX medienconsulting.at/…

— Marcel Waldvogel

Це приклад обмеженої поведінки, так. Саме обмеження походить від RFC 2781 у визначенні "мета":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

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

Тільки тому, що його можна знайти в дикій природі, не означає, що це "добре", і те, що відбувається, коли стандарт ігнорується, залежить від продукту до продукту. Я не перевіряв взаємодію із SRVзаписами, але дуже відомим дизайнерським рішенням ISC BIND щодо NSзаписів, що вказують на псевдоніми, - це повністю скинути запис, якщо його виявили під час рекурсії. Якщо всі NSзаписи впадуть таким чином, результат усіх запитів буде стосуватися SERVFAILвідповідного субдомену.

Словом, дотримуйтесь стандарту. Це єдине безпечне, що потрібно зробити.

— Андрій Б
джерело