Recientemente, un socio nos pidió que hiciéramos lo siguiente en una de nuestras 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.comDNS define un registro MX parasend
Para mi sorpresa, esto funcionó y tanto _dmarc.send.domain.com.(TXT) como send.domain.com(MX).
¿Cómo es esto posible?
Algunas reflexiones sobre las zonas de raíces:
Sé que en las zonas raíz, por ejemplo .COM, los dominios se definen de manera similar (simplifiqué el resultado):
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
Sin embargo, si ns1.google.comy ns2.google.comdeja de funcionar, consulte asíPUEDEDeje de funcionar también (supongo que tengo un servidor DNS local en localhost):
dig google.com ns @127.0.0.1
Puede detenerse porque el servidor DNS local ns1.google.comle solicitará ns2.google.comla información.
Algunas ideas sobre "cargar" hosts en las zonas raíz:
Esta es precisamente la razón por la que configurar DNS www.domain.comno funcionará. Déjame explicarlo más detalladamente:
Algunos registradores .com le permiten configurar un único servidor DNS (en lugar de dos). Luego registra un dominio domain.com, luego configura DNS en su dominio www.domain.comy en su servidor web, también coloca el servidor DNS.
Ahora, si alguien visita su sitio web, en teoría, la consulta DNS se maneja desde el servidor raíz .COM.
Excepto que esto no funciona. O seamos precisos: la mayoría de las veces, la consulta DNS va a su servidor DNS de todos modos y si su DNS local deja de funcionar, la mayoría de los clientes no pueden resolver el nombre www.domain.com.