Não está recebendo e-mails de alguns remetentes devido à configuração de DNS

Question

Eu observei um comportamento peculiar do meu domínio do Google Apps. A maioria dos e-mails vem como você esperaria, mas durante um período de tempo eu cheguei à conclusão de que os e-mails de remetentes certos não aparecem. Depois de identificar um desses remetentes, cujos e-mails não foram enviados, pedi a ele que tentasse me enviar um e-mail e encaminhar a resposta "falha na entrega" ao meu Gmail normal.

A resposta de falha na entrega continha o seguinte snippet:

----- Transcript of session follows -----
<[email protected]>... Deferred: Connection timed out with ghs.l.google.com.

Isso me ajudou a identificar o problema fazendo uma pesquisa rápida que me levou a esta página no Fórum de Ajuda do Google Apps. De fato, verifiquei o registro de DNS do meu domínio e @ foi definido como ghs.google.com. (CNAME), o que não deveria ser. Mudando isso para @ 74.125.93.121 (A) * resolveu o problema.

Entendo que nos casos em que o e-mail não foi enviado, meu nome de domínio foi substituído por seu nome canônico por meio de uma consulta CNAME, por isso o e-mail foi enviado para [email protected] em vez de [email protected] . Mas por que funcionou para a grande maioria dos remetentes? Os remetentes cujos e-mails não foram enviados usam algum tipo diferente de protocolo de e-mail, algumas configurações de DNS estranhas ou o que poderia ser?

Pelo que pude ver ao pesquisar o problema no google, isso parece ser uma questão muito difundida (muitas pessoas reclamando de e-mails da battle.net não aparecerem, seria um exemplo popular), apenas que as pessoas não parece estar ciente de que o problema está em suas próprias configurações de DNS, e não no lado dos remetentes.

Então, como isso pode ser explicado?

^{* Eu usei este IP por causa do que eu li aqui , mas acho que qualquer IP faria o truque. alguém pode confirmar isso? Note que simplesmente remover o registro @ não resolveu o problema, ele precisou ser alterado.}

    

Answer 1

A partir do RFC 2821 "Simple Mail Transfer Protocol", secção 5 "Resolução de Endereços e Tratamento de Correspondência":

The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name.

Em geral, é assim que os CNAMEs funcionam. Eles são freqüentemente mal utilizados, mal compreendidos e mal implementados. : -)

Se o seu domínio é example.com, você provavelmente tem registros MX existentes apontando para os hosts normais do Google Apps.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Parece que você também teve uma entrada como esta:

example.com. CNAME ghs.l.google.com.

O RFC 1034 "Conceitos e Instalações de Domínio" indica na seção 3.6.2 "Apelidos e nomes canônicos" recomenda contra essa configuração:

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.

No caso do erro que você colou, o servidor de e-mail e / ou o servidor DNS na extremidade de envio tentaram pesquisar o (s) registro (s) MX do seu domínio, example.com, e encontraram um CNAME apontando para ghs.l .google.com. Em seguida, tentou procurar o (s) registro (s) MX para ghs.l.google.com. Esse domínio não possui atualmente nenhum registro MX, portanto, o servidor de e-mail teria caído no registro A de ghs.l.google.com. Esse endereço IP não estava escutando na porta SMTP, portanto, o resultado é o erro "A conexão expirou com ghs.l.google.com".

Ao remover o registro CNAME, você corrigiu seus problemas de e-mail. Você pode encontrar problemas se o endereço IP definido em seu lugar for alterado no final do Google.

Em vez disso, você pode definir o nome para www.example.com:

www.example.com. CNAME ghs.l.google.com.

E execute um pequeno servidor em qualquer IP em que você apontar example.com, o que simplesmente faz um redirecionamento HTTP para o link

É um tanto surpreendente que tenha funcionado tão bem quanto o fez. A lei de Postel recebe algum crédito lá, eu acredito. : -)

Voltar para o RFC 1034 2.6.2:

CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted.

Portanto, neste caso, pode-se argumentar que o servidor DNS não deveria / deveria seguir o CNAME em uma pesquisa MX, a menos que não houvesse registros MX encontrados.

Ao enviar e-mails, o Sendmail e o qmail (e provavelmente outros) tentarão, por padrão, reescrever qualquer CNAME usado no lado direito de um endereço de e-mail para o nome canônico.

De fato, alguns sites se basearam nesse comportamento. O djb detalha por que ele acha que as pessoas deveriam parar de confiar nele em seu documento "Registros CNAME no correio" .

    

Answer 2

O símbolo @ em um registro BIND é apenas uma forma abreviada de gravar o domínio. Se você estiver criando um registro para example.com , então @ é apenas um alias para example.com . Dizer que o registro @ tinha que ser um IP é uma declaração que está faltando informações críticas - você não nos disse que tipo de registro era.

No relatório de exibição, parece que você talvez tenha feito alguma coisa com seu DNS para fazer com que o servidor de e-mail remoto reescreva seu domínio para ghs.l.google.com - muito estranho (PS, um registro A deve ser um IP, um registro CNAME deve não ser um IP ou outro registro CNAME).

Por que o servidor de e-mail de pessoas está reescrevendo seu endereço é estranho - não deveria a menos que essa pessoa fizesse algo para explicitamente dizer para reescrevê-lo. Ele também não deve se preocupar com o IP do seu domínio, a menos que não encontre nenhum registro MX, já que os registros MX são como os servidores de correio descobrem para onde o email vai.

Parece-me que, dadas as poucas informações fornecidas, você não seguiu as instruções do google sobre como configurar corretamente seu DNS para e-mail. Você provavelmente tem alguns erros no seu arquivo de zona - eles são verificados por um administrador de zona competente.