Resumen

  • La Homenet Naming Authority crea y firma la Public Homenet Zone, conserva las claves privadas DNSSEC y funciona como primario oculto; la infraestructura externalizada entrega las respuestas públicas.
  • La autenticación TLS mutua demuestra quién participó en un canal protegido, pero no acredita propiedad del dominio, instalación del DS en el padre, despliegue completo ni validación desde Internet.
  • La afirmación «la zona está publicada» necesita siete comprobantes enlazados: derecho, firma, transferencia, distribución, delegación, observación y retirada.

Una firma correcta frente a una delegación equivocada

La avería más desconcertante no empieza con una clave robada. Empieza con una clave correcta. La HNA ha firmado el nuevo contenido, el Distribution Manager ha aceptado la transferencia y los servidores públicos responden. Sin embargo, el padre todavía contiene el DS anterior. Para un validador externo, la cadena falla.

Todos los equipos pueden presentar un éxito local. El firmante produjo una zona coherente. El secundario la recibió. El sistema de publicación la sirvió. Ninguno de esos hechos contiene por sí solo la lectura del padre. Cuando una consola resume la secuencia con una marca verde, eleva una colección de actos parciales a una autoridad que no han ganado.

RFC 9526 ofrece un caso especialmente claro de poder distribuido. El propietario residencial decide qué revelar. La HNA convierte esa decisión en una zona y la firma. El proveedor externo la reparte. Un registrador o el operador del padre conecta la confianza. Los resolutores observan lo que realmente quedó disponible. La simplicidad para el usuario depende de que esas fronteras no desaparezcan para el operador.

La zona pública no es un volcado de la red doméstica

El protocolo publica una zona bajo un dominio registrado. No publica home.arpa, que sigue siendo un espacio local. Esta separación impide tratar el inventario interno como si fuera material público por defecto.

La HNA puede descubrir nombres y direcciones mediante DHCP, mDNS, UPnP, PCP o configuración manual. Después tiene que aplicar una política. Las direcciones de enlace local deben quedar fuera. Una dirección privada o ULA puede ser útil detrás de una VPN, pero un nombre resoluble no garantiza que el servicio esté abierto al mundo.

La evidencia inicial es, por tanto, editorial y operativa: lista de nombres aceptados, exclusiones, versión de política, responsable de la decisión y motivo de cada dirección. Si solo se conserva la zona resultante, resulta imposible explicar si un nombre sensible se publicó a propósito, entró por descubrimiento automático o sobrevivió a un dispositivo ya retirado.

La cautela también es de privacidad. Los nombres suelen ser menos aleatorios y más duraderos que las direcciones. Pueden revelar funciones familiares, tipos de dispositivo o hábitos. NSEC3 y la protección del transporte limitan algunas formas de enumeración, pero no convierten una etiqueta pública en información secreta.

El autor no se convierte en servidor público

RFC 9526 exige que la HNA genere todo el contenido de la zona y la firme con DNSSEC. La HNA administra las operaciones y el material privado de claves. El diseño no contempla entregar esas claves privadas al Distribution Manager.

La HNA actúa como primario oculto. No debería figurar en los NS públicos sin protección adicional y no debe responder consultas ordinarias de Internet. Esa tarea corresponde a los servidores autoritativos de la DNS Outsourcing Infrastructure.

La división evita que el proveedor pueda inventar una nueva zona auténtica. Pero no evita que controle la visibilidad: puede no recuperar una versión, retrasar su propagación o mantener una versión anterior mientras sus firmas sigan siendo válidas. La casa conserva la autoría criptográfica; el proveedor controla buena parte de la imprenta y el reparto.

Por eso hacen falta dos estados. «Firmada» debe identificar serie, hash, DNSKEY e intervalos de firma. «Servida» debe identificar instancias, versión observada y hora. Que la primera sea cierta no concede permiso para afirmar la segunda.

El canal de control y el de sincronización cambian de dirección

En el canal de control, la HNA inicia una sesión con el DM. Intercambian parámetros para la delegación, el DS y la localización del servicio de sincronización. TLS autentica a ambos extremos.

En el canal de sincronización, el DM se convierte en cliente TLS y la HNA en servidor y primario oculto. AXFR o IXFR transporta la zona. NOTIFY puede acelerar la consulta, mientras los temporizadores SOA permiten que el secundario busque cambios sin depender del aviso.

Que ambos canales compartan direcciones no los convierte en una misma prueba. La sesión de control acredita interlocutores según una configuración de confianza. La sesión de sincronización acredita un transporte. Para afirmar qué versión cruzó, hace falta enlazar serie y contenido. Para afirmar que llegó a la infraestructura pública, hace falta otro recibo.

Tampoco la autenticación del dispositivo demuestra el derecho sobre el Registered Homenet Domain. El certificado, la cuenta del dominio y la clave DNSSEC pueden pertenecer a ciclos distintos. Autenticación, autorización, ejecución y resultado son escalones, no sinónimos.

La etapa más visible queda fuera de una receta única

El DM recibe la zona como secundario oculto y la reparte a los servidores autoritativos públicos. RFC 9526 llama a este tramo Distribution Channel, pero permite que el proveedor use AXFR, replicación de bases de datos, REST u otro mecanismo probado.

La flexibilidad es práctica. La consecuencia es que la garantía entre DM y borde debe definirse para cada servicio. Un AXFR exitoso desde la casa no es confirmación de todos los nodos. Detrás de una dirección anycast pueden convivir regiones, versiones y colas de despliegue diferentes.

El proveedor debe registrar la generación aceptada por el DM y la aplicada por cada destino relevante, o declarar un criterio de cuórum con límites claros. Las comprobaciones externas de SOA, DNSKEY y registros representativos aportan observación. No sustituyen un inventario interno completo, pero pueden revelar divergencias que una sola sonda ocultaría.

Una declaración honesta conserva el alcance: «el DM aceptó la serie 108; cuatro perspectivas devolvieron 108 y una devolvió 107». La frase permite localizar la deuda. «Publicación completada» la borra.

NOERROR confirma una aceptación, no el estado del padre

La HNA entrega el hash de su KSK en un RRset DS. Si el DOI tiene relación con el registrador o registro, puede solicitar la actualización de la zona padre. Cuando el DM acepta la petición, responde NOERROR como compromiso de realizar ese cambio.

El compromiso tiene valor probatorio, pero termina en el DM. No muestra la respuesta actual del padre, ni el procesamiento del registro, ni la expiración de cachés. Puede persistir un DS antiguo, coexistir más de uno o faltar el derecho de la cuenta que debía efectuar la modificación.

La delegación segura solo existe cuando la zona hija está firmada, el padre contiene el DS correcto y un validador enlaza ambos. El RFC obliga a la HNA a firmar incluso si no puede organizar la delegación segura. Esa regla hace explícito que una firma válida puede quedar huérfana.

Hay que conservar el DS enviado, la respuesta del DM, una lectura independiente del padre y una validación externa. Un único campo «DNSSEC activado» destruye la capacidad de distinguir un problema de firma, transporte, registro o caché durante una rotación.

La propiedad del dominio precede al protocolo

El DOI no debe servir la zona si no confía en que la HNA posee el dominio registrado. RFC 9526 deja la prueba de esa propiedad fuera de alcance. Antes del canal técnico existe, por tanto, una decisión de gobierno.

Si el DOI también es registrador, la cuenta y el contrato pueden aportar esa confianza. Si el proveedor DNS es independiente, hará falta otro método. En ambos casos, el derecho del dominio, la credencial del canal y las claves DNSSEC pueden tener distintos custodios y procedimientos de recuperación.

Una migración sólida dibuja el mapa completo. ¿Quién puede editar el padre? ¿Qué credencial de HNA puede ordenar al DM? ¿Qué clave firma la generación activa? ¿Cuándo dejará de contestar el proveedor anterior? Restaurar la zona no restaura necesariamente la identidad de control. Crear una clave nueva no otorga el dominio.

La retirada demuestra si la delegación estaba bajo control

La HNA debe poder pedir al DM que elimine la delegación. Al recibir la orden, el DM debe dejar de servir la Public Homenet Zone y puede devolver NOERROR para indicar la eliminación.

El alcance vuelve a ser local. Los servidores públicos necesitan retirar su copia; los NS o DS del padre pueden requerir otra operación; los resolutores conservan cachés hasta el vencimiento. En una mudanza de proveedor, los dos servicios pueden responder simultáneamente.

El recibo de retirada debe comprobar ausencia: antiguo DM, destinos autoritativos, registros del padre, horizonte de TTL, vigencia de firmas y activación del sustituto. Mientras el proveedor antiguo siga siendo observable, queda un residuo de autoridad aunque la nueva plataforma funcione.

La eliminación de una HNA inactiva depende además del acuerdo comercial. La facultad del cliente de solicitar una baja y la facultad contractual del proveedor de limpiar una cuenta abandonada no son la misma. Sus plazos y vías de recurso necesitan responsables explícitos.

El cambio de prefijo distribuye el tiempo

Durante una renumeración, la HNA actualiza las direcciones, comunica al DM su nueva localización de sincronización y provoca otra transferencia. En una transición con solapamiento conviven el prefijo anterior y el nuevo. En una renumeración repentina, el anterior puede dejar de funcionar antes de conocer el siguiente.

El RFC recomienda que la HNA actualice su localización al arrancar, porque no sabe cuánto tiempo estuvo apagada ni si la zona firmada venció. La intención, el serial de la HNA, la copia del DM, las copias públicas, el padre y los cachés avanzan con relojes diferentes.

La monitorización debe compararlos. Una dirección vieja puede seguir correctamente cacheada y ser ya inalcanzable. Una nueva puede aparecer antes que la regla de cortafuegos. El nombre local puede funcionar mientras la ruta pública está rota. Preguntar «¿funciona DNS?» oculta la generación y la frontera que importan.

Fuentes

Fuentes