¿Algunos servidores DNS en el mundo dan una dirección IP incorrecta para nuestro dominio?

Nuestro dominio, grahamhancock.com, está siendo resuelto erróneamente por algunas personas en todo el mundo, pero se resuelve correctamente para la mayoría de las personas.

Cuando reviso una lista de proveedores de DNS abiertos gratuitos, aproximadamente el 90% resuelve correctamente y proporciona información coherente con nuestro archivo de zona. Sin embargo, el 10% no lo hace y afirma que la dirección IP está vinculada a alguna instancia de Amazon EC2 que nunca hemos tenido o usado en el pasado. Aquí hay algunos ejemplos de servidores DNS que brindan información incorrecta:

dig www.grahamhancock.com @173.84.127.88
dig www.grahamhancock.com @209.222.18.222

¿Cómo podrían estos servidores tener la información incorrecta y cómo podemos recuperar el control de la situación?

¿Podría ser esto algo malicioso o una configuración incorrecta? Somos un sitio de 1 millón de visitas al mes, con buenas clasificaciones de búsqueda, por lo que probablemente somos el objetivo de algo malicioso. La dirección IP incorrecta que el servidor erróneo está devolviendo a algunas personas apunta a un sitio para hacerse rico rápidamente en una instancia de AWS EC2.

¿Qué debemos hacer?

domain-name-system

— Duncan Marshall
fuente

¿Es ese el nombre de dominio real?

— Drifter104

Sí, ese es el dominio real.

— Duncan Marshall

Algunos servidores DNS también están mal configurados, la pregunta es ¿por qué su cliente no usa su ISP DNS? como mínimo, puede pedirle a una línea directa que lo arregle si está en un ISP DNS.

— yagmoth555 - GoFundMe Monica

Nuestros usuarios están utilizando los servidores DNS de su ISP, pero esos servidores no aceptarán mis consultas ya que no soy su cliente. Los servidores DNS anteriores son públicos, por lo que los usé para probar. Si están mal configurados, están mal configurados de la misma manera, y de repente se han vuelto mal configurados, ya que esto no estaba sucediendo ayer. Aquí está la IP de uno de los servidores DNS del ISP de nuestro usuario: 177.86.168.11. Nuestros otros usuarios no respondieron ni fueron lo suficientemente competentes como para darnos la IP de su servidor DNS.

— Duncan Marshall

¿Puedo de paso agradecer profundamente al póster original por incluir el nombre de dominio real en su pregunta, en lugar de redactarlo? Como he tenido ocasión de señalar antes , las preguntas de DNS son miembros de esa clase, que son mucho más fáciles de responder de forma rápida y canónica cuando se realiza la divulgación completa, y personalmente creo que la muy alta calidad de las respuestas que ha tenido esta pregunta se debe en parte a muchas los globos oculares pueden mirar directamente al problema.

— MadHatter apoya a Monica el

Respuestas:

Drifter es correcto, tiene un problema de configuración del servidor de nombres. Aquí está el final de la salida de dig +trace +additional www.grahamhancock.com:

grahamhancock.com.      172800  IN      NS      ns1.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      ns2.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      server.grahamhancock.com.
ns1.grahamhancock.com.  172800  IN      A       199.168.117.67
ns2.grahamhancock.com.  172800  IN      A       199.168.117.67
server.grahamhancock.com. 172800 IN     A       199.168.117.67
;; Received 144 bytes from 192.35.51.30#53(f.gtld-servers.net) in 92 ms

www.grahamhancock.com.  14400   IN      CNAME   grahamhancock.com.
grahamhancock.com.      14400   IN      A       199.168.117.67
grahamhancock.com.      86400   IN      NS      ns2.grahamhancock.com.com.
grahamhancock.com.      86400   IN      NS      ns1.grahamhancock.com.com.
;; Received 123 bytes from 199.168.117.67#53(ns2.grahamhancock.com) in 17 ms

Sus registros de pegamento apuntan a una dirección IP de 199.168.117.67, que devuelve la respuesta correcta. Sin embargo, su zona está definiendo registros de servidor de nombres que terminan en com.com. Si en su lugar somos +traceuno de esos servidores de nombres ...

com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
;; Received 212 bytes from 192.26.92.30#53(c.gtld-servers.net) in 22 ms

ns1.grahamhancock.com.com. 30   IN      A       54.201.82.69
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
;; Received 196 bytes from 205.251.195.127#53(ns-895.awsdns-47.net) in 16 ms

... terminamos en los servidores de nombres alojados por AWS de alguien.

Su problema es algo conocido como un desajuste de registro de pegamento . Los servidores de nombres remotos inicialmente están aprendiendo sobre su dominio a través de los registros de pegamento, pero una vez que esos servidores remotos realizan una actualización , terminan consultando los servidores de nombres falsos que ha definido con un extra .comal final.

