DNS: subdomínios que exigem um registro MX e um CNAME

17

Digamos que possuímos a zona mywebservice.com.

Desejo que cada um de meus clientes obtenha seu próprio subdomínio, como customer.mywebservice.com.

customer.mywebservice.com precisa ser um CNAME para um determinado servidor externo. Como esse site gerencia seu próprio equipamento e pode alterar os endereços a qualquer momento, o CNAME é um requisito.

As pessoas também precisam enviar e-mail para inbox@customer.mywebservice.com, o que exigiria um simples registro MX.

No entanto, e é aqui que eu gostaria de algumas orientações:

De acordo com a RFC 1034 :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

Também verifiquei que meu servidor DNS se recusará a fornecer qualquer coisa, exceto um CNAME para hosts que os usam.

Então, parece que posso ter uma situação perdida. Se eu quiser usar o registro MX, preciso usar um A em vez de um CNAME.

Alguém pode pensar em alguma solução alternativa? Obrigado!

domain-name-system cname-record mx-record

— Michael Gorsuch
fonte

20

Infelizmente, o que você está enfrentando é uma limitação da especificação do DNS. Ter um registro MX para o mesmo nome de host definido como um registro CNAME falhará na maioria das implementações de servidor DNS. Alguns servidores DNS antigos permitirão isso, mas eles foram eliminados principalmente em favor de implementações mais novas e mais seguras.

Em vez de usar registros CNAME, você precisará usar registros 'A' diretamente com os endereços IP dos sites dos clientes, em vez de usar o apelido.

— Justin Scott
fonte

Sim, acho que vou enfrentar essa. Obrigado!

— Michael Gorsuch

2

Devo também observar, para aqueles que estão lendo isso no futuro, que o motivo dessa limitação é que um CNAME deve se referir ao "nome canônico" do host que está sendo procurado. Por exemplo, se você tiver um host x2.example.com, que é um registro CNAME apontando para x1.example.com, qualquer resolvedor que procure x2 deverá ver o CNAME, substituir o que estiver fazendo no x2 por x1 e começar de novo . Se você tivesse um registro MX para x2 além do CNAME, se x1 também tivesse um MX, é possível que eles fossem diferentes, o que é indesejável, então eles simplesmente o proíbem.

— 23610 Justin Bieber

18

Depois de muito trabalho e pesquisa aqui, encontrei uma solução aceitável. Primeiro, é importante que todos sigamos os RFCs. Corrigi o meu servidor DNS para violar a RFC e descobri que vários outros servidores DNS importantes não respeitariam a alteração.

A ação apropriada é colocar o MX no host ao qual o CNAME aponta. Portanto, se customer.mywebservice.com for um CNAME para o registro A loadbalancer.mywebservice.com, é adequado também criar um registro MX para loadbalancer.mywebservice.com. Eu verifiquei que isso funciona com todos os principais resolvedores.

Se uma consulta MX for feita para customer.mywebservice.com, a biblioteca de resolvedores seguirá o CNAME e obterá o MX apropriado para o registro A final. Viva!

— Michael Gorsuch
fonte

4

customer.mywebservice.com precisa ser um CNAME para um determinado servidor externo. Como esse site gerencia seu próprio equipamento e pode alterar os endereços a qualquer momento, o CNAME é um requisito.

Alguém pode pensar em alguma solução alternativa? Obrigado!

Você precisa que os clientes possam alterar o endereço, já pensou em permitir que o cliente atualize dinamicamente seu próprio registro? Com o DNS dinâmico, você pode usar o registro A e o cliente pode alterar o registro conforme necessário. Demoraria um pouco de trabalho, mas você poderia cada subdomínio individual como uma zona separada para garantir que um cliente possa tocar apenas em sua própria zona.

Eu não tentei, mas o gnudip parece ser uma ferramenta de código aberto para facilitar as atualizações dinâmicas sem precisar lidar com a autenticação e configurar muitas zonas no servidor DNS.

— Zoredache
fonte

3

Se os seus registros MX forem os mesmos para todos esses registros, você poderá tentar usar um DNAME para redirecionar XYZ.mywebservice.com para hosting.mywebservice.com. Em hosting.mywebservice.com, adicione seus registros MX e A relevantes.

Devo dizer que nunca utilizei registros DNAME na produção, mas você pode ler mais sobre eles no RFC2672 .

