Какво прави DNS и как работи?

DNS (Domain Name System) е разпределената инфраструктура за именуване в интернет, която превежда четими от хора имена на домейни — като example.com — в четими от машини IP адреси като 93.184.216.34. Без DNS всяка заявка от браузър, API повикване и доставка на имейл би изисквала от потребителите и приложенията да знаят точния числов адрес на всеки отдалечен хост, което би направило съвременния интернет оперативно невъзможен в мащаб.

В основата си DNS е глобално разпределена, йерархична база данни. Тя не е единичен сървър или централизиран регистър — тя е дърво на делегиране, обхващащо стотици хиляди авторитетни сървъри за имена по целия свят, координирани чрез малък набор от корени сървъри и управлявани от стандарти, дефинирани в RFC 1034 и RFC 1035.

Защо DNS е повече от просто „телефонен указател”

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

• Маршрутизиране на поща чрез MX записи, насочващи имейла към правилните пощенски сървъри
• Откриване на услуги чрез SRV записи, използвани от протоколи като SIP, XMPP и вътрешната мрежа на Kubernetes
• Верификация на собствеността на домейн чрез TXT записи, използвани за SPF, DKIM, DMARC и Google Search Console
• Канонично именуване чрез CNAME записи, позволяващи CDN интеграция и балансиране на натоварването
• IPv6 адресиране чрез AAAA записи
• Обратни търсения чрез PTR записи в зоната in-addr.arpa, критични за репутацията на пощенски сървъри и одит на сигурността
• DNSSEC валидация, която добавя криптографски подписи към DNS отговорите за предотвратяване на отравяне на кеша

Всеки път, когато изпращате имейл, свързвате се с VPN или зареждате уеб приложение, DNS разрешава множество типове записи на заден план — често десетки заявки на зареждане на страница.

DNS йерархията: Как е структурирано пространството от имена

DNS е организиран като обърнато дърво. Разбирането на тази структура е от съществено значение за разбирането защо разрешаването работи по начина, по който работи.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Корена зона (.): Управлявана от IANA. Има 13 логически адреса на корени сървъри (от A до M), управлявани от организации като Verisign, NASA и ICANN. На практика те се обслужват от стотици физически машини чрез anycast маршрутизиране.
• Домейни от най-високо ниво (TLD): Общи TLD като .com, .net, .org, и TLD по код на държава като .uk, .de, .md. Всеки TLD има свой собствен набор от авторитетни сървъри за имена.
• Домейни от второ ниво (SLD): Домейнът, който регистрирате — example.com. Авторитетният DNS за тази зона се контролира от лицето, регистрирало домейна.
• Поддомейни: www, mail, api, staging — това са записи в зоната на SLD, напълно контролирани от собственика на домейна.

Стъпка по стъпка: Как се разрешава DNS заявка

Пълното рекурсивно DNS разрешаване включва до седем отделни мрежови обмена. Ето точната последователност:

Стъпка 1 — Проверка на кеша на браузъра

Когато въведете www.example.com в браузъра си, операционната система първо проверява локалния си DNS кеш. В Linux това може да се управлява от systemd-resolved; в Windows — от услугата DNS Client. Ако съществува валиден кеширан запис и неговият TTL (Time to Live) не е изтекъл, разрешаването спира тук.

Можете да прегледате локалния DNS кеш в Linux с:

resolvectl statistics

Или да го изчистите с:

sudo resolvectl flush-caches

В Windows:

ipconfig /displaydns
ipconfig /flushdns

Стъпка 2 — Заявка към рекурсивния резолвер

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

• Резолверът на вашия ISP (присвоен чрез DHCP)
• Публичен резолвер: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Самостоятелно хостван резолвер като Unbound или BIND на вашата собствена VPS Хостинг инфраструктура

Рекурсивният резолвер върши тежката работа. Той ще обходи DNS йерархията от ваше име и ще кешира резултатите, за да обслужва бъдещи заявки по-бързо.

