¿Cómo se supone que funcionan los tiempos de espera de DNS?

Recientemente tuve un problema en el que un servicio remoto que solicitaba la dirección IP de mi servidor (con un proveedor de DNS alojado) respondía con:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Actualización: el servicio remoto mencionado aquí es Let's Encrypt; presenté un error contra su rastreador de problemas, lo que me llevó a este camino).

Al realizar pruebas en mi red local, pude ver que a veces recibo una respuesta DNS vacía del servidor DNS alojado. Aparentemente, esto es intermitente porque ocurre solo cuando los registros DNS no están en la caché, y solo es un problema cuando el servidor DNS está realmente ocupado.

Aquí hay una descripción de Wireshark de un mensaje de respuesta vacío:

Por supuesto, dado que la mayoría de las consultas y respuestas de DNS se envían a través de UDP, un solucionador local esperará un momento la respuesta y luego se dará por vencido. Lo que ahora me pregunto es si hay pautas para los tiempos de respuesta de DNS. Mi servidor DNS se encogió de hombros y dijo que mi resolutor local envió la respuesta vacía demasiado pronto. Nunca he tenido este problema antes, pero me sorprende el modo de falla: una respuesta de DNS vacía sin un código de error.

¿Alguien sabe de algunas pautas sobre cómo se supone que esto funciona, y cuándo / cómo puedo probar que mi alojamiento DNS está haciendo algo mal?

domain-name-system dns-hosting

— djc
fuente

¿Puede actualizar la pregunta para proporcionar más información sobre la respuesta vacía? Eso puede significar varias cosas dependiendo del conjunto de indicadores y de cómo se ve la sección de autoridad. Necesitaríamos ver la salida de dig/ nslookupo una disección de Wireshark. ( tcpdumpno será lo suficientemente bueno) Si está usando nslookup, ejecute set debugprimero.

— Andrew B

Tengo un pcap, pero no estoy seguro de cómo puedo mostrarlo mejor aquí.

— djc

Ábralo en Wireshark, haga clic en el paquete, luego expanda la información para el protocolo DNS. Expanda las subcategorías también, luego publique una captura de pantalla en su pregunta usando el botón de insertar imagen. Puede recortar la captura de pantalla al material del protocolo DNS.

— Andrew B

Respuestas:

La respuesta vacía que estás viendo es un estado sintético conocido como NODATA. NODATAy NXDOMAINambos indican que el nombre no existe, pero también se NXDOMAINaplica a todos los nombres debajo del registro indicado. NODATAinforma que ese nombre está asociado con registros de un tipo no solicitado o que hay otros registros que están debajo de lo que está solicitando. (es decir example.test.xavamedia.nl.)

Su conclusión NODATAy NXDOMAINes efectivamente la misma en este contexto: el registro del nombre y tipo solicitados no existía. Se alcanzó un servidor de nombres autorizado para el dominio solicitado, y respondió respondiendo que no existía un registro de ese nombre y tipo. Esto no es un error de comunicación. El servidor autorizado dijo que no tenía los datos. Es muy probable que el servidor con el que estaba hablando ya haya procesado esta solicitud y haya guardado en caché la ausencia de ese registro en las últimas cuatro horas. (14400 segundos es el intervalo de caché negativo definido por el registro SOA para xavamedia.nl.)

Ninguno de los dos, NXDOMAINo NODATA por sí mismos , provocará un tiempo de espera cuando se encuentre en esta instancia, pero su biblioteca de resolución probablemente pasará de aquí para agregar el sufijo de búsqueda de DNS, lo que a su vez puede provocar un tiempo de espera para los servidores DNS autorizados del dominio de búsqueda.

Cabe señalar que nada de esto explica por qué encontró una SERVFAILrespuesta al buscar mysql.xavamedia.nl.. Eso apunta a un problema con el servidor recursivo obteniendo la respuesta de los servidores autorizados. O bien el servidor autorizado respondió SERVFAIL, el servidor recursivo no pudo llegar a ninguno de los servidores autoritativos o el servidor recursivo determinó que los datos devueltos no eran válidos. Nada de esto se puede probar con la información que ha proporcionado.

— Andrew B
fuente

¡Gracias por tu respuesta detallada! Algunas cosas aún no están claras: si la respuesta NODATA es iniciada por el servidor autorizado de alguna manera, mi alojamiento DNS tiene un problema, porque estos dominios han existido durante mucho tiempo (en virtud de un registro comodín A). Entonces, mi otra pregunta es, ¿cómo podría probar si el servidor autorizado hizo algo mal?

— djc

La NODATAcaptura en su paquete es la prueba. La pregunta pertinente es "¿por qué un servidor autorizado respondió y dijo que no existía tal registro?" . Desafortunadamente, es un tema difícil de presionar a menos que pueda probarlo con búsquedas directas en los servidores autorizados (eliminando la capacidad de encogerse de hombros y culpar a los operadores de los servidores recursivos), teniendo en cuenta que solo uno de los tres puede comportarse mal ocasionalmente.

— Andrew B

NODATAsignifica el nombre hace existir, pero no tiene un registro del tipo solicitado. Por ejemplo, pide un Aregistro, pero solo tiene MXregistro. También podría suceder si el nombre es para un nodo intermedio en la jerarquía DNS y no tiene registros propios.

— Barmar

@Barmar Sí, lo que se dice aquí es que el servidor autorizado informa sobre la ausencia de ese par de nombre de registro + tipo, y djc está expresando confusión sobre esto debido a un registro comodín que ha estado presente durante algún tiempo.

— Andrew B

Mi comentario está dirigido a su primer punto "NODATA y NXDOMAIN indican que el nombre no existe". NXDOMAINsignifica que el nombre no existe, NODATAsignifica que el nombre existe pero el tipo de registro solicitado no existe.

— Barmar

No conozco ninguna guía específica, excepto las definidas en la sección "6.1.3.3 Uso eficiente de recursos" de RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77

Allí se especifica un valor de tiempo de espera de "no menos de 5 segundos". El RFC también establece que las fallas temporales deben almacenarse en caché. Esto es para evitar una cantidad excesiva de solicitudes de DNS si los clientes violan la sección 2.2 del RFC. Esa sección establece que los clientes deben esperar una cantidad de tiempo "razonable" entre reintentos en caso de fallas leves.

También hay un hilo de Stackoverflow sobre este tema, pero no contiene mucha más información, excepto algunas observaciones del mundo real. /programming/3036054/ideal-timeout-period-for-dns-lookup

Eso es todo lo que puedo decir sobre este tema. Si alguien más tiene más que agregar, yo también estaría interesado.

— Janek Bevendorff
fuente