Resumen
- SRP liga un nombre al primer par de claves aceptado y usa SIG(0) para comprobar continuidad; no certifica a la empresa, al propietario, al registrador ni al servicio.
- Un
NoErrordebe enlazarse con la propagación desde el primario oculto, las respuestas de cada autoridad, la vista del resolver y una transacción de aplicación.
El dispositivo envió una sola actualización. Incluía su nombre, direcciones, instancia de servicio, puerto, atributos, clave pública y firma. El registrador respondió NoError. Diez minutos después, ningún cliente encontraba el servicio.
Las dos observaciones pueden ser correctas. RFC 9665 permite que el registrador SRP sea un primario oculto que alimenta a los servidores autoritativos que sí contestan consultas. Aceptar la actualización y publicar su resultado son etapas distintas. Entre ellas puede haber diario, firma de zona, transferencia, cola, réplica o una política que suprima direcciones no utilizables.
El error operativo consiste en convertir el primer recibo en el último.
Qué decidió realmente el registrador
SRP reutiliza DNS Update con una forma más estricta. Una actualización contiene exactamente una descripción de host y puede incluir varias descripciones e instrucciones de descubrimiento de servicios. No lleva las precondiciones explícitas habituales de RFC 2136. El registrador aplica reglas implícitas y acepta todo o rechaza todo.
Comprueba la relación entre PTR, SRV, TXT, A o AAAA; que las descripciones usen la misma KEY; que la firma SIG(0) corresponda a esa clave; que exista la opción Update Lease; y que el nombre no pertenezca a otra clave todavía vigente. Esa atomicidad evita que aparezca media inscripción.
No obstante, NoError solo afirma que esa entrada fue válida bajo esas reglas. No identifica al operador legal del dispositivo. Tampoco demuestra que el registrador que respondió era el esperado: la especificación exige TLS en el servidor, pero no define una validación automática y práctica de su clave. DNS-over-TLS aporta privacidad oportunista si el solicitante no autentica el certificado o una clave fijada.
Primero en llegar significa primero en poseer la clave
FCFS Naming sustituye una credencial previamente distribuida por continuidad criptográfica. El primer solicitante que reclama un nombre libre deposita una clave pública y firma la operación. Mientras viva el KEY-LEASE, una actualización posterior debe probar la misma clave privada.
Es una propiedad útil y limitada. No prueba que el solicitante represente a la organización cuyo edificio ocupa, que el fabricante siga administrándolo, que el empleado tenga permiso o que el servicio anunciado sea benigno. Una firma auténtica puede describir con fidelidad un servicio equivocado o inaccesible.
La clave debe ser única por dispositivo y permanecer en almacenamiento estable. Si un restablecimiento de fábrica o cambio de propietario la elimina, la nueva clave no hereda el nombre. El dispositivo elige otro o espera a que venza la reserva anterior. Por eso el procedimiento de reset necesita una decisión de nombres, inventario y soporte; regenerar claves no es un detalle aislado.
El servicio y su derecho al nombre caducan en momentos distintos
Los registros de servicio suelen usar un LEASE de unas dos horas. La KEY puede conservar su nombre cerca de catorce días. Así, un equipo apagado desaparece de los menús de descubrimiento sin perder inmediatamente su etiqueta.
Una consola debe mostrar esos estados por separado. “Nombre reservado, servicio ausente” es válido. “Servicio publicado con clave inesperada” requiere investigación. También hay que distinguir el lease del TTL: el primero decide cuándo la autoridad deja de servir el registro; el segundo permite que una copia ya obtenida sobreviva en una caché. El registrador no puede retirar esa copia a distancia.
La política de zona es parte de la seguridad
SRP no aporta otra autorización que FCFS. Por eso el perímetro de admisión importa. El registrador debería rechazar fuentes exteriores a su dominio administrativo. TCP ofrece resistencia a suplantación fuera de ruta mediante el handshake, salvo que se acepten datos Fast Open sin validación equivalente. UDP en redes restringidas depende del filtrado de origen y de interfaz.
También importa dónde se concede el derecho. Activar SRP sobre la zona corporativa permitiría reclamar nombres como www, mail o smtp. RFC 9665 recomienda una subzona de descubrimiento y una lista de términos prohibidos. El nombre técnico de esa subzona no necesita ser prestigioso; precisamente conviene que no lo sea.
Los mecanismos de actualización no deben pisarse. Una credencial de DNS Update convencional, distinta de la clave SRP, podría reemplazar registros ya prometidos al primer solicitante. Si ambos caminos existen, el operador necesita separación de objetos, reglas de precedencia y auditoría.
service.arpa. tampoco es una identidad global
Los nodos restringidos pueden registrar en default.service.arpa. y dejar que el registrador reescriba el nombre si la red lo requiere. La zona se sirve localmente. Un equipo que ignora los resolvers ofrecidos por la red puede no resolverla o ver una respuesta ajena al contexto correcto.
El sufijo no eleva la confianza. No proporciona un nombre global apto para un certificado PKI. El cliente sigue necesitando el método de autenticación propio de la aplicación. Además, publicar KEY puede convertir la clave en identificador rastreable; el operador puede ocultarla, pero debe conservar coherencia con DNSSEC y las respuestas negativas.
Construir el recibo completo
Antes de la actualización se registran el acceso de red, la interfaz, el dominio de inscripción, la forma de descubrir el registrador, su dirección y el transporte. Durante la entrada se guardan el mensaje exacto, la huella KEY, el algoritmo, la validación SIG(0), el conflicto, los leases solicitados y concedidos y la respuesta.
Después se exige el evento del diario o serial, la salida del firmante, consultas a las autoridades que sirven, una observación recursiva con TTL y una conexión real al endpoint. Solo esa cadena permite decir dónde terminó el éxito.
Fuentes
- IETF, RFC 9665 — Service Registration Protocol
- IETF, RFC 9664 — DNS Update Lease
- IETF, RFC 2136 — DNS Update
- IETF, RFC 2931 — SIG(0)
- IETF, RFC 6763 — DNS-SD
- IETF, RFC 7858 — DNS over TLS
- IETF, RFC 8945 — TSIG
- IANA, Locally-Served DNS Zones
- IETF Datatracker, historial de publicación de RFC 9665
- RFC Editor, metadatos de RFC 9665
- RFC Editor, erratas de RFC 9665
- RFC Editor, texto canónico de RFC 9665
- RFC Editor, XML de RFC 9665
- IETF, RFC 3007 — actualización dinámica DNS segura
- IETF, RFC 4035 — protocolo DNSSEC
- IETF, RFC 6761 — nombres de uso especial
- IETF, RFC 8766 — Discovery Proxy
- Heng Lu, Minimum Initial Specification
- Heng Lu, Reality Layers
- Heng Lu, Running Code Primary
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

