DNS при трансфер

Модул 6: Време, кеш и трансфер на домейн · Време за четене: 10 минути

Цел на урока: След този урок ще можете да планирате трансфер на Вашия уебсайт, Вашия имейл или Вашето DNS управление така, че посетителите да не забележат нищо и да не пропуснете поща.

Основни понятия: видове трансфер, последователност, предварително намаляване на TTL, подготвяне на записи, резервно копие на зоната, тестване преди смяната (hosts файл, адрес за наблюдение), поща по време на смяната, предварителна проверка от регистъра, DNSSEC и DS записът

Четири вида трансфер

"Трансферирам моя домейн" може да означава четири различни неща. Полезно е първо да определите кое от тях имате предвид, защото всеки вид засяга различни записи.

Често се случват няколко от тях едновременно, например когато трансферирате всичко от един доставчик към друг. Тогава важат капаните на всичките четири вида.

Златното правило за последователността

Най-важният принцип: първо подгответе всичко на новото място, едва тогава извършете смяната. Самата смяна е малко действие, няколко записа или DNS сървърите. Всичко, което може да се направи преди смяната, се прави преди смяната.

Няколко дни предварително

1. Направете резервно копие на текущата си зона. Експортирайте записите, направете екранна снимка или ги запишете. Без преглед на това какво е имало, няма да знаете впоследствие какво липсва. Много панели имат бутон за DNS резервно копие.
2. Направете опис. Прегледайте всеки ред и запишете за какво служи: уебсайт, поща, верификация при Google или Microsoft, услуга за бюлетини, поддомейн за онлайн магазин. Точно тези допълнителни записи (TXT за верификация, CNAME за DKIM на услуга за бюлетини) често се забравят при трансфери.
3. Подгответе новата среда. Уебсайтът е на новия сървър, пощенските кутии съществуват при новия доставчик на поща.
4. Тествайте преди смяната. Можете да прегледате уебсайт на нов сървър без да променяте DNS: с ред в hosts файла Ви, или с тестов адрес или адрес за наблюдение, който новият доставчик предоставя. Не забравяйте да премахнете този ред в hosts файла след това.

Поне един стар TTL предварително

5. Намалете TTL на записите, които ще променяте, на 300 секунди (урок 6.1). Ако TTL е бил 3600, направете го поне час предварително; за всеки случай ден. Ако е бил 86400, направете го поне ден предварително.

Внимание: TTL на NS записите при регистъра (урок 6.2) не можете сами да намалите. При смяна на DNS сървъри винаги имате това време на изчакване.

Смяната

6. Променете записите (при трансфер на уебсайт или поща), или сменете DNS сървърите при Вашия регистратор (при трансфер на DNS управлението).
7. Проверете веднага при авторитетния DNS сървър дали новите стойности са там (dig A example.com @ns1.newhost.example).

След това

8. Проверете всичко: уебсайт чрез http и https, сертификата, тестова поща в двете посоки, и онлайн проверка на MX, SPF, DKIM и DMARC.
9. Върнете TTL обратно на 3600, когато всичко работи.
10. Прекратете старата услуга едва когато няколко дни не пристига повече поща или посещения на старото място. Ако прекратите по-рано, сайтът Ви или пощата могат да изчезнат, или в най-лошия случай домейнът Ви да стане свободен.

Трансфер на DNS управлението

Ако трансферирате DNS управлението си към друг доставчик (други DNS сървъри), има едно допълнително правило: зоната трябва да е напълно готова при новия доставчик, преди да смените DNS сървърите. От момента на смяната новият доставчик определя всички отговори. Това, което липсва там, повече не съществува.

Вземете този списък като минимум:

@          A      192.0.2.10
@          AAAA   2001:db8::10
www        A      192.0.2.10        (или CNAME)
mail       A      192.0.2.25        (ако Вашият MX сочи към mail.example.com)
@          MX     10 mail.example.com.
@          TXT    "v=spf1 ... ~all"
x._domainkey  TXT "v=DKIM1; k=rsa; p=..."   (селекторът се различава според доставчика)
_dmarc     TXT    "v=DMARC1; p=quarantine"

Плюс всички поддомейни, верификационни записи и записи на външни услуги.

Някои регистри проверяват новите DNS сървъри, преди да приемат промяната. DENIC (регистърът на .de), например, проверява дали новите DNS сървъри вече отговарят за домейна. Ако зоната все още не е там, промяната се отхвърля. И затова: първо подгответе зоната.

Пример от практиката

Един домейн беше свързан със сайтостроител чрез насочване на DNS сървърите към тази платформа. Платформата сама зададе MX запис към mail.example.com и SPF запис, но не и A запис за mail.example.com. Резултатът: изпращането работеше, получаването не. Всеки пощенски сървър, който искаше да достави поща, не намираше адрес за името от MX записа. Един A запис при платформата реши проблема. Поука: ако трансферирате DNS сървърите, трябва да прехвърлите и всеки запис, към който сочи друг запис.

Имейл по време на смяната

По време на преходния период част от пощата все още пристига на старото място: подателите със стар отговор в кеша си доставят там. Това е нормално и не е проблем, стига да четете и двете пощенски кутии.

