Timeout y retransmisión DNS en PCAP: resolver consultas lentas

---

Las fallas de DNS a menudo se hacen pasar por fallas de aplicaciones. Un navegador dice que no se puede acceder a un sitio. Un cliente API muestra un tiempo de espera. Un servicio tarda cinco segundos antes de abrir una conexión. Los usuarios buscan "pcap de tiempo de espera de DNS", "Retransmisión de DNS Wireshark", "consulta de DNS sin respuesta", "captura de paquetes de resolución DNS lenta" y "SERVFAIL vs tiempo de espera" porque el error visible rara vez explica si la resolución de nombres falló, el solucionador fue lento o la red perdió paquetes.

Una captura de paquetes puede responder a esto precisamente si mantiene intactos el comportamiento de consulta, respuesta, sincronización, retransmisión y respaldo de DNS.

La cirugía PCAP es útil porque la evidencia DNS a menudo está enterrada dentro de un rastro grande. Es posible que necesite aislar un cliente, un solucionador, un dominio y una ventana de tiempo mientras conserva las marcas de tiempo y los ID de solicitud.

Cómo se ve un intercambio de DNS saludable

Un intercambio básico de DNS UDP es breve:

Client -> Resolver: Query A example.com
Resolver -> Client: Response A example.com 93.184.216.34

The important fields are:

• Query name
• Query type
• Transaction ID
• Source and destination port
• Resolver address
• Response code
• Answer records
• Timing between query and response

If the response comes back quickly with NOERROR, DNS probably is not the delay source. If there is no response, delayed response, repeated query, or error response, DNS becomes part of the diagnosis.

DNS timeout vs DNS error

A timeout means the client did not receive a usable response before its resolver logic gave up or retried. A DNS error means the resolver returned a response with an error code such as:

• NXDOMAIN: domain does not exist.
• SERVFAIL: resolver failed to complete resolution.
• REFUSED: resolver refused the query.
• FORMERR: format error.

These are different failures. A timeout points to packet loss, resolver unavailability, firewall, routing, or delayed response. SERVFAIL points to resolver recursion, DNSSEC, upstream server, or authoritative lookup problems. NXDOMAIN may be a real name problem or a search-domain/configuration issue.

Retransmission and retry behavior

DNS over UDP does not have transport-level retransmission like TCP. If a client does not receive a response, it sends another query. The retry may go to the same resolver or a different resolver.

A trace may show:

0.000 Client -> 8.8.8.8 Query example.com
1.000 Client -> 8.8.8.8 Query example.com
2.000 Client -> 1.1.1.1 Query example.com
2.030 1.1.1.1 -> Client Response example.com

Esto sugiere que el primer solucionador no respondió a tiempo, mientras que el segundo sí. El retraso de la aplicación incluye el tiempo transcurrido esperando al primer solucionador.

Consulta perdida versus respuesta perdida

Con un punto de captura, es posible que no sepa si se perdió la consulta o la respuesta. La ubicación de la captura importa.

Si realiza una captura en el cliente y ve que la consulta sale pero no llega ninguna respuesta, es posible que la respuesta se haya perdido, se haya bloqueado, se haya retrasado o nunca se haya generado. Si captura en el solucionador y nunca ve la consulta, la consulta se perdió antes de llegar al solucionador o se bloqueó en la ruta. Si el solucionador ve y responde la consulta pero el cliente nunca ve la respuesta, la pérdida está en el camino de regreso.

Dos capturas son más fuertes:

• Captura del lado del cliente
• Captura del lado del resolver

Juntos pueden probar si el paquete desapareció antes del solucionador, después del solucionador o dentro del host del cliente.

Fragmentación UDP y grandes respuestas DNS

Las respuestas DNS pueden volverse grandes debido a DNSSEC, muchos registros, registros TXT o tamaños de búfer EDNS0. Las respuestas UDP grandes pueden fragmentarse. La fragmentación puede fallar en firewalls o dispositivos NAT.

Los síntomas incluyen:

• Las pequeñas consultas de DNS funcionan.
• Las respuestas grandes expiran.
• Los dominios DNSSEC fallan con más frecuencia.
• El respaldo de TCP se realizó correctamente.
• Las respuestas con un bit de truncamiento provocan un reintento a través de TCP.

Si un solucionador establece el bit truncado, el cliente puede volver a intentarlo a través de TCP. Eso es normal. Si se bloquea el respaldo de TCP, el usuario puede ver tiempos de espera de DNS o fallas intermitentes.

DNS sobre TCP, DoT y DoH

El DNS clásico usa UDP y el puerto TCP 53. Los entornos modernos pueden usar DNS sobre TLS o DNS sobre HTTPS. Es posible que una captura de paquetes normal no exponga los nombres de dominio para DNS cifrado, pero aún puede mostrar tiempos, conexiones, reintentos y accesibilidad del servidor.

Al analizar el retraso de la aplicación, primero determine qué ruta de resolución se utiliza. Un navegador puede usar DoH mientras que las herramientas del sistema usan el solucionador del sistema operativo. Eso puede explicar por qué nslookup funciona pero el navegador falla, o por qué una aplicación es lenta y otra no.

Buscar dominios y consultas repetidas

Los entornos empresariales y VPN suelen añadir dominios de búsqueda. Una simple búsqueda de "servicio" puede generar consultas como:

service.corp.example.com
service.office.example.com
service

If several of those time out before the final name works, the user experiences delay. The final response may be correct, but the lookup path was slow.

A good DNS trace preserves the full query sequence, not only the final successful answer.

Checklist for DNS PCAP analysis

Use this process:

1. Identify the client, resolver, and queried name.
2. Filter by DNS transaction ID and query name.
3. Measure query-to-response latency.
4. Check response code: NOERROR, NXDOMAIN, SERVFAIL, REFUSED, or no response.
5. Look for repeated queries and resolver failover.
6. Check whether UDP responses are large or fragmented.
7. Look for TCP fallback after truncation.
8. Compare system resolver behavior with application-specific DoH or DoT.
9. Preserve timestamps before trimming the capture.
10. Correlate DNS delay with application connection timing.

Final diagnosis

DNS timeout analysis is not just "the domain failed." The packet evidence can show whether the resolver was slow, the query was lost, the response was lost, the response was an error, fallback happened, search domains added delay, or encrypted DNS used a different path.

PCAP Surgery supports the investigation by letting you isolate the DNS evidence while preserving the timing and packet sequence that explain the real user-visible delay.

<!-- pcap-localized-evidence-foundation-v1:start -->

Respuesta basada en paquetes para «Timeout y retransmisión DNS en PCAP: resolver consultas lentas»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «Timeout y retransmisión DNS en PCAP: resolver consultas lentas», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

<!-- pcap-localized-evidence-foundation-v1:end -->