Едно от най-сложните и най-неразбраните действия, които може да ви се наложи да извършвате в днешния Интернет, е това да преместите ваш домейн от едни сървъри за имена (DNS-сървъри или nameserver-и) към други. Това се случва много рядко, обикновено единствено когато сменяте хостинг доставчика си. При такава миграция бихте искали да няма нито един момент, в който клиентите да получават остаряла или просто грешна информация и съответно сайтовете и услугите ви да са недостъпни за тях. За щастие съществува процедура за смяна на сървъри за имена от няколко стъпки, чието следване ще ви позволи да постигнете тази цел.

Системата за имена на домейни (DNS) има йерархия от сървъри. В основата са т.нар. root (коренови) сървъри, които знаят само кои други сървъри отговарят за домейните от първо ниво (top-level domains, TLD). TLD представлява последният компонент от името на един домейн, например „com“ за „example.com“ или „bg“ за „space.bg“. Следващите са TLD-сървърите, които отговарят за един определен домейн от първо ниво (само за „com“, само за „bg“ и т.н.) и знаят адресите на два сървъра за всеки конкретен домейн в тази зона. Например TLD-сървърите за зоната „bg“ знаят, че за домейна „space.bg“ отговарят сървърите „a.ns.space.bg“ и „b.ns.space.bg“.

Информацията кои са двата сървъра, които отговарят за всеки домейн – стига до TLD-сървърите чрез т.нар. регистратори на домейни. Тези организации позволяват лесното регистриране на домейни в зоните „com“, „net“, „org“, „bg“ и т.н., като поемат грижата за това информацията да стига до правилните TLD-сървъри и да бъде обновявана бързо и коректно. Повечето хостинг доставчици работят с един определен регистратор на домейни, който им предлага лесен начин за промяна на информацията във всички домейни от първо ниво. Най-често това е прозрачно за клиентите – те управляват домейна си през контролния панел на хостинг доставчика и не им се налага дори да знаят кой регистратор всъщност го поддържа.

Стъпките при преместването на домейн от едни DNS-сървъри върху други изискват координация между поне три страни – доставчика, чиито сървъри за имена отговарят за домейна в момента, доставчика, чиито сървъри ще започнат да отговарят за него, и регистратора на домейна. Някои от тези стъпки представляват само изчакване – след като сте променили някакви данни в системата DNS, хубаво е да изчакате толкова време, колкото е било тяхното досегашно време за живот (time to live, TTL), така че всички клиенти по целия свят да са се обърнали поне още веднъж към сървърите за имена и да са получили новите данни.

Ще онагледим процедурата по промяна на сървъри за имена с пример – преместването на домейн example.com от доставчика example.net към доставчика space.bg, т.е. нас. Да приемем, че сегашните сървъри за имена за example.com са ns1.example.net и ns2.example.net, а трябва да го преместим към a.ns.space.bg и b.ns.space.bg. Имайте предвид, че често, но не задължително, DNS-сървърите, отговарящи за даден домейн, са сървъри на уеб хостинг доставчика за този домейн.

Ето и самата процедура:

1. Взимате от доставчикa example.net точното съдържание на DNS зоната ви – обикновен текстов файл, списък от записи с име, тип, стойност и time to live. В някои случаи тази стъпка можем да направим ние, ако сървърите за имена на example.net разрешават т.нар. AXFR – прехвърляне на данните за цял домейн наведнъж. Ако обаче това не е така, ще трябва да помолите доставчика си да ви даде DNS-зоната или да препишете на ръка DNS-записите от контролния панел, до който имате достъп.
2. Ние създаваме зоната example.com върху нашите DNS сървъри като точно копие на сегашното й съдържание върху сървърите на example.net.
3. При нас добавяме два записа за nameserver-и – a.ns.space.bg и b.ns.space.bg с time to live 86400 секунди (24 часа) и променяме time to live на записите за nameserver-ите на example.net на 300 секунди (пет минути)
4. В example.net добавяте двата записа за nameserver-и:

   example.com 86400 NS a.ns.space.bg
example.com 86400 NS b.ns.space.bg

   …и променяте time to live на старите:

   example.com 300 NS ns1.example.net
example.com 300 NS ns2.example.net

5. Изчакваме толкова, колкото е времето за живот (TTL) на досегашните nameserver записи върху сървърите на example.net. Обикновено този период е между четири часа и два-три дни. Това е необходимо, за да се обнови информацията за nameserver-ите във всички resolver-и по света; сега вече всички „предпочитат“ нашите сървъри и знаят, че тези на example.net са с малък TTL.
6. В контролния панел за управление на домейна при регистратора сменяте имената на DNS-сървърите, отговарящи за домейна, от ns1.example.net и ns2.example.net на a.ns.space.bg (77.77.142.9) и b.ns.space.bg (77.77.142.10)
7. Изчакваме толкова, колкото е времето за живот (TTL) на досегашните nameserver записи при регистратора. Обикновено това е най-дългото изчакване, тъй като тези времена варират от две денонощия до седмица в зависимост от политиката на самия регистратор.
8. След като вече е сигурно, че всички resolver-и по света знаят, че основните nameserver-и за example.com са нашите, при нас махаме двата записа за ns1 и ns2.example.net, така че оттук нататък никой никога няма да пита техните nameserver-и за DNS зоната example.com.
9. Върху досегашните сървъри за имена – ns1 и ns2.example.net – премахвате всякаква информация за домейна example.com. Това е много важна стъпка – винаги има клиенти, чиито resolver-и са запомнили старите nameserver-и и ще се обръщат само към тях, без да обръщат внимание на това, че в отговорите им са се появили и нови. Много е важно старите nameserver-и да „забравят“ за този домейн, така че клиентите да потърсят информация за него отначало – да започнат от основата на системата DNS, да преминат през TLD-сървърите, те да им дадат имената на нашите nameserver-и (a.ns.space.bg и b.ns.space.bg) и оттук нататък клиентите винаги да получават новите, правилни данни и да достигат до вашия сайт.

На пръв поглед звучи сложно. Затова пък, ако изпълните правилно тези няколко стъпки, ще е сигурно, че няма да има нито един момент, в който ваш клиент да не може да достигне до сайтове ви, да ви изпрати електронна поща или да използва другите ви услуги. Ако действително искате да поддържате услугите си достъпни за клиентите и можете да си позволите двете изчаквания по ден-два-три, докато информацията бъде обновена навсякъде, следването на тази процедура ще ви спести много ядове.

Снимка: James Jordan (cc-by-nc)

Сподели: