Resumen

  • El perfil de Ray Bellis en IETF Datatracker mostraba diez RFC el 5 de agosto de 2026, incluido el RFC 10029 publicado en julio. En esa consulta no figuraban Internet-Drafts activos. Es un índice de documentos y autores, no una medida de despliegue ni una atribución exclusiva. [1]
  • RFC 5966, firmado por Bellis en 2010, quedó obsoleto cuando cinco autores publicaron RFC 7766 en 2016. El texto nuevo exige TCP en una implementación DNS completa de propósito general y permite usarlo como transporte normal, no solo como último intento después de UDP. [3] [4]
  • RFC 7828 y RFC 8490 hacen explícitas decisiones asociadas a conexiones persistentes: tiempo ocioso, establecimiento de sesión, éxito, rechazo, espera agotada y cierre. El servidor conserva el control de sus recursos y el cliente recibe más información para reaccionar. [5] [6]
  • RFC 8906 describe la falta de respuesta como un problema operativo. Para el cliente, pérdida, filtrado, incompatibilidad y control de carga pueden parecer el mismo silencio. En condiciones ordinarias, una respuesta de protocolo permite distinguirlos mejor. [7]
  • RFC 9619 aclaró que una consulta normal tiene una pregunta principal. RFC 10029 añadió una opción EDNS para pedir tipos adicionales, comunicar cuáles se completaron y recuperar el resto mediante consultas separadas. Su publicación reciente como Proposed Standard —un estándar propuesto de IETF— no prueba que ya sea común. [8] [9]

Una consulta breve atraviesa muchas responsabilidades

DNS es el Sistema de Nombres de Dominio. Su tarea visible consiste en relacionar un nombre con información que una aplicación puede utilizar. Una consulta puede pedir un registro A, que contiene una dirección IPv4, un registro AAAA para IPv6, o datos como HTTPS que ayudan a preparar la conexión con un servicio.

El programa normalmente entrega la pregunta a un resolutor. Ese componente busca la respuesta, a menudo mediante un servidor recursivo que sigue delegaciones hasta llegar a los servidores autoritativos. «Autoritativo» significa que el servidor publica la información oficial de una zona concreta; no significa que gobierne el resto del DNS. Las cachés evitan repetir pasos cuando todavía conservan una respuesta válida.

Entre el cliente y el servidor pueden aparecer un proxy doméstico, un cortafuegos, un traductor de direcciones, un balanceador o varias redes independientes. Cada elemento tiene software, capacidad y política propios. El operador del dominio mantiene su delegación. El operador recursivo define reintentos. El fabricante decide cómo implementa el protocolo. La aplicación decide cuánto puede esperar una persona.

Esa separación es una fortaleza cuando los mensajes conservan significado. Una respuesta negativa dice que la pregunta fue entendida, aunque el dato no exista. Un código de «no implementado» identifica una operación desconocida. Una marca de truncamiento indica que el mensaje no contiene todo y que conviene usar otro transporte.

El silencio no contiene ninguna de esas pistas. El resolutor debe elegir entre esperar, repetir, cambiar de servidor, retirar una extensión o probar otra forma de transporte. El conjunto puede terminar en éxito, pero después de gastar buena parte del tiempo que la aplicación concede a la conexión.

Los documentos relacionados con Bellis no intentan que una entidad central tome esas decisiones por todos. Especifican respuestas, estados y alternativas que sistemas separados pueden reconocer. La coordinación funciona como un registro común de comportamiento; la capacidad, el filtrado y las prioridades siguen siendo decisiones locales.

El paso de TCP de excepción a requisito

DNS suele explicarse con dos transportes. UDP envía mensajes sin crear una conexión persistente y resulta eficiente para intercambios pequeños. TCP establece una conexión, mantiene estado y puede transportar respuestas mayores de forma fiable. También consume sockets, memoria y tiempo de gestión en ambos extremos.

Durante años se resumió la práctica diciendo que DNS usa UDP y recurre a TCP para transferencias de zona o respuestas que no caben. La frase ayuda a empezar, pero puede hacer creer que TCP es prescindible. Las respuestas firmadas mediante DNSSEC, el mecanismo que permite validar datos del DNS, el aumento de tamaño y los problemas de fragmentación volvieron peligroso dejar esa ruta sin probar.

RFC 5966 se publicó en agosto de 2010 con R. Bellis como autor y estableció requisitos para DNS sobre TCP. [3] No es hoy el texto final. En marzo de 2016, John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin y Duane Wessels publicaron RFC 7766, que lo dejó obsoleto. [4]

