Enunciado y alcance
Diseñe un plano de control de DNS autoritativo para un SaaS multiinquilino. Los usuarios envían registros A, AAAA, CNAME y TXT. El sistema valida conflictos, crea versiones de zona, notifica a los nodos autoritativos y admite AXFR/IXFR, DNSSEC, despliegue, reversión y auditoría.
Qué evalúa el entrevistador
- Separar el plano de control, el plano de servicio autoritativo y los resolutores recursivos.
- Utilizar versiones de zona inmutables y publicación atómica.
- Conectar el serial SOA, NOTIFY, AXFR e IXFR.
- Aislamiento de inquilinos, autorización, protección de claves DNSSEC y prevención de versiones defectuosas.
- Gestión de nodos rezagados, publicación parcial, almacenamiento en caché negativo y reversión.
Aclaraciones que conviene hacer primero
Confirme el recuento de zonas, la tasa de escritura, el SLO de propagación, DNSSEC, la geografía de los nodos, el modelo de autorización y aprobación, y si los nodos antiguos solo admiten AXFR. Si no se especifica, asuma un clúster autoritativo distribuido globalmente con visibilidad a nivel de minutos.
Estructura de respuesta en treinta segundos
Escriba registros normalizados en el plano de control, cree una versión de zona inmutable, valídela y cambie atómicamente los nodos autoritativos. Incremente el serial SOA; NOTIFY activa IXFR, con AXFR como alternativa. Cada lanzamiento tiene estado, evidencia de auditoría y un puntero de reversión. DNSSEC, la autorización de inquilinos y la monitorización de la propagación son barreras de control de lanzamiento.
Análisis detallado paso a paso
1. Separar los planos
El plano de control almacena inquilinos, zonas, registros y versiones. El plano de servicio responde únicamente desde una versión publicada. Los resolutores recursivos están fuera de la ruta de escritura, y el TTL crea un retraso en la visibilidad. Una versión incluye datos canónicos de zona, serial SOA, suma de comprobación, estado de firma y destinos.
2. Diseñar escrituras y validación
Escriba una transacción candidata y valide nombres, TTL, restricciones de tipo, conflictos de CNAME, límites de delegación y cuotas de inquilinos. Los cambios por lotes llevan un id de idempotencia y una versión optimista. Una validación fallida nunca crea una versión publicable.
3. Generar y publicar atómicamente
Genere la estructura de zona y ejecute comprobaciones de sintaxis, delegación, ciclos y DNSSEC. Almacene el objeto direccionado por contenido validado y la suma de comprobación. Los nodos cambian un puntero de versión de forma atómica, evitando respuestas mezcladas entre lo antiguo y lo nuevo.
4. Propagación y nodos rezagados
El nodo primario incrementa el serial y envía NOTIFY. Los secundarios solicitan IXFR, recurriendo a AXFR cuando la cadena de deltas no está disponible o falla la validación. Los nodos reportan el serial, la suma de comprobación y el estado de firma. Un nodo rezagado se drena o sirve una versión antigua validada; nunca debe servir silenciosamente una zona vacía.
5. TTL, almacenamiento en caché negativo y reversión
El TTL controla el almacenamiento en caché recursivo, y las respuestas NXDOMAIN se almacenan en caché negativo. Prepare el nuevo destino antes de cambiar los TTL; eliminar un registro autoritativo no borra las cachés externas de inmediato. Revierta a una versión antigua validada con un serial más alto en lugar de reutilizar un serial antiguo.
6. Seguridad y aislamiento de inquilinos
Utilice RBAC con ámbito de zona, aprobaciones y control dual. Autentique las API de actualización internas y evite la reproducción de peticiones. Mantenga las claves DNSSEC en KMS o HSM y bloquee un lanzamiento cuando falle la firma. Audite al actor, la solicitud, la versión, el serial y el resultado sin almacenar secretos de inquilinos.
7. Observabilidad y simulacros
Supervise la latencia de publicación, el desfase de seriales, la proporción IXFR/AXFR, los fallos de firma, SERVFAIL, los cambios de NXDOMAIN, el éxito de las consultas y la distribución regional. Realice simulacros de fallos del primario, partición de red, pérdida del historial de deltas, zonas defectuosas, rotación de claves y reversión, mientras demuestra que la versión antigua validada permanece disponible.
Ejemplo de respuesta de alta calidad
Mantendría versiones de zona inmutables aisladas por inquilino en el plano de control y dejaría que los nodos autoritativos sirvan una versión validada. Validaría nombres, TTL, conflictos de CNAME, delegación y cuotas con solicitudes por lotes idempotentes y versiones optimistas. Generaría una zona canónica, verificaría la sintaxis, DNSSEC y la suma de comprobación, y luego cambiaría el puntero atómicamente.
El primario incrementa el serial y envía NOTIFY; los secundarios prefieren IXFR y recurren a AXFR. Los nodos reportan serial, suma de comprobación y estado de firma. El TTL y la caché negativa determinan la visibilidad externa, mientras que la reversión utiliza un serial más nuevo. RBAC, aprobaciones, KMS/HSM, auditoría, monitorización de SERVFAIL y desfase de seriales, y simulacros de partición y rotación de claves actúan como barreras de control de lanzamiento.
Errores comunes
- Tratar el retraso de la caché recursiva como un fallo del plano de control.
- Editar un archivo de zona compartido directamente y servir una escritura parcial.
- Asumir que NOTIFY significa que la propagación está completa.
- Servir una zona vacía después de que falle IXFR.
- Reutilizar un serial SOA antiguo durante la reversión.
- Dar a los inquilinos acceso directo a las claves privadas de DNSSEC.
- Omitir la monitorización de NXDOMAIN y SERVFAIL.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué debe aumentar el serial SOA?
Los nodos y las cachés comparan seriales para determinar la frescura. La reversión también necesita un serial más alto para que no se confunda con una versión antigua.
Pregunta de seguimiento 2: ¿Qué sucede si IXFR no puede encontrar el delta?
Solicite AXFR. Si la transferencia falla, mantenga la versión validada y genere una alerta; nunca sirva una zona vacía.
Pregunta de seguimiento 3: ¿Qué hace con un nodo muy rezagado?
Compare el serial y la suma de comprobación, drénelo o manténgalo en una versión antigua validada, y luego póngalo al día con AXFR y consultas de muestreo.
Pregunta de seguimiento 4: ¿Se pueden publicar datos sin firmar después de que falle la firma DNSSEC?
Si el contrato de la zona requiere firmas, bloquee la publicación y repare la clave o la cadena. No degrade silenciosamente.