Kas nutinka, kai įmonės DNS valdo buvęs darbuotojas arba senas IT tiekėjas?

„Domenas mūsų, tik prisijungimą turi buvęs administratorius“

Įsivaizduokime įmonę, kuri keičia IT partnerį. Svetainės failai perduoti, serverių prieigos gautos, tačiau DNS pakeitimui reikia rašyti senam tiekėjui. Cloudflare paskyros atkūrimo laiškas keliauja buvusiam darbuotojui, o domeno pratęsimas apmokamas nebegaliojančia kortele. Tai iliustracinis scenarijus, kuriame techninė priklausomybė tampa verslo tęstinumo problema.

Pati išorinė DNS priežiūra nėra trūkumas. Problema atsiranda tada, kai įmonė nežino savo domeno turėtojo duomenų, neturi sutarto prieigų perdavimo ir negali savarankiškai užtikrinti paslaugų tęstinumo. Pirmas darbas — atskirti registraciją, DNS ir pačias paslaugas.

Trys skirtingi valdymo sluoksniai

Cloudflare gali teikti DNS, nors domeno registracija ir paštas yra kitur. Pakeitus registratorių nebūtinai pasikeičia DNS paslauga, o nukreipus DNS į kitą tiekėją pašto dėžučių turinys nepersikelia. Šiuos darbus planuojame atskirai.

1. Patikriname domeno turėtoją ir registraciją

Peržiūrime registro informaciją, sutartis ir valdymo paskyrą: kokia įmonė ar asmuo nurodytas turėtoju, kas aptarnauja domeną, kada baigiasi registracija ir kam siunčiami pranešimai. Vien sąskaita už svetainės kūrimą arba galimybė redaguoti DNS neatsako į visus šiuos klausimus.

.lt domeno aptarnaujantį teikėją galima patikrinti DOMREG WHOIS, o domeno turėtojo paskyra naudojama ir teikėjo keitimo ar perleidimo inicijavimui. Tai skirtingos procedūros. Jei turėtojo duomenys neatitinka įmonės lūkesčių, situaciją pirmiausia aiškinamės su teikėju ir turėtoju. DOMREG domeno turėtojo paskyra.

Įmonė turi kontroliuoti atsiskaitymą, registracijos priminimus ir atkūrimo kanalus. Numatome bent du įgaliotus atsakingus asmenis, vardines prieigas ir MFA. Atkūrimas neturi priklausyti tik nuo vieno darbuotojo telefono ar vienintelės pašto dėžutės tame pačiame domene, kurio veikimą mėginame atkurti.

2. Užfiksuojame DNS zoną ir priklausomas paslaugas

Iš veikiančios valdymo sistemos gauname zonos eksportą ir susiejame įrašus su jų paskirtimi. Viešos DNS užklausos padeda patikrinti žinomus vardus, tačiau negarantuoja visos zonos sąrašo. Ypač lengva nepastebėti retai naudojamo subdomeno, DKIM selektoriaus ar paslaugos patvirtinimo TXT įrašo.

• A, AAAA ir CNAME: pagrindinė svetainė, www, klientų portalai, VPN ir kiti subdomenai.
• MX ir el. pašto TXT/CNAME: laiškų priėmimas, SPF, DKIM bei DMARC.
• SRV, CAA ir patvirtinimo įrašai: paslaugų aptikimas, sertifikatų išdavimas ir integracijos.
• NS, DS ir DNSKEY: delegavimas bei DNSSEC pasitikėjimo grandinė; DS tikrinamas tėvinėje zonoje.

Neaiškaus įrašo paskirties nespėjame iš pavadinimo. Ieškome sistemos savininko ir fiksuojame, kas bus paveikta jį pakeitus. Vidinio įmonės DNS konfigūraciją vertiname atskirai nuo viešos zonos.

3. Cloudflare paskyra yra daugiau nei DNS lentelė

Jeigu įmonės zona yra seno tiekėjo paskyroje kartu su kitais klientais, visos paskyros perdavimas gali būti netinkamas sprendimas. Sutariame, ar pakanka tinkamai apribotų prieigų, ar reikia atskiros įmonės valdomos aplinkos ir suplanuoto zonos perkėlimo.

DNS eksportas padeda išsaugoti įrašus, tačiau atskirai inventorizuojame WAF, peradresavimus, SSL/TLS nustatymus, Workers, Tunnel, Access ir API integracijas, jeigu jos naudojamos. Užfiksuojame ir kiekvieno tinkamo įrašo proxy būseną. Cloudflare eksporto ir importo dokumentacijoje aprašyta, kaip perkeliami įrašai ir jų atributai.

