☰

¿Por qué la vinculación es más lenta que los proveedores de DNS públicos?

tag-icon • tag-icon bind
¿Por qué la vinculación es más lenta que los proveedores de DNS públicos?

Hemos enlazado 9.8.1.dfsg.P1-4ubuntu0.13 en ubuntu 12.04, que se ejecuta en un servidor no muy cargado (promedio de carga: 0,19, 0,12, 0,13) y atiende solicitudes para redes de oficinas pequeñas con estaciones de trabajo macos y ubuntu.

Ejecuté algunas pruebas de DNS en un script en un contenedor que se ejecuta como servidor DNS y envié los resultados a influxdb.

#!/bin/bash
while true
do
        rndc flush

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=yes value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=yes value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=yes value=$yandex_timeout" &
        wait

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=no value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=no value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=no value=$yandex_timeout" &
        wait

        sleep 5
done

Descubrí que bind responde a las solicitudes más lentamente que8.8.8.8y77.88.8.8. Esto se puede ver en los gráficos:

Vaciar la caché antes de la primera serie de solicitudes con rndc flush. Enlazar usa google8.8.8.8y8.8.4.4como transportistas:

ingrese la descripción de la imagen aquí

Nunca vacíe el caché del enlace en ejecución. Enlazar usa google8.8.8.8y8.8.4.4como transportistas:

ingrese la descripción de la imagen aquí

Vaciar la caché antes de la primera serie de solicitudes con rndc flush. Bind utiliza una lista actualizada de servidores raíz como reenviadores:

ingrese la descripción de la imagen aquí

Nunca vacíe el caché del enlace en ejecución. Bind utiliza una lista actualizada de servidores raíz como reenviadores:

ingrese la descripción de la imagen aquí

¿Por qué el tiempo máximo de consulta (aproximadamente 5k en el primer gráfico y 2,5k en el tercer gráfico) con el dns público de Google es mayor que el de los servidores raíz?

¿Por qué la consulta a través de bind es más lenta que la consulta directa a servidores DNS públicos?

¿Puede haber algún problema en mis pruebas?

ACTUALIZACIÓN 1

Hay 20 segundos TTL en los gráficos; está mal. El TTL para redhat.com es de 60 segundos.

Respuesta1

Sus pruebas miden el tiempo total para realizar su consulta, incluyendo

  • Retraso de red desde y hacia la máquina que ejecuta su script de prueba.
  • tiempo de procesamiento en el servidor de nombres bajo prueba
  • tiempo que el servidor de nombres bajo prueba pasa esperando respuestas de otros servidores de nombres, es decir. tiempo para realizar cualquier subconsulta recursiva

Los resultados son más o menos los esperados.

  • Si consulta su servidor BIND local sin vaciar el caché, la respuesta provendrá del caché la mayor parte del tiempo. Incluso si el TTL para el A RR ha expirado, el NS RR seguirá en la memoria caché, por lo que solo el A RR debe solicitarse externamente.
  • Si consulta su servidor BIND local después de vaciar el caché y tienenoreenviadores configurados, su servidor BIND local realizará una consulta recursiva comenzando desde un servidor raíz hacia abajo.
  • Si consulta su servidor BIND local después de vaciar el caché y ha configurado los servidores de Google como reenviadores, su servidor BIND local reenviará la consulta tal cual a uno de los servidores de Google, que a su vez responderá la consulta desde su caché o realizar una consulta recursiva. Tenga en cuenta que no tiene control sobre el caché de los servidores de Google.

En consecuencia, las consultas a su servidor BIND local sin borrar primero el caché son más rápidas y no se ven afectadas por la configuración del reenviador. Las consultas a su servidor BIND local después de borrar el caché y con los servidores de Google configurados como reenviadores son más lentas que las consultas directas a los servidores de Google porque agregan a estos últimos la sobrecarga de pasar primero por su servidor BIND local.

información relacionada