Una respuesta de registro faltante puede sobrevivir al registro faltante
un nuevo Selector DKIM puede existir en DNS autorizado mientras un solucionador recursivo aún responde como si la clave estuviera ausente. Una posible explicación es el almacenamiento en caché negativo: el solucionador se enteró previamente de que el nombre o el tipo de registro solicitado no estaba disponible y retuvo esa respuesta. Guardando repetidamente lo mismo registro TXT no notificará a cada caché que la situación cambió.
Comience demostrando que el registro deseado ahora está presente en la autoridad correcta. Verifique el nombre completo del propietario, el tipo solicitado y cualquier alias objetivo. El almacenamiento en caché negativo es una hipótesis que se debe probar después de que se confirme la publicación, no una explicación conveniente para un récord que se creó en la zona equivocada o no ha sido atendido por todas las autoridades pertinentes.
Identificar lo que la respuesta anterior negó.
NXDOMAIN indica que un nombre no existe. NODATA describe una respuesta sin registros relevantes del tipo solicitado, en lugar de un código de respuesta DNS dedicado. Su código de encabezado habitual es NOERROR. Inspeccione la sección de autoridad y el procesamiento de alias para distinguir ese resultado de una referencia o una búsqueda sin terminar. Una sección de respuestas vacía por sí sola no es suficiente. RFC 2308 , secciones 2.1–2.2.
El alcance importa. Según el modelo de caché de RFC 2308 , una entrada de error de nombre está asociada con el nombre y la clase; una entrada sin datos también incluye el tipo solicitado. Si un alias precede a la respuesta negativa, establezca qué nombre final falta. Un alias de selector del lado del cliente puede existir incluso cuando su destino del lado del proveedor no existe. Eso requiere que investigue un propietario diferente al de un registro de cliente faltante.
Conserve el resultado anterior si está disponible. Una respuesta positiva actual no puede reconstruir el TTL y la sección de autoridad de una respuesta negativa obtenida ayer. Cuando no existe una captura anterior, digamos que el almacenamiento en caché negativo es consistente con las observaciones pero no está probado.
Calcule la vida útil a partir de los campos SOA correctos
Para una respuesta negativa autorizada, RFC 2308 establece la registro SOAen esa respuesta al TTL más pequeño del propio registro SOA y su campo MINIMUM. Luego, la vida útil negativa almacenada en caché cuenta atrás. Leer SOA.MINIMUM solo como temporizador universal de caché negativa está incompleto. RFC 2308 , secciones 3 a 5.
En un ejemplo ficticio, el TTL SOA de la zona es de 900 segundos y el MÍNIMO es de 3600. Una respuesta negativa generada utilizando esos valores tiene una vida útil negativa inicial de 900 segundos, no 3600. Si un solucionador lo obtuvo a las 12:00 y el nuevo selector se publicó a las 12:03, la entrada negativa anterior aún podría afectar a ese solucionador durante la ventana de caché ordinaria restante. Estos tiempos inventados ilustran el cálculo, no un incidente observado.
A las 12:05, una respuesta recursiva de muestra podría mostrar un TTL SOA reducido. Conserve lo que realmente informa en lugar de reemplazar ese valor con los campos configurados de una consulta SOA nueva. Es posible que otros cachés hayan adquirido diferentes respuestas en diferentes momentos y la política de resolución puede limitar el almacenamiento en caché. Un solo cálculo no establece la recuperación universal a las 12:15.
No confunda el almacenamiento en caché de ausencia con el almacenamiento en caché de fallas
SERVFAIL y un tiempo de espera no afirman que el registro esté ausente. Describen la imposibilidad de obtener un resultado utilizable. RFC 9520 actualiza las reglas de almacenamiento en caché negativas más antiguas al exigir el almacenamiento en caché en caso de fallo de resolución, incluido DNSSEC fallas de validación; su duración de caché de falla es de al menos un segundo y no más de cinco minutos. Esto es independiente del cálculo NXDOMAIN / NODATA derivado de SOA. RFC 9520 , secciones 3.2–3.4.
Las actualizaciones fallidas repetidas pueden generar más entradas de caché fallidas, por lo que el límite superior no es una garantía de recuperación de interrupciones. Si una búsqueda devuelve SERVFAIL después de una reparación, conserve la respuesta e investigue los diagnósticos del solucionador y la disponibilidad ascendente. No reemplace una política de autenticación simplemente porque un error de resolución se describió informalmente como un registro faltante.
Durante las fallas de actualización de autoridad, el comportamiento de servicio obsoleto también puede complicar la línea de tiempo, incluidos los datos negativos obsoletos. Registre si el solucionador afectado está configurado para ofrecer respuestas obsoletas cuando esa información esté disponible. No infiera la configuración a partir de una sola línea de salida. RFC 8767 , secciones 4 y 10.
Publicar nuevos nombres antes de que se conviertan en dependencias.
Para una rotación de selector planificada, prepare el nuevo registro público antes de cambiar el servicio de firma para usarlo. Verifique el propietario exacto y cualquier objetivo con los operadores responsables. Evite sondear repetidamente un nombre de producción no creado como si se esperara éxito; dichas consultas pueden establecer entradas de caché negativas antes de la publicación.
Si es necesaria una consulta de verificación previa, conserve su tiempo y respuesta. Incluya consideraciones de caché negativa en el plan de lanzamiento en lugar de ocultar una falla de verificación previa inconveniente. Un TTL más bajo en el registro TXT futuro no acorta retroactivamente una respuesta de ausencia ya almacenada en caché en otro lugar. Del mismo modo, limpiar la computadora portátil de un administrador no purga el solucionador de un proveedor de correo.
Cree un registro de recuperación acotado
La hoja de trabajo propuesta tiene una fila para cada punto final y observación: hora UTC, pregunta exacta, código de respuesta, respuesta o alias relevante, propietario de SOA y TTL devuelto, y autoridad o función de recursividad. Compare los resultados autorizados actuales con la ruta recursiva afectada y un solucionador de comparación identificado por separado. Conserve las respuestas completas y repita en un intervalo documentado razonable.
Si a la autoridad le falta el registro, arreglar la publicación. Si la autoridad es correcta y una entrada negativa capturada explica el resultado recursivo, realice un seguimiento de esa ruta de caché específica. Si aparecen SERVFAIL , referencias o autoridades inconsistentes, investigue esas ramas en su lugar. Finalmente, verifique un mensaje controlado usando el nuevo selector. Este artículo contiene aritmética ficticia y únicamente un flujo de trabajo propuesto. Las comparaciones de los resolutores originales y los resultados de los mensajes recibidos siguen pendientes, por lo que la puerta de evidencia operativa del catálogo aún está abierta.