Registros SRV publicados apontando para alias CNAME violando o RFC 2782?

Question

No decorrer de algumas responsabilidades de trabalho, preciso detalhar os registros SRV e estou tentando reconciliar uma declaração da Wikipedia com o que estou vendo nas escavações de DNS.

De acordo com a entrada de registro SRV da Wikipedia ,

the target in SRV records must point to hostname with an address record (A or AAAA record). Pointing to a hostname with a CNAME record is not a valid configuration.

mas vejo registros em que dig retorna um registro SRV apontando para um nome que é o alias em um registro CNAME.

Ou seja, algo assim:

> 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

Parece que o registro SRV está configurado exatamente da maneira que a entrada da Wikipedia diz que não é permitido. O que eu estou entendendo mal? Não está mostrando que o registro SRV aponta para alias.domain.com, que tem um registro CNAME, não um registro de endereço?

    

Answer 1

O artigo da Wikipedia que você está citando relata o que os RFC 2782 relevantes para registros SRV afirmam:

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).

O que você está vendo é uma clara violação das regras; no entanto, pode funcionar (e geralmente faz), se qualquer aplicativo cliente estiver procurando por esse registro SRV for inteligente o suficiente para manipular corretamente um registro CNAME, mesmo que seja espera apenas um registro A na resposta.

Mas também pode não funcionar: não é suportado e depende completamente da aplicação cliente; portanto, deve ser evitado, porque não está seguindo as regras adequadas e pode levar a resultados errôneos e / ou imprevisíveis.

Isso é semelhante a apontar um registro MX para um CNAME, que é definido como errado , não apenas em um , mas dois RFCs, e ainda assim é uma prática bastante comum (e nenhum servidor de e-mail parece ter um problema com isso).

    

Answer 2

Esse é um exemplo do comportamento restrito, sim. A restrição em si vem de RFC 2781 na definição de "alvo":

   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.

O software de servidor DNS que permite configurações proibidas não é novidade, infelizmente. Isso pode acontecer e acontece, como acontece com outros tipos de registro em que alvos com alias são proibidos, como NS e MX . (mencionado acima)

Só porque pode ser encontrado na natureza não significa que esteja "bem", e o que acontece quando um padrão é ignorado varia de produto para produto. Eu não testei a interação com SRV records, mas uma decisão de design muito conhecida do ISC BIND em relação a NS registros apontando para aliases é soltar o registro inteiramente se encontrado durante a recursão . Se todos os registros NS forem descartados dessa maneira, o resultado de todas as consultas será SERVFAIL para o subdomínio em questão.

Em resumo, atenha-se ao padrão. É a única coisa segura a fazer.