Määritä, mikä DNS palvelu hallitsee muutosta
Todennustietueen julkaiseminen on muutos toimialueen luottamuskokoonpanoon. Aloita tunnistamalla valtuutettu virallinen palvelu, oikea DigitalOcean-tiimi ja tarkka vyöhyke, joka sisältää aiotun omistajan nimen. Dropletilla toimiva verkkosivusto ei määritä, missä sen verkkotunnuksen DNS isännöi. Tili, jossa näkyy verkkotunnus, ei myöskään todista julkisen delegoinnin osoittavan sinne.
DigitalOceanin DNS rajoitukset erottaa sen DNS -isännöinnin verkkotunnuksen rekisteröinnistä. He myös dokumentoivat vähintään 30 sekunnin TTL-tietueen ja ilmoittavat, että sen nimipalvelimet eivät tue DNSSEC-yhteensopivia verkkotunnuksia. Käsittele olemassa olevaa allekirjoitettua delegaatiota verkkotunnuksen omistajan yhteensopivuuspäätöksenä, ei kehotuksena poistaa suojaus käytöstä sähköpostin määritysharjoituksen aikana. Tämä opas olettaa jo hyväksytyn, yhteensopivan DigitalOceanin isännöimän vyöhykkeen; se ei siirrä delegointia tai muuta DNSSEC.
Määritä haluamasi muutos ennen editorin avaamista. Tunnista jokaiselle ehdotetulle tietueelle sen toimittanut lähetyspalvelu, sen tukema liiketoiminnan kulku, odotettu omistaja ja tietuetyyppi sekä hyväksyjä. Säilytä aiheeseen liittymättömät verkko-, saapuvat sähköpostit ja vahvistukset muutoksen ulkopuolella, ellei tietty riippuvuus vaadi tarkistamista.
Säilytä käyttökelpoinen lähtökohta
Palveluntarjoaja dokumentoi vyöhykkeen latausvaihtoehdon kohdassa Verkko, Domains ja toimialueen Lisää-valikko. Sen vyöhykkeen vientiohjeet kuvaile pelkkä tekstitiedosto, joka sisältää vyöhykkeen tietueet. Käytä valtuutettua vientiä elvytyssuunnitelman yhtenä syötteenä, johon liittyy ehdotettu ero, tietueen omistajuus ja hyväksytty palautuskriteeri. Vienti ei ole todiste palautuspainikkeen olemassaolosta tai siitä, että edellinen tila voidaan palauttaa vaikuttamatta myöhempiin muutoksiin.
Anna ehdotettuun todistelomakkeeseen aiotun omistajan nimi oma sarake. Tietueen tyyppi ja arvo kuuluvat eri sarakkeisiin. Tämä estää yleisen tarkistusvirheen: väärään DNS nimeen on liitetty muuten oikea käytäntö, koska koko omistaja, suhteellinen tunniste ja tekstiarvo käsiteltiin vaihdettavina merkkijonoina.
Käytä dokumentoitua editorimallia
Nykyinen tietueenhallintaopas reitittää operaattorit Networking-, Domains- ja valitun toimialueen kautta ja sitten Luo ennätys. TXT :ssä Isäntänimi-kenttä hyväksyy apex-merkin @ tai aliverkkotunnuksen etuliitettä, kun taas TXT arvo sisältää tekstin. Se kuvaa SPF ja suora DKIM avainjulkaisu TXT kautta ja tukee NS-tietueita aliverkkotunnuksen delegoinnissa.
Käännä pyydetty täysin pätevä omistaja kyseisen vyöhykkeen sisääntulomalliksi tarkoituksella. Kuvitteelliselle example.com -vyöhykkeelle suhteellinen DMARC tunniste _dmarc edustaa osoitetta _dmarc.example.com . Tämä on selitys nimen rakentamisesta, ei ehdotettu vakuutusarvo tai väite siitä, että jokin tietue on tallennettu. Odotettu julkinen omistaja tulee tarkistaa riippumatta siitä, miten se näkyy lomakkeessa.
Käytä lähetyspalvelun ajankohtaista, tilikohtaista materiaalia a DKIM valitsin, julkinen avain tai delegoitu kohde. DNS isäntä ei valitse lähettäjän allekirjoitusidentiteettiä. Jos palvelu vaatii a CNAME suoran TXT -avaimen sijaan säilytä tämä ero ja tarkasta tarkka omistaja olemassa olevien riippuvuuksien varalta ennen vaihtamisen hyväksymistä. Älä koskaan päättele puuttuvaa kohdetta toisen asiakkaan asetusten kuvakaappauksesta.
Pidä todennustietueet loogisesti erillään
RFC 7208 kohdat 3.2 ja 3.3 erottaa useita ehdokkaita SPF tietueita useista merkkijonoista yhden tietueen sisällä. Älä lisää toista kilpailevaa SPF -käytäntöä uudelle palvelulle. Lainaus tai merkkijonon jakaminen näytössä ei sinänsä kerro, arvioidaanko yksi vai useampi tietue. Tarkista palautetut tietueen rajat ja tuloksena oleva ketjutettu arvo.
DKIM :lle RFC 6376 kohta 3.1 sitoo avaimen haun valitsin- ja allekirjoitustoimialueeseen. Pelkkä julkaisu ei voi osoittaa, että sovellus valitsi kyseisen avaimen tai allekirjoitti tarkoitetun viestin. Lähettäjämäärityksen ja julkisen DNS materiaalin on viitattava samaan suunniteltuun identiteettiin.
DMARC kuuluu sovellettavalle _dmarc omistajalle, ei sinne, missä SPF tietue sattuu olemaan. RFC 9989 kohdat 4.1 ja 4.4 kuvaile politiikkaa ja linjaus suhdetta. Vain DNS-tulos ei ole osoitus onnistuneesta kohdistetusta postista, eikä todennusmekanismi, joka ei liity toisiinsa, riitä.
Tarkista julkaisu ja todellinen käyttö eri tuloksina
Valtuutetun vahvistussuunnitelman tulee sisältää arvovaltaiset vastaukset ennen hyväksyttyä muokkausta ja sen jälkeen, mukaan lukien palvelin, aikaleima, omistaja, tyyppi, TTL ja täydellinen tietuejoukko. Pidä poissa oleva vastaus erotettavissa aikakatkaisusta tai väärälle palvelimelle lähetetystä kyselystä. Vain kojelaudan kuvakaappauksen vertaaminen toiseen kojelaudan kuvakaappaukseen jättää julkisen julkaisun huomiotta.
Hanki seuraavaksi ohjattu viesti todellisen sovelluskulun kautta ja säilytä luotettavat vastaanottimen tulokset. Vertaa sen näkyvää Lähettäjä-verkkotunnusta, kirjekuoren identiteettiä, DKIM allekirjoitusverkkotunnusta ja valitsinta hyväksyttyyn kokoonpanoon. Tallenna todennus ja kohdistus erillään toimituksesta tai kansioon sijoittamisesta. Onnistunut DNS haku ei saa täyttää tyhjää viestitestisolua.
Jos havaittu omistaja tai arvo poikkeaa suunnitelmasta, keskeytä muut muutokset ja tunnista pienin hyväksytty palautustoimi. Välimuisti voi säilyttää aikaisemman vastauksen, joten palautuksen havainnointi vaatii ajoituksen ja kontekstin pikemminkin kuin lupauksen välittömästä maailmanlaajuisesta johdonmukaisuudesta. Pidä tapahtumatietue riittävän täsmällisenä erottaaksesi syöttövirheen vanhentuneista tiedoista tai passiivisista lähetysmäärityksistä.
Kuvitteellinen arvostelu ja erinomainen todiste
Kuvitteellinen arvioija saa luonnoksen, joka sisältää pätevän näköisen DMARC arvon osoitteen example.com huipussa. Tarkistaja havaitsee omistajan ristiriidan ennen lähettämistä ja muuttaa ehdotetuksi omistajaksi _dmarc . Tehtävälistalla ei edelleenkään ole arvovaltaisia ennen/jälkeen vastauksia eikä vastaanotettua viestiä. Se on paperikatsaus, ei onnistunut DigitalOcean-opastus.
Täsmällinen alkuperäinen vaatimus jää avoimeksi: nykyinen DigitalOcean-julkaisun läpikäynti, jossa on arvovaltaiset ennen/jälkeen kyselyt ja itsenäisesti vahvistettu viesti. Käyttöönottoportti on: Vahvista tuotteen nykyinen tunniste ja toimittajan omistama dokumentaatio; testaa todellista viestiä tai julkaistuja tietueita. Ilmoita ei-tuetut mukautetun verkkotunnuksen ominaisuudet rehellisesti. Dokumentaatio tukee tätä ehdotettua työnkulkua, mutta vuokralaisen soveltuvuus, alkuperäiset testit, tekninen pk-yritystarkastus, reaaliaikainen visuaalinen tarkastus ja omistajan julkaisun hyväksyntä jäävät ratkaisematta. DNS tai tilitoimintoa ei ole suoritettu.