Resolver el nombre de host tarda 5 segundos

Question 1

Respuesta corta:

Una solución alternativa es obligar glibca reutilizar un socket para buscar registros AAAAy Aagregando una línea a /etc/resolv.conf:

options single-request-reopen

La verdadera causa de este problema podría ser:

firewall o enrutador mal configurado (por ejemplo, unLa configuración del firewall de Juniper se describe aquí) lo que provoca la caída AAAAde paquetes DNS
error en el servidor DNS

Respuesta larga:

Programas como curlo wgetusan la función de glibcobteneraddrinfo(), que intenta ser compatible tanto con IPv4 como con IPv6 buscando ambos registros DNS en paralelo. No devuelve resultado hasta que se reciben ambos registros (hayvarios problemas relacionados con tal comportamiento) - esto explica lo straceanterior. Cuando se fuerza IPv4, como curl -4internamente gethostbyname(), que consulta Asolo para registros.

De tcpdumppodemos ver que:

-> A?Se envían dos solicitudes al principio.
-> AAAA?(solicitando dirección IPv6)
<- AAAAresponder
-> A?solicitando nuevamente la dirección IPv4
<- Aobtuve respuesta
-> AAAA?solicitando IPv6 nuevamente
<- AAAAresponder

Una Arespuesta se descarta por algún motivo; ese es este mensaje de error:

error sending response: host unreachable

Sin embargo, no me queda claro por qué es necesaria una segunda AAAAconsulta.

Para verificar que tienes el mismo problema, puedes actualizar el tiempo de espera en /etc/resolv.conf:

options timeout:3

Primero cree un archivo de texto conconfiguración de informes de tiempo personalizados:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

luego envía una solicitud:

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

Hay otras dos opciones relacionadas en man resolv.conf:

solicitud única (desde glibc 2.10)se establece RES_SNGLKUP en _res.options. De forma predeterminada, glibc realiza búsquedas de IPv4 e IPv6 en paralelo desde la versión 2.9. Algunos servidores DNS de dispositivos no pueden manejar estas consultas correctamente y hacen que las solicitudes expiren. Esta opción desactiva el comportamiento y hace que glibc realice las solicitudes de IPv6 e IPv4 de forma secuencial (a costa de cierta ralentización del proceso de resolución).

reapertura de solicitud única (desde glibc 2.9) El solucionador utiliza el mismo socket para las solicitudes A y AAAA. Algunos hardware envían por error sólo una respuesta. Cuando eso suceda, el sistema cliente se sentará y esperará la segunda respuesta. Activar esta opción cambia este comportamiento de modo que si dos solicitudes del mismo puerto no se manejan correctamente, se cerrará el socket y se abrirá uno nuevo antes de enviar la segunda solicitud.

Asuntos relacionados:

Answer

Respuesta corta:

Una solución alternativa es obligar glibca reutilizar un socket para buscar registros AAAAy Aagregando una línea a /etc/resolv.conf:

options single-request-reopen

La verdadera causa de este problema podría ser:

firewall o enrutador mal configurado (por ejemplo, unLa configuración del firewall de Juniper se describe aquí) lo que provoca la caída AAAAde paquetes DNS
error en el servidor DNS

Respuesta larga:

Programas como curlo wgetusan la función de glibcobteneraddrinfo(), que intenta ser compatible tanto con IPv4 como con IPv6 buscando ambos registros DNS en paralelo. No devuelve resultado hasta que se reciben ambos registros (hayvarios problemas relacionados con tal comportamiento) - esto explica lo straceanterior. Cuando se fuerza IPv4, como curl -4internamente gethostbyname(), que consulta Asolo para registros.

De tcpdumppodemos ver que:

-> A?Se envían dos solicitudes al principio.
-> AAAA?(solicitando dirección IPv6)
<- AAAAresponder
-> A?solicitando nuevamente la dirección IPv4
<- Aobtuve respuesta
-> AAAA?solicitando IPv6 nuevamente
<- AAAAresponder

Una Arespuesta se descarta por algún motivo; ese es este mensaje de error:

error sending response: host unreachable

