Модул 6 · 6.2

„Разпространение“: защо едни го виждат веднага, а други не

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

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

Основни понятия: „разпространение“ (propagation), кеш, негативен кеш (NXDOMAIN), SOA minimum, TTL на делегация, смяна на DNS сървър, изчистване на кеш

Едно недоразумение в една дума

Променили сте запис. Колегата Ви вече вижда новия уебсайт, а Вие все още стария. В интернет четете: „почакайте, DNS все още трябва да се разпространи.“ Думата пропагация (разпространение) създава впечатлението, че промяната Ви се разпространява като вълна по интернет, от сървър на сървър.

Това не работи така. Промяната Ви веднага присъства на авторитетните DNS сървъри (nameserver) на Вашия домейн (или в рамките на няколко минути, ако Вашият DNS доставчик синхронизира няколко DNS сървъра). Нищо не се изпраща наоколо. Това, което виждате, е изтичането на кешове: всеки резолвер (resolver) дава старото отговор, докато TTL в неговия кеш не изтече (урок 6.1). Тъй като всеки резолвер е започнал да брои в различен момент, едни виждат промяната по-рано от други.

„Разпространението“ е всъщност: изчакване докато всички кешове се изпразнят. Това разбиране Ви помага, защото сега знаете точно какво чакате и колко максимално дълго.

Колко време отнема?

Това зависи от това какво променяте.

Какво променяте	Какво чакате?	Обикновено
Съществуващ запис (A, MX, TXT ...)	TTL на стария запис	В рамките на TTL, често един час
Нов запис, който преди не е съществувал	Нищо, освен ако някой вече е питал за името по-рано (негативен кеш)	Веднага до няколко минути
DNS сървърите на Вашия домейн	TTL на NS записите при регистъра	От няколко часа до два дни

Съществуващи записи

Тук е просто: старият TTL е максимумът. Ако записът е имал TTL 3600, всеки ще види новия отговор най-късно един час след промяната Ви. Ако някой все още вижда старото след повече от час, проблемът е другаде (вижте по-долу).

Нови записи и негативният кеш

Нов запис обикновено работи веднага, освен ако някой вече е питал за името, докато то още не е съществувало. Резолверът (resolver) тогава е получил отговор NXDOMAIN („това име не съществува“) или „това име съществува, но няма запис от този тип“. И това „не“ се запомня. Това се нарича негативен кеш.

Колко дълго се пази едно „не“, не е записано в запис, който не съществува. То идва от SOA записа на зоната: според RFC 2308 това е по-малкото от две числа, TTL на самия SOA запис и последното поле на SOA записа („minimum“). Пример:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; сериен номер
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Тук едно „не“ се запомня максимум 300 секунди (по-малкото от 3600 и 300). При някои зони това е час или повече.

Затова и златното правило: не отваряйте нов поддомейн в браузъра си, преди да сте го създали. Иначе Вашият компютър и резолвер ще запомнят, че той не съществува, и само Вие ще трябва да чакате.

Смяна на DNS сървъри

При смяна на DNS сървъри чакате нещо друго: NS записите при регистъра (registry) на Вашето разширение. Тези записи казват на резолверите къде се намират DNS сървърите на Вашия домейн (урок 2.1), и те също се запомнят. Всеки регистър избира собствен TTL за това. Измерено през ноември 2026:

Разширение	TTL на NS записите при регистъра
.nl	3600 секунди (1 час)
.org	3600 секунди (1 час)
.com	172800 секунди (2 дни)

Освен това регистърът понякога не публикува промяната Ви веднага, а DNS сървърите на предишния Ви доставчик често продължават да отговарят със старата зона през това време. Затова при смяна на DNS сървъри разчитайте на няколко часа, а при .com на максимум два дни. Затова се погрижете двата доставчика да имат едни и същи, правилни записи по време на смяната (урок 6.3).

Само Вие ли все още виждате старото?

Онлайн проверка вече показва новия отговор при почти всички резолвери, но не и при Вас? Тогава старият отговор се намира някъде близо до Вас. Преминете през тези стъпки, от бързи към по-задълбочени:

Поверителен прозорец или друг браузър. Браузърът Ви пази DNS отговори и страници.
Телефон чрез 4G или 5G, с изключен wifi. Така ще използвате резолвера на мобилния си оператор вместо този на домашната Ви мрежа.
Изчистване на кеша на компютъра Ви.
- Windows (Командна подкана): ipconfig /flushdns
- macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux със systemd-resolved: resolvectl flush-caches
Рестартиране на рутера. Много рутери работят като малък резолвер със собствен кеш.
Проверка на hosts файла. Тествали ли сте преди нов сървър, като сте поставили адреса в hosts файла (C:\Windows\System32\drivers\etc\hosts или /etc/hosts)? Този ред има предимство пред DNS. Премахнете го. Това често се забравя.
Проверка директно при източника. Запитайте записа при авторитетния DNS сървър (dig A example.com @ns1.hosting.example). Ако там все още стои старият отговор, промяната не е запазена правилно или сте я направили на грешното място.

И след времето на изчакване все още нищо?

Ако TTL отдавна е изтекъл и дори онлайн инструментите показват стария отговор, чакането е безсмислено. Тогава има нещо друго. Трите най-чести причини:

Промяна на грешното място. Вашият домейн използва DNS сървърите на друг доставчик (например Cloudflare или конструктор на сайтове), а Вие сте променили записите при Вашия хостинг доставчик. Проверете кои DNS сървъри има Вашият домейн (урок 2.1) и направете промяната там.
Печатна грешка или липсваща точка. mail.example.com без точка в края в много панели се превръща в mail.example.com.example.com (урок 2.2).
DNS сървърите не са съгласувани помежду си. Един домейн има поне два DNS сървъра. Ако те не се синхронизират правилно, единият дава новия, а другият стария отговор. Сравнете серийния номер на SOA при всеки DNS сървър: той трябва да е еднакъв.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

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

Искате ли да видите какво отговарят резолвери на различни места по света, използвайте онлайн DNS проверка, която пита резолвер за всяка държава (например dnschecker.org). В примерния панел Моят WebOké картата Domain / Email проверява DNS сървърите и записите на Вашия домейн при авторитетните DNS сървъри, а DNS диагностиката сравнява серийните номера на DNS сървърите. Други доставчици често имат подобна проверка в своя панел; ако не, dig и онлайн инструментите от урок 8.3 дават същата картина.

Обобщение

Нищо не се „разпространява“: Вие чакате кешовете да изтекат.
Променен запис се вижда навсякъде най-късно след стария TTL; нов запис обикновено веднага, освен ако някой вече е питал за името по-рано (негативен кеш, определен от SOA записа).
Смяната на DNS сървър зависи от TTL при регистъра: при .nl един час, при .com два дни.
Само Вие ли все още виждате старото? Поверителен прозорец, 4G, изчистване на кеша, рестартиране на рутера и проверка на hosts файла.
Все още старо при авторитетния DNS сървър? Тогава чакането е безсмислено: потърсете грешката.

Тест

Задача

Задача Z6.2: TTL на делегация и негативен кеш. Два въпроса, на които може да се отговори с dig или онлайн dig инструмент:

Колко секунди помнят резолверите, според регистъра на .com, DNS сървърите на google.com? Запитайте .com сървър: dig NS google.com @a.gtld-servers.net и погледнете TTL в частта AUTHORITY.
Колко секунди помни резолверът, че име под sidn.nl не съществува? Запитайте SOA записа на sidn.nl при ns1.sidn.nl и приложете правилото от този урок (по-малкото от SOA TTL и SOA minimum).

За допълнително четене

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

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг