Всеки уебсайт има числов адрес, но никой не помни числа – помним имена. DNS е невидимата система, която свързва двете, и без нея интернет, какъвто го познаваме, не би съществувал за хората. Всяко зареждане на страница, всеки изпратен имейл и всяка API заявка минават през нея, обикновено за под секунда и без да забележите.
В тази статия екипът на CreateWeb обяснява какво е DNS, как работи стъпка по стъпка, какви видове записи съществуват и защо правилната DNS конфигурация е важна за скоростта, сигурността и SEO на сайта ви – всичко с прости думи, без предположение за технически познания. За да стане ясно как заявката намира отговора си, въвеждаме оригинална рамка, наречена DNS Resolution Relay, щафетата на разрешаването.
Какво е DNS
DNS (Domain Name System) е системата, която превръща домейн имена (например createweb.bg) в IP адреси (например 185.199.108.153). Най-простата аналогия е телефонният указател – вие знаете името на човека, а указателят ви дава номера.
Всеки уебсайт се намира на сървър с уникален IP адрес. Когато въведете домейн в браузъра, DNS „превежда“ това име в числовия адрес на сървъра, за да може браузърът да се свърже с него и да зареди страницата. Без DNS щяхте да въвеждате числа вместо имена за всеки сайт; с DNS работите с имена, а системата се грижи за всичко останало, невидимо и за под секунда. Системата е глобален, йерархичен указател, координиран от организации като ICANN, и е разпределена по хиляди сървъри на всеки континент. За мащаба: Cloudflare DNS покрива над 20% от всички уебсайтове и обработва трилиони заявки дневно. DNS е тясно свързан с понятието за домейн – какво точно представлява домейнът е разгледано в материала какво е домейн.
DNS Resolution Relay: рамка за това как заявката намира отговора
Повечето хора си представят, че някъде има един голям списък „домейн към IP“, който браузърът проверява. Реалността е по-елегантна: никой сървър не знае целия отговор, но всеки знае кой го знае. DNS Resolution Relay прави този процес видим като щафета, в която заявката се предава от звено на звено, докато стигне до този, който държи реалния адрес.
| Бегач | Какво знае | Подава на |
|---|---|---|
| Browser/OS кеш | скорошни отговори | resolver (ако няма кеш) |
| Recursive resolver | нищо, но търси вместо вас | root сървър |
| Root сървър | кой отговаря за .bg | TLD сървър |
| TLD сървър (.bg) | кой е authoritative за домейна | authoritative сървър |
| Authoritative сървър | реалния IP адрес | връща отговора |
Принцип на рамката: нито едно звено не знае целия път – всяко знае само следващата спирка. Затова скоростта зависи от това колко рано щафетата спира: ако отговорът е в кеша, тя приключва за под 1 милисекунда; ако трябва да измине целия път, отнема 20-120 милисекунди. Това прави кеширането (TTL) и бързият resolver двата основни лоста за скорост, а сигурността (DNSSEC, криптиране) защитава всяко подаване от подмяна.
Прилагане на рамката: когато оптимизирате или диагностицирате DNS, мислете за щафетата. Бавно първо зареждане често значи бавна щафета (далечен или претоварен resolver), а решението е бърз anycast DNS доставчик, който скъсява пътя. Промяна, която „не се вижда“ веднага, значи, че старият отговор още е кеширан някъде по щафетата – решението е предварително намаляване на TTL. А имейл, който не пристига, значи че едно конкретно звено (MX записът) сочи на грешно място. Силата на модела е, че всеки симптом сочи към конкретно звено: вместо мъгливото „нещо с DNS не е наред“, знаете дали проблемът е в скоростта на щафетата, в кеширането или в конкретен запис. Следващите секции разглеждат всяко звено и всеки тип запис поотделно.
Как работи DNS: стъпка по стъпка
Когато напишете createweb.bg в адресната лента, браузърът минава през щафетата, за да намери IP адреса. Първо проверява собствения си кеш – ако сте посещавали сайта наскоро, вече знае адреса и зарежда директно. Ако не, пита операционната система, която също поддържа DNS кеш.
Ако и там няма отговор, заявката отива до recursive resolver – DNS сървър, обикновено управляван от интернет доставчика или от публичен доставчик като Cloudflare (1.1.1.1) или Google (8.8.8.8). Resolver-ът е „детективът“, който тръгва да търси. Той първо пита root сървър (в света има 13 групи root сървъри, означени от A до M, разпределени чрез anycast на стотици локации); root сървърът не знае IP адреса на createweb.bg, но знае кой отговаря за .bg домейните и насочва resolver-а към TLD сървъра за .bg. TLD сървърът знае кой е авторитетният DNS сървър за конкретния домейн и насочва resolver-а натам. Авторитетният сървър е последната спирка – той има записите и връща IP адреса. Resolver-ът получава отговора, кешира го за следващите заявки и го предава на браузъра, който се свързва със сървъра и зарежда страницата. Цялото пътуване отнема 20-120 милисекунди при нормални условия, а за повторни посещения под 1 ms, защото отговорът е кеширан. Подробната механика е описана и в обяснението на Cloudflare какво е DNS.
DNS кеширане и TTL
TTL (Time to Live) е стойност в секунди, която казва на resolver-а колко дълго да пази DNS отговора в кеша, преди да попита отново. Стандартният TTL за повечето домейни е 3 600 секунди (1 час). Високият TTL означава по-малко DNS заявки и по-бързо зареждане за повторни посещения, но по-бавно разпространение на промените; нисък TTL означава по-бърза реакция при промяна, но повече заявки.
За стабилен сайт, който рядко сменя хостинг, TTL от 3 600 секунди до 86 400 секунди (24 часа) е оптимален. Преди планирана промяна (например смяна на хостинг) TTL трябва да се намали до 300 секунди поне 24-48 часа предварително, така че когато промените записите, новият адрес да се разпространи за минути, а не за часове. Практически пример: планирате да преместите сайта в петък – в сряда намалявате TTL от 3 600 на 300, изчаквате 48 часа да изтече старият TTL от кешовете, а в петък правите промяната на A записа, при което за 5-15 минути повечето потребители вече виждат новия сървър. Точно тази механика стои зад целия процес на миграция на сайт.
Видове DNS записи и за какво служат
DNS не е един запис, а набор от записи, всеки с конкретна функция. A записът е най-фундаменталният – свързва домейн име с IPv4 адрес и казва на интернет „този сайт се намира на този сървър“. AAAA записът прави същото за IPv6 адреси (по-новия стандарт), а повечето модерни хостинг доставчици поддържат и двата протокола. При изработка на уебсайт A записът е първото нещо, което се конфигурира.
CNAME (Canonical Name) записът е псевдоним – насочва едно име към друго, най-често www версията към основния домейн (или обратно), за да работят и двата варианта. Използва се и за поддомейни (например blog.домейн.bg), но не може да съществува заедно с други записи за същото име, затова не се ползва за главния домейн, където стои A записът. MX (Mail Exchange) записът определя кой сървър получава имейлите за домейна – когато някой пише до info@домейн.bg, пощенският сървър на подателя проверява MX записа, за да разбере къде да достави писмото; грешен или липсващ MX означава загубени имейли. В нашия екип конфигурираме MX записите при всеки проект, за да работи професионалната имейл услуга от ден първи, като част от хостинг услугите.
TXT записът съхранява текстова информация, която други системи четат. Три критични употреби са свързани с имейл сигурността: SPF (Sender Policy Framework) указва кои сървъри имат право да изпращат имейли от името на домейна, DKIM (DomainKeys Identified Mail) добавя цифров подпис, доказващ че имейлът не е променян, а DMARC казва на получаващия сървър какво да прави с имейли, които не минават SPF или DKIM проверката. TXT записите се ползват и за верификация – например когато свързвате домейна с Google Search Console, Google ви дава TXT запис, който добавяте в DNS. Накрая NS (Name Server) записът определя кои DNS сървъри са авторитетни за домейна; променя се при смяна на DNS доставчик, не при смяна на хостинг.
Как DNS влияе на скоростта и SEO
DNS lookup time е първата стъпка от зареждането на всяка уеб страница – преди браузърът дори да се свърже със сървъра, трябва да получи IP адреса. Бърз DNS отговор е под 50 ms, среден 50-100 ms, а бавен над 150 ms. Разликата звучи малка, но се натрупва: една страница може да зарежда ресурси от 5-15 различни домейна (CDN, шрифтове, скриптове, аналитика), така че ако всеки lookup отнема 150 ms вместо 30 ms, добавяте 600-1 800 ms само за DNS, преди сървърът да е върнал и един байт.
Google използва Time to First Byte (TTFB) като компонент на Core Web Vitals, а DNS resolution е част от TTFB – бавният DNS може да е невидимият фактор, който дърпа SEO позициите надолу, тема, свързана с материала за Core Web Vitals. За да подобрите DNS скоростта, използвайте premium доставчик с anycast мрежа (Cloudflare, чийто безплатен план е достатъчен за повечето сайтове, Google Cloud DNS или AWS Route 53) – тези доставчици имат сървъри на десетки локации и отговарят за под 20 ms от почти навсякъде. Важно: дори най-бързият хостинг не може да компенсира бавен DNS, защото DNS е първото звено на щафетата – ако то е бавно, всичко останало чака.
DNS и сигурност
DNS е критична точка за сигурността, защото целият трафик минава през него – ако атакуващ манипулира DNS отговорите, може да пренасочи потребителите към фалшив сайт, без те да забележат. DNS spoofing (cache poisoning) е атака, при която злонамерен отговор се „инжектира“ в кеша на resolver; потребителят въвежда вашия домейн, но получава фалшив IP и попада на сайт, контролиран от атакуващия, с риск от кражба на пароли и данни. Това е една от причините криптирането и подписването на DNS да стават все по-важни.
DNSSEC (DNS Security Extensions) е механизъм за цифрово подписване на DNS отговори, който гарантира, че отговорът идва от авторитетния сървър и не е променян по пътя. Приемането е изненадващо ниско – към началото на 2026 г. едва малка част от заявките са реално валидирани с DNSSEC – но ако вашият доставчик го поддържа, активирайте го: допълнителен слой сигурност без негативен ефект върху скоростта. DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) криптират самите заявки, за да не виждат трети страни (включително интернет доставчикът) какви сайтове посещавате; ако ползвате Cloudflare (1.1.1.1) или Google (8.8.8.8) като resolver, заявките се криптират автоматично. На ниво домейн TXT записите за SPF, DKIM и DMARC са критичната защита срещу имейл spoofing – без тях всеки може да изпрати имейл „от“ вашия домейн (например фалшиво писмо от info@вашатафирма.bg с молба за банков превод). Сигурността на DNS е част от по-широката картина, разгледана в материала за плъгини за сигурност и в ръководството за SSL сертификати.
DNS при миграция на сайт или смяна на хостинг
Миграцията неизбежно включва DNS промени. Типичният сценарий: имате сайт на стар хостинг и искате да го преместите на нов сървър – файловете и базата данни се копират, но „превключването“, моментът, в който домейнът започва да сочи към новия сървър, се случва чрез DNS.
При правилна подготовка процесът изглежда така: две седмици преди миграцията се проверяват и документират текущите записи; 24-48 часа преди промяната TTL се намалява до 300 секунди, за да изтече старият кеш; в момента на миграцията A записът се променя да сочи към IP на новия сървър; пропагацията започва за 5-15 минути за resolver-и с нисък TTL; мониторингът продължава 24-48 часа, включително за имейли (MX записи). Фразата „DNS пропагация отнема 24-48 часа“ е worst-case сценарий, който се случва, когато TTL не е намален предварително – при правилна подготовка повечето потребители виждат новия сървър за минути. Пълният процес на миграция е разгледан в специализираното ни ръководство, а в нашия екип намаляваме TTL предварително, правим промените в часове с нисък трафик и мониторираме пропагацията в реално време за нулев или минимален downtime.
Как да изберете DNS доставчик
Когато регистрирате домейн, регистраторът предлага безплатен DNS и за повечето малки сайтове това е достатъчно. Но ако скоростта, сигурността и uptime-ът са важни, managed DNS доставчик прави разлика. Cloudflare предлага безплатен план с anycast мрежа на 330+ локации, DNSSEC поддръжка и средно време за отговор под 15 ms – за повечето бизнес сайтове в България това е оптималният безплатен избор. Google Cloud DNS и AWS Route 53 са платени (от $0,20-0,50 на зона месечно), но предлагат 100% SLA и са за enterprise проекти.
Критериите при избор са: anycast мрежа (сървъри на множество локации за по-бърз отговор), uptime SLA (99,99% е стандартът за premium DNS), DNSSEC поддръжка, лесен интерфейс за управление на записи и скорост на пропагация при промени. За повечето клиенти конфигурираме Cloudflare DNS заедно с хостинга – безплатен, бърз и сигурен; за проекти с по-високи изисквания използваме Google Cloud DNS или AWS Route 53.
Практически чеклист: DNS настройки за вашия сайт
Ако имате уебсайт или планирате нов, уверете се, че следните настройки са на място:
- A запис към IP адреса на хостинг сървъра (основата – без него сайтът не зарежда); добавете AAAA запис, ако хостингът поддържа IPv6.
- CNAME за www към основния домейн (или обратно), за да работят и двата варианта и да се избегне дублирано съдържание за SEO.
- MX записи към правилния имейл сървър (хостинг имейл, Google Workspace или Microsoft 365) – проверете два пъти, защото грешен MX означава загубени имейли.
- TXT записи за SPF, DKIM и DMARC за защита от spoofing и по-добра доставяемост (без тях имейлите ви имат по-голям шанс да попаднат в спам).
- TXT запис за Google Site Verification за свързване с Search Console.
- TTL 3 600 секунди за стабилен сайт; намалете до 300 секунди само преди планирана промяна.
- DNSSEC активиран, ако доставчикът го поддържа – няма недостатъци, добавя сигурност.
Ако всичко това звучи сложно, при всеки проект на CreateWeb конфигурираме DNS записите като част от процеса – домейн, хостинг, имейли, Google инструменти и поддръжка – всичко настроено правилно от ден първи. Свържете се с нашия екип за консултация.
Често задавани въпроси
Какво е DNS?
DNS (Domain Name System) е системата, която превръща домейн имена (например createweb.bg) в IP адреси – числовите адреси на сървърите. Без DNS трябва да помните числа вместо имена за всеки сайт. Тя работи като глобален телефонен указател, разпределен по хиляди сървъри.
Какво представлява DNS Resolution Relay?
DNS Resolution Relay е рамка, която представя DNS заявката като щафета от пет звена: browser/OS кеш, recursive resolver, root сървър, TLD сървър и authoritative сървър. Принципът е, че никое звено не знае целия отговор, а само следващата спирка, така че скоростта зависи от това колко рано щафетата спира (кеш = под 1 ms, пълен път = 20-120 ms).
Колко време отнема DNS пропагацията?
При правилна подготовка (намален TTL до 300 секунди 24-48 часа предварително) повечето потребители виждат промяната за 5-30 минути. Без подготовка пропагацията може да отнеме до 48 часа в най-лошия случай, защото ISP кешовете задържат стария отговор по-дълго.
Мога ли да сменя DNS без downtime?
Да, при правилен процес. Намалете TTL предварително, направете промяната в часове с нисък трафик и мониторирайте. Ако новият и старият сървър работят паралелно по време на пропагацията, downtime е нулев.
Какво е A запис и какво е MX запис?
A записът свързва домейна с IPv4 адреса на сървъра, на който е сайтът – без него сайтът не зарежда. MX (Mail Exchange) записът определя кой сървър получава имейлите за домейна – грешен или липсващ MX означава, че имейлите просто не пристигат.
DNS влияе ли на SEO?
Да, косвено. DNS lookup time е част от Time to First Byte (TTFB), който Google измерва като компонент на Core Web Vitals. Бавен DNS добавя 100-300 ms към зареждането, а всеки 100 ms допълнително намалява конверсиите с приблизително 1%. Premium DNS доставчик като Cloudflare може да намали lookup time до под 20 ms.
Какво е DNSSEC и трябва ли да го активирам?
DNSSEC (DNS Security Extensions) е механизъм за цифрово подписване на DNS отговори, който гарантира, че отговорът идва от правилния сървър и не е манипулиран. Приемането е ниско, но ползите са безспорни, а ако доставчикът ви го поддържа, активирането му е без недостатъци и добавя слой сигурност.
Заключение: невидимата основа на всеки сайт
DNS е невидимата основа, върху която стъпва всичко онлайн – всяко зареждане, всеки имейл, всяка заявка минава през него. DNS Resolution Relay прави процеса разбираем: заявката е щафета, в която никой не знае целия път, а само следващата спирка, и скоростта зависи от това колко рано спира щафетата. Правилната конфигурация на записите (A, CNAME, MX, TXT), разумен TTL, бърз anycast доставчик и активиран DNSSEC превръщат DNS от потенциален проблем в безшумна, надеждна основа.
За повечето бизнеси Cloudflare с безплатен план покрива скорост и сигурност повече от достатъчно; ключовото е записите да са правилни от самото начало, защото грешен A запис означава недостъпен сайт, а грешен MX – загубени имейли. Малко внимание към тези детайли при стартиране спестява часове диагностика по-късно. Свържете се с екипа на CreateWeb за консултация или разгледайте портфолиото с реализирани проекти.
За свързани специализирани ресурси: какво е домейн, качествен уеб хостинг, какво е SSL сертификат, миграция на сайт, Core Web Vitals, Google Search Console, плъгини за сигурност на WordPress, изработка на уеб сайт, поддръжка на сайт.
