Limitaciones de Technitium, Pi-hole y AdGuardHome frente a la infraestructura DNS moderna: análisis y soluciones reales

1. Introducción: por qué el DNS está cambiando

El ecosistema DNS ha evolucionado rápidamente debido a tecnologías como HTTP/3, QUIC y los registros SVCB/HTTPS (RR65).
Estos nuevos mecanismos modifican la forma en que navegadores y sistemas operativos consultan la red,
incrementando la complejidad y el volumen de consultas.
La consecuencia es clara: los resolutores domésticos tradicionales ya no alcanzan.

Tal como explica Dagorret en

“Optimización de resolutores DNS en la era de HTTP/3: mitigación del impacto de consultas HTTPS/SVCB en el rendimiento de caché”,
la mayoría de los dominios aún no publica registros HTTPS/SVCB, pero los navegadores igualmente los solicitan masivamente.
Esto genera un volumen enorme de respuestas negativas (NXDOMAIN / NODATA)
que degrada la eficiencia de la caché y aumenta la carga de resolución.

En este contexto, herramientas como Technitium, AdGuardHome y Pi-hole comienzan a mostrar sus limitaciones.
Por otro lado, resolutores modernos como Unbound, Knot Resolver o PowerDNS Recursor
están diseñados para soportar la nueva infraestructura.

2. Qué son los registros SVCB/HTTPS y por qué transforman el DNS

Los registros SVCB y HTTPS (RFC 9460) permiten que el cliente obtenga información avanzada del servicio
antes de iniciar una conexión. Esto incluye soporte para HTTP/3/QUIC, parámetros ALPN, endpoints alternativos
y claves necesarias para tecnologías como ECH.

Ejemplo de consulta:

_https.ejemplo.com. IN HTTPS

Esto reduce la latencia, optimiza la negociación con servidores y mejora la seguridad.
Sin embargo, la mayoría de los dominios aún no ofrece estos registros, por lo que la mayoría de las consultas resultan en NXDOMAIN.

3. Por qué los navegadores consultan primero HTTPS/SVCB y luego A/AAAA

Los navegadores modernos siguen esta secuencia:

1. Consultar SVCB/HTTPS.
2. Si existen, usar esa información para decidir si usar HTTP/3, QUIC y otros parámetros.
3. Solo si no existe registro HTTPS, consultar A/AAAA.

Lo hacen porque:

• Reduce round-trips.
• Habilita HTTP/3 desde el primer paquete.
• Optimiza rutas y rendimiento.
• Mejora privacidad mediante compatibilidad con ECH.

Si bien este comportamiento es ideal para los usuarios, genera una nueva carga técnica para los resolutores.

4. Limitaciones técnicas de Technitium, Pi-hole y AdGuardHome

Estas soluciones son excelentes como herramientas de filtrado de publicidad y gestión simple de DNS.
Sin embargo, no fueron diseñadas para manejar cargas masivas de NXDOMAIN/NODATA provocadas por consultas
HTTPS/SVCB en redes modernas.

No incluyen:

• Límites explícitos de caché negativa (cache-max-negative-ttl).
• Aggressive NSEC/NSEC3 para sintetizar respuestas negativas.
• Prefetch avanzado basado en popularidad real.
• Serve-expired controlado.
• TTL mínimos/máximos configurables.
• Políticas específicas por tipo (HTTPS vs A/AAAA).

El resultado es una mayor latencia, desperdicio de ancho de banda, más recursiones innecesarias
y menor rendimiento general del DNS.

5. Negative caching y el problema del TTL de los TLD

Los TLD como .com o .net frecuentemente devuelven SOA con TTL de 1800 a 3600 segundos.
Los resolutores ligeros respetan ese TTL sin modificarlo, lo que causa dos problemas:

• Los cambios en registros HTTPS/SVCB no se ven hasta una hora después.
• Las consultas negativas se repiten si la caché está fría o poco optimizada.

En su análisis, Dagorret muestra ejemplos reales donde estas respuestas negativas saturan la infraestructura
y degradan la eficiencia del resolutor.

6. Por qué Unbound y resolutores avanzados sí resuelven este escenario

Resolutores como Unbound, Knot Resolver y PowerDNS Recursor están diseñados para la nueva realidad de DNS.
Incorporan:

• Límite de caché negativa configurable (cache-max-negative-ttl).
• Aggressive NSEC/NSEC3 para sintetizar NXDOMAIN sin consultar arriba.
• Prefetch inteligente basado en popularidad real.
• Serve-expired para reducir latencia bajo carga.
• TTL mínimos y máximos configurables.
• DNSSEC completo y maduro.
• QNAME minimization eficiente.

En pocas palabras: son resolutores capaces de soportar HTTP/3, QUIC y la nueva infraestructura DNS.

7. Arquitecturas recomendadas (educativas + prácticas)

7.1 Capa de filtrado (Pi-hole / Technitium / AGH) + Unbound como recursor

Clientes → Pi-hole / Technitium / AdGuardHome → Unbound → Root/TLD

Ventajas:

• Interfaz de administración cómoda.
• Filtrado centralizado.
• Recursión moderna y eficiente.

7.2 Unbound como resolutor único

Ideal para redes técnicas, servidores, homelabs e infraestructura crítica.

8. Conclusión

La transición hacia HTTP/3, QUIC y los registros SVCB/HTTPS exige resolutores DNS capaces de manejar
consultas negativas en masa, TTL flexibles y técnicas modernas de caching.
Los resolutores ligeros no fueron diseñados para esta nueva carga,
mientras que Unbound y resolutores equivalentes sí ofrecen las herramientas necesarias.

El trabajo de Dagorret muestra la importancia de actualizar la arquitectura DNS para mantener
rendimiento, estabilidad y compatibilidad con la infraestructura web moderna.