Resumen

  • La RFC 5625, escrita por Ray Bellis, asume que un proxy DNS de recursos limitados no conocerá todas las extensiones presentes y futuras. Por eso debe transportar banderas, clases y tipos desconocidos, respuestas completas, EDNS, TC, TCP y bytes sensibles a autenticación; solo los mensajes intrínsecamente malformados o una política activa explícita justifican otra conducta.
  • El documento se publicó en 2009 como BCP 152. No demuestra adopción universal ni conformidad actual, y la transparencia no valida DNSSEC. Su aportación duradera es separar competencias: las especificaciones y los extremos determinan el significado; el proxy controla un estado acotado, la exposición de sus interfaces y decisiones locales atribuibles.

La respuesta que parecía suficiente

Una aplicación consulta varios registros y espera una contestación que supera el antiguo límite de 512 bytes. El servidor responde por UDP y marca correctamente que el mensaje debe continuar por TCP. El router doméstico recorta el paquete, borra la señal de truncamiento y entrega al cliente una porción con apariencia válida. No hay alarma. Solo falta información.

El intermediario no ha detenido el DNS; ha hecho algo peor para el diagnóstico: ha ocultado el límite que él mismo introdujo.

La RFC 5625, publicada en agosto de 2009 como Best Current Practice 152, aborda precisamente a estos proxies. Ray Bellis, entonces en Nominet UK, figura como único autor. Su punto de partida no es que un pequeño gateway pueda aprender todos los detalles del DNS, sino que nunca podrá anticipar las funciones creadas después de terminar su firmware.

De ahí nace una función deliberadamente estrecha. El proxy recibe una consulta en la LAN, la remite sin alterar a un resolvedor recursivo conocido y devuelve al cliente originario la respuesta entera. Puede correlacionar clientes, seleccionar upstream, limitar interfaces y aplicar una política declarada. Lo que no puede hacer es convertir su gramática parcial en una frontera silenciosa del protocolo.

Un problema medido en 2008

El resumen ejecutivo de SAC035 y su informe completo documentan pruebas controladas realizadas en julio y agosto de 2008 sobre 24 routers residenciales o cortafuegos de oficina pequeña.

Los 24 podían encaminar consultas DNSSEC directamente hacia resolvedores externos. Veintidós ofrecían además modo proxy. Seis de esos proxies mostraron problemas con banderas vinculadas a DNSSEC o con respuestas validadas. Dieciocho restringían las respuestas UDP a 512 bytes o a un tamaño dependiente de la MTU; cuatro llegaban hasta 4096 bytes y solo uno transmitía DNS sobre TCP. Seis equipos eran plenamente compatibles en su configuración predeterminada; otros nueve permitían reconfiguración para evitar el proxy incompatible.

La fecha y el tamaño de la muestra deben acompañar siempre a esas cifras. No constituyen un censo del mercado actual, ni permiten atribuir una conducta a productos modernos. Sí muestran el mecanismo que motivó la BCP: dos extremos compatibles pueden quedar separados por un dispositivo que no reconoce el cambio.

La reseña de aprobación del IETF señala un consenso fuerte en el grupo DNS Extensions y el interés de proveedores y compradores. Es evidencia del proceso y de una necesidad percibida, no telemetría de despliegue.

Preservar sin interpretar

La separación decisiva de RFC 5625 es entre desconocido y malformado. Una bandera de cabecera que el proxy no conoce no es, por ello, inválida. Debe ignorarla para sus propias decisiones y reenviar el mensaje. Lo mismo vale para formas de etiquetas, QTYPE, QCLASS y valores TYPE o CLASS de los registros.

Una implementación antigua puede haber aprendido que cierto bit reservado debía ser cero. Cuando una especificación posterior le asigna significado, conservar la regla anterior equivale a delegar la evolución de DNS en todos los firmwares intermedios instalados. El cliente y el resolvedor podrían estar de acuerdo, pero nunca llegarían a comunicarse.

La RFC 3597 expresa la regla de extensibilidad para tipos de registro desconocidos. El RDATA se trata como binario no estructurado, se almacena y se transmite sin cambios. Preservar no significa afirmar que se entiende; significa no destruir la información antes de que alcance a quien sí la entiende.

