Опубликованные записи 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, и все же это довольно распространенная практика (и похоже, что ни у одного почтового сервера с этим нет проблем).

— Massimo
источник

Имейте в виду, что «достаточно умный» является относительным. Некоторые разработчики программного обеспечения считают, что мириться с реализациями braindead только поощряет больше реализаций того же самого. RFC 2781 был обновлен только одним RFC, и формулировка о том, чего ожидать, очень тверда, поэтому я не ожидал бы здесь большой жалости.

— Андрей Б

Большинство клиентских приложений просто полагаются на системные библиотеки для выполнения DNS-запросов, и большинство библиотек (особенно на языках более высокого уровня) будут стараться разрешить любой запрос, который вы им дадите, и с радостью и безмолвно последуют CNAME к записи A назначения и Айпи адрес.

— Массимо

Приложению не нужно много умов, оно просто попросит ОС подключиться к «alias.domain.com» через порт 4443 и оставить все детали для него.

— Массимо

Клиентское приложение и системные библиотеки не будут иметь возможность использовать псевдоним, если рекурсор восходящего потока отклоняет достоверные данные и отказывается продолжать. (это относительная смекалка, о которой я говорил) Обработка NSзаписей и запрещенные псевдонимы в BIND являются классическим примером этого. Несмотря на это, мы согласны, что это чья-то игра с непредсказуемыми результатами.

— Андрей Б

Некоторые почтовые серверы начали активно игнорировать MX для CNAME, например, GMX medienconsulting.at/…

— Марсель Вальдвогель

Это пример ограниченного поведения, да. Само ограничение исходит из 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поддомен.

Короче, придерживайтесь стандарта. Это единственная безопасная вещь.

— Андрей Б
источник