Registros SRV publicados apontando para o alias CNAME em violação da RFC 2782?

No decorrer de algumas responsabilidades de trabalho, preciso me aprofundar nos registros SRV e estou tentando conciliar uma declaração da Wikipedia com o que estou vendo nas pesquisas de DNS.

De acordo com a entrada de registro SRV da Wikipedia ,

o destino nos registros SRV deve apontar para o nome do host com um registro de endereço (registro A ou AAAA). Apontar para um nome de host com um registro CNAME não é uma configuração válida.

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

Ou seja, algo como isto:

> 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 estou entendendo mal? Não está mostrando que o registro SRV aponta para alias.domain.com, que possui um registro CNAME, não um registro de endereço?

domain-name-system cname-record srv-record

— Scott
fonte

na minha empresa usamos SRV registra muito, ea maioria deles está usando CNAMEs e ele funciona muito bem, por isso, contra as regras ou não, ele funciona muito bem :)

— olivierg

Respostas:

O artigo da Wikipedia que você está citando relata o que o RFC 2782 relevante para registros SRV indica:

Alvo

O nome do domínio do host de destino. DEVE haver um ou mais registros de endereços para esse nome, o nome NÃO DEVE ser um alias (no sentido da RFC 1034 ou RFC 2181).

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

Mas também pode não funcionar: não é suportado e depende totalmente do aplicativo cliente; portanto, deve ser evitado, porque não segue as regras apropriadas 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 em dois RFCs, e ainda assim é uma prática bastante comum (e nenhum servidor de email parece ter um problema com ele).

— Massimo
fonte

Lembre-se de que "inteligente o suficiente" é relativo. Alguns projetistas de software pensam que aguentar implementações de braindead apenas incentiva mais implementações da mesma. A RFC 2781 foi atualizada apenas por uma única RFC e o idioma sobre o que esperar é muito firme, portanto, não esperaria muita piedade aqui.

— Andrew B

A maioria dos aplicativos clientes depende apenas de bibliotecas do sistema para executar consultas DNS, e a maioria das bibliotecas (especialmente em idiomas de nível superior) fará o possível para resolver qualquer consulta que você lançar neles e seguirá feliz e silenciosamente um CNAME para seu registro A de destino. Endereço de IP.

— Massimo

O aplicativo não precisa de muita inteligência, simplesmente solicitará que o sistema operacional se conecte a "alias.domain.com" na porta 4443 e deixe todos os detalhes.

— Massimo

O aplicativo cliente e as bibliotecas do sistema não terão a oportunidade de seguir o alias se o recursor upstream rejeitar os dados autoritativos e se recusar a continuar. (que é a relativa inteligência a que me referi) O manuseio de NSregistros pelo BIND e o aliasing proibido são o exemplo clássico disso. Independentemente disso, concordamos que é um jogo de qualquer pessoa com resultados imprevisíveis.

— Andrew B

Alguns servidores de correio começaram a ignorar ativamente os MXes nos CNAMEs, por exemplo, GMX medienconsulting.at/…

— Marcel Waldvogel

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

   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.

Infelizmente, o software de servidor DNS que permite configurações proibidas não é novidade. Isso pode e acontece, como acontece com outros tipos de registro em que destinos alias são proibidos, como NSe MX. (Mencionado acima)

Só porque pode ser encontrado na natureza, não significa que esteja "ok", e o que acontece quando um padrão é ignorado varia de produto para produto. Não testei a interação com os SRVregistros, mas uma decisão de design muito conhecida pelo ISC BIND em relação aos NSregistros que apontam para aliases é abandonar o registro inteiramente, se encontrado durante a recursão. Se todos os NSregistros forem descartados dessa maneira, o resultado de todas as consultas será SERVFAILpara o subdomínio em questão.

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

— Andrew B
fonte