
Recentemente, um parceiro nos pediu para fazer o seguinte em uma de nossas zonas DNS:
_dmarc.send.domain.com. TXT "v=DMARC1; p=none"
send.domain.com. NS ns1.otherdomain.com.
send.domain.com. NS ns2.otherdomain.com.
otherdomain.com
DNS define um registro MX parasend
Para minha surpresa, isso funcionou tanto _dmarc.send.domain.com.
(TXT) quanto send.domain.com
(MX).
Como isso é possível?
Algumas reflexões sobre zonas raiz:
Eu sei que em zonas raiz, por exemplo .COM, os domínios são definidos de maneira semelhante (simplifiquei a saída):
dig google.com ns @a.gtld-servers.net.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN A 216.239.32.10
No entanto, se ns1.google.com
e ns2.google.com
parar de funcionar, faça uma consulta assimPODERIApare de funcionar também (presumo que tenho um servidor DNS local em localhost):
dig google.com ns @127.0.0.1
Pode parar porque o servidor DNS local solicitará ns1.google.com
as ns2.google.com
informações.
Algumas reflexões sobre o "upload" de hosts nas zonas raiz:
É precisamente por isso que definir o DNS como www.domain.com
não funcionará. Deixe-me elaborar sobre isso:
Alguns registradores .com permitem definir um único servidor DNS (em vez de dois). Então você registra um domínio - domain.com
, então você define o DNS no seu domínio - www.domain.com
e no seu servidor web, você coloca o servidor DNS também.
Agora, se alguém visitar o seu site, teoricamente, a consulta DNS será feita no servidor raiz .COM.
Exceto que isso não funciona. Ou sejamos mais precisos - na maioria das vezes, a consulta DNS vai para o seu servidor DNS de qualquer maneira e se o DNS local parar de funcionar, a maioria dos clientes não conseguirá resolver name www.domain.com
.