¿Cuánto dura normalmente el almacenamiento en caché de DNS negativo?

44

Si un servidor DNS busca un registro y falta, a menudo "almacenará en caché negativamente" el hecho de que falta este registro, y no intentará buscarlo nuevamente por un tiempo. No veo nada en el RFC sobre el TTL en el almacenamiento en caché negativo, así que supongo que es algo arbitrario. En el mundo real, ¿por cuánto tiempo permanecen estos registros negativos?

domain-name-system Leopd
fuente
66
RFC 2308, Almacenamiento en caché negativo de consultas DNS explica cómo se supone que funciona. (Pregunta SO relacionada: ¿un servidor de nombres de almacenamiento en caché suele almacenar en caché la respuesta DNS negativa SERVFAIL? )
Skyhawk

Respuestas:

60

El TTL para el almacenamiento en caché negativo no es arbitrario. Se toma del registro SOA en la parte superior de la zona a la que habría pertenecido el registro solicitado, si hubiera existido. Por ejemplo:

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

El último valor en el registro SOA ("86400") es la cantidad de tiempo que los clientes deben almacenar en caché los resultados negativos example.org..

Si un cliente lo solicita doesnotexist.example.org., almacenará en caché el resultado durante 86400 segundos.

Celada
fuente
1
@MarcusAdams ... y un cliente no guardará en caché ningún registro en SERVFAIL. El TTL en el registro SOA se usa, de hecho, para el almacenamiento en caché negativo. Es por eso que el registro SOA se produce en las respuestas de NXDOMAIN.
Celada
3
@MarcusAdams Correcto. Si obtiene un SERVFAIL, entonces no obtiene un SOA ni un TTL. No hay respuesta para usted al caché negativo. Si, en cambio, obtienes un NXDOMAIN , entonces obtienes un SOA, con un TTL. Hará un caché negativo de esa respuesta mientras dure el TTL.
Celada
Beartrap para usuarios de DNS RBL: dado que las respuestas RBL tienden a ser mínimas (y la implementación del servidor DNS posiblemente no sea conforme), es posible que no obtenga un SOA con la respuesta NXDOMAIN. Esto puede significar que su caché DNS no almacena en caché NXDOMAIN (es decir, los que no son spammers): - /
mr.spuratic
En realidad MIN(SOA TTL, SOA.MINIMUM), no es simplemente SOA.MINIMUM. (Ver tools.ietf.org/html/rfc2308#section-5 )
Håkan Lindqvist
12

Esto depende de su definición exacta de una "consulta negativa", pero en cualquier caso, esto se documenta en rfc2308 «Almacenamiento en caché negativo de consultas DNS (DNS NCACHE)» :

NXDOMAIN

  • Si la resolución es exitosa y resulta en NXDOMAIN, la respuesta vendrá con un SOAregistro, que contendría el NXDOMAINTTL (tradicionalmente conocido como el MINIMUMcampo). rfc2308#section-4

SERVFAIL

  • Si la resolución no es exitosa y resulta en un tiempo de espera excedido ( SERVFAIL) , es mejor que no se almacene en caché y, en todas las circunstancias, NO DEBE almacenarse en caché por más de 5 minutos. rfc2308#section-7.1

    Tenga en cuenta que, en la práctica, el almacenamiento en caché de dichos resultados durante los 5 minutos permitidos es una excelente manera de disminuir la experiencia de un cliente en caso de que su servidor de caché ocasionalmente sufra breves problemas de conectividad (y efectivamente lo hace fácilmente vulnerable a una amplificación de denegación de servicio, donde unos segundos de tiempo de inactividad darían como resultado que ciertas partes del DNS estén inactivas durante los cinco minutos completos).

    Antes de BIND 9.9.6-S1 (lanzado en 2014), aparentemente, SERVFAILno estaba en caché en absoluto. a878301(2014-09-04)

    Por ejemplo, en el momento de su pregunta y en todas las versiones de BIND lanzadas antes de 2014, el solucionador recursivo BIND NO se almacenó SERVFAILen caché , si se cree en la confirmación anterior y la documentación sobre la primera introducción en 9.9.6-S1 .

    En el último BIND, el valor predeterminado servfail-ttles 1s, y la configuración está codificada en un techo de 30s(en lugar del techo obligatorio de RFC de 300s). 90174e6(17/10/2015)

    Además, las siguientes son algunas citas notables al respecto:

    El resultado del almacenamiento en caché de las respuestas de SERVFAIL ha incluido algunas situaciones en las que se consideró que era perjudicial para la experiencia del cliente, particularmente cuando las causas de la presentación de SERVFAIL al cliente eran transitorias y de un escenario donde un reintento inmediato de la consulta sería acción más apropiada

    La segunda táctica es afirmar que los clientes DNS generalizados harán algo particularmente malo cuando no puedan acceder a todos los servidores DNS. El problema con este argumento es que la afirmación es falsa. Cualquiera de estos clientes está claramente defectuoso y no podrá sobrevivir en el mercado: considere lo que sucede si los enrutadores del cliente se caen brevemente o si la red del cliente se inunda temporalmente.

En resumen, una NXDOMAINrespuesta se almacenaría en caché como se especifica en la SOAzona correspondiente, mientras que SERVFAILes poco probable que se almacene en caché o, si se almacena en caché, será como máximo un número de segundos de dos dígitos.

cnst
fuente
1

Hay un RFC dedicado a este tema: RFC 2308 - Almacenamiento en caché negativo de consultas DNS (DNS NCACHE) .

La sección relevante para leer es 5: almacenamiento en caché de respuestas negativas que establece:

Al igual que las respuestas normales, las respuestas negativas tienen tiempo de vida (TTL). Como no hay un registro en la sección de respuestas a la que se pueda aplicar este TTL, el TTL se debe llevar por otro método. Esto se hace incluyendo el registro SOA de la zona en la sección de autoridad de la respuesta. Cuando el servidor autorizado crea este registro, su TTL se toma del mínimo del campo SOA.MINIMUM y el TTL de SOA. Este TTL disminuye de manera similar a una respuesta en caché normal y al llegar a cero (0) indica que la respuesta negativa en caché NO DEBE usarse nuevamente.

En primer lugar, identifiquemos SOA.MINIMUMy el SOA TTL descrito en el RFC. El TTL es el número antes del tipo de registro IN( 900segundos en el ejemplo a continuación). Mientras que el mínimo es el último campo en el registro ( 86400segundos en el ejemplo a continuación).

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

Ahora veamos algunos ejemplos, la serverfault.comzona es ilustrativa ya que tiene servidores autorizados de dos proveedores diferentes que están configurados de manera diferente.

Vamos a encontrar los servidores de nombres autorizados para la serverfault.comzona:

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

Luego verifique el registro SOA usando un servidor de nombres aws:

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

De esto podemos ver que el TTL del registro SOA es 900segundos, mientras que el valor TTL negativo es 86400segundos. El valor de SOA TTL 900es menor, por lo que esperamos que se use este valor.

Ahora, si consultamos un servidor autorizado para un dominio inexistente, deberíamos obtener una respuesta sin respuesta y con un registro SOA en la sección de autoridad:

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

Cuando un resolutor recursivo (almacenamiento en caché) recibe esta respuesta, analizará el registro SOA en el AUTHORITY SECTIONy utilizará el TTL de este registro para determinar cuánto tiempo debe almacenar en caché el resultado negativo (en este caso, 900segundos).

Ahora sigamos el mismo procedimiento con un servidor de nombres de Google:

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

Puede ver que los servidores de nombres de Google tienen valores diferentes para los valores SOA TTL y Negative TTL. En este caso, el TTL negativo de 300es menor que el TTL de SOA de 21600. Por lo tanto, el servidor de Google debe usar el valor más bajo en el AUTHORITY SECTIONregistro SOA al devolver una NXDOMAINrespuesta:

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

Como se esperaba, el TTL del registro SOA en la NXDOMAINrespuesta es 300segundos.

El ejemplo anterior también demuestra lo fácil que es obtener diferentes respuestas a la misma consulta. La respuesta que utiliza un solucionador de almacenamiento en caché individual se basa en qué se consultó el servidor de autoridad autorizado.

En mis pruebas, también he observado que algunos resolutivos recursivos (almacenamiento en caché) no devuelven un AUTHORITY SECTIONcon un registro SOA con un TTL decreciente para solicitudes posteriores, mientras que otros lo hacen.

Por ejemplo, el solucionador Cloudflare hace (tenga en cuenta la disminución del valor TTL):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Mientras que el solucionador predeterminado en una VPC de AWS responderá con una sección de autoridad solo en la primera solicitud:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Nota: Esta respuesta aborda el comportamiento de las NXDOMAINrespuestas.

Glosario:

htaccess
fuente