Un puntero de compresión imposible o un recuento de secciones incompatible con el paquete es diferente. Esos mensajes pueden rechazarse. Aun así, RFC 5625 recomienda, cuando resulta seguro, responder SERVFAIL en vez de callar. La respuesta permite que el cliente termine el intento y deja una prueba del punto de rechazo.

Una política activa de seguridad o red también puede bloquear o modificar. La autoridad existe, pero debe ser explícita y atribuible. Una limitación casual del parser no adquiere legitimidad por producir el mismo resultado que una política.

TC, TCP y EDNS conservan la historia completa

El indicador TC no es un detalle de presentación. Dice al cliente que la respuesta UDP quedó truncada y que debe intentar TCP. Un proxy que elimina TC impide la recuperación. Uno que trunca sin añadirlo convierte una ausencia en éxito aparente.

RFC 5625 rechaza el recorte automático por superar 512 bytes. Si un límite local obliga a truncar, el proxy debe marcar TC y nunca borrar el recibido desde upstream. La diferencia operativa es clara: un límite comunicado puede corregirse; un límite invisible se parece a un dato auténtico.

El proxy debe aceptar y reenviar DNS sobre TCP. Si la consulta llega por TCP, debe continuar por TCP hacia el resolvedor, sin rebajarla primero a UDP. La RFC 7766, que Bellis escribió después con otros cuatro autores, convirtió el soporte TCP en requisito para implementaciones DNS. Esa continuidad normativa no es una prueba de cumplimiento universal.

EDNS hace visible la extensión mediante el registro OPT. RFC 5625 indica que su presencia no debe causar rechazo. La RFC 6891 añade que un middlebox conforme no debe imponer el límite UDP de 512 bytes, y que un reenviador simple no debe modificar ni eliminar el contenido OPT en ninguna dirección. La recomendación de soportar 4096 bytes en 2009 refleja aquella época, no fija un máximo permanente.

El control que sí corresponde al proxy

Ser transparente no equivale a ser pasivo. El equipo guarda la relación entre consulta y cliente, decide cuánto dura, elige o aprende un resolvedor y puede cambiar el Query ID de salida. También decide en qué interfaces escucha y qué dirección entrega DHCP.

RFC 5625 remite a la RFC 5452 para reforzar la resistencia a respuestas falsificadas mediante identificadores y puertos de origen aleatorios. Esta aleatorización reduce exposición, pero no autentica una respuesta ni sustituye DNSSEC.

TSIG muestra dónde termina la libertad de reescritura. Cambiar las partes autenticadas del mensaje, excepto el tratamiento permitido del identificador, rompe la verificación. O se preserva el paquete, o se implementa por completo el mecanismo de autenticación. Una corrección parcial es corrupción observable.

El alcance de interfaz también importa. Un proxy concebido para la LAN no debería responder por defecto desde la WAN, donde puede servir de superficie de reflexión. La RFC 5358 aporta el contexto de ataques mediante servidores recursivos abiertos. Transparencia ante usuarios autorizados no significa exposición pública.

Por último está la salida. Salvo que una política explícita lo impida, los clientes deberían poder utilizar resolvedores específicos y evitar el proxy. La intercepción obligatoria de toda alternativa otorga al gateway una capacidad semántica que el diseño transparente intentaba limitar.

Una prueba centrada en lo que la máquina ignora

El perfil de Ray Bellis en el IETF enumera diez RFC, entre ellas la 5625. La página del equipo de ISC lo identifica actualmente como Director of DNS Operations. La trayectoria importa porque el texto evalúa la operación real, no la cantidad de funciones anunciadas.

La prueba correcta introduce lo inesperado. ¿Pasa una bandera nueva? ¿Sobrevive un tipo de registro desconocido? ¿Llegan completos TC y OPT? ¿Una consulta TCP continúa como TCP? ¿El operador puede distinguir un bloqueo deliberado de la ignorancia del firmware?

La posterior RFC 8906, de Mark Andrews y Ray Bellis, formula casos explícitos con campos, tipos, versiones, opciones y banderas EDNS inesperados, además de truncamiento y TCP. Transforma la ausencia ambigua en resultados que se pueden comparar.

RFC 5625 no atribuye a la transparencia validación, privacidad o disponibilidad. Tampoco elimina la selección de upstream ni la política local. Su límite es más preciso: estar en medio no concede derecho a definir lo desconocido. El proxy custodia el trayecto; el significado sigue perteneciendo al protocolo y a sus extremos.

Fuentes