[ DNS ja verkkotunnukset ]

DNS CAA -tietueet: ymmärrä niiden rooli varmenteiden myöntämisessä

Yhdistä CAA:n myöntäjän valtuutus todellisiin varmenteiden työnkulkuihin, erottele yleismerkkisäännöt ja uusimisriskit ja pidä varmenteiden hallinta erillään sähköpostin todentamisesta.

EmailAuth -tutkimusryhmä · 9 min lukuaika

[Avainkohdat]

  • CAA hallitsee varmenteiden myöntämistä, ei sähköpostin lähettäjän todennusta.
  • Tarkista kunkin pyydetyn varmenteen nimen soveltuva tietuejoukko.
  • Vahvista hallinnoitu myöntäminen ja uusiminen ennen kuin hyväksyt CAA-muutoksen.
Tällä sivulla
  1. Keskeiset kohdat
  2. Takeaway
  3. Roolin mukaan
  4. Usein kysytyt kysymykset
  5. Lähteet
  6. Sanasto
  7. Aiheeseen liittyviä oppaita

[ Takeaway ]

Valtuuta vain dokumentoitujen varmenteiden työnkulkujen edellyttämät myöntäjät, säilytä jokerimerkkien ja aliasten käsittelyn vivahteet ja testaa uusiminen ilman, että CAA lasketaan SPF , DKIM tai DMARC todistuksiksi.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Varastotodistusten riippuvuudet

Brändätyt sähköpostipalvelun päätepisteet voivat riippua hallitun varmenteen uusimisesta.

Seuraavat vaiheet

  1. Listaa tarkat nimet ja varmenneoperaattorit.
  2. Hanki tuetut myöntäjän tunnisteet.
  3. Testaa varsinaista uusimisen työnkulkua.

CISO / SecOps

Tee valtuutus tarkoituksellisesti

Ilmailulaitoksen politiikan tulisi heijastaa hyväksyttyä liikkeeseenlaskijan viranomaista kumuloituneiden poikkeuksien sijaan.

Seuraavat vaiheet

  1. Tarkista jokainen uusi liikkeeseenlaskija.
  2. Tarkista jokerimerkkien ja kriittisten ominaisuuksien toiminta.
  3. Säilytä erilliset sähköpostin todennuksen hallintalaitteet.

Perustaja / ei-tekninen

Vältä viivästynyt HTTPS-katkos

DNS -käytännön muutos voi näyttää vaarattomalta varmenteen uusimiseen asti.

Seuraavat vaiheet

  1. Määritä hallinnoitujen päätepisteiden omistajuus.
  2. Vaadi uusimisen kestävä käyttöönottosuunnitelma.
  3. Eskaloi vahvistamattomat palveluntarjoajan riippuvuudet ennen julkaisua.

[ UKK ]

Usein kysytyt kysymykset

Todentaako CAA verkkotunnuksestani lähetetyt viestit?

Ei. Se ilmaisee varmenteen myöntämisvaltuutuksen. SPF , DKIM ja DMARC määrittävät erilaiset sähköpostin todennusominaisuudet.

RFC 8659

Peruuttaako CAA:n uusi käytäntö olemassa olevat sertifikaatit?

Ei. CAA on myöntämisen valvontaviranomainen. Olemassa olevan varmenteen voimassaolo ja peruuttaminen ovat eri mekanismeja, joten toimiva vanha varmenne ei ole uusimistodistus.

RFC 8659

Rajoittaako issuewild ei-wildcard-varmennepyyntöjä?

Ei. Se koskee jokerimerkkien myöntämistä. Jokerimerkkipyynnöissä asiaankuuluvat issuewild-ominaisuudet ovat ensisijaisia ​​julkaisuun nähden; ilman issuewildiä, kysymys hallitsee myös jokerimerkkien myöntämistä.

RFC 8659

Vaaditaanko CAA-tietue jokaisessa isäntänimessä?

Ei välttämättä. Relevanttijoukko-algoritmi kyselee pyydettyä nimeä ja kiipeää sen päänimiin, kunnes se löytää CAA-joukon, jossa aliakset käsitellään tavallisella DNS haulla.

RFC 8659

Ohittaako tyhjä myöntäjämerkintä toisen sallitun myöntäjän?

Ei. Valtuutukset ovat täydentäviä. Tyhjä liikkeeseenlaskija yhdessä ei-tyhjän valtuutetun liikkeeseenlaskijan kanssa ei peruuta valtuutusta.

RFC 8659

Tekeekö lippukentän asettaminen arvoon 1 kiinteistön myöntäjälle kriittistä?

Ei. Myöntäjäkriittisen bitin numeerinen arvo on 128. Tuntematon tai tuettu kriittinen ominaisuus estää myöntämisen sovellettavassa joukossa.

RFC 8659

Voinko kopioida tilirajoituksia toisesta käyttöönotosta?

Ei. RFC 8657 -tilin ja vahvistusmenetelmän rajoitukset edellyttävät oikeat tuetut CA-, tili- ja menetelmäarvot. Vahvista todellinen varmenteen työnkulku ennen niiden käyttöönottoa.

RFC 8657

Mitkä testit suoritettiin tätä opasta varten?

Ainoastaan ​​dokumentaaristen lähteiden tarkistus suoritettiin. CAA:n live-julkaisu, varmenteiden myöntäminen tai uusiminen, palveluntarjoajan käyttäytyminen, visuaalinen tarkastelu ja omistajan hyväksyntä jäävät vahvistamatta.

[ Lähteet ]

Lähteet

  1. RFC 8659

    Osat § 1 Johdanto · § 3 Relevant Resource Record Set · § 4.1 Syntaksi · § 4.2 CAA issue ominaisuus · § 4.3 CAA issuewild -ominaisuus · § 4.4 CAA jodef -ominaisuus · § 4.5 Critical Flag · § 6 Käyttöönottonäkökohdat · § 7 Erot RFC 6844 stä

  2. RFC 9499

    Osat §2 nimet · §5 resurssitietueet · §7 vyöhykkeet

  3. RFC 8657

    Osat §3 CAA-tietueen laajennukset: "accounturi"-parametri · §3.1 Käyttö ACME:n kanssa · §4 CAA-tietueen laajennukset: "Validationmethods"-parametri · §5.2 Rajoitukset, jotka eivät toimi ilman CA:n tunnistusta · §5.8 Väärinmääritysvaarat

[ Sanasto ]

Sanasto

CAA
DNS tietue, joka ilmaisee myöntämisen varmenteen myöntäjän valtuutuksen.

RFC 8659

Asiaankuuluva RRset
Pyydetyn nimen vakiohakumenettelyllä valittu CAA-tietuejoukko.

RFC 8659

issuewild
CAA-ominaisuus, joka hallitsee jokerimerkkien myöntämistä, kun se on kyseisessä joukossa.

RFC 8659

Liikkeeseenlaskijakriittinen lippu
Lippu, joka edellyttää, että CA ei anna, kun asiaankuuluvaa kriittistä ominaisuutta ei tunneta tai sitä ei tueta.

RFC 8659

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta