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