Tenemos una red pequeña, con un servidor principal (que aloja nuestro propio sitio web y funciona como servidor de nombres) y algunos servidores de alojamiento web. Desde ayer tenemos un problema con un dominio de un cliente nuestro que alojamos en nuestra red.
El servidor web está configurado correctamente, el servidor de nombres también (y ambos funcionan bien para otros dominios), pero no se puede acceder al dominio porque falla la búsqueda del nombre de host. Chrome dice que no se pudo resolver el nombre de host, algunas herramientas de verificación de DNS dicen que no se pudo encontrar el dominio o incluso simplemente fallan.
Cuando ejecuto el dig directgeslaagd.comcomando, solo aparece una sección de autoridad que dice com 600 IN SOA a.gtld-...cuál es para el TLD. Cuando ejecuto el dig @ns1.webwhales.nl directgeslaagd.comcomando, obtengo los resultados correctos ( directgeslaagd.com. 86400 IN A 149.210.185.13). Esto sucede tanto desde dentro como desde fuera de nuestra red de servidores. Entonces mi conclusión es que mi servidor de nombres funciona correctamente, ¿verdad?
Cuando ajusto el archivo de hosts de mi PC con Windows y cargo este dominio desde 149.210.185.13 directamente, el sitio web funciona, la conclusión es que también el servidor web funciona correctamente. Cuando busco los datos de WHOIS, todos los servidores de nombres y los datos son correctos. Ayer actualicé los detalles del servidor de nombres a través de nuestro registrador, pero eso no ayudó.
¿Sabes cuál podría ser el problema aquí? Nunca antes había visto algo como esto. Los dominios utilizados aquí son los dominios reales, para que pueda comprobarlo usted mismo.
Respuesta1
Recibí una respuesta de mi registrador. Resulta que ICANN envía un correo electrónico de verificación cuando cambia la dirección de correo electrónico del titular del dominio. Hacen esto para todos sus TLD desde hace un par de meses. Le dan de una a dos semanas para hacer clic en el enlace de ese correo electrónico o su dominio será bloqueado.
Cuando este sea el caso, el estado del registrador en los datos de WHOIS debe serretencion de clientes. Irónicamente, este correo electrónico suele desaparecer en la casilla de spam del destinatario. Sería bueno si primero enviaran una alerta al contacto técnico (o al menos a otra dirección de correo electrónico registrada con ese dominio).
Espero que esto ayude a otras personas.
Respuesta2
Es mejor pensar en WHOIS como una herramienta de información de "mejor esfuerzo" para humanos. La información que proporciona no siempre es actual o precisa y, en cualquier caso, DNS no consulta nunca.
dig +trace +additional example.comes tu amigo; le ayuda a visualizar problemas y le mostrará cosas que WHOIS nunca mostrará. Esto inicia un seguimiento en los servidores de nombres raíz y sigue las delegaciones del servidor de nombres.
En su caso particular, hasta aquí llega el rastro:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1425204658 1800 900 604800 86400
;; Received 112 bytes from 192.33.14.30#53(192.33.14.30) in 11 ms
Esto debería sonarte conocido: es muy similar a lo que estabas viendo en tu excavación anterior. (una sección de autoridad para com.y su registro SOA) El problema es que los servidores de nombres de TLD com.no sirven como delegación a otros servidores de nombres.
Aquí es donde la información de WHOIS finalmente se vuelve útil: directgeslaagd.com.no ha caducado (válida hasta diciembre de 2016) ysegún cabe suponerHay tres servidores de nombres configurados... pero eso no es un reflejo válido de lo que realmente sirven los servidores de nombres de TLD cuando reciben la consulta.
El problema está en algún lugar entre la interfaz web de su registrador y los servidores de nombres de TLD. Intente encontrar algo dentro de la interfaz web del registrador que pueda proporcionar una pista de por qué sucede esto. Aparte de eso, deberá consultar esto directamente con su registrador, ya que ellos son los únicos que pueden brindarle una respuesta directa sobre cuál es el problema.