Udskift udbredelsesfristen med en ændringsplan
En DNS TTL hjælper med at bestemme, hvornår cachelagrede oplysninger genovervejes. Det planlægger ikke et verdensomspændende øjeblik, hvor hver modtager begynder at bruge en erstatning SPF politik eller DKIM nøgle. Forskellige resolvere fik det gamle svar på forskellige tidspunkter, autoritative servere serverer muligvis ikke alle de nye data, og applikationer kan have deres eget opslag og genforsøg.
En nyttig ændringsplan adskiller autoritativ publicering fra downstream-observation. " DNS værten accepterede redigeringen" er en tidligere milepæl end "de relevante autoritative servere returnerer det tilsigtede svar." Ingen af erklæringerne fastslår, hvad en specifik mailmodtager brugte til en besked sendt for et minut siden. Start tidslinjen med beviser for hver milepæl i stedet for et generisk løfte om, at DNS tager et fast antal timer.
Forstå hvilken TTL der observeres
En autoritativ ressourcepost har en TTL knyttet til dens offentliggjorte data. Et cachelagret svar rapporterer normalt den resterende levetid for cachelagrede data, så to rekursive resolvere kan returnere identisk tekst med forskellige resterende TTL'er. Disse værdier beskriver forskellige cachetilstande; de er ikke to konkurrerende erklæringer af rekordens tilsigtede konfiguration. RFC 1035 , afsnit 4.1.3; RFC 1034 , afsnit 6.2.1.
Hvis en eksisterende post har en lang TTL, vil reduktion af denne værdi ikke nå baglæns til caches, der allerede har gemt det ældre svar. Planlæg reduktionen forud for den indholdsmæssige ændring, og lad det forudgående cachingvindue tages i betragtning. Bekræft, at den nedre TTL faktisk bliver serveret, før du behandler den som en del af vedligeholdelsesplanen. Dette er planlægningsvejledning, ikke et bevis på, at hver cache er blevet observeret.
En aliaskæde tilføjer distinkte afhængigheder. Aliasposten og målets rekordsæt kan have forskellige TTL'er og forskellige operatører. En kort TTL på kundesiden CNAME tvinger ikke en allerede cachelagret målnøgle til at opdatere på samme tidspunkt. Skriv begge navne ned, før du prøver at forklare timingen.
Modeller de gamle og nye svar separat
Overvej en fiktiv SPF opdatering på mail.example.com. Resolver A opnår den gamle politik kl. 09:50 med en TTL på 3.600 sekunder. 10:00 ændrer den autoritative operatør den offentliggjorte TTL til 300. Kl. 10:10 erstatter operatøren politikken. Resolver A's tidligere indtastning kan stadig være brugbar under dens oprindelige cache-levetid indtil 10:50, uden anden adfærd. En anden resolver, der først ser efter 10:10, kan allerede returnere erstatningen.
Dette udførte eksempel er opfundet aritmetik, ikke en måling eller en garanteret udløbsplan. Dens lektie er, at sænkning af TTL kl. 10:00 ikke omskriver Resolver A's 09:50-indgang. Et operationelt regneark skal beholde de tidligere data, tidligere TTL, tidspunktet for TTL-ændringen blev observeret ved myndighed, tidspunktet for ændring af indholdet og efterfølgende samplede resolversvar.
For en DKIM rotation skal du beholde separate milepæle for udgivelse af det nye vælger, verificere dens tilgængelighed, starte signaturer, der bruger den og trække den gamle vælger tilbage. DNS cache-aritmetik alene kan ikke afgøre, hvornår tidligere sendt e-mail afsluttes med at blive bekræftet. Afsenderens krav til kødannelse, genforsøg og fastholdelse hører også med i rotationsbeslutningen. RFC 6376 , afsnit 3.1 og 3.6.
Inkluder negative svar og afbrydelsesadfærd
Et nyoprettet navn har muligvis ingen gammel positiv rekord til tid. En resolver kunne i stedet indeholde et tidligere NXDOMAIN eller NODATA resultat. Det negative svars SOA-baserede levetid er en anden værdi end TTL på den nyligt offentliggjorte TXT post. Ændring af den nye TXT TTL sletter derfor ikke et tidligere cachelagret fravær. RFC 2308 , afsnit 3 og 5.
Der er også en eksplicit standard undtagelse til en simpel udløbshistorie. RFC 8767 tillader visning af forældede data, når en udløbet post ikke kan opdateres autoritativt. Om det sker afhænger af resolveren og fejlforholdene. Antag ikke, at et returneret svar er frisk, blot fordi det har en lille TTL, der ikke er nul. RFC 8767 , afsnit 4-5.
Disse sager bør ændre undersøgelsen, ikke invitere til en vilkårlig ekstra ventetid. Hvis myndighederne er uenige, skal du rette offentliggørelsens konsistens. Hvis et negativt svar fortsætter, skal du undersøge dets oprindelige spørgsmål og SOA-kontekst. Hvis autoriteten ikke er tilgængelig, skal du gendanne eller undersøge tilgængeligheden i stedet for gentagne gange at redigere en allerede korrekt TXT post.
Vælg observationer, der besvarer udgivelsesspørgsmålet
Inden ændringen skal du fange den nøjagtige post og dens TTL fra de relevante myndigheder og udvalgte rekursive stier. Gentag derefter den samme ejer, type og klasse mod de samme endepunkter. Inkluder en sti, der er relevant for det berørte miljø, når den er tilgængelig; adskillige offentlige resolvere forbliver prøver, ikke en optælling af hver postmodtager.
En foreslået forespørgsel er dig @RESOLVER_IP mail.example.com . TXT, parret med dig @AUTH_IP mail.example.com . TXT +norecurse. Gem de fulde svar med UTC-tidsstempler og mærk alle pladsholdere før brug. En lokal cache-flash ændrer kun den lokale cache-sti. Det kan ikke rydde en fjernmodtagers rekursive cache, så det er ikke en global fuldførelseskontrol.
Rapportér resultatet præcist: hvilke myndigheder er enige, hvilke samplede resolvere returnerer den nye værdi, og hvilke observationer der mangler. Send derefter en kontrolleret besked gennem den tilsigtede tjeneste og inspicér de faktiske autentificeringsidentiteter og modtagerresultatet. Der blev ikke udført DNS -forespørgsler eller meddelelsestests for dette udkast. Den påkrævede resolver-sammenligning, herunder TTL, svartype, autoritet og observationstid, forbliver åben.