Resumen

  • WKS convertía los servicios de una dirección IPv4 en un número de protocolo y un mapa de bits indexado por puertos. Un uno expresaba que debía haber un servidor escuchando, no que se hubiera comprobado su estado.
  • La RFC 974 recomendó usar ese mapa para eliminar destinos MX sin SMTP. La RFC 1123 retiró el paso al constatar que WKS tenía poco soporte: no publicar un catálogo no equivalía a no prestar el servicio.
  • El número registrado, la declaración DNS, el proceso activo, la autorización de la red y la identidad del interlocutor pertenecen a planos distintos. La conexión real seguía siendo necesaria para unirlos.

El puerto 25 antes de hablar con nadie

El agente de correo aún no ha enviado un SYN. Tiene una lista de destinos MX y consulta un registro WKS de cada uno. Busca el protocolo TCP y lee el bit 25. Si está activado, interpreta que debería existir un servidor SMTP en el puerto 25 de la dirección indicada. Si no lo está, considera que el destino carece del servicio.

La idea parecía una economía razonable. Un intento fallido puede consumir tiempo, sobre todo si termina por agotamiento del plazo. El DNS ya permite encontrar el host; añadir su catálogo de servicios podría evitar trabajo inútil y acelerar la entrega.

El problema estaba en lo que se ahorraba. Al omitir la conexión, el cliente también omitía la única observación capaz de confirmar que el servicio respondía desde su posición. Sustituía esa observación por una afirmación administrativa, posiblemente almacenada en caché. Un bit de significado exacto empezaba a decidir sobre un sistema cuyo estado podía cambiar sin modificarlo.

Un catálogo ligado a la dirección

La RFC 883 definió WKS en noviembre de 1983. La RFC 1035 conservó el diseño en 1987: 32 bits de dirección Internet, ocho bits de número de protocolo IP y un mapa de longitud variable, siempre en múltiplos de ocho bits.

La posición de cada bit es el número de puerto del protocolo seleccionado. El primero representa el puerto cero. El vigésimo sexto representa el puerto 25. Las posiciones que quedan fuera del mapa transmitido se interpretan como cero. El ejemplo de la especificación afirma que, con TCP, un uno en la posición 25 indica que debería haber un servidor SMTP escuchando.

La afirmación termina en una dirección IPv4 literal. No contiene un nombre de destino que pueda resolverse después ni una identidad de instancia. Un host con varias direcciones necesita varios registros; TCP y UDP también requieren registros separados. WKS describe parejas de dirección y protocolo, no un servicio independiente de la máquina que lo ejecuta.

El mapa es denso. Su tamaño depende del puerto más alto anunciado, no de cuántos servicios se ofrecen. Aunque solo se activen dos posiciones, hay que conservar las intermedias; los ceros finales sí pueden omitirse. Es una consecuencia del formato, no una medición de tráfico histórico. Expone una premisa: los servicios interesantes ocupan coordenadas relativamente bajas y conocidas de un espacio numérico.

Tampoco hay campos para prioridades, pesos, destinos alternativos, mantenimiento o un puerto elegido para una instancia concreta. Añadir registros amplía el inventario, pero no proporciona una política de selección. El cliente sabe qué afirma el editor acerca de cada dirección, no cómo elegir entre ellas.

La recomendación que dio poder al cero

En enero de 1986, la RFC 974 incorporó WKS a las pautas de encaminamiento del correo. Para cada MX, aconsejaba consultar WKS y descartar los nombres que no soportaran el servicio deseado. El paso era opcional, pero estaba fuertemente recomendado.

En un catálogo completo y actualizado, el cero permite ahorrar una conexión destinada al fracaso. En una infraestructura de adopción voluntaria, ese mismo cero puede significar que nadie creó el registro, que el administrador olvidó actualizarlo o que la copia consultada es antigua. El servicio puede funcionar mientras su descripción no existe.

Así, una información ausente adquiría capacidad de veto. Un servidor SMTP válido podía desaparecer de la lista de entrega sin recibir un solo paquete. La optimización no se limitaba a fallar en su propósito; podía causar el resultado que trataba de evitar.

La separación administrativa hacía el problema más probable en principio: DNS y servidores podían tener responsables distintos, el MX podía cambiar antes que WKS, un proceso podía comenzar a escuchar durante el TTL y las réplicas de zona podían avanzar a ritmos diferentes. Las fuentes no prueban que cada una de estas situaciones ocurriera en un despliegue concreto; son formas en que el contrato no garantiza sincronización.

Un uno tampoco zanjaba la cuestión. El proceso podía detenerse después de publicar el registro. Una política de acceso podía bloquear a unos clientes y permitir a otros. La dirección podía cambiar de dueño operativo. Un puerto abierto podía alojar otro programa. Incluso una conversación SMTP iniciada correctamente no aseguraba la aceptación final del mensaje.