— Doug Luxem
fonte

Queria tentar usar o DNAME com alguns de nossos domínios SSL, mas ouvi dizer que ainda existem problemas com os servidores DNS mais antigos etc. Isso é relevante? Ou o DNAME é seguro para uso em servidores de produção?

— drybjed

Se eu tivesse que adivinhar, muitos aplicativos não esperam registros DNAME e provavelmente quebram ao usá-los. Todos os servidores de correio seguem DNAMEs para pesquisar registros MX? Eu não sei, mas eles deveriam. Para o seu problema de SSL, os servidores DNS que não entendem DNAME devem receber uma referência CNAME. Eu testaria isso completamente antes de implementá-lo.

— Doug Luxem

O aplicativo certamente NÃO precisa processar registros DNAME! Isso é feito apenas em servidores de nomes.

— Bortzmeyer

3

O RHS do CNAME customer.mywebservice.com possui uma entrada MX?

Nesse caso, o servidor de correio usará esse MX para encontrar o servidor a ser usado. Espero que você possa controlar isso.

— MikeyB
fonte

1

A resposta de Michael Gorsuch está amplamente correta, a cadeia CNAME -> A + MX funciona ... principalmente . No entanto, ele desencadeia algum mau comportamento em certos MTAs. O que eu achei executando esta solução em uma quantidade decente de escala:

alguns MTAs simplesmente se recusam a encontrar o registro.
outras pessoas substituirão incorretamente o registro A onde deveria estar o CNAME: ou seja, enviei email para "joe@foo.example.com", que CNAMES para web.example.com, que possui um MX de mail.example.com e o O MTA reescreve o cabeçalho do envelope como "Para: joe@web.example.com".

Ainda não está claro quão difundidos são esses problemas (google / hotmail / yahoo / etc, todos parecem lidar com isso corretamente), mas eles certamente nos fazem procurar melhores soluções.

— osheroff
fonte

2

Isto está certo; o comportamento documentado para servidores SMTP compatíveis com RFC5321 é primeiro verificar a existência de um registro MX para o domínio e, se isso falhar, verificar a existência de um registro A. Esse comportamento é a verdadeira razão técnica pela qual o MX não deve ser um CNAME: ele irá parar de ser resolvido após a primeira resposta utilizável.

— adaptr

0

Uma solução possível e válida seria criar um nome de host básico para todos os seus clientes e configurá-lo para o registro a e aaaa do servidor da web externo e do seu mx, depois CNAME todos os domínios de seus clientes para esse único nome de host. Dessa forma, você precisará alterar apenas um registro quando o endereço IP externo do site for alterado.

É a única maneira possível e valiosa, pois CNAME é um alias para um conjunto completo de registros, não apenas um.

— Bachsau
fonte

-4

MX e CNAME são registros completamente separados - o primeiro determina o servidor de email para um determinado domínio, o segundo fornece o endereço para um domínio. Isso deve funcionar:

@ NA SOA ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8h
)

                        NS ns1.mywebservice.com.
                        NS ns2.mywebservice.com.

CNAME do cliente offsite.host.
cliente MX 10 mail.server.

— drybjed
fonte

4

Isso pode funcionar, mas viola o RFC1034 e o RFC1219, que afirmam que nenhum outro registro de recurso pode ter o mesmo nome que um CNAME.

— Doug Luxem

Meu daemon DNS é RFC estrito, que simplesmente se recusa a enviar a resposta para o MX. Acredito que existem alguns problemas de cache em potencial no lado do cliente, se colocarmos isso em prática.

— Michael Gorsuch

Qual daemon DNS? Estou usando o BIND9, que deve funcionar com essa configuração sem problemas. Talvez seja hora de atualizar? Grande infraestrutura, presumo?

— drybjed

Estou usando o MyDNS. É uma configuração bastante grande, e este pequeno daemon tem sido uma bênção até este momento. Estou pensando em corrigi-lo, mas não estou muito interessado em lidar com os efeitos colaterais que dão à luz. Se for contra a RFC, parece uma má ideia.

— Michael Gorsuch

@Maciej - com certeza, seu servidor de autoridade pode ser capaz de hospedar esses registros. Eles confundirão a maioria dos servidores recursivos que os consultam.

— Alnitak