Oranžinis debesėlis nėra universalus saugumo jungiklis. Įprastas Cloudflare žiniatinklio proxy neperduoda SMTP, IMAP ar įprasto VPN srauto. Pašto serverio vardui parenkame pašto tiekėjo reikalaujamą DNS-only konfigūraciją, o kitų protokolų tarpininkavimą vertiname pagal konkretų sprendimą.

4. DNSSEC: vien NS pakeitimo neužtenka

DNSSEC leidžia tikrinančiam DNS resolveriui patikrinti atsakymo autentiškumą. Jis nešifruoja svetainės ar el. pašto srauto. Perkeliant zoną svarbu, kad tėvinėje zonoje paskelbtas DS atitiktų naujos zonos pasirašymo raktus.

Standartiniame Cloudflare pilnos zonos perkėlimo scenarijuje gamintojas nurodo prieš keičiant NS išjungti seną DNSSEC registratoriaus pusėje, o aktyvavus zoną jį įjungti naujoje aplinkoje. Praktikoje patikriname DS pašalinimą ir ankstesnio įrašo TTL išlaukimą, tada užbaigiame naują pasitikėjimo grandinę. Nenutrūkstamam pasirašytam perkėlimui reikia atskiro, abiejų tiekėjų palaikomo plano. Cloudflare vardų serverių keitimo gairės.

5. MX, SPF, DKIM ir DMARC tikriname atskirai

Veikianti svetainė dar neįrodo, kad po perkėlimo veikia paštas. Užrašome visus teisėtus siuntėjus: darbuotojų paštą, CRM, apskaitą, naujienlaiškių platformą ir svetainės formas.

DMARC patikrai pakanka vieno sėkmingo ir su From suderinto mechanizmo — SPF arba DKIM. Vien TXT įrašo buvimas to nepatvirtina: tikriname realių laiškų Authentication-Results antraštes. p=none skirtas stebėjimui ir pats neprašo atmesti nesėkmingų laiškų; griežtinimą planuojame patikrinę siuntėjus. Microsoft DMARC gairės.

DKIM rakto neperkuriame vien dėl DNS tiekėjo keitimo: išsaugome pašto sistemos reikalaujamus įrašus ir patikriname parašą. SPF, DKIM ir DMARC taisymą deriname su kiekvienos siuntimo paslaugos administratoriumi.

6. Perkeliame pagal planą ir turime grįžimo kelią

1. Paruošiame: suderiname darbų laiką, atsakingus asmenis, zonos kopiją ir grįžimo sąlygas.
2. Sulyginame: naują zoną užpildome prieš keisdami delegavimą ir patikriname jos autoritetingų serverių atsakymus.
3. Įvertiname podėlius: kur galima, iš anksto sumažiname keičiamų įrašų TTL. Naujas TTL neišvalo jau sukauptų atsakymų ir nekeičia visų NS ar DS podėlių.
4. Perjungiame: NS ir DNSSEC veiksmus atliekame pagal suderintą seką. Seną zoną išlaikome pereinamajam laikui.
5. Patikriname: naudojame kelis nepriklausomus resolverius, išbandome svetainę, HTTPS, laiškų gavimą ir siuntimą bei svarbias integracijas.
6. Užbaigiame: įsitikinę veikimu sutvarkome senas teises, API žetonus, atsiskaitymą ir dokumentaciją.

Grįžimas taip pat nėra momentinis: seni atsakymai gali likti podėliuose, o DNSSEC būsena turi atitikti pasirinktus serverius. Todėl plane numatome ir senos zonos prieinamumą, ir pasitikėjimo grandinės atkūrimą.

Jei senas tiekėjas neatsiliepia

Pirmiausia surenkame įmonės turimus registracijos, paslaugų ir įgaliojimų dokumentus bei kreipiamės į aptarnaujantį teikėją oficialiu atkūrimo kanalu. Jeigu įmonė yra domeno turėtoja, aiškinamės jai prieinamą valdymo atkūrimo ar teikėjo keitimo procedūrą. Jei turėtojas kitas, tai atskiras klausimas, kurio vien DNS pakeitimu neišspręsime.

Kol nėra zonos eksporto, trūkstamus įrašus atkuriame iš sistemų dokumentacijos, paslaugų valdymo paskyrų ir žinomų DNS atsakymų. Nežinomų įrašų riziką aiškiai užfiksuojame prieš bet kokį delegavimo pakeitimą.