La experiencia devolvió la pregunta al servicio

La RFC 1123, de octubre de 1989, recogió una conclusión sencilla. Las aplicaciones no debían confiar en encontrar un WKS con una lista exacta de todos los servicios de una dirección, porque los sitios Internet no utilizaban con frecuencia ese tipo. Para confirmar la presencia de un servicio, había que intentar usarlo.

El documento corrigió además el caso de correo de forma expresa. La experiencia posterior a la RFC 974 había mostrado que WKS no estaba ampliamente soportado, por lo que el paso WKS no debía emplearse en el procesamiento MX. Una consulta adicional dejó de considerarse una mejora automática de la decisión.

La retirada de la recomendación no convirtió todos los WKS en falsos ni borró el tipo del protocolo. El registro DNS de IANA sigue asignando a WKS el tipo 11. Mantener el código impide colisiones y permite interpretar registros históricos; no demuestra adopción actual.

Lo que se rechazó fue una inferencia demasiado fuerte. Si el catálogo es opcional y escaso, no estar en él no prueba inexistencia. Cuando el coste de excluir un servidor útil supera el de intentar una conexión, la prueba directa es la opción más robusta. La exactitud sintáctica del cero no compensa la falta de cobertura del sistema que lo publica.

Cinco preguntas, no una

La frase «esta dirección ofrece SMTP» puede descomponerse. ¿Qué uso coordina el número 25? Lo responde el registro de puertos. ¿Qué configuración declara el dominio? Lo responde su operador DNS. ¿Hay un proceso escuchando? Lo decide y observa el host. ¿Puede llegar este cliente? Depende del camino y de las reglas de red. ¿Es realmente el servicio esperado? Debe establecerlo el protocolo y su autenticación.

WKS juntaba esas preguntas visualmente, pero no sus autoridades. Un dato auténtico de una zona puede estar desactualizado. Una configuración correcta puede ser inaccesible desde fuera. Un socket abierto no identifica por sí solo a la aplicación. El DNS no dispone de un campo capaz de describir todas las políticas específicas de cada origen.

La RFC 6335 formuló después la frontera del registro: asignar un nombre o un puerto no supone respaldar un producto, y el tráfico que utiliza un puerto asignado ni siquiera tiene por qué pertenecer al servicio registrado. Los administradores deben decidir sus reglas a partir del tráfico que conocen, no del número como sello de confianza.

La advertencia es posterior a WKS, pero ayuda a no leer su mapa como una lista de permisos. El número coordina un vocabulario. No enciende procesos, no autoriza usuarios y no convierte una respuesta en identidad verificada.

Lo que cambió con nombres y destinos

La RFC 2782 describe SRV como una forma distinta de localizar servicios. La consulta incluye servicio, transporte y dominio. La respuesta aporta prioridad, peso, puerto y un nombre de destino con registros de dirección.

Frente al inventario WKS, el cliente recibe candidatos explícitos. Puede distinguir principales y reservas, usar puertos anunciados para cada destino y seguir a un servicio que se mueve entre hosts. La identidad simbólica deja de estar encerrada en la posición de un bit.

La RFC 6335 permitió registrar un nombre de servicio sin asignarle un puerto fijo cuando mecanismos como SRV lo descubren en tiempo de ejecución. Nombre y número siguen relacionados, pero ya no son el mismo acto administrativo.

Ese avance no convierte SRV en una sonda. Su peso no es carga instantánea, y el destino puede fallar mientras la respuesta sigue en caché. Resolver, conectar y verificar la aplicación continúa siendo trabajo del cliente. La mejora consiste en expresar con más precisión la intención de localización, no en delegar al DNS toda la verdad operativa.

El alcance de la evidencia

El conjunto cerrado de siete fuentes oficiales permite seguir la definición de 1983, el uso propuesto en 1986, el formato de 1987, la corrección de 1989, el contraste con SRV, la separación entre nombre y puerto y la asignación vigente del tipo 11.

No mide cuántas zonas publican WKS hoy, cuánto tráfico produce, qué implementaciones lo entienden ni cuántos clientes siguieron cada recomendación. Tampoco prueba que una entrada particular estuviera obsoleta. El análisis del tamaño del mapa es aritmética del formato, no una estimación de ahorro o pérdida real.

La historia no termina con un DNS capaz de saberlo todo. Termina con una pregunta mejor situada. Un registro puede declarar que un servicio debería existir; para saber si está vivo, es alcanzable y es el interlocutor correcto, hay que cruzar la frontera hacia el servicio. WKS enseñó el peligro de impedir ese cruce por un bit ausente.