Стъпка 3 — Препращане от корен сървър

Рекурсивният резолвер запитва един от 13-те клъстера от корени сървъри. Корен сървърът не знае IP адреса на www.example.com. Вместо това той връща препращане — списък с авторитетни сървъри за имена за зоната на TLD .com, заедно с техните IP адреси (наречени glue записи).

Стъпка 4 — Заявка към TLD сървъра за имена

Резолверът запитва TLD сървърите за имена на .com (управлявани от Verisign). Тези сървъри също не притежават окончателния отговор. Те връщат друго препращане — авторитетните сървъри за имена конкретно за example.com (напр. ns1.example.com, ns2.example.com).

Стъпка 5 — Заявка към авторитетния сървър за имена

Резолверът запитва авторитетния сървър за имена за example.com. Този сървър съдържа действителния файл на зоната и връща окончателния отговор — записа A, съдържащ IPv4 адреса (или AAAA за IPv6).

Стъпка 6 — Кеширане на отговора и доставка

Рекурсивният резолвер кешира отговора според TTL стойността на записа (напр. 300 секунди = 5 минути, 86400 секунди = 24 часа). След това връща IP адреса на операционната система на клиента, която го предава на браузъра.

Стъпка 7 — TCP/IP връзка

Браузърът използва разрешения IP адрес, за да отвори TCP връзка (обикновено на порт 443 за HTTPS). Задачата на DNS е вече завършена. Уеб сървърът отговаря и страницата се зарежда.

Целият процес — стъпки от 2 до 6 — обикновено завършва за 20–120 милисекунди при топъл кеш на резолвера, и под 500 милисекунди при напълно студено, некеширано разрешаване, преминаващо през всички нива на йерархията.

Типове DNS записи: Техническа справка

CAA записите заслужават специално споменаване: те инструктират сертифициращите органи кои организации имат право да издават SSL Сертификати за вашия домейн — критичен контрол за сигурност, който често се пренебрегва.

Типове DNS заявки: Рекурсивни срещу итеративни срещу нерекурсивни

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

TTL: Най-неразбраният DNS параметър

TTL (Time to Live) е броят секунди, през които DNS запис може да бъде кеширан от резолвери и клиенти. Задава се от собственика на домейна в файла на зоната.

• Нисък TTL (60–300 секунди): По-бързо разпространение на промените. От съществено значение преди планирани миграции, промени на IP или събития при отказ. Увеличава натоварването от заявки към авторитетните сървъри.
• Висок TTL (3600–86400 секунди): Намалява натоварването на резолвера и ускорява повторните заявки. Промените отнемат повече време за глобално разпространение.

Критична оперативна информация: При планиране на миграция на сървър или промяна на IP, намалете TTL до 300 секунди поне 48 часа преди промяната. Това гарантира, че когато актуализирате записа A, нито един резолвер не кешира старата стойност за повече от 5 минути. Неспазването на това е една от най-честите причини за продължителен престой по време на миграции.

Когато регистрирате домейн чрез Регистрация на домейн и го насочите към нов сървър, прозорецът за разпространение се управлява директно от предишната TTL стойност — не от произволното правило „24–48 часа”, което често се цитира неправилно.

DNS транспортни протоколи: UDP, TCP, DoH и DoT

Традиционният DNS работи върху UDP порт 53 за заявки под 512 байта. Отговори, надвишаващи този размер, предизвикват преминаване към TCP порт 53. DNSSEC отговори, трансфери на зони (AXFR) и големи TXT записи обикновено изискват TCP.

Съвременните DNS протоколи за поверителност значително промениха тази картина:

DoH срещу DoT — реалната оперативна разлика: DoH тунелира DNS в HTTPS трафик на порт 443, правейки го неразличим от обикновен уеб трафик. Това е полезно за поверителност, но прави мониторинга и филтрирането на корпоративни мрежи значително по-трудни. DoT използва специален порт (853), който мрежовите администратори могат да наблюдават, блокират или проверяват независимо. За самоуправлявана инфраструктура на Dedicated сървър, стартирането на локален DoT или DoH резолвер ви дава едновременно поверителност и пълен контрол върху политиката за разрешаване.

