Tartalom

Zóna (domain) kiszolgáló authoritatív névszerverek váltása.
Kivételek.
TTL értékek csökkentése.
Gyakori hibák.
DNS zóna adatok átadása más DNS-szolgáltatónak.
Ajánlások.
Regisztrátorváltás és névszerverváltás.
Registry lock. 

 

Zóna (domain) kiszolgáló authoritatív névszerverek váltása

Amennyiben egy zóna (domain) DNS szervereit váltani szeretnénk, akkor legtöbb esetben ezt minden probléma, üzemkiesés nélkül meg lehet tenni.

Ha a jelenlegi és a majdani névszerverek ugyanazon információkat szolgáltatják, akkor a váltás tipikusan nem okozhat semmiféle zavart, hiszen egy kliens akár egy régi, akár egy újabb névszervert kérdez le, ugyanazon válaszokat kapja.

Névszerver váltásnál tehát az alapvető amit tennünk kell, hogy az új névszervereken pontosan ugyanazon zónainfomrációkat állítjuk be, mint amilyenek a régi névszerveren voltak beállítva.

Ha nem névszervert váltunk, hanem új névszervert iktatunk be, akkor szintén ez a szabály, hogy az új névszerver pontosan azonos információt szolgáltasson a korábbiakkal. Ez az alapvető szabály: minden névszervernek mindig azonos információkat kell szolgáltatnia, bár ez alól is van kivétel.

Kivételek

A névszervereken egyes esetekben nem biztosítható, hogy a korábbi és az újabb névszerverek pontosan azonos információkat szolgáltassanak.

Amennyiben a lecserélendő névszervereken az adott zónáknál DNSSEC alkalmazott, akkor további lépésekre, kicsit más eljárásra lehet szükség. Legtöbbször elegendő csupán a TTL-ek kis értékre történő levétele a lecserélendő névszervereknél, néha erre sincs szükség, pl. parkoló domaineknél, de egyes esetekben a TTL-ek kis értékre vétele sem kielégítő megoldás, további lépésekre lehet szükség (az INTEGRITY teljeskörű authoritatív névszerver szolgáltatása /dns1.hu, dns2.hu, dns3.hu … névszerverek/ DNSSEC-et alkalmaznak minden zónánál /domainnél/).

Ilyen eset fordulhat elő, amikor a névszerverek gyorsan változó adatokat is szolgáltatnak (pl. egy load balance megoldás miatt rövid időn belül történnek változások).

Egyes esetekben egy zónát (domaint) kiszolgáló egyes névszerverek más információkat szolgáltatnak, pl. földrajzi helytől függően más információkat.

Ezen esetek legtöbb domain használót nem érintik, vagy ha mégis, akkor szakértői szintű megoldást és tervezést igényel a váltás.

A régi és új névszerverek szolgáltatási minőségében, válaszideiben, földrajzi helyzetében lehetnek eltérések, ezért névszerverek váltásakor erre figyelni kell, mert egyes esetekben ezen különbségek problémákhoz vezethetnek.

TTL értékek csökkentése

Szokás a TTL értékeket módosításkor kis értékre állítani, de ez nem feltétlenül indokolt. Annyiban mindenképpen előnyös lehet, hogy hiba esetén, a hiba korrekciója gyorsabban érvényesül.

Ezért a TTL értékek kisebbre csökkentését tipikusan javasoljuk DNS szerverek váltásakor, majd ha mindent rendben találunk, akkor az értékeket a normál értékekre javasolt visszaállítani.

Gyakori hibák

Több domainhasználónál előfordult, hogy az új névszervereken nem vett fel minden rekordot, vagy az új névszerver szolgáltatójának nem adott át minden korábbi rekordot.

Volt amikor ez annak következménye volt, hogy kívülről kérdezte le a névszerverek rekordjait, de így bizonyos rekordokat, pl. aldomaineket figyelmen kívül hagyott, majd a névszerver váltáskor ez problémát okozott (pl. nem töltődtek be bizonyos webtartalmak).

Ezen esetben az üzemzavar elhúzódásához vezethet az is, hogy a TTL értékek nem lettek kicsire állítva, illetve azok túl nagyok voltak.

DNS zóna adatok átadása más DNS-szolgáltatónak

A szolgáltatók többféle módon tárolhatnak DNS adatokat.

Vannak szolgáltatók, akik még BIND zónafile-okat alkalmaznak, bár tipikusan ez már nem tekinthető korszerű és praktikus megoldásnak, noha lehetnek okok, hogy mégis zónafile-okat vagy BIND-ot célszerű alkalmazni (a BIND még mindig a legelterjedtebb DNS szerver, és még mindig leginkább zónafile-okkal alkalmazzák). [1]^,[2]