• Задайте новата пощенска кутия предварително в пощенската си програма, с името на сървъра, което новият доставчик предоставя (не mail.example.com, защото това име сочи към променящи се места по време на смяната).
• Оставете старата пощенска кутия също в пощенската си програма, докато няколко дни не пристига нищо повече.
• Копирайте старата поща с инструмент за трансфер на новия доставчик или с програма за IMAP копиране.
• При трансфер на поща не забравяйте SPF записа: новият доставчик трябва да бъде включен в него, и докато старият все още изпраща поща (например формата за контакт на Вашия уебсайт), той също трябва да остане в него.

DNSSEC при трансфер

Ако Вашият домейн използва DNSSEC (урок 8.1), при регистъра има DS запис: отпечатък на ключа, с който текущият Ви DNS доставчик подписва зоната. Ако трансферирате DNS управлението си, новият доставчик подписва с друг ключ. Ако старият DS остане при регистъра, отпечатъкът вече не съвпада. Валидиращите резолвери (а те са много) тогава връщат SERVFAIL: целият Ви домейн е недостъпен за тях, уебсайт и поща.

Безопасният подход:

1. Нека DS бъде премахнат при регистъра (DNSSEC изключен) и изчакайте, докато TTL на DS изтече.
2. Сменете DNS сървърите.
3. Включете DNSSEC при новия доставчик и нека новият DS бъде поставен при регистъра.

Съществува и метод, при който трансферирате без прекъсване на DNSSEC (ключовете на двамата доставчици временно едновременно), но той изисква съдействие от двете страни и далеч не навсякъде се поддържа. Ако при трансфер все пак нещо се обърка и домейнът Ви внезапно стане недостъпен, докато записите изглеждат наред, проверете първо DNSSEC.

На практика: ето как изглежда в един панел

В примерния панел Моят WebOké правите резервно копие на цялата зона в раздела DNS с един бутон, и го връщате обратно с едно кликване, ако нещо се обърка. Трансфер на самия домейн започвате там в Центъра за трансфер, а картата Здраве на домейн / имейл показва след смяната дали DNS сървърите, A записът, сертификатът, MX, SPF, DMARC и DNSSEC са коректни. Други доставчици често предлагат експорт на зоната (понякога като зонов файл, който можете да импортирате при новия доставчик) и подобна проверка; ако Вашият панел няма това, направете екранна снимка на списъка със записи.

Обобщение

• Определете първо какво се трансферира: уебсайт, поща, DNS управление или регистрация.
• Резервно копие, опис, подготовка на новата среда и тестване стават преди смяната.
• Намалете TTL поне един стар TTL предварително и го върнете обратно след това.
• При трансфер на DNS управлението зоната трябва да е напълно готова при новия доставчик преди смяната на DNS сървърите; не забравяйте записи като A записа на пощенския сървър.
• С DNSSEC: първо премахнете стария DS, после сменете, после поставете новия DS.
• По време на смяната четете и двете пощенски кутии и прекратете старата услуга едва когато всичко работи.

Тест

Задача

Задача Z6.3: Опис за трансфер. Направете опис за трансфер на Вашия собствен домейн (или, ако нямате домейн, на sidn.nl, сайта на SIDN, регистъра на .nl в Нидерландия). Намерете и попълнете: DNS сървърите, A и AAAA записите на @ и www, MX записите, SPF записа, DMARC записа и дали има DS запис. Програмата сравнява всяка стойност с това, което DNS отговаря сега.

Задача O6.3: Самостоятелна настройка във Вашата тренировъчна зона. Във Вашата тренировъчна зона <code>.dnspractice.eu има малък "съществуващ" уебсайт: www.<code>.dnspractice.eu сочи към 192.0.2.10 (A) и 2001:db8::10 (AAAA), с TTL 300. Пощата на тренировъчната зона е на mail.<code>.dnspractice.eu (192.0.2.25) с MX запис (приоритет 10). Изиграйте трансфер на уебсайт:

1. Намалете TTL на записите на www.<code>.dnspractice.eu на 60.
2. Накарайте www.<code>.dnspractice.eu да сочи към новия сървър 198.51.100.10 и премахнете AAAA записа: новият сървър няма IPv6.
3. Върнете TTL на www.<code>.dnspractice.eu обратно на 300.
4. Оставете пощенските записи непроменени.

Тренировъчната зона използва кратки TTL стойности (между 30 и 300 секунди), за да не се налага да чакате; при Вашия реален домейн използвате например 3600 като стандарт и 300 по време на трансфера.

Допълнително четене

Стъпките в тези статии се отнасят за панелите на WebOké; в други панели работи по подобен начин.

• Прехвърляне на домейн, уебсайт и имейл едновременно без прекъсване: план за действие
• Използване на собствени или външни nameserver сървъри (като Cloudflare) за Вашия домейн
• Уебсайтът или имейлът не работи след преместване или промяна на DNS: проверете Вашия домейн
• Създаване и възстановяване на резервно копие на DNS
• Получаване на имейли по време на трансфера на домейн
• Разгледайте Вашия уебсайт в WebOké, преди да прехвърлите домейна
• Ръководство за DirectAdmin 18.7: Моят домейн още не работи след трансфер или промяна
• Ръководство за DirectAdmin 18.8: Тестване на моя уебсайт преди преместването на домейна
• Ръководство на WebOké 5.7: Връщане на DNS и създаване на резервно копие на DNS
• Ръководство на WebOké 5.8: DNSSEC и DANE