OpenWAF funciona mejor con una zona por dominio registrable: www, api y tienda son nombres dentro de example.com, cada uno con sus propios ajustes si hace falta. Si diste de alta un subdominio como zona propia (por ejemplo api.example.com) y el dominio también tiene su zona (example.com), fusiona la zona del subdominio en la del dominio. Sus nombres, registros y certificados se mueven, y el borde sigue sirviendo exactamente la misma configuración para cada nombre.
Necesitas el rol admin en toda la organización. Las dos zonas tienen que ser de la misma organización, estar activas y tener el mismo modo DNS y el mismo cliente (o ninguno).
Qué se mueve
- Los registros pasan a la zona padre con los mismos ids, y los certificados se van con ellos.
- Los ajustes de la zona hija que difieren de los de la padre pasan a ser ajustes por nombre de los nombres de la hija en la padre.
- Las reglas de la zona hija pasan a ser reglas de la padre limitadas a los nombres de la hija. Las reglas de la padre que valían para «todos los nombres» se limitan a los nombres propios de la padre cuando hace falta, para que no empiecen a aplicarse a los nombres movidos.
- La padre hereda el cliente de la hija si no tenía.
Fusionar
Simula siempre antes. La respuesta es la misma tanto si la fusión se simula como si se aplica o se rechaza: un informe de equivalencia que compara, para cada nombre de las dos zonas, el sitio que sirve el borde antes y después (equal, y las differences con la ruta de cada campo).
openwaf-cloud ctl zones merge api.example.com --into example.com --reason "Una zona por dominio"La CLI simula, enseña la equivalencia por nombre y pide confirmación. Solo aplica cuando todos los nombres son equivalentes.
curl -X POST "https://dash.openwaf.dev/v1/orgs/$ORG/zones/$CHILD_ZONE/merge" \
-H "Authorization: Bearer $OPENWAF_TOKEN" \
-H "Content-Type: application/json" \
-d '{"into": "example.com", "reason": "Una zona por dominio", "dry_run": true}'Envíala de nuevo con "dry_run": false para aplicarla. Añade "expected_versions": {"example.com": 12, "api.example.com": 7} para que se rechace si alguna de las dos zonas ha cambiado desde que la revisaste.
Si algún nombre no se serviría igual, o la fusión no se puede expresar (clientes distintos, modos DNS distintos, una zona que no está activa…), no se aplica nada: la respuesta es 409 merge_not_equivalent con el plan y los problems.
Después de la fusión
- La padre recibe una versión nueva (acción
zone.merge), y la hija una última (zone.merged). - La zona hija pasa a desactivada, en solo lectura y oculta en la lista de zonas (la API la muestra con
?include=merged). Se conserva 14 días para poder deshacer la fusión y después se borra. - Zonas delegadas: no hay ningún hueco en el DNS. Los nombres de la hija se publican en la padre; la zona hija sigue respondiendo lo mismo hasta que todos los servidores DNS sirven la versión nueva de la padre, y solo entonces desaparece.
- Zonas externas: no cambia nada en el DNS. Los CNAME de tu proveedor siguen apuntando al borde.
Deshacer una fusión
Mientras la padre no haya cambiado desde la fusión, puedes devolver las dos zonas a como estaban antes (los registros y los certificados vuelven a la hija, que se reactiva):
openwaf-cloud ctl zones unmerge api.example.com --reason "Deshacer la fusión"En la API: POST /v1/orgs/{org}/zones/{child}/unmerge con {"reason": "…", "expected_version": <versión de la padre tras la fusión>}. Si la padre ha cambiado después de la fusión, la respuesta es 409 merge_not_reversible: revierte antes esos cambios.
Mover un solo sitio
Para mover un sitio (un nombre con sus registros con proxy) de una zona a otra de tu organización sin fusionar zonas enteras, escribe a [email protected].