Reemplazar la fecha límite de propagación con un plan de cambio
Un TTL DNS ayuda a determinar cuándo se reconsidera la información almacenada en caché. No programa un momento mundial en el que cada receptor empiece a utilizar un sustituto SPF política o DKIM llave. Diferentes solucionadores adquirieron la respuesta anterior en diferentes momentos, es posible que no todos los servidores autorizados proporcionen los nuevos datos y las aplicaciones pueden tener su propio comportamiento de búsqueda y reintento.
Un plan de cambio útil separa la publicación autorizada de la observación posterior. "El host DNS aceptó la edición" es un hito anterior a "los servidores autorizados relevantes devuelven la respuesta deseada". Ninguna declaración establece qué utilizó un receptor de correo específico para un mensaje enviado hace un minuto. Comience el cronograma con evidencia para cada hito en lugar de una promesa genérica de que DNS requiere una cantidad fija de horas.
Comprender qué TTL se está observando
Un registro de recursos autorizado tiene un TTL asociado con sus datos publicados. Una respuesta almacenada en caché normalmente informa la vida útil restante de los datos almacenados en caché, por lo que dos solucionadores recursivos pueden devolver texto idéntico con diferentes TTL restantes. Esos valores describen diferentes estados de caché; no son dos declaraciones en competencia de la configuración prevista del registro. RFC 1035 , sección 4.1.3; RFC 1034 , sección 6.2.1.
Si un registro existente tiene un TTL largo, reducir ese valor no retrocede a las cachés que ya almacenaron la respuesta anterior. Planifique la reducción antes del cambio sustancial y permita que se considere la ventana de almacenamiento en caché anterior. Confirme que el TTL inferior realmente se esté atendiendo antes de tratarlo como parte del plan de mantenimiento. Esta es una guía de planificación, no una prueba de que se hayan observado todos los cachés.
Una cadena de alias agrega dependencias distintas. El registro de alias y el conjunto de registros del objetivo pueden tener diferentes TTL y diferentes operadores. Un TTL corto del lado del cliente CNAME no obliga a que una clave de destino ya almacenada en caché se actualice en el mismo momento. Escriba ambos nombres antes de intentar explicar el momento.
Modele las respuestas antiguas y nuevas por separado.
Considere una actualización ficticia SPF en mail.example.com. El solucionador A obtiene la política anterior a las 09:50 con un TTL de 3600 segundos. A las 10:00, el operador autorizado cambia el TTL publicado a 300. A las 10:10, el operador reemplaza la póliza. La entrada anterior del solucionador A aún se puede utilizar durante su vida útil de caché original hasta las 10:50, en ausencia de otro comportamiento. Es posible que un segundo solucionador que se ocupe primero de las 10:10 ya devuelva el reemplazo.
Este ejemplo elaborado es aritmética inventada, no una medición o un cronograma de vencimiento garantizado. Su lección es que bajar el TTL a las 10:00 no reescribe la entrada de las 09:50 del Resolver A. Una hoja de trabajo operativa debe conservar los datos anteriores, el TTL anterior, la hora en que se observó el cambio de TTL en la autoridad, la hora en que cambió el contenido y las respuestas de resolución de muestra posteriores.
Para una rotación DKIM , conserve hitos separados para publicar el nuevo selector, verificando su disponibilidad, iniciando firmas que lo utilizan y retirando el antiguo selector. La aritmética de la caché DNS por sí sola no puede decidir cuándo terminará de verificarse el correo enviado anteriormente. Los requisitos de cola, reintento y retención del remitente también pertenecen a la decisión de rotación. RFC 6376 , secciones 3.1 y 3.6.
Incluir respuestas negativas y comportamientos de interrupción
Es posible que un nombre recién creado no tenga ningún registro positivo antiguo en el tiempo. En cambio, un solucionador podría contener un resultado anterior NXDOMAIN o NODATA . La vida útil basada en SOA de la respuesta negativa es un valor diferente del TTL en la publicación recientemente publicada. registro TXT. Por lo tanto, cambiar el nuevo TXT TTL no borra una ausencia anterior en caché. RFC 2308 , secciones 3 y 5.
También existe una excepción estándar explícita para una historia de vencimiento simple. RFC 8767 permite entregar datos obsoletos cuando una entrada caducada no se puede actualizar con autoridad. Que eso ocurra depende del solucionador y de las condiciones de falla. No asuma que una respuesta devuelta es nueva simplemente porque tiene un TTL pequeño distinto de cero. RFC 8767 , secciones 4 a 5.
Estos casos deberían cambiar la investigación, no invitar a un período de espera adicional arbitrario. Si las autoridades no están de acuerdo, corrija la coherencia de la publicación. Si persiste una respuesta negativa, inspeccione su pregunta original y el contexto SOA. Si no se puede acceder a la autoridad, restaure o investigue la disponibilidad en lugar de editar repetidamente un registro TXT que ya es correcto.
Elija observaciones que respondan a la pregunta de publicación.
Antes del cambio, capture el registro exacto y su TTL de las autoridades pertinentes y las rutas recursivas seleccionadas. Luego, repita el mismo propietario, tipo y clase en los mismos puntos finales. Incluir un camino relevante para el entorno afectado cuando esté disponible; Varios solucionadores públicos siguen siendo muestras, no un censo de cada receptor de correo.
Una consulta propuesta es cavar @RESOLVER_IP mail.example.com . TXT, emparejado con cavar @AUTH_IP mail.example.com . TXT +norecurso. Guarde las respuestas completas con marcas de tiempo UTC y etiquete todos los marcadores de posición antes de usarlos. Un vaciado de caché local cambia solo esa ruta de almacenamiento en caché local. No puede borrar la caché recursiva de un receptor remoto, por lo que no es un control de finalización global.
Informe el resultado con precisión: qué autoridades están de acuerdo, qué resolutores muestreados devuelven el nuevo valor y qué observaciones siguen faltando. Luego envíe un mensaje controlado a través del servicio previsto e inspeccione las identidades de autenticación reales y el resultado del receptor. No se realizaron consultas DNS ni pruebas de mensajes para este borrador. La comparación de resolución requerida, incluido TTL, tipo de respuesta, autoridad y tiempo de observación, permanece abierta.