Resumen

  • El RFC 1788 asignó los tipos ICMP 37 y 38 para consultar a cada dirección unicast qué nombres de dominio conocía, evitando depender sólo de la delegación inversa.
  • La dirección de origen, el identificador, la secuencia, el TTL y hasta una respuesta sin nombres daban contexto a un intercambio, no prueba de propiedad, persona o ruta autorizada.
  • El RFC 6918 deprecó ambos mensajes en 2013 porque nunca alcanzaron implementación o despliegue amplios: el código en funcionamiento decidió el resultado.

Una dirección que hablaba por sí misma

La consulta inversa tradicional pregunta al DNS qué nombre corresponde a una dirección. Ese camino no es simplemente el árbol de nombres recorrido al revés. Sigue la delegación de los bloques de direcciones, mientras que el nombre directo sigue la administración de dominios. Con CIDR, las dos geometrías podían separarse aún más.

El RFC 1788 describió la consecuencia operativa: la información IN-ADDR no se mantenía de forma fiable y las aplicaciones podían sufrir pausas largas al buscar nombres para una interfaz o un registro de seguridad. Su solución era dirigir la pregunta al punto que ya localizaba el enrutamiento. La dirección consultada recibiría un ICMP Domain Name Request y contestaría con un Domain Name Reply.

El cambio reducía una dependencia administrativa, pero creaba otra clase de contrato. Ya no bastaba con mantener una zona. Cada host y router debía incorporar un servidor, las redes debían dejar pasar tipos ICMP nuevos y las aplicaciones debían aprender a interpretar la respuesta.

La igualdad de direcciones sólo acotaba el recibo

El tipo 37 era la solicitud; el 38, la respuesta. Un identificador y un número de secuencia permitían asociarlas y podían ser cero. Para cada destino IP se enviaba una solicitud independiente.

La regla de origen era precisa: la dirección fuente de la respuesta tenía que ser igual a la dirección de destino de la consulta. Evitaba que otro interfaz respondiera con una identidad de conveniencia y hacía auditable el par pregunta-respuesta.

Sin embargo, la igualdad de dos campos no resolvía la cadena de autoridad. El enrutamiento podía llevar el paquete a quien recibía tráfico para A en ese momento; no demostraba que el anuncio de A fuera legítimo. El software podía devolver un nombre; no demostraba el propietario legal de A ni la persona detrás de la sesión. Tampoco establecía por sí solo la coherencia con el DNS directo.

El propio RFC advertía que el enrutamiento no era seguridad. Imaginaba protección mediante IPsec y una firma criptográfica obtenida a través del DNS directo. Esas capas adicionales muestran justamente lo que faltaba en el intercambio básico.

Una negativa explícita era mejor que un timeout

La respuesta podía contener cero o más nombres plenamente cualificados. Si la máquina no conocía ninguno, aún debía responder. El RFC llamaba a ese resultado una indicación autorizada de que no se conocía nombre alguno.

La utilidad era temporal y operacional: distinguir «no sé» de «tal vez se perdió el paquete». No era una negación DNSSEC, un certificado de propiedad ni una promesa de que mañana seguiría sin haber nombre. La autoridad pertenecía al respondedor dentro del protocolo.

Cuando había varios nombres, debían incluirse todos. Pero si uno no cabía en el MTU de la respuesta, se omitía. Por tanto, el conjunto recibido podía ser incompleto sin que el emisor hubiera elegido ocultarlo. El límite físico del paquete intervenía en el significado de la evidencia.

El TTL también exigía prudencia. Era un entero con signo en complemento a dos por razones históricas. Indicaba cuánto tiempo conservar la información, no cuánto duraría la ruta, la máquina o la relación institucional. Frescura y autenticidad seguían siendo dimensiones diferentes.

Preguntar a un grupo habría creado una tormenta

El RFC prohibió usar el mecanismo con destinos broadcast o multicast. La solicitud debía descartarse en silencio. Si todos los oyentes obedecían el mandato de responder, una única pregunta a un grupo podía multiplicarse en una ráfaga de contestaciones.

La aparente universalidad estaba, pues, rodeada de límites. «Todo host y router» se refería a implementar el servidor para consultas unicast válidas, no a contestar en cualquier contexto. Una dirección, una petición y una respuesta eran parte del mínimo seguro.

Incluso así, el coste de coordinación era enorme. Sistemas operativos, routers, appliances, pilas embebidas, cortafuegos y herramientas tendrían que adoptar el mismo par de mensajes. El formato era pequeño; la población necesaria era casi toda Internet.