RFC 7766 exige que una implementación DNS completa de propósito general soporte UDP y TCP. Permite que un resolutor elija TCP por razones operativas sin esperar a un fallo previo de UDP, y recomienda reutilizar una conexión adecuada que ya esté abierta. [4]

Para una empresa, el efecto puede verse lejos del servidor DNS. Un cortafuegos que acepta UDP en el puerto 53 pero descarta TCP sin responder puede convertir una respuesta grande en una espera. El nombre, la zona y la ruta pueden estar bien. El usuario solo ve que el servicio tarda o falla.

La publicación del requisito no certifica a ningún producto. Da un comportamiento que puede comprobarse: enviar la misma pregunta por ambos transportes, observar si se establece la conexión, si se devuelve la respuesta completa, si se reutiliza la sesión y si un fallo produce un rechazo visible o un tiempo agotado.

El relevo entre RFC 5966 y RFC 7766 también muestra cómo funciona la continuidad documental. El trabajo inicial no se borra, pero deja de ser la referencia vigente. Un grupo más amplio toma el problema y cambia las obligaciones. Bellis figura en ambas etapas sin convertirse por ello en propietario del transporte o de las decisiones de los operadores.

El proxy puede conservar la forma y perder la intención

Un proxy DNS recibe consultas en una dirección cercana y las envía a otro resolutor. Es habitual en routers domésticos y redes locales. El cliente puede pensar que habla directamente con un servicio DNS, aunque un programa intermedio esté copiando, limitando o modificando mensajes.

RFC 5625, publicado en 2009 con Bellis como autor, reúne pautas de implementación para proxies DNS. [2] No afirma que todos los dispositivos las sigan. Su valor está en señalar que ese intermediario debe tratar correctamente tamaños, indicadores, códigos de respuesta, extensiones y TCP.

Un proxy puede responder bien a una prueba sencilla y fallar cuando aparece una respuesta grande, un tipo desconocido o EDNS. EDNS es una extensión del DNS que permite anunciar capacidades y transportar opciones adicionales sin reemplazar la pregunta principal. Si el proxy elimina una opción que no entiende o se queda callado ante un error válido, el resolutor puede diagnosticar mal al servidor autoritativo.

Por eso una prueba de compatibilidad no debería limitarse a cambiar el nombre consultado. Conviene comparar UDP y TCP, DNS ordinario y EDNS, tipos conocidos y desconocidos, respuestas pequeñas y truncadas. Una función no soportada puede ser aceptable durante una transición si se comunica. La desaparición de la evidencia no lo es.

La fuente acredita a Bellis como autor de orientación pública, no como fabricante de cada proxy. Tampoco ofrece estadísticas de cumplimiento. La realidad solo aparece cuando el equipo concreto se prueba dentro del camino real.

Mantener una conexión abierta es una negociación de capacidad

Reutilizar TCP reduce el coste de abrir una conexión por consulta. A cambio, el servidor conserva información sobre clientes y peticiones. Si el tiempo ocioso es demasiado corto, la reutilización desaparece. Si es ilimitado, una carga grande o un ataque puede agotar recursos.

RFC 7828, escrito por Paul Wouters, Joe Abley, Sara Dickinson y Ray Bellis, define la opción edns-tcp-keepalive. [5] El cliente expresa interés en conservar la conexión y el servidor anuncia un tiempo ocioso acorde con su situación. Si necesita que el cliente cierre, puede indicar cero después del trabajo pendiente.

El cero es información, no necesariamente una avería. Dice que el servidor no ofrece una espera adicional en ese momento. Un cliente puede actuar de manera distinta ante esa señal que ante un cierre inesperado. El operador puede contar ambos eventos por separado.

El estándar no fija un único valor para todo Internet. Una instancia pequeña, un gran resolutor y un servicio bajo ataque tienen límites distintos. La regla compartida describe el campo y su interpretación; la decisión de capacidad queda donde están los recursos.

El documento también señala que una conexión larga hacia una dirección anycast puede romperse si cambia el camino. En anycast, varios lugares anuncian la misma dirección y el enrutamiento selecciona uno. Si la ruta cambia, una conexión existente puede dejar de llegar al mismo servidor. Los dispositivos intermedios también pueden interferir con EDNS o con determinados tamaños. [5]

Por tanto, «conexión abierta» no es una medida suficiente. El operador necesita saber cuánto tardó en abrirse, cuántas consultas se reutilizaron, quién cerró, qué valor se anunció, cuántas peticiones quedaron pendientes y si hay diferencias entre ubicaciones.

DSO separa conexión, sesión y cierre

Una conexión TCP puede existir sin que ambas partes hayan acordado operaciones adicionales con estado. RFC 8490 define DNS Stateful Operations, o DSO, para organizar esas funciones en sesiones persistentes. [6]

El documento tiene seis autores, incluido Bellis. Describe el establecimiento de sesión, operaciones de mantenimiento, retraso antes de reintentar, relleno para privacidad, respuestas de éxito o error y cierre. También permite ciertos mensajes iniciados por el servidor una vez establecida la sesión.

La distinción ayuda a evitar un diagnóstico común: pensar que una conexión abierta equivale a una sesión funcional. El cliente puede estar conectado pero todavía negociando DSO. La petición puede ser rechazada con un código, puede superar el tiempo de espera o puede aceptarse. Son estados distintos.

Un timeout, o tiempo de espera agotado, significa que el sistema dejó de esperar al alcanzar un límite. No revela por sí mismo por qué faltó la respuesta. En el establecimiento de DSO, sin embargo, identifica el punto de la secuencia y conduce al cierre; en determinadas circunstancias el cliente puede volver a conectarse sin usar DSO. [6]

Si el servidor responde con un código de error, el DNS ordinario puede continuar sobre la conexión sin una sesión DSO activa. Ese resultado es más específico que «el DNS se desconectó». Puede registrarse, compararse por versión y relacionarse con un cambio de configuración.

Nada de esto demuestra despliegue masivo ni éxito operativo. La especificación aporta una máquina de estados compartida. El servidor todavía puede quedarse sin capacidad, la red puede perderse y un intermediario puede interferir. La ventaja es que más etapas tienen nombre.

Cuando no llega nada, demasiadas causas parecen iguales

RFC 8906, de Mark Andrews y Ray Bellis, se publicó en septiembre de 2020 con un título directo: un problema operativo común en servidores DNS, la falta de comunicación. [7]

Una solicitud bien formada puede quedarse sin respuesta por pérdida de paquete, filtrado de una opción, limitación de tasa, un código desconocido mal manejado o un fallo de implementación. El resolutor no ve la intención del servidor. Solo ve que el reloj avanza.

El documento sostiene que, fuera de situaciones de ataque, los servidores de nombres deberían responder a consultas bien formadas. Enumera respuestas esperadas para tipos, indicadores y códigos de operación desconocidos, así como para TCP. También reconoce que, durante un ataque, soltar tráfico o limitar respuestas puede ser necesario. [7]

Esa excepción es importante. La coordinación no obliga al servidor a ignorar su propia seguridad. El problema aparece cuando la ausencia de respuesta se convierte en sustituto rutinario de un error de protocolo. Entonces un cliente legítimo no puede distinguir protección de avería.

La consecuencia alcanza a EDNS y DNSSEC. Si el resolutor interpreta el silencio como falta de soporte de EDNS, puede repetir sin la extensión. A veces obtendrá una respuesta final, pero quizá pierda funciones necesarias para validar firmas o usar nuevas opciones. La compatibilidad se conserva a costa de ocultar el punto roto.

El documento también mira las delegaciones. Los registros NS de la zona superior dicen qué servidores atienden la zona delegada. RFC 8906 recomienda comprobar que esa lista sea coherente con los NS publicados dentro de la propia zona. [7] Una delegación antigua puede llevar consultas a un servidor que ya no tiene responsabilidad.

El beneficio de una respuesta explícita es práctico. Un error de formato, un «no implementado», una respuesta negativa normal o un rechazo limpio de TCP reducen el árbol de decisiones. Ninguno garantiza que el usuario obtenga el dato deseado, pero todos dicen más que el silencio.

Una pregunta sigue siendo el centro de una solicitud combinada

El mensaje DNS incluye QDCOUNT, un campo que cuenta preguntas. Aunque el formato histórico parecía permitir varias, los programas no establecieron una interpretación interoperable y general. RFC 9619, escrito por Ray Bellis y Joe Abley y publicado en 2024, aclaró que una consulta DNS normal suele contener una pregunta. [8]

Las aplicaciones actuales pueden necesitar varios tipos para el mismo nombre. Al iniciar una conexión, pedir A, AAAA y HTTPS por separado añade intercambios. Reunirlos puede ahorrar tiempo, siempre que el servidor y el cliente sepan qué se completó.

RFC 10029, escrito por Bellis y publicado en julio de 2026 como Proposed Standard, define DNS Multiple QTYPEs. [9] Mantiene una pregunta principal y usa una opción EDNS para enumerar tipos adicionales. La respuesta contiene una opción que marca cuáles fueron procesados completamente.

