DNS
Monitoreo DNS
Que resuelva, y que la respuesta sea exactamente lo que esperas que sea.
Pruébalo ahora
Una comprobación, desde un lugar, ahora mismo, y nada se guarda. Un monitor verifica desde cada ubicación en la que operamos y confirma un fallo desde otros dos continentes antes de que alguien sea despertado, lo cual una sola mirada no puede mostrarte.
Para qué sirve
Cada otro chequeo en esta lista depende de DNS, y DNS es lo único que puede fallar mientras todo lo que apunta está perfectamente saludable. Una transferencia de zona que salió mal, un panel de registro que alguien editó, una delegación expirada: el sitio está activo e inaccesible.
El fallo que vale la pena pagar es más específico que eso. Un registro puede resolverse rápidamente, desde cualquier resolver, y apuntar a la dirección de otra persona. Nada que verifique si las respuestas DNS lo verá jamás. Danos la respuesta que esperas y verificamos eso en su lugar.
Como cada chequeo aquí, se ejecuta desde Amsterdam, New York, Sydney and Singapore, y un fallo se confirma desde otros dos continentes antes de despertar a nadie. Cómo funciona.
Lo que puedes configurar
Todo lo siguiente está en el formulario cuando añades uno, en todos los planes.
- Registro
- A, AAAA, MX, TXT, NS, CNAME o SOA.
- Respuesta esperada
- En blanco verifica que el nombre resuelva en absoluto. Completado, verifica que la respuesta siga siendo correcta, que es el fallo que nada más detecta.
- Coincidencia
- Cualquiera de ellos, o exactamente estos. Solo exactamente estos te permite notar que se ha añadido un registro en lugar de cambiarlo.
- Preguntar a este resolver
- Nombra tu propio servidor autoritativo y verás un cambio en el momento en que se haga, en lugar de esperar a que el resolver que usamos expire su caché.
Preguntas
¿Qué tipos de registros puedes vigilar?
A, AAAA, CNAME, MX, TXT, NS y SOA están en el formulario, y también se aceptan CAA, PTR y SRV. La lista es deliberadamente más corta que todo lo que DNS puede contener: cada uno aquí es un registro cuyo cambio es algo que un cliente notaría, que es el único tipo que merece una alerta.
¿Cuál es la diferencia entre NXDOMAIN y SERVFAIL?
NXDOMAIN significa que el nombre no existe: un error tipográfico, un registro eliminado o una delegación que expiró. SERVFAIL significa que se consultaron los servidores de nombres y ninguno dio una respuesta útil, lo que indica una zona rota o servidores caídos. Un tercer caso, el nombre existe pero no hay registro de ese tipo, se informa aparte de ambos, porque los tres tienen soluciones diferentes.
¿Puedes decirme si un cambio se ha propagado?
En parte, y vale la pena ser preciso sobre qué es la propagación: nada se extiende hacia afuera, las cachés simplemente expiran a su propio ritmo. Las comprobaciones se realizan desde tres continentes, así que un cambio que ha llegado a uno y no a otro aparece como un desacuerdo. Nombra tu propio servidor autoritativo y verás el cambio en el momento en que se haga.
¿Esto detectaría un secuestro de DNS?
Esa es la falla para la que existe. Un registro puede resolverse rápidamente, desde cualquier resolver, con un TTL saludable, y apuntar a la dirección de otra persona; nada que solo pregunte si DNS respondió lo verá. Rellena la respuesta que esperas y un registro que apunte a otro lugar fallará dentro de un intervalo.
¿Revisas el TTL o validas DNSSEC?
No, y lo decimos en lugar de implicar lo contrario. El TTL es lo que diga tu zona y esto no lo verifica, y las firmas DNSSEC no se validan. Lo que se comprueba es la respuesta que llega y si sigue siendo la que esperas, que es la falla que el resto de tu monitoreo no puede ver.
¿Qué hace coincidir exactamente que no haga coincidir cualquiera?
Cualquiera de ellos pasa cuando tu valor esperado está en alguna parte de la respuesta, que es lo que quieres para un nombre detrás de un grupo de direcciones. Exactamente estos falla cuando se ha añadido algo, y añadir es como suele llegar el daño: un registro A extra o un MX extra junto al tuyo es detección de cambios en registros que nada más detecta.
¿Por qué no ejecutar dig desde un script?
Puedes, y para comprobar un registro una vez es la herramienta adecuada. La dificultad es que no existe algo como la respuesta: lo que devuelve tu resolver y lo que devuelve un resolver en Sídney pueden diferir durante el tiempo de un TTL, y un script en una máquina que pregunta a un resolver ve una de esas respuestas. Esto pregunta desde cuatro continentes y puede apuntar a un resolver específico, que es lo que convierte una consulta en una comparación.
Mi registrador me envía un correo cuando cambia un registro. ¿No es suficiente?
Consérvalo, es una comprobación real y es la forma más rápida de descubrir que alguien de tu propio equipo cambió algo. Lo que cubre es el caso en que el cambio pasó por tu registrador, que es el que menos te preocupaba. No dice nada cuando un registro se cambia en un proveedor que también usas, cuando una transferencia de zona falla, o cuando un resolver en algún lugar devuelve algo que tu registrador nunca publicó. Esas son las fallas que parecen que no hay problema.