Az ügyfél levelezésének Office 365-be költöztetése egy komoly informatikai projekt, amely tervezést, szakértelmet, odafigyelést és rutint igényel. Amikor szolgáltatót választ az ember, nem elég, ha csak azt nézzük ki vág nagyobbat a Microsoft hivatalos liszensz árain. Egy elhibázott Office 365 bevezetés, ahol nem tervezett módon napokra kiesik az ügyfél levelezése, bizony nem csak az ügyfél – szolgáltató viszonyát teszi tönkre, hanem az ügyfél Office 365-be, mint termékbe vetett hitét is. Mi a Systemfarmernél ezt komolyan vesszük, és úgy hisszük, hogy a hosszútávú, gyümölcsöző kapcsolat egyik legfontosabb alappillére a jól megvalósított Office 365 migráció.
Ez a post arról szól, mennyire nem triviális egy DNS rekord kezelési folyamat.
A projekt részeként az ügyfél leendő Office 365 környezetében (továbbiakban: Tenant) az egyik kulcs lépés a levelező domain bevitele. Alapvetően két részből áll. Az első a Domain verifikáció, a második pedig az összes többi DNS rekord kezelése.
Sok migrációt végző szolgáltató úgy gondolja, hogy ebben a témában a DNS verifikációt követően lelistázott további 10 rekordot elég csak felcsépelni a DNS regisztrátor weboldalán, majd hátradőlnek, mint akik jól végezték dolgukat, és készen vannak. Ez nagyjából egy startup cég újonnan vásárolt levelezésre használandó domainja esetében állja meg a helyét, de ezt nem is hívnám migrációnak. Bár ezen a ponton is belefuthatunk pár akadályba. Egyrészt nagyon sok DNS regisztrátor cég van a piacon, akik még online DNS rekord szerkesztési felületet sem biztosítanak az ügyfél részére. E-mailben fogadják az ilyen irányú kéréseket. Rosszabb esetben a biztonságra sem adnak, és akárkitől elfogadnak DNS rekord módosítási kéréseket (csak nehogy a konkurencia így tegyen nekem keresztbe), jobb esetben megcsinálják a verifikációs DNS rekord kérést (ez 1 db rekord felrögzítése), majd mikor megkapják a maradék 10 rekordra vonatkozó listát, akkor érdekes módon napokra vagy hetekre eltűnnek.
A folyamat ennél lényegesen nagyobb körültekintést igényel, ezért mi azt preferáljuk, ha kapunk hozzáférést az online DNS rekord szerkesztéshez. Egyébként nem szerencsés a DNS regisztrátor céggel az ügyfélen keresztüli levelezgetés, mert hosszadalmas, és torzulhatnak a küldött technikai információk, időzítések, és sajnos még a regisztrátor cég is sokszor elhibázza a bonyolultabb, pl. SRV rekordok felvitelét.
Nézzük a buktatókat a DNS verifikáció kapcsán.
A verifikáció lényege, hogy az Office 365 részére megnyugtató módon bizonyítsuk, hogy miénk az a levelező domain, amelyet a Tenantban használni szeretnénk. Nem papírokat és pecséteket kell beküldeni, mindössze arról van szó, hogy kapunk a folyamat elején egy egyedi kódot, amelyet 1 db TXT rekord formájában be kell rögzítenünk a DNS rekordok közé. Amennyiben ez sikerült (mely egyben bizonyítja, hogy rendelkezünk felhasználónévvel és jelszóval a DNS zóna szerkesztéséhez, vagy jogosultak vagyunk ilyen kérést a domainre vonatkozólag leadni a szolgáltatónál, azaz tehát miénk a domain), akkor a Tenantban a domain verifikált státuszt kap, használatba vehetjük.
Mi van akkor, amikor a berögzített TXT rekord hibátlan, és mégsem látja az Office 365? Előfordulhat, hogy a konkurencia szakembere nem is a névszerveren szerkeszti a DNS rekordokat? Vajon tudja, hogyan kell ellenőrizni, melyik az authoritatív DNS névszervere az adott levelező domain-nak? Tudja mi az a SOA rekord? Másik tipikus eset, hogy ellenőrzéskor az Office 365 egyszer csak egy újabb kódot generál. Furcsállhatjuk, nem értjük, de mi mást tehetnénk, mint hogy ezt is bevisszük a DNS rekordok közé, majd megint ellenőrzünk, és kapunk egy 3. kódot. Érthetetlen? Nem. Arról van szó, hogy a levelező domain már benn van legalább verifikált szinten egy másik Tenantban, és az Office 365 egy adott levelező domaint egyszerre egy időben csak egy helyen enged használatba venni. Hogy lehet benn egy másik Tenantban? Nyilván tudna róla az ügyfél, ha már Office 365-ben levelezne, nem?! Nem feltétlenül. Lehet, hogy csak verifikálta, de félbehagyta a beköltözést, pl. nem vett liszenszeket, vagy lejárt a próba liszensze a beköltözés előtt. De az is lehet, hogy a volt informatikus a letelepített levelezőszerverük elé kötött egy O365 spam szűrő rendszert ily módon. Fel kell kutatni az ilyen másik Tenantot, és vagy annak kiépítését folytatni, vagy kikötni (törölni) belőle a levelező domaint. Mi a Systemfarmernél ilyenekre is odafigyelünk.