DNSSEC: Криптографска цялост за DNS

DNSSEC (DNS Security Extensions) добавя верига от криптографски подписи към DNS отговорите, позволявайки на резолверите да проверят, че отговорът е автентичен и не е бил манипулиран при предаване. Защитава срещу отравяне на DNS кеша (атака на Kaminsky) и DNS подправяне тип „човек по средата”.

DNSSEC не криптира DNS трафика — само го подписва. Веригата от подписи работи по следния начин:

1. Собственикът на зоната генерира Zone Signing Key (ZSK) и Key Signing Key (KSK)
2. Всеки набор от DNS записи се подписва с ZSK, произвеждайки RRSIG записи
3. KSK подписва набора от записи DNSKEY
4. Запис DS (Delegation Signer) се публикува в родителската зона (напр. .com), създавайки веригата на доверие обратно до корена

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

Чести DNS грешки и как да ги диагностицирате

NXDOMAIN — Несъществуващ домейн

Авторитетният сървър потвърди, че домейнът не съществува. Чести причини: правописна грешка в името на домейна, изтекла регистрация на домейна, изтрит DNS запис.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Грешка на сървъра

Резолверът не успя да завърши заявката. Чести причини: грешка при DNSSEC валидация, недостъпен авторитетен сървър, неправилно конфигуриран файл на зоната.

dig +dnssec example.com
# Look for: status: SERVFAIL

За да заобиколите DNSSEC валидацията и да изолирате проблема:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Остарял кеш / Забавяне на разпространението

След актуализиране на DNS запис, старите стойности продължават да съществуват в кешовете на резолверите до изтичане на TTL. За да запитате директно авторитетния сървър и да заобиколите кеша на резолвера:

dig @ns1.example.com www.example.com

Проверка на глобалното разпространение на DNS

Използвайте dig с конкретни публични резолвери, за да проверите статуса на разпространение:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS в хостинг среди: Практически конфигурации

Когато разгръщате уебсайт или приложение на VPS с cPanel, управлението на DNS обикновено се извършва чрез DNS клъстера на WHM или Zone Editor на cPanel. Разбирането на основната структура на файла на зоната ви позволява да правите промени, които GUI не излага.

Минимален файл на зоната за example.com изглежда така:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

За да функционира правилно Имейл хостинг, записът MX трябва да сочи към хостово име (не директно към IP адрес), а самото хостово име трябва да се разрешава чрез запис A. Честа неправилна конфигурация е насочването на MX директно към IP — това нарушава RFC 2821 и причинява грешки при доставка при строги пощенски сървъри.

DNS производителност: Какво всъщност влияе на скоростта на разрешаване

• Близост на резолвера: Резолвер, географски близо до клиента (или в същата мрежа), драстично намалява времето за двупосочно предаване.
• Процент на попадения в кеша: Домейни с висок трафик и разумни TTL стойности почти винаги се обслужват от кеша. Разрешаването при студен кеш е 5–20 пъти по-бавно.
• Anycast маршрутизиране: Корени сървъри и основни публични резолвери използват anycast, автоматично насочвайки заявките към най-близкия физически възел.
• Брой DNS търсения на страница: Една уеб страница може да предизвика 20–50 DNS заявки (CDN активи, анализи, шрифтове, рекламни мрежи). Браузърите ги паралелизират, но всяко уникално хостово име изисква собствено търсене.
• DNS предварително извличане: Съвременните браузъри поддържат <link rel="dns-prefetch" href="//cdn.example.com"> за разрешаване на хостови имена на трети страни преди да са необходими, намалявайки възприеманата латентност.

DNS срещу алтернативни механизми за разрешаване