La regla incluye las respuestas truncadas. Ante una solicitud válida, un servidor conforme devuelve la opción incluso si el mensaje general no contiene todo. Si un tipo no pudo completarse, no debe aparecer como terminado. El cliente envía después una consulta individual para lo que todavía necesita.

Ese paso individual es el fallback, la alternativa compatible con servidores antiguos o límites locales. Si el servidor no entiende la extensión, el cliente puede conservar la respuesta a la pregunta principal y seguir con consultas normales. La novedad no exige romper el camino anterior.

La combinación puede aumentar trabajo y tamaño de respuesta. Eso importa porque el DNS puede usarse para amplificación cuando un atacante falsifica la dirección de origen. El RFC pide límites configurables, adecuados al entorno. [9] Un servicio puede permitir menos tipos que otro sin violar el principio de control local.

La fecha reciente obliga a la cautela. El documento define una conducta propuesta y verificable; no proporciona cifras de adopción. Los datos importantes ahora serán el soporte real, la frecuencia de consultas separadas, los tipos omitidos por tamaño y la carga adicional.

El historial público muestra relevo, no propiedad

Datatracker atribuía diez RFC a Bellis en la fecha consultada. [1] Ese recuento pertenece al índice oficial y debe mantenerse dentro de su contexto. No es una lista completa de su carrera ni una evaluación de impacto.

La autoría cambia entre documentos. RFC 5625 y RFC 5966 nombran a Bellis como autor. RFC 7766, RFC 7828, RFC 8490, RFC 8906 y RFC 9619 son colectivos. RFC 10029 vuelve a nombrarlo como autor, pero sigue siendo una especificación resultante del proceso IETF. [2] [3] [4] [5] [6] [7] [8] [9]

Los RFC forman una cadena: uno queda obsoleto, otro amplía un transporte, otro organiza sesiones, una aclaración prepara el terreno para una nueva opción. Las listas de autores y las relaciones entre documentos permiten que el conocimiento continúe sin convertir a una persona en autoridad sobre las redes.

La evidencia permite decir que Bellis participó de manera repetida en especificaciones DNS públicas. No permite afirmar que inventó en solitario TCP para DNS, EDNS, DSO, los proxies o Multiple QTYPEs. Tampoco permite inferir intenciones privadas, resultados comerciales o calidad de implementaciones.

Lo duradero es el registro abierto. Otro ingeniero puede recuperar el texto, revisar las palabras normativas, comparar versiones y probar una implementación. El documento coordina; el código en ejecución demuestra qué ocurre.

La última milla está en los sistemas en funcionamiento

Un RFC no reconfigura automáticamente un cortafuegos ni corrige un proxy antiguo. No asigna memoria a conexiones persistentes ni mantiene estable una ruta anycast. Tampoco obliga a un resolutor a exponer todos sus reintentos en las métricas.

Cada mecanismo nuevo añade decisiones. DSO crea estado de sesión. Multiple QTYPEs puede reducir viajes pero incrementar trabajo por mensaje. Un límite protege al servidor y deja tipos pendientes. El fallback protege al usuario y puede ocultar que la ruta nueva casi nunca funciona.

Separar norma de resultado evita exageraciones. Un «debe» del RFC es un objetivo de prueba. Un código es una evidencia recibida. Un tiempo agotado es una transición. Ninguno demuestra por sí solo rapidez, disponibilidad o adopción.

La continuidad aparece cuando los equipos relacionan el registro público con respuestas observadas, estados de conexión, delegaciones, tamaños, carga y tiempo de aplicación. En esa capa, lo importante no es quién guarda el documento, sino si los datos siguen siendo únicos y coherentes, las responsabilidades se pueden localizar y el camino alternativo está probado.

El hilo común del trabajo documentado de Bellis puede formularse como una pregunta sencilla: cuando un participante no entiende, no completa, limita o termina una operación DNS, ¿puede el otro recibir un hecho útil en lugar de una espera vacía? Los estándares no eliminan todas las averías. Hacen que algunas dejen de parecer idénticas.

Quién paga la incertidumbre y quién puede reducirla

El coste de una respuesta ausente rara vez se queda en el servidor que no contestó. El resolutor utiliza tiempo y tráfico en reintentos. La aplicación conserva una tarea abierta. El usuario vuelve a pulsar o abandona. El servicio de soporte recibe una queja sin una causa visible. El operador del dominio revisa datos correctos porque no sabe que un intermediario eliminó el mensaje.

Una respuesta explícita mueve información en sentido contrario. El componente que todavía conoce el contexto comunica si entendió la petición, si no soporta la operación, si completó solo parte o si necesita cerrar por recursos. Los demás participantes mantienen su libertad de decisión, pero ya no parten de una hoja en blanco.

Las aplicaciones comerciales pueden notar esta diferencia aunque nunca hablen de DNS. Una tienda puede cargar con retraso aun cuando su servidor web esté disponible. Un sistema de correo puede aplazar una entrega porque no distingue una ausencia válida de una espera temporal. Un agente de monitorización puede marcar varios servicios cuando todos dependen del mismo proxy o resolutor. Son consecuencias generales de una búsqueda de nombres; las fuentes no las presentan como resultados privados de Bellis.

Los equipos de seguridad afrontan un equilibrio real. Responder sin control durante una ofensiva puede consumir capacidad o aumentar la amplificación. Callar siempre ante una función desconocida, en cambio, convierte una medida excepcional en incompatibilidad rutinaria. RFC 8906 conserva el espacio para limitar durante un ataque y, al mismo tiempo, pide respuestas de protocolo para condiciones ordinarias. [7]

Los responsables de producto también necesitan separar disponibilidad de calidad del camino. Una consulta EDNS que queda en silencio y luego triunfa sin EDNS entrega la página, pero demuestra que una capacidad no atravesó la ruta. Una solicitud Multiple QTYPEs que termina en varias consultas individuales conserva compatibilidad, pero no logra el intercambio combinado previsto. [9]

Por eso una tasa final de éxito puede resultar engañosa. Dos resolutores pueden devolver el mismo número de respuestas; uno quizá lo haga directamente y otro después de agotar varias esperas. La experiencia del usuario y el coste del servidor son distintos. Medir solo el último resultado recompensa los parches invisibles y deja sin dueño el primer fallo.

Hacer visible la causa no exige conservar indefinidamente cada nombre que consulta una persona. Un operador puede contar transportes, códigos, estados, cierres y rutas de fallback de forma agregada. La privacidad, el acceso a registros y el tiempo de conservación siguen siendo decisiones locales. El objetivo técnico es preservar la diferencia entre eventos, no reunir más datos de los necesarios.

La asignación de responsabilidad mejora cuando los límites están claros. El operador autoritativo puede demostrar que respondió por UDP y TCP. El proveedor recursivo puede mostrar qué alternativa eligió. El responsable del cortafuegos puede comprobar si una conexión fue rechazada o desapareció. El titular del dominio puede verificar la coherencia de la delegación. Ningún actor necesita asumir control sobre todo DNS para entregar su parte de la evidencia.

Ese reparto coincide con la naturaleza del sistema. Los repositorios de RFC mantienen un registro de reglas y versiones, pero no encienden servidores ni corrigen zonas. La autoridad efectiva sobre capacidad, filtros y datos está en las organizaciones que operan cada tramo. La utilidad del estándar está en que sus registros sean suficientemente exactos para comparar esas decisiones.

También importa el momento del diagnóstico. Una subida gradual de cambios de UDP a TCP, cierres keepalive, retiradas de EDNS o consultas individuales después de Multiple QTYPEs puede aparecer antes de una interrupción visible. [4] [5] [7] [9] Si la organización conserva esos contadores, puede revisar capacidad o compatibilidad antes de que el tiempo acumulado supere el límite de la aplicación.

La respuesta explícita facilita además el relevo humano. El siguiente turno puede leer un código, reproducir la consulta y comprobar si el comportamiento cambió. La frase «no llegó nada» obliga a reconstruir pérdida, filtrado, carga y soporte desde el principio. En una infraestructura distribuida, esa diferencia determina si el conocimiento sobrevive al cambio de equipo.

La pregunta de negocio no es si todos los fallos desaparecerán. Es cuánto tiempo y cuántos sistemas deben participar antes de que una causa quede clasificada. Los documentos asociados con Bellis no fijan un objetivo universal, pero ofrecen señales con las que cada organización puede definirlo sin confundir coordinación pública con control central de sus operaciones.

Fuentes

  1. IETF Datatracker, perfil de Ray Bellis.
  2. RFC Editor, RFC 5625: DNS Proxy Implementation Guidelines.
  3. RFC Editor, RFC 5966: DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor, RFC 7766: DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor, RFC 7828: The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor, RFC 8490: DNS Stateful Operations.
  7. RFC Editor, RFC 8906: A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker, RFC 9619: In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker, RFC 10029: DNS Multiple QTYPEs.