Опубликованные записи 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, а не запись адреса?

В статье Википедии, которую вы цитируете, сообщается, что говорится в соответствующем RFC 2782 для записей SRV:

цель

Доменное имя целевого хоста. Для этого имени ДОЛЖНА быть одна или несколько адресных записей, имя НЕ ДОЛЖНО быть псевдонимом (в смысле RFC 1034 или RFC 2181).

То, что вы видите, является явным нарушением правил; однако, это может работать (и обычно работает), если клиентское приложение ищет эту запись SRV достаточно умен, чтобы правильно обрабатывать запись CNAME, даже если в ответе она ожидает только запись A.

Но он также может не работать вообще: он не поддерживается и полностью зависит от клиентского приложения; поэтому его следует избегать, поскольку он не следует надлежащим правилам и может привести к ошибочным и / или непредсказуемым результатам.

Это похоже на указание записи MX на CNAME, которая определена как неправильная не только в одном , но и в двух RFC, и все же это довольно распространенная практика (и похоже, что ни у одного почтового сервера с этим нет проблем).

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

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