Файлът /etc/hosts се оценява преди DNS на практически всяка операционна система. Това го прави безценен за локална разработка — можете да съпоставите myapp.local с 127.0.0.1 без да докосвате каквато и да е DNS инфраструктура.

Основни изводи и контролен списък за вземане на решения

Използвайте този контролен списък при конфигуриране или отстраняване на проблеми с DNS за всяка производствена среда:

• Преди всяка миграция на сървър: Намалете TTL до 300 секунди поне 48 часа предварително
• За доставяемост на имейл: Проверете дали MX, SPF (TXT), DKIM (TXT), DMARC (TXT) и PTR записите са всички правилно конфигурирани
• За сигурност: Активирайте DNSSEC на вашия домейн и добавете CAA записи за ограничаване на издаването на сертификати
• За поверителност: Използвайте DoT или DoH на клиентски устройства и сървъри; избягвайте изпращането на некриптиран DNS през ненадеждни мрежи
• За производителност: Задайте TTL на 3600–86400 за стабилни записи; използвайте 300 само за записи, които се променят често
• За диагностика: Винаги запитвайте директно авторитетния сървър с dig @ns1.yourdomain.com, за да разграничите забавянето на разпространението от действителна неправилна конфигурация
• За управление на зони: Увеличавайте серийния номер на SOA всеки път, когато модифицирате файл на зоната — резолверите го използват за откриване на промени
• За хостинг: Потвърдете, че делегирането на сървъри за имена на вашия регистратор съответства на NS записите в файла на вашата зона — несъответствието е най-честата единична причина за „DNS не работи” след прехвърляне на домейн

Често задавани въпроси

Каква е разликата между DNS резолвер и авторитетен DNS сървър?

Рекурсивният резолвер (напр. 8.8.8.8) е посредник, който запитва DNS йерархията от името на вашето устройство и кешира резултатите. Авторитетният сървър за имена съдържа действителните записи на зоната за конкретен домейн и предоставя окончателни отговори. Вашият резолвер запитва много авторитетни сървъри; авторитетният сървър на вашия домейн отговаря само за зоните, които хоства.

Защо разпространението на DNS отнема време след актуализиране на запис?

Забавянето на разпространението се причинява от кеширане, базирано на TTL. Всеки резолвер, който преди това е кеширал стария ви запис, ще продължи да го обслужва до изтичане на TTL. Ако TTL ви е бил 86400 (24 часа), резолверите могат да обслужват стария запис до 24 часа след актуализацията ви. Това не е грешка — това е предвиденият механизъм за кеширане, който прави DNS мащабируем.

Какво е DNS течове и защо е важно?

DNS течове възникват, когато вашето устройство изпраща DNS заявки извън предвидения резолвер — обикновено резолвера на вашия ISP — дори когато използвате VPN или инструмент за поверителност. Това излага вашата активност при сърфиране на вашия ISP. Можете да тествате за течове на dnsleaktest.com и да ги поправите, като конфигурирате вашия VPN клиент да налага DNS маршрутизиране чрез собствения си резолвер.

Може ли DNS да се използва като вектор за атака?

Да. Честите DNS-базирани атаки включват отравяне на кеша (инжектиране на фалшиви записи в кеша на резолвера), DNS усилване DDoS (използване на отворени резолвери за заливане на цел с големи DNS отговори), DNS отвличане (пренасочване на заявки към злонамерени сървъри) и DNS тунелиране (ексфилтриране на данни чрез кодирането им в низове на DNS заявки). DNSSEC смекчава отравянето на кеша; ограничаването на скоростта и ограничаването на скоростта на отговор (RRL) на авторитетните сървъри смекчават усилването.

Как да намеря авторитетните сървъри за имена за всеки домейн?

Използвайте dig с типа запис NS и флага +short за чист изход:

dig NS example.com +short

За проследяване на пълния път на делегиране от корена до авторитетния, използвайте:

dig +trace example.com

Това показва всеки препращащ прескок — корен → TLD → авторитетен — което е най-надеждният начин за диагностициране на неправилни конфигурации на делегиране.