Sin embargo, no me queda claro por qué es necesaria una segunda AAAAconsulta.

Para verificar que tienes el mismo problema, puedes actualizar el tiempo de espera en /etc/resolv.conf:

options timeout:3

Primero cree un archivo de texto conconfiguración de informes de tiempo personalizados:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

luego envía una solicitud:

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

Hay otras dos opciones relacionadas en man resolv.conf:

solicitud única (desde glibc 2.10)se establece RES_SNGLKUP en _res.options. De forma predeterminada, glibc realiza búsquedas de IPv4 e IPv6 en paralelo desde la versión 2.9. Algunos servidores DNS de dispositivos no pueden manejar estas consultas correctamente y hacen que las solicitudes expiren. Esta opción desactiva el comportamiento y hace que glibc realice las solicitudes de IPv6 e IPv4 de forma secuencial (a costa de cierta ralentización del proceso de resolución).

reapertura de solicitud única (desde glibc 2.9) El solucionador utiliza el mismo socket para las solicitudes A y AAAA. Algunos hardware envían por error sólo una respuesta. Cuando eso suceda, el sistema cliente se sentará y esperará la segunda respuesta. Activar esta opción cambia este comportamiento de modo que si dos solicitudes del mismo puerto no se manejan correctamente, se cerrará el socket y se abrirá uno nuevo antes de enviar la segunda solicitud.

Asuntos relacionados:

Question 2

Como dice @Tombart, el retraso se debe a la espera del tiempo de espera de resolución de IPv6.

Otro posible curso de acción es dar prioridad a IPv4 en /etc/gai.conf

De comentarios en /etc/gai.conf

#   For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

Después de cambiar gai.conf, debe reiniciar cualquier aplicación que utilice la biblioteca de resolución de DNS para que el cambio surta efecto.

Tenga en cuenta que si está utilizando un servidor BIND sin conectividad IPv6, le recomiendo deshabilitar IPv6 namedy tomar de la raíz las direcciones IPv6. Obviamente seguirá intentando resolver las direcciones AAAA.

Entonces, para la configuración BIND,

En /etc/default/bind9, agregue -4 para direcciones IPv4:

OPTIONS="-4 -u bind"

y en /etc/bind/db.root, elimine todas las líneas con raíces DNS AAAA.

Answer

Como dice @Tombart, el retraso se debe a la espera del tiempo de espera de resolución de IPv6.

Otro posible curso de acción es dar prioridad a IPv4 en /etc/gai.conf

De comentarios en /etc/gai.conf

#   For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

Después de cambiar gai.conf, debe reiniciar cualquier aplicación que utilice la biblioteca de resolución de DNS para que el cambio surta efecto.

Tenga en cuenta que si está utilizando un servidor BIND sin conectividad IPv6, le recomiendo deshabilitar IPv6 namedy tomar de la raíz las direcciones IPv6. Obviamente seguirá intentando resolver las direcciones AAAA.

Entonces, para la configuración BIND,

En /etc/default/bind9, agregue -4 para direcciones IPv4:

OPTIONS="-4 -u bind"

y en /etc/bind/db.root, elimine todas las líneas con raíces DNS AAAA.

Question 3

Tuve un problema similar al usar BIND9. Para solucionar esto necesitaba agregar:

filter-aaaa-on-v4 yes;

opción a mi named.conf.

(Más información)

Answer

Tuve un problema similar al usar BIND9. Para solucionar esto necesitaba agregar:

filter-aaaa-on-v4 yes;

opción a mi named.conf.

(Más información)

Question 4

En caso de que alguien esté buscando el archivo curl-format.txt. Pega esto en tu shell y creará el archivo de formato por ti. El enlace original no funcionó para mí. encontré este ejemploaquí

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

Answer

En caso de que alguien esté buscando el archivo curl-format.txt. Pega esto en tu shell y creará el archivo de formato por ti. El enlace original no funcionó para mí. encontré este ejemploaquí

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

Resolver el nombre de host tarda 5 segundos

Respuesta1

Respuesta2

Respuesta3

Respuesta4

información relacionada