Bizonyos értelemben BIND formátum lingua franca-ként szolgálhat, de nem minden BIND zónaadat lehet kompatibilis egy másik névszerverrel, és fordítva is ez igaz. Másrészt nem BIND szerverbe BIND zónafile beolvasása problémás lehet (bizonyos zónafile-okat éppen kompatibilitási problémák miatt nem lehet kezelni).

(Az INTEGRITY Kft. authoritatív DNS kiszolgálásra nem alkalmaz BIND-ot, zónafile-okat, illetve zónatranszfert sem /2004. óta nem alkalmaz/.)

[1] A BIND különös hátránya, ha zónatranszfer alkalmazott az egyes DNS szerverek közt, azaz egy master (primary) DNS-ből több slave (secondary) DNS szerver zónatranszferen keresztül kap frissítést, mert a zónatranszfer viszonylag lassabb adatátvitelt és így késedelmes frissítési időt eredményezhet  (bár létezik a zónatranszfernek gyorsabb módja, pl. inkrementális zónatranszfer). Megjegyezzük, hogy BIND zónafile-okat sem csak a BIND, illetve zónatranszfert sem csak a BIND alkalmaz, hanem más névszerver szoftverek, illetve megvalósítások is.

[2] Az INTEGRITY teljes DNS szolgáltatásában nem alkalmaz zónatranszfert, de az ún. másodlagos névszerver (secondary name server) szolgáltatásában támogatja a zónatranszfert, bár ezen szolgáltatást nem ajánlja használni, helyette a teljeskörű névszerver szolgáltatását ajánlja.

Ajánlások

Ha megoldható, hogy a régi és új névszerverek azonos zónaadatokat szolgáltassanak, akkor névszerverek váltásakor a zónaadatok egyezését biztosítani kell.

(Arra az esetre, ha ez nem megoldható, jelen ajánlásunk nem tér ki, ez esetben kérjük vegyen igénybe szakértőt.)

Lépések:

1. Tervezzük meg a folyamatot, készítsünk írott tervet. Ha indokolt, akkor egyeztessünk a domain regisztrátorával, és a (jelenlegi és majdani) névszerverek üzemeltetőivel.

2. Biztosítsuk, hogy a váltás ideje alatt ne történhessen zóna adat módosítása.

3. Váltás előtt a régi névszerverek zóna adatait vegyük revízió alá, szükség esetén javítsuk, szépítsük, korszerűsítsük azokat, felesleges adatokat gyomláljuk ki.

4. Mentsük le az összes zóna adatot, hogy azok szükség esetén azonnal elérhetők legyenek.

5. Az új névszervereken vegyük fel a zóna adatokat, de ha lehet, akkor átmenetileg rövidebb TTL-ekkel.

6. Teszteljük, hogy az új zóna adatok biztosítják-e a kiszolgálást (a tesztelés nem triviális feladat, hiszen ilyenkor a DNS kiszolgáltatást még a régi névszerverek biztosítják).

7. Ezután csökkentsük le a TTL értékeket a kiszolgálást még nyújtó DNS szervereken.

8. Ezután írjuk át a felettes (root) zónában a régi névszervereket az új névszerverekre.

9. Tesztelés, majd egy ésszerű rátartás (mely során még kibukhatnak esetleg problémák) után az új névszervereken a TTL értékeket a kívánt éles üzemi értékekre állítsuk át.

10. A régi névszervereken a zónák kiszolgálása leállítható, majd a zónák is törölhetők (a törlés technikailag nem sürgős feladat).

 

Regisztrátorváltás és névszerverváltás

Gyakori, hogy regisztrátorváltásnál névszerver váltás is történik.

Alapvetően ez problémamentes, ha biztosítható, hogy a régi és az új névszerverek azonos zónainformációkat szolgáltassanak a névszerek váltása során.

Maga a regisztrátorváltás közvetlenül nem érinti a DNS szolgáltatást (pl. az új regisztrátorhoz került domaint még kiszolgálhatják a régi DNS szerverek továbbra is).

Azonban, ha egyszerre két váltás is van, azaz mind regisztrátor, mind névszerver váltás, akkor nyilván mindkét váltásra, esetleges egymásra hatásaira figyelnünk kell.

Registry lock

Amennyiben registry lock alkalmazott a domainen, akkor erre tekintettel különös figyelemmel legyünk, előre egyeztessünk, ellenőrizzünk le mindent, hogy a névszerver váltás úgy és akkor kivitelezhető lesz, amikor azt meg akarjuk tenni.

INTEGRITY Kft. 2017. január 2.