Erilaisten arvovaltaisten palvelimien tulisi tarjota yhtenäinen näkymä palvelemastaan vyöhykkeestä. Jos todennustarkistukset eivät ole samaa mieltä, kysy jokaiselta mainostetulta viranomaiselta samaa omistajaa, tyyppiä ja luokkaa. Säilytä muokkaamattomat vastaukset ennen niiden normalisointia; ytimekäs arvoluettelo voi piilottaa viittaukset, virheet ja puuttuvat auktoriteetit.
Selvitä, mitkä palvelimet ovat tärkeitä
Viitteet: RFC 1034 §4.2, RFC 1035 §4.1.1.
Lue ylätason delegaatio ja vertaa sitä alihuipun NS-joukkoon. Ratkaise mainostetut palvelinnimet osoitteiksi ja kirjaa ylös, mitä osoitetta kysyttiin. Isäntänimellä voi olla useita osoitteita, ja anycast voi reitittää saman osoitteen eri esiintymiin. Yksi onnistunut kysely ei siis todista, että kaikki mahdolliset taustaohjelmat ovat ajan tasalla.
Käytä suoraa ei-rekursiivista kyselyä, kuten dig @SERVER_IP _dmarc.example .test. TXT +norecurse. Tarkista vastauskoodi ja AA-lippu, vastaus- ja valtuutusosat sekä mahdolliset aliakset. Viittaus tai ei-virallinen vastaus palvelimelta, jonka odotit olevan arvovaltainen, eroaa arvovaltaisesta vastauksesta, jonka sisältö on vanhentunut.
Vertaa tietoja tuhoamatta rakennetta
Viitteet: RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.
DNS -tietuejoukkojärjestys ei ole politiikan prioriteetti. Lajittele riippumattomat tietueobjektit vertailua varten, mutta säilytä merkkijonojärjestys jokaisen sisällä TXT tietue. TTL:t voivat vaihdella määrityksen tai kyselykontekstin vuoksi; äänitä ne sen sijaan, että hylkää ne äänettömästi. Rekursiivista TTL-laskentaa ei pidä verrata ikään kuin se olisi viranomaisen vyöhykekonfiguraatiota.
Kysy SOA:ta tukevana kontekstina. SOA-sarja ei ole vyöhykkeen hajautus. Vastaavat sarjat eivät voi todistaa vastaavia tietueita, ja suurempi painettu kokonaisluku ei ole yleisesti uudempi, koska sarjaaritmeettinen rivitys. RFC 1982 mukaan vertailut tasan puolet sarjatilasta toisistaan ovat määrittelemättömiä; älä pakota niitä uudempaan/vanhempaan tilaukseen. Vertaa pyydettyjä tietoja suoraan ja selitä erot toimittajan siirto- tai julkaisulokeilla.
Toista erimielisyydet ja vaarattomat uudelleenjärjestelyt
Luo kaksi erillistä auktoriteettia esimerkiksi.testille. Molemmat julkaisevat saman MX sarjan, mutta palauttavat tietueet eri järjestyksessä. Odotettu normalisoitu vertailu on yhtä suuri. Anna seuraavaksi valtuutus A _dmarc.example.test TXT "v=DMARC1; p=none" ja B _dmarc.example.test TXT "v=DMARC1; p=reject". Odotettu vertailu on epätasainen, vaikka molemmat SOA-sarjat olisivat tarkoituksella samat.
Tee kysely molemmille viranomaisille samalla tyypillä ja vaihtoehdoilla. Tallenna palvelimen osoite, aikaleima, vastauskoodi, liput, täydelliset tietueet ja sarja. Alkuperäistä offline-vertailua täydentää alla säilytetty historiallinen silmukkahavainto. Mitään julkista käytäntöä tai tuotannon DNS palvelinta ei muutettu.
Korjaa julkaisupolku
Viitteet: RFC 1034 §4.3.5, RFC 8767 §4.
Tarkista, onko yksi palvelin vanhentunut toissijainen, eläkkeellä oleva palveluntarjoaja, joka on edelleen delegoinnissa, vai kohde, joka ei koskaan saanut suunniteltua päivitystä. Korjaa tuettu julkaisu tai siirtopolku sen sijaan, että tekisit satunnaisia toistuvia muokkauksia useissa paneeleissa. Vahvista samat odotetut tiedot jokaisessa testatussa viranomaisessa muutoksen jälkeen.
Toista havainnot asiaankuuluvista verkoista, kun epäillään mitä tahansa lähetystä tai jaettuja näkymiä. Erota tahallinen näkemyspolitiikka vahingossa tapahtuvasta julkisesta epäjohdonmukaisuudesta. Viimeistele rekursiivisilla ja edustavilla sähköpostitodistuksilla, koska viranomainen ei yksinään voi poistaa välimuistissa olevia vastauksia tai todistaa viestin todennusta.
Säilytetty historiallinen laboratoriotodistus
Säilytetty kaappaus on päivätty 7. marraskuuta 2026. Seuraavassa kuvataan tätä rajoitettua historiallista havaintoa, ei EmailAuth.ai uutta suoritusta tai testiä.
Todelliset UDP-kyselyt kahdelle kiinteän vyöhykkeen takaisinsilmukan viranomaiselle palasivat p=none ja p=reject samalle absoluuttiselle TXT omistajalle. Molemmissa vastauksissa oli AA asetettu. Sieppaus säilyttää jokaisen päätepisteen, UTC-ajan, TTL:n, vastaustyypin, koodin ja lankatavut. Tämä osoittaa todellisen havaitun laboratorion epäjohdonmukaisuuden; se ei tutki julkista anycast-palvelua. Sieppaustunnisteet ovat Authority_A_policy; Authority_B_policy. Säilytetty juoksija ja raakakaappaukset sisältyvät tähän katsauspakettiin historiallisina todisteina. Ne tarkastettiin, ei uusittu tätä tarkistusta varten. Tuotanto DNS , DNSSEC ja SMTP tuloksia ei ole testattu.