Ilmoita erittely ja toteutusalue
Domain Connect voi auttaa palveluntarjoajaa määrittämään DNS yhteistyössä toimivan DNS palveluntarjoajan kautta. Säilytetty virallinen arkistoasiakirja tunnistaa itsensä versioksi 2.3 ja kuvaa synkronisia ja asynkronisia virtoja. Tämä artikkeli tulkitsee tätä versioitua lähdettä; se ei väitä, että jokainen palveluntarjoaja tukee molempia virtoja tai että se määrittää myöhemmän standardiehdotuksen tilan. Vahvista tietyn palveluntarjoajan integrointi ja malli ennen kuin käytät työnkulkua toiminnallisesti.
Automaatio vähentää manuaalista tietueiden syöttämistä, mutta se ei poista vastuuta toimialueesta, olemassa olevista palveluista tai valtuuksista. Yhteyspyyntö voi muuttaa postin, verkkosivustojen ja vahvistusprosessien käyttämiä tietueita. Arvioijan on ymmärrettävä ehdotettu vaikutus, nykyinen viranomainen ja tili, joka sen hyväksyy, sen sijaan, että hän pitäisi tuttua palvelulogoa riittävänä todisteena. Domain Connect -määritys, versio 2.3
Erota kertaluonteinen suostumus jatkuvasta luvasta
Säilytetyssä synkronisessa vuossa käyttäjä ohjataan DNS palveluntarjoajan puoleen, todennetaan tarvittaessa ja palveluntarjoaja varmistaa, että käyttäjä hallitsee DNS vyöhykettä. Palveluntarjoaja vahvistaa toimitetut parametrit ja pyytää suostumusta muutokseen. Tämä on erityinen kulun kuvaus, ei todiste siitä, että oikea tili tai verkkotunnus on vahvistettu tälle käsikirjoitukselle.
Samassa versiossa kuvattu asynkroninen kulku antaa OAuth-käyttöoikeuden, jotta palveluntarjoaja voi käyttää malleja myöhemmin. Sen käyttöoikeus on rajoitettu pyydettyihin malleihin ja määritettyyn verkkotunnukseen ja aliverkkotunnuksiin käyttäjän hallinnassa. Jatkuva pääsy eroaa olennaisesti yksittäisestä nykyisestä DNS muokkauksesta. Tarkista sen laajuus, kesto, peruutusprosessi ja vastuullinen omistaja erikseen sen sijaan, että olettaisit, että yksi klikkaus merkitsee vain yhtä muutosta.
Muutostaulukossa tai artikkelitodisteessa ei saa esiintyä valtuustietoja, valtuutuskoodeja tai tunnuksia. Todellinen pääsylupa vaatii oman hyväksynnän ja turvallisen käsittelyn. Tämä käsikirjoitus ei aloita kirjautumista eikä luo jatkuvaa pääsyä. Domain Connect: Synchronous Flow ja Asynchronous Flow
Vaadi konkreettinen tietueen tarkistus
Säilytä mallin tunniste, palveluntarjoajan ja palvelun tunnisteet, mallin versio tai sisällön hash, verkkotunnus, korvatut parametrit ja ehdotettu tietuejoukko. Vertaa haluttua tulosta nykyiseen arvovaltaiseen tilaan. Tunnista lisäykset, korvaukset ja poistot, mukaan lukien tietueet, jotka tukevat olemassa olevaa palvelua. Tarkastuksessa on erotettava mallin yleiset muuttujat tietylle toimialueelle ehdotetuista todellisista arvoista.
Säilytetty spesifikaatio jättää paljastamisen ja ristiriitojen havaitsemisen olennaisesti DNS palveluntarjoajalle. Se kuvaa toteutuksia, jotka voivat näyttää tietueita, varoittaa ristiriidoista tai käsitellä päällekkäisiä malleja eri tavalla. Siksi älä lupaa, että jokainen suostumusnäyttö näyttää täydellisen eron tai suojaa kaikkia olemassa olevia riippuvuuksia. Organisaatio voi vaatia tarkempaa tarkastelua kuin palveluntarjoajan käyttöliittymässä näkyvät vähimmäistiedot.
Jos käyttöliittymä ei paljasta tarpeeksi tietoa, keskeytä muutos, kunnes vaikutus ymmärretään tuetun dokumentaation tai valtuutetun tarkistuspolun avulla. Älä päättele, että piilotettu konflikti on vaaraton. Vaadittu organisaation näyttö on ymmärrettävä ehdotettu muutos, ei pelkkä kuvakaappaus Jatka-painikkeesta. Domain Connect: Muutosten ja ristiriitojen paljastaminen
Arvioi malli ja tallenna ristiriidat
Uusi malli voi olla päällekkäinen aikaisemman mallin tai manuaalisten muokkausten hallinnoimien tietueiden kanssa. Säilytetty määrittely osoittaa, että mallin tilaa ylläpitävä toimittaja saattaa poistaa aikaisemman päällekkäisen mallin, mikä vaikuttaa tietueisiin sen yksittäisen ristiriidan lisäksi, joka herätti ensimmäisen huomion. Tämä tekee riippuvuustarkastelusta tärkeän, vaikka uusi palvelu näyttää tarvitsevan vain yhden DNS tietueen.
Todennustyötä varten tunnista olemassa oleva SPF politiikan rajat, DKIM valitsimet, DMARC käytäntö ja kaikki vahvistustiedot ennen hyväksymistä. Älä keksi palveluntarjoajakohtaista sisällyttää tai valitsin yleisestä esimerkistä. Aiottujen tietueiden on oltava peräisin todellisesta tuetuista kokoonpanoista. Jos malli korvaisi olemassa olevan arvon, määritä, kuka omistaja vahvistaa korvaamisen ja kuinka lailliset lähetysreitit säilyvät katettuina.
Myös mallipäivitykset vaativat huomiota. Säilytetyssä asiakirjassa käsitellään muuttuneiden mallien käyttöönottoa DNS palveluntarjoajien kanssa ja versiokentän käyttöä läpinäkyvyyden vuoksi. Aikaisempi hyväksyntä ei saa kattaa hiljaa olennaisesti erilaista mallia tai parametrijoukkoa. Säilytä tarkistettu versio ja kysy, ratkaiseeko palveluntarjoajan nykyinen tuettu kulku samaan suunniteltuun muutokseen. Domain Connect: Mallin versiointi ja tietuetyypit ja ristiriidat
Hyväksymistaulukko ja toipumissuunnitelma
Työtaulukon tulee sisältää verkkotunnuksen valtuutus, hyväksyvän tilin rooli, palvelun tarkoitus, mallin identiteetti, lähdepäivämäärä, tarkat ehdotetut tietueet, nykyiset tietueet, ristiriidat, sovellukset ja palautuksen omistaja. Lisää erillinen käyttöoikeusosio kertaluonteisille ja jatkuville luville, sen tuetulle laajuudelle ja peruutusmenettelylle. Tallenna varsinainen hyväksymispäätös sen sijaan, että olettaisi, että tekninen käyttöoikeus vastaa yrityksen valtuutusta.
Suunnittele vahvistus ennen toteutusta. Valmistumisnäyttö on todiste käyttöliittymän tilasta, ei automaattisesti todiste tehokkaasta, arvovaltaisesta DNS tai toimivasta viestitodennusta. Hyväksymissuunnitelmassa tulisi vaatia säilytetyt pätevät vastaukset muutoksen jälkeen ja tarvittaessa erikseen valtuutettu viestitodiste kyseiselle reitille. Rekursiiviset havainnot ja välimuistin rajoitukset tulee dokumentoida lupaamatta yleistä välitöntä leviämistä.
Palautus vaatii tuetun reitin ja nykyisen tilan edeltävän tilannevedoksen. Vanhan vyöhykkeen sokea palauttaminen voi korvata laillisen samanaikaisen työn. Tunnista pienin korjaava toimenpide, omistaja, joka voi hyväksyä sen ja todisteet, joita tarvitaan toipumisen vahvistamiseksi. Nämä ovat ehdotettuja suunnitteluvaatimuksia, eivät väitteitä siitä, että tapahtuma tai peruutus on suoritettu.
Kuvitteellinen arvostelu: palveluyhteys peittää olemassa olevan postin
Kuvittele kuvitteellinen palveluyhteys, jonka malli ehdottaa TXT muutosta postityönkulun jo käyttämään nimeen. DNS palveluntarjoajan suostumusnäytössä nimetään uusi palvelu, mutta se ei näytä tarpeeksi yksityiskohtia sen määrittämiseksi, korvataanko nykyinen arvo. Varsinaista mallia ei käytetty eikä verkkotunnusta kysytty tässä esimerkissä.
Arvioija pyytää tarkat ehdotetut tietueet ja tunnistaa nykyisen postiriippuvuuden omistajan. Hyväksyntä odottaa, kunnes vuorovaikutus on ymmärretty. Jos kulku pyytää myös jatkuvaa käyttöoikeutta, pyyntö saa erillisen laajuuden tarkistuksen. Se, että käyttäjä voi todentaa DNS tilin, ei ratkaise kumpaakaan kysymystä sinänsä.
Onnistunut suunnitelma säilyttäisi tietueero-, hyväksyntä- ja muutoksen jälkeisen varmennusvaatimukset. Kuvitteellinen skenaario päättyy tuohon suunnitelmaan, ei keksittyyn vihreään shekkiin. Se osoittaa, miksi automaatio voi olla kätevää, mutta silti konkreettisten DNS ja lupavaikutusten vastuullinen tarkistaminen edellyttää.
Todisteet ja vapautuksen tila
Luettelo vaatii verkkotunnuksen vahvistuksen, luvat, tarkat ehdotetut tietueet ja arvovaltaiset muutoksen jälkeiset todisteet. Yhtään näistä toiminnallisista esineistä ei ole kerätty tänne. Säilytetty lähde tukee versiokohtaista työnkulun keskustelua, kun taas varsinainen palveluntarjoajan tuki, tilin laajuus ja suoritus jäävät vahvistamatta.
Kaikki kuusi vapautusporttia pysyvät auki. DNS muutoksia, tiliin kirjautumista, tunnuksen luomista, mallisovellusta tai viestitestejä ei tapahtunut. Ennen julkaisua pätevän tarkistajan tulee vahvistaa tietty integrointiversio ja tarkastaa todelliset hyväksyntä- ja varmistusartefaktit. Artikkelin on pysyttävä ehdotettuna tarkistusmenetelmänä, kunnes todisteet ovat olemassa.