Sostituire la scadenza di propagazione con un piano di modifica
Un TTL DNS aiuta a determinare quando le informazioni memorizzate nella cache vengono riconsiderate. Non è previsto un momento mondiale in cui ogni ricevitore inizierà a utilizzare un ricambio SPF politica o DKIM chiave. Diversi risolutori hanno acquisito la vecchia risposta in momenti diversi, i server autorevoli potrebbero non servire tutti i nuovi dati e le applicazioni possono avere il proprio comportamento di ricerca e riprova.
Un utile piano di cambiamento separa la pubblicazione autorevole dall’osservazione a valle. "L'host DNS ha accettato la modifica" è una pietra miliare precedente rispetto a "i server autorevoli pertinenti restituiscono la risposta prevista". Nessuna delle due affermazioni stabilisce cosa abbia utilizzato uno specifico destinatario di posta per un messaggio inviato un minuto fa. Inizia la sequenza temporale con prove per ogni traguardo piuttosto che con una promessa generica che DNS impieghi un numero fisso di ore.
Comprendi quale TTL viene osservato
Un record di risorse autorevole ha un TTL associato ai suoi dati pubblicati. Una risposta memorizzata nella cache normalmente riporta la durata rimanente dei dati memorizzati nella cache, quindi due risolutori ricorsivi possono restituire testo identico con TTL rimanenti diversi. Questi valori descrivono diversi stati della cache; non sono due dichiarazioni concorrenti della configurazione prevista del record. RFC 1035 , sezione 4.1.3; RFC 1034 , sezione 6.2.1.
Se un record esistente ha un TTL lungo, la riduzione di tale valore non raggiunge le cache che hanno già archiviato la risposta precedente. Pianificare la riduzione prima della modifica sostanziale e consentire di considerare la finestra di memorizzazione nella cache precedente. Confermare che il TTL inferiore venga effettivamente servito prima di trattarlo come parte del piano di manutenzione. Questa è una guida alla pianificazione, non una prova che ogni cache sia stata osservata.
Una catena di alias aggiunge dipendenze distinte. Il record alias e il set di record della destinazione possono avere TTL e operatori diversi. Un breve TTL dal lato del cliente CNAME non forza l'aggiornamento contemporaneo di una chiave di destinazione già memorizzata nella cache. Annota entrambi i nomi prima di provare a spiegare i tempi.
Modella le risposte vecchie e nuove separatamente
Considera un aggiornamento SPF immaginario su mail.example.com. Il Resolver A ottiene la vecchia policy alle 09:50 con un TTL di 3.600 secondi. Alle 10:00 l'operatore autorevole modifica il TTL pubblicato in 300. Alle 10:10 l'operatore sostituisce la polizza. La voce precedente del Resolver A può ancora essere utilizzabile durante la durata della cache originale fino alle 10:50, in assenza di altri comportamenti. Un secondo risolutore che si occupa per primo di 10:10 potrebbe già restituire il rimpiazzo.
Questo esempio pratico è un'aritmetica inventata, non una misurazione o un programma di scadenza garantito. La sua lezione è che l'abbassamento del TTL alle 10:00 non riscrive la voce 09:50 del Resolver A. Un foglio di lavoro operativo dovrebbe conservare i dati precedenti, il TTL precedente, l'ora in cui è stata osservata la modifica del TTL all'autorità, l'ora in cui il contenuto è cambiato e le successive risposte campionate del risolutore.
Per una rotazione DKIM , conserva tappe separate per la pubblicazione del nuovo selettore, verificandone la disponibilità, avviando le firme che lo utilizzano e ritirando il vecchio selettore. L'aritmetica della cache DNS da sola non può decidere quando la posta inviata in precedenza finirà di essere verificata. Anche i requisiti di accodamento, riprovazione e conservazione del mittente rientrano nella decisione di rotazione. RFC 6376 , sezioni 3.1 e 3.6.
Includere risposte negative e comportamenti di interruzione
Un nome appena creato potrebbe non avere alcun record positivo precedente. Un risolutore potrebbe invece contenere un risultato NXDOMAIN o NODATA precedente. La durata basata su SOA della risposta negativa ha un valore diverso dal TTL della risposta appena pubblicata registrazione TXT. La modifica del nuovo TXT TTL quindi non cancella una precedente assenza memorizzata nella cache. RFC 2308 , sezioni 3 e 5.
Esiste anche un'esplicita eccezione agli standard per una semplice storia di scadenza. RFC 8767 consente di fornire dati non aggiornati quando una voce scaduta non può essere aggiornata in modo autorevole. Se ciò si verifica dipende dal risolutore e dalle condizioni di guasto. Non dare per scontato che una risposta restituita sia fresca semplicemente perché ha un TTL piccolo diverso da zero. RFC 8767 , sezioni 4–5.
Questi casi dovrebbero cambiare l’indagine e non richiedere un periodo di attesa aggiuntivo arbitrario. Se le autorità non sono d'accordo, correggere la coerenza della pubblicazione. Se una risposta negativa persiste, esamina la domanda originale e il contesto SOA. Se l'autorità non è raggiungibile, ripristina o esamina la disponibilità anziché modificare ripetutamente un record TXT già corretto.
Scegli le osservazioni che rispondono alla domanda di rilascio
Prima della modifica, acquisisci il record esatto e il relativo TTL dalle autorità competenti e dai percorsi ricorsivi selezionati. Successivamente, ripeti lo stesso proprietario, tipo e classe sugli stessi endpoint. Includere un percorso pertinente all'ambiente interessato quando disponibile; diversi risolutori pubblici rimangono esempi, non un censimento di tutti i destinatari della posta.
Una query proposta è dig @RESOLVER_IP mail.example.com . TXT, in coppia con dig @AUTH_IP mail.example.com . TXT +norecurse. Salva le risposte complete con timestamp UTC ed etichetta tutti i segnaposto prima dell'uso. Uno svuotamento della cache locale modifica solo il percorso di memorizzazione nella cache locale. Non può cancellare la cache ricorsiva di un ricevitore remoto, quindi non è un controllo di completamento globale.
Riportare il risultato in modo preciso: quali autorità sono d'accordo, quali risolutori campionati restituiscono il nuovo valore e quali osservazioni rimangono mancanti. Quindi invia un messaggio controllato tramite il servizio previsto e controlla le identità di autenticazione effettive e il risultato del destinatario. Per questa bozza non sono state eseguite query DNS o test dei messaggi. Il confronto del risolutore richiesto, incluso TTL, tipo di risposta, autorità e tempo di osservazione, rimane aperto.