Definição de registros MX com registrador vs. host do servidor de nomes

4

Estou um pouco confuso sobre o que aconteceu com uma das contas de e-mail do meu cliente.

Meu cliente registrou um domínio em dotster.com. Ela queria começar a usar o e-mail para esse domínio antes de atualizar seu website, por isso configurei-o por meio do e-mail do Google Apps e adicionei os registros MX apropriados à sua conta do Google Pointster.

Quando o site dela estava pronto, eu o hospedei no dreamhost e apontei os servidores de nomes do Dreamhost para o domínio na conta do dotster. (por exemplo, o domínio hospedado no dotster apontava para servidores de nomes Dreamhost para hospedagem na web). Os registros MX ficaram os mesmos de antes e tudo funcionou bem por um tempo.

Hoje, ela me disse que o email dela começou a saltar. " erro que o outro servidor retornou foi: 554 554 5.7.1: Endereço do destinatário rejeitado: Acesso negado (estado 14) ". Quando fiz um traceroute, os registros MX não foram mostrados, mas o registro de texto foi feito (também definido como dotster).

Então fui ao Dreamhost e adicionei os registros MX lá. Agora o email dela está funcionando novamente.

Minhas perguntas:

1) Os registros MX precisam ser definidos no local para o qual os servidores de nomes são apontados? Eu pensei que eles eram independentes.

2) Eu também tenho certeza que seu e-mail estava funcionando por um bom tempo depois que eu apontei os servidores de nomes para dreamhost. Então, por que de repente pararia de funcionar?

Eu sou um web designer / desenvolvedor de front-end, então tenha isso em mente em termos de quanto você acha que eu já conheço. :) (coisas relacionadas ao servidor geralmente me entope mais do que qualquer outra coisa).

    
por Kerri 17.06.2011 / 01:11

2 respostas

4

1) Absolutamente. Quando uma pesquisa de DNS é feita (neste caso, para ver onde enviar mensagens), essa pesquisa é feita a partir dos servidores de nomes. Portanto, se os servidores de nome não tiverem o registro MX listado, a pesquisa não resultará em nada.

É o mesmo que uma lista telefônica - exceto imaginar que você só pode listar seu número de telefone em uma lista telefônica de cada vez. Então você diz aos seus amigos "Procure-me na lista telefônica da Acme". Então, quando eles querem entrar em contato com você, eles procuram seu número de telefone na lista telefônica da Acme, encontram sua listagem e ligam para você. Mas se você mover sua listagem para a "Lista Telefônica de Outros", mas não informar à OtherGuy qual é o seu número de telefone, quando seus amigos procurarem você na OtherGuys, eles não verão seu número de telefone, porque ele está listado o livro Acme em vez disso.

2) Isso ocorre porque os registros do servidor de nomes dos domínios do cliente foram armazenados em cache por um tempo (normalmente por várias horas, possivelmente até vários dias - o tempo limite é configurável). Isso significa que (aproximadamente) qualquer pessoa que fez uma pesquisa de MX antes de você mudar de nome, manteve as informações antigas na memória por um tempo, para que elas não precisassem procurar novamente. Mas, eventualmente, essa informação expirou, então quando eles tentaram procurar as informações novamente - desta vez do novo servidor - eles não conseguiram "nada", então o e-mail começou a pular.

    
por 17.06.2011 / 01:23
5
  1. Sim
  2. cache de DNS. Uma vez que o tempo limite expirou, as coisas começaram a ir para o inferno.

Cada domínio tem o que é chamado de registro SOA . Ele define, entre outras coisas, por quanto tempo outros servidores devem armazenar em cache informações sobre onde solicitar registros para o dito domínio .

Como exemplo:

@   IN  SOA     nameserver.place.dom.  postmaster.place.dom. (
                       1            ; serial number
                       3600         ; refresh   [1h]
                       600          ; retry     [10m]
                       86400        ; expire    [1d]
                       3600 )       ; min TTL   [1h]

Quando uma consulta é feita para algo em place.dom (MX, TXT, etc), o local de onde fazer todas as solicitações futuras é armazenado em cache por no máximo 1 dia. No seu caso, foi muito mais longo, por isso você não percebeu porque o SOA estava em cache.

Para obter mais informações sobre o registro SOA de um domínio, tente isso na linha de comando:

~$ nslookup
> set type=soa
> set debug
> zaplabs.com
Server:     192.168.1.1
Address:    192.168.1.1#53

------------
    QUESTIONS:
    zaplabs.com, type = SOA, class = IN
    ANSWERS:
    ->  zaplabs.com
    origin = dns1.name-services.com
    mail addr = info.name-services.com
    serial = 2002050701
    refresh = 10001
    retry = 1801
    expire = 604801
    minimum = 181
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
zaplabs.com
        origin = dns1.name-services.com
        mail addr = info.name-services.com
    serial = 2002050701
    refresh = 10001
    retry = 1801
    expire = 604801
    minimum = 181

Authoritative answers can be found from:
> 
    
por 17.06.2011 / 01:15