Este no es tu único problema. Está enumerando la misma dirección IP tres veces en sus registros de pegamento, lo cual es extremadamente volátil. Siempre debe tener varios servidores de nombres, nunca deben compartir una subred o un par de red ascendente, y nunca deben ubicarse en la misma ubicación física. Tal como están las cosas actualmente, cualquier breve problema de enrutamiento entre los servidores DNS y su servidor único hará que su dominio sea temporalmente inaccesible.

Actualizar:

Este Q&A ha aparecido en la portada y está recibiendo muchos comentarios. Por desgracia, eso incluye a las personas que son sólo un poco demasiado dispuestos a responder a esta pregunta sin comprobar para ver si sus puntos ya se han tratado en los comentarios expandidas.

El detalle que la mayoría de la gente parece pasar por alto es el comentario que estoy citando aquí:

Los servidores DNS geo-redundantes evitan escenarios en los que una breve interrupción del enrutamiento da como resultado un almacenamiento en caché negativo temporal de los servidores de nombres. Por breve que sea el período de almacenamiento en caché negativo, es casi seguro que excederá la cantidad de tiempo que hubo una interrupción de conectividad. [...] el número de escenarios donde la falta de redundancia geográfica de DNS no creará problemas de disponibilidad esporádicos y difíciles de solucionar es exactamente cero.

Si cree que mi comprensión del almacenamiento en caché negativo de los servidores de nombres es incorrecta, es un juego abierto para discusión, pero aparte de eso, debe traer algo a la mesa que no sea "es un sitio pequeño y a quién le importa si tanto el sitio web como el servidor DNS están caídos". al mismo tiempo". Si dices esto, no entiendes el tema tan bien como crees que lo haces.

Segunda actualización

Seguí adelante y escribí un Q&A canónico que podemos vincular siempre que surja el tema del servidor DNS único en el futuro. Esperemos que esto ponga el asunto a descansar.

— Andrew B
fuente

No importa lo que vea en el panel de control, esta es la realidad. dig @199.168.117.67 grahamhancock.com NSdeja esto explícitamente claro: que los datos provienen de sus servidores. En cuanto a que se trata de un "problema financiero", voy a ser franco aquí: si no va a ejecutar servidores DNS redundantes, no tiene absolutamente ningún negocio operar su propio DNS. Tendrás tiempo de inactividad. A menos que esté muy cerca del propietario, será responsable de ese tiempo de inactividad y de permitir que se implemente esta configuración.

— Andrew B

Te escucho, pero está fuera de mis manos. De todos modos, gracias por la ayuda.

— Duncan Marshall

@Bodo lo suficientemente justo. Dicho esto, todavía está pasando por alto el hecho de que los servidores DNS geo-redundantes evitan escenarios en los que una breve interrupción del enrutamiento resulta en el almacenamiento en caché negativo temporal de los servidores de nombres. Por breve que sea el período de almacenamiento en caché negativo, es casi seguro que excederá la cantidad de tiempo que hubo una interrupción de conectividad. (o para decirlo de manera más simple, ya que no puedo seguir respondiendo a esto: "bla, bla, bla, DNS, bla, la cantidad de escenarios en los que la falta de redundancia geográfica de DNS no creará problemas de disponibilidad esporádicos y difíciles de solucionar es exactamente cero" .)

— Andrew B

Puede obtener alojamiento de DNS por $ 1 con servidores NS redundantes. No es una opción financiera. No seas un vaquero.

— JamesRyan

Hay muchos proveedores de DNS secundarios gratuitos que son adecuados para zonas de baja carga. O como dijo @JamesRyan anteriormente, uno puede pagar una cantidad (muy pequeña) de dinero por un servicio administrado profesionalmente con algún tipo de SLA. Ambas son alternativas viables para sitios de poco tráfico.

— un CVn

El uso de las siguientes herramientas da un par de pistas

https://www.whatsmydns.net/#NS/grahamhancock.cominforma que los registros NS en el dominio apuntan a ns1.grahamhancock.com.comnotar el .com adicional

http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage también informa que el mismo servidor de nombres informa que tiene autoridad.

Si echa un vistazo aquí http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.com, también informa que sus servidores de nombres están abiertos.

Por lo tanto, parecería que en algún lugar a lo largo de la línea los servidores de nombres no están configurados correctamente. Si aparecen correctamente a través de un panel de control, etc., deberá hablar con el proveedor para que pueda verificarlos en los servidores reales.

Esos enlaces también tienen un informe completo sobre las mejores prácticas y cómo tratarlas.

— Drifter104
fuente

Y los parásitos ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ Las personas en com.comhan configurado DNS comodín para aprovechar este tipo de error. Si su registro NS apunta a anything.com.com, responderán cualquier consulta que reciban de una manera que les dirija el tráfico. ¡Intenta dig @anything.com.com anyotherthing.comcomprobar la autoridad y las secciones adicionales de la respuesta!