ICMP nunca prometió entrega

El RFC 792 situaba los mensajes ICMP en su contexto. Sirven para informar de problemas y condiciones de control, pero no vuelven fiable a IP. No se garantiza que llegue el datagrama original ni el propio mensaje ICMP.

Por eso un silencio no podía equivaler a «el host no implementa RFC 1788». Podía haber filtrado, pérdida, cambio de ruta o política. De manera simétrica, una respuesta válida sólo probaba que una ruta y un respondedor produjeron ese paquete en ese instante.

Para una bitácora seria, cinco estados debían permanecer separados: nombre positivo, negativa explícita, timeout, rechazo administrativo y fallo de autenticación. Fundirlos en «nombre desconocido» destruiría la realidad observable que el protocolo intentaba mejorar.

El requisito universal no obtuvo una base universal

La frase normativa central no dejaba margen: cada host y router debía implementar la función de servidor. El RFC también recomendaba una interfaz de aplicación para diagnósticos. El diseño aspiraba a ser infraestructura común, no una extensión de nicho.

La historia documentada fue otra. En 2013, el RFC 6918 afirmó que los tipos 37 y 38 nunca habían sido ampliamente implementados o desplegados. Los deprecó y dejó obsoleto al RFC 1788. La tabla actual de IANA refleja ese resultado.

No conviene exagerarlo. «Nunca ampliamente» no significa «jamás existió un prototipo». Las fuentes oficiales tampoco atribuyen el desenlace a una sola causa. Lo que sí prueban es la ausencia de densidad suficiente para que las aplicaciones pudieran confiar en la función como servicio general.

La dinámica era difícil. Sin aplicaciones usuarias, implementar tenía poco retorno. Sin implementaciones, una aplicación obtenía demasiados silencios. Los filtros podían bloquear tipos desconocidos. El DNS ya ofrecía interfaces instaladas. Además, responder desde cada terminal abría preguntas de privacidad, autenticación y coherencia.

El RFC 6918 añadió que la deprecación podía facilitar el filtrado. Una vez formalizado el fracaso de adopción, mantener la puerta abierta resultaba todavía menos atractivo. El registro terminó de alinear expectativa y práctica.

IPv6 volvió con un contrato más estrecho

El RFC 4620 definió después IPv6 Node Information Queries con categoría Experimental. Reconoció el antecedente IPv4, pero no reclamó autoridad global sobre nombres: reservó el mecanismo para diagnóstico, depuración y gestión, mientras el DNS seguía siendo autoritativo a escala global.

Incluyó un nonce, límites de alcance por defecto, controles de tasa y consideraciones de privacidad. Advirtió que los datos aprendidos no debían alimentar decisiones de seguridad sin autenticación adicional. Para el nombre del nodo, el TTL tenía que ser cero.

Estas decisiones no prueban continuidad ni adopción amplia. Muestran una especificación posterior consciente de que la información directa del terminal necesitaba más límites y menos ambición institucional.

El voto fue ejecutar o no ejecutar

La idea de Running-Code Primacy de Heng Lu permite leer el contraste sin convertirlo en burla. Un estándar coordina porque sistemas independientes lo adoptan y se encuentran en una conducta interoperable. El documento puede disciplinar a quien implementa; no puede crear una población de implementaciones por decreto.

RFC 1788 tenía número, asignaciones y el MUST más amplio posible. Ésos eran hechos de la capa simbólica. La capa operativa no reunió suficientes respuestas. RFC 6918 terminó corrigiendo la primera para que reconociera la segunda.

El marco Minimum Initial Specification, Localized Future Decision y Voluntary Adoption añade que el tamaño del paquete no mide el tamaño de la decisión. Dos tipos ICMP simples exigían cambios locales en casi todos los hosts, routers, políticas y aplicaciones. Era una especificación compacta con una superficie de adopción gigantesca.

Es una lectura contemporánea y no una afirmación sobre lo que pensaban los autores en 1995. Tampoco invalida el lenguaje normativo: los MUST son esenciales una vez definido el conjunto de participantes. Sólo recuerda que la norma no demuestra que ese conjunto exista.

El RFC 1788 quiso que la dirección contestara con su propio nombre y que incluso la ausencia tuviera respuesta. El diseño delimitó bien un paquete. Lo que no pudo delimitar fue la voluntad de millones de sistemas autónomos. La dirección debía hablar; la mayoría del mundo nunca aprendió ese idioma.

Fuentes