Arvioi seuraus varoitusvärin sijaan
DNS -kunnontarkistus voi yhdistää protokollavirheet, kestävyyssuositukset ja valinnaiset ominaisuudet yhdeksi hälyttäväksi pisteeksi. Postioperaattorit tarvitsevat erilaisen järjestyksen: mihin päätökseen se vaikuttaa, millä reitillä ja millä todisteilla? Ei saatavilla oleva aktiivinen DKIM avain ja suositus alemmalle TTL:lle eivät saa automaattisesti saada samaa tapahtumaprioriteettia.
Aloita tallentamalla tarkka varoitus, testattu nimi ja tietuetyyppi, aika, ratkaiseja tai näkökulma sekä työkalun selitys. Luokittele se havaituksi epäonnistumiseksi, uskottavaksi riskiksi tai neuvoa-antavaksi suositukseksi. Jos työkalu sisältää vain etiketin, säilytä tämä rajoitus. Älä julkaise toista todennustietuetta vain tehdäksesi kojelaudan vihreäksi.
Selvitä, kuuluuko testattu nimi postipolkuun
Poissaolevalla DKIM tietueella on merkitystä vain suhteessa valitsin ja tutkimuksen kohteena olevan palvelun tosiasiallisesti käyttämä allekirjoitusverkkotunnus. RFC 6376 kohta 3.6.2.1 johtaa hakunimen allekirjoitusarvoista. Skanneri, joka arvaa valitsimen, saattaa unohtaa kelvollisen käyttöönotetun avaimen tai varoittaa käyttämättömästä nimestä. Pyydä edustavaa viestitodistusta, ennen kuin käsittelet oletetun poissaolon tuotantohäiriönä.
Käytä samaa kurinalaisuutta SPF. Työkalu, joka tarkistaa näkyvän From-toimialueen, ei ehkä tarkista vastaanottimen arvioimaa SMTP identiteettiä. RFC 7208 osa 2 erottaa nuo identiteetit. Määritä reitti ja todellinen arvioitu nimi ennen kuin päätät, kenen omistajan tulee korjata varoitus.
Etsi tällä hetkellä valtuutettu valtuutus, mukaan lukien kaikki asiaankuuluvat lapsialueen delegaatiot tai aliakset. Ohjauspaneeli on todiste aiotusta konfiguraatiosta vain, kun sen suhde kyseiseen viranomaiseen tunnetaan. Säilytä ero puuttuvan tietueen, väärän nimen arvon ja väärällä isännöintitilillä tehdyn muokkauksen välillä.
Tulkitse vastaus ennen tietueen muuttamista
NXDOMAIN osoittaa, että kyseistä nimeä ei ole, kun taas NODATA tulos osoittaa, että pyydetty data puuttuu olemassa olevasta nimestä. Negatiivinen välimuisti voi säilyttää aiemmat tulokset, kuten kohdassa on kuvattu RFC 2308 kohdat 2 ja 5. Äskettäin luotu tietue voi siksi ilmestyä auktoriteetille ennen kuin tietty rekursiivinen polku näyttää sen.
SERVFAIL sen sijaan kuvaa ratkaisun epäonnistumista eikä todista, että käytäntö puuttuu. RFC 9520 kohta 2.1 käsittelee sen monia mahdollisia syitä. Tutki delegointia, tavoitettavuutta ja validointitodisteita. Päällekkäisten tietueiden lisääminen resoluution ollessa rikki voi jättää toisen ongelman alkuperäisen vian korjaamisen jälkeen.
Varoitus TCP-tuesta ansaitsee enemmän kuin kosmeettisen irtisanomisen. RFC 7766 jakso 5 vaatii yleiskäyttöisiä DNS -toteutuksia tukemaan sekä UDP:tä että TCP:tä. Pieni onnistunut haku ei varmista, että suuremmat vastaukset tai muut polut toimivat oikein. Oikea seuranta on laajennettu kuljetusdiagnoosi, ei väite, että jokainen nykyinen viesti on jo epäonnistunut.
Erottele välitön vaikutus piilevasta riskistä
Välitön sähköpostiin vaikuttava löydös yhdistää havaitun DNS ongelman aktiiviseen reittiin: esimerkiksi valitsimen ratkaisijavika, jota vastaanottaja tarvitsi vahvistushetkellä. Piilevä luotettavuusongelma saattaa jättää nykyiset testit läpäisemään ja samalla heikentää joustavuutta. Neuvoa-antava havainto voi koskea toivottavaa ominaisuutta, jonka puuttuminen ei mitätöi todellisuudessa käytettyjä protokollia.
Luokittele kahdella ulottuvuudella: luottamus havaintoon ja seuraus, jos tilanne jatkuu. Vaikuttava epäily, jossa on puutteellisia todisteita, voi vaatia kiireellistä tutkintaa ilman keskeytysilmoitusta. Vanhentuneen neuvoa-antavan poikkeuksen pitäisi saada omistaja ja tarkistuspäivämäärä sen sijaan, että se katoaisi hiljaa raportista.
Vältä peittotarroja, kuten "DNSSEC puuttuminen tarkoittaa, että sähköpostin todennus on rikki." DNSSEC voi lisätä todennettuja DNS tietoja, kun taas SPF , DKIM ja DMARC niillä on omat vaatimuksensa ja tuloksensa. Jossa DANE SMTP on käytössä, DNSSEC on suora rooli kyseisessä kuljetussuunnittelussa RFC 7672 kohta 2.1. Samalla varoituksella voi siis olla erilaisia seurauksia eri palveluissa.
Kuvitteellinen esimerkki kolmesta varoituksesta
Kuvitteellinen tarkistustoiminto example.com raportoi poissaolevan valitsimen nimeltä oletus, epäonnistuneen TCP-haun yhteen arvokkaaseen päätepisteeseen ja TTL-suosituksen. Postitiimin keksimä inventaario tunnistaa kesäkuun aktiivisen laskureitin käyttämäksi valitsimeksi. Ensimmäinen varoitus vaatii siksi valitsimen vahvistuksen välittömän tietueen luomisen sijaan.
Toinen varoitus lähetetään DNS omistajalle, jossa on testattu päätepiste, aika ja vaikutuksen alaisen vastauksen tiedot. Se edustaa kuljetusongelmaa, vaikka yksi pieni UDP-kysely onnistui. TTL-suosituksesta tulee muutossuunnittelukeskustelu: TTL:n vähentäminen saattaa auttaa tulevia muutoksia, mutta se ei osoita nykyistä toimitushäiriötä tai lyhennä välittömästi jo välimuistissa olevia merkintöjä vanhemmalla arvolla.
Mitään kyselyä tai viestiä ei suoritettu tälle skenaariolle. Sen ehdotetut prioriteetit havainnollistavat, kuinka vältetään kojelaudan sekapisteiden käsittely teknisenä tuomiona. Todellinen luokittelu edellyttäisi, että säilytetään arvovaltaisia ja rekursiivisia tuloksia ja todisteita, jotka sitoisivat testatut tietueet palveluun.
Kirjaa päätös, joka voidaan tarkistaa
Kirjaa jokaisen varoituksen kohdalla muistiin vaikuttanut riippuvuus, todisteet, luottamus, omistaja, seuraava toimenpide ja sulkemisehto. "Tarkista myöhemmin" on epätäydellinen ilman, että se tunnistaa, mikä on muuttunut ja mitä seuraavan havainnon on määritettävä. "Hyväksytty riski" sisältää sen, kuka sen hyväksyi ja milloin päätöstä harkitaan uudelleen.
Valtuutetun korjauksen jälkeen toista asiaankuuluva havainto ja tarkista riippuvainen palvelu sen sijaan, että päivittäisit vain alkuperäisen tuloksen. Säilytä ratkaisemattomat erot auktoriteettien, rekursiivisten polkujen ja viestitulosten välillä. Alkuperäisten todisteiden portti pysyy auki, kunnes aikaleimatut arvovaltaiset ja rekursiiviset vastaukset tunnistavat tarkan omistajan nimen ja tietuetyypin. Tämä käsikirjoitus ei tarjoa näitä havaintoja tai todista verkkotunnuksen terveyttä.