Korvaa leviämisen määräaika muutossuunnitelmalla
DNS TTL auttaa määrittämään, milloin välimuistissa olevia tietoja harkitaan uudelleen. Se ei ajoita yhtäkään maailmanlaajuista hetkeä, jolloin jokainen vastaanotin alkaa käyttää korvaavaa vastaanotinta SPF politiikkaa tai DKIM avain. Eri ratkaisijat saivat vanhan vastauksen eri aikoina, kaikki arvovaltaiset palvelimet eivät välttämättä palvele uusia tietoja ja sovelluksilla voi olla oma haku- ja uudelleenyrityskäyttäytyminen.
Hyödyllinen muutossuunnitelma erottaa arvovaltaisen julkaisun loppupään havainnoista. " DNS isäntä hyväksyi muokkauksen" on aikaisempi virstanpylväs kuin "asianmukaiset arvovaltaiset palvelimet palauttavat aiotun vastauksen". Kumpikaan lausunto ei kerro, mitä tietty sähköpostin vastaanottaja käytti minuutti sitten lähetetyssä viestissä. Aloita aikajanalla todisteet jokaisesta virstanpylvästä sen sijaan, että ilmoitat yleisen lupauksen siitä, että DNS kestää tietyn määrän tunteja.
Selvitä, mitä TTL:ää tarkkaillaan
Arvovaltaisella resurssitietueella on TTL, joka liittyy sen julkaistuihin tietoihin. Välimuistissa oleva vastaus raportoi tavallisesti välimuistissa olevien tietojen jäljellä olevan käyttöiän, joten kaksi rekursiivista ratkaisijaa voivat palauttaa identtisen tekstin erilaisilla jäljellä olevilla TTL:illä. Nämä arvot kuvaavat erilaisia välimuistitiloja; ne eivät ole kaksi kilpailevaa ilmoitusta tietueen aiotusta konfiguraatiosta. RFC 1035 , kohta 4.1.3; RFC 1034 , kohta 6.2.1.
Jos olemassa olevalla tietueella on pitkä TTL, tämän arvon pienentäminen ei ulotu taaksepäin välimuistiin, joissa on jo tallennettu vanhempi vastaus. Suunnittele vähennys ennen olennaista muutosta ja ota huomioon aikaisempi välimuistiikkuna. Varmista, että alempi TTL on todella käytössä, ennen kuin käsittelet sitä osana huoltosuunnitelmaa. Tämä on suunnitteluohje, ei todiste siitä, että jokaista kätköä on havaittu.
Aliasketju lisää selkeitä riippuvuuksia. Aliastietueella ja kohteen tietuejoukolla voi olla eri TTL:t ja eri operaattorit. Lyhyt TTL asiakaspuolella CNAME ei pakota jo välimuistissa olevaa kohdeavainta päivittymään samalla hetkellä. Kirjoita molemmat nimet muistiin ennen kuin yrität selittää ajoitusta.
Mallina vanhat ja uudet vastaukset erikseen
Harkitse kuvitteellista SPF päivitystä osoitteessa mail.example.com. Ratkaisija A saa vanhan käytännön klo 09.50 TTL:llä 3 600 sekuntia. Klo 10.00 valtuutettu operaattori muuttaa julkaistun TTL:n arvoon 300. Klo 10.10 operaattori vaihtaa käytännön. Ratkaisija A:n aikaisempi merkintä voi edelleen olla käytettävissä sen alkuperäisen välimuistin käyttöiän aikana klo 10.50 asti, ilman muuta toimintaa. Toinen ratkaiseja, joka etsii ensin 10:10 jälkeen, voi jo palauttaa korvaavan tuotteen.
Tämä toimiva esimerkki on keksitty aritmetiikka, ei mittaus tai taattu vanhenemisaikataulu. Sen opetus on, että TTL:n alentaminen klo 10:00 ei kirjoita uudelleen Resolver A:n 09:50-merkintää. Operatiivisen laskentataulukon tulee säilyttää aiemmat tiedot, edellinen TTL, aika, jolloin TTL-muutos havaittiin viranomaisella, aika, jolloin sisältö muuttui, ja myöhemmät otoksiset ratkaisuvastaukset.
Säilytä erilliset virstanpylväät uuden julkaisemista varten DKIM kiertoa varten valitsin, varmistaa sen saatavuuden, käynnistää sitä käyttävät allekirjoitukset ja poistaa vanhan valitsimen käytöstä. DNS välimuistin aritmetiikka ei yksin voi päättää, milloin aiemmin lähetetyt viestit on tarkistettu. Myös lähettäjän jonotus-, uudelleenyritys- ja säilytysvaatimukset kuuluvat kiertopäätökseen. RFC 6376 , kohdat 3.1 ja 3.6.
Sisällytä kielteiset vastaukset ja käyttökatkoskäyttäytyminen
Äskettäin luodulla nimellä ei välttämättä ole vanhaa positiivista kirjaa. Ratkaisija voisi sen sijaan sisältää aikaisemman NXDOMAIN tai NODATA tuloksen. Kielteisen vastauksen SOA-pohjainen käyttöikä on eri arvo kuin juuri julkaistun TTL:n arvo TXT tietue. Uuden TXT TTL:n muuttaminen ei siis poista aiempaa välimuistissa olevaa poissaoloa. RFC 2308 , kohdat 3 ja 5.
Yksinkertaiseen vanhenemistarinaan liittyy myös selkeä standardipoikkeus. RFC 8767 sallii vanhentuneiden tietojen näyttämisen, kun vanhentunutta merkintää ei voida virallisesti päivittää. Se, tapahtuuko näin, riippuu ratkaisejasta ja vikaolosuhteista. Älä oleta, että palautettu vastaus on tuore, koska sillä on pieni nollasta poikkeava TTL. RFC 8767 , kohdat 4–5.
Näiden tapausten tulisi muuttaa tutkintaa, ei kutsua mielivaltaiseen ylimääräiseen odotusaikaan. Jos viranomaiset ovat eri mieltä, korjaa julkaisun johdonmukaisuus. Jos kielteinen vastaus jatkuu, tarkista sen alkuperäinen kysymys ja SOA-konteksti. Jos valtuuksia ei voida saavuttaa, palauta tai tutki saatavuus sen sijaan, että muokkaat toistuvasti jo oikeaa TXT tietuetta.
Valitse havainnot, jotka vastaavat julkaisukysymykseen
Tallenna ennen muutosta tarkka tietue ja sen TTL asiaankuuluvilta viranomaisilta ja valituilta rekursiivisilta poluilta. Toista myöhemmin sama omistaja, tyyppi ja luokka samoissa päätepisteissä. Sisällytä vaikutusalueeseen liittyvä polku, jos se on saatavilla. useat julkiset ratkaisijat jäävät näytteiksi, ei jokaisen postin vastaanottajan laskentaa.
Ehdotettu kysely on dig @RESOLVER_IP mail.example.com . TXT, yhdistettynä dig @AUTH_IP mail.example.com . TXT +norecurse. Tallenna täydelliset vastaukset UTC-aikaleimoilla ja merkitse kaikki paikkamerkit ennen käyttöä. Paikallisen välimuistin tyhjennys muuttaa vain paikallista välimuistipolkua. Se ei voi tyhjentää etävastaanottimen rekursiivista välimuistia, joten se ei ole yleinen loppuunsaannin ohjaus.
Ilmoita tulos tarkasti: mitkä viranomaiset ovat samaa mieltä, mitkä otokseen valitut ratkaisijat palauttavat uuden arvon ja mitkä havainnot puuttuvat. Lähetä sitten ohjattu viesti aiotun palvelun kautta ja tarkasta todelliset todennustunnukset ja vastaanottajan tulos. Tälle luonnokselle ei tehty DNS kyselyitä tai viestitestejä. Vaadittu ratkaisijavertailu, mukaan lukien TTL, vastaustyyppi, auktoriteetti ja havaintoaika, jää avoimeksi.