DNS Сървърът Не Отговаря: Пълно Ръководство за Отстраняване на Проблеми

Грешката "DNS сървърът не отговаря" означава, че операционната ви система е изпратила заявка за разрешаване до DNS резолвър и не е получила отговор в рамките на времето за изчакване — така браузърът никога не е получил IP адреса, необходим за отваряне на TCP връзка. Резултатът е неуспешно зареждане на страницата дори когато физическата ви мрежова връзка работи напълно нормално. Основната причина може да се намира навсякъде в веригата за разрешаване: вашият локален stub резолвър, рекурсивният резолвър на вашия ISP, upstream авторитативен сървър или неправилно конфигурирано мрежово устройство между вас и някое от тях.

Това ръководство преминава през всеки слой на тази верига — от 30-секундно рестартиране на рутера до подмяна на драйвери на ниско ниво — с точни команди за Windows, macOS и Linux, плюс сравнение на публични резолвъри и матрица за вземане на решения, която да ви помогне бързо да изолирате проблема.

Какво всъщност се случва по време на DNS разрешаване

Преди да отстраните грешката, разбирането на пътя за разрешаване предотвратява загубата на усилия. Когато въведете example.com в браузър:

1. ОС проверява своя локален DNS кеш (и файла hosts).
2. Ако няма кеширан запис, stub резолвърът препраща заявката към рекурсивния резолвър, конфигуриран на мрежовия интерфейс (обикновено вашият рутер или сървър, назначен от ISP).
3. Рекурсивният резолвър обхожда DNS йерархията — root сървъри, TLD nameserver-и, авторитативни nameserver-и — и връща крайния запис A или AAAA.
4. ОС кешира резултата за продължителността на TTL на записа и предава IP адреса на браузъра.

Грешката „не отговаря” обикновено се появява на стъпка 2 или 3. Stub резолвърът е изпратил UDP пакет до порт 53 и е получил тишина. Тази тишина има изненадващо голям брой причини.

Основни причини за грешката „DNS сървърът не отговаря”

Повреди от страна на DNS резолвъра

• Конфигурираният рекурсивен резолвър е временно претоварен или офлайн.
• DNS инфраструктурата на вашия ISP е под DDoS атака или се извършва поддръжка.
• IP адресът на резолвъра се е променил, но устройството ви все още съхранява старата стойност.

Проблеми с локалната мрежа и хардуера

• Грешки във фърмуера на рутера, които повреждат DNS релето (често срещано при потребителски устройства след дълго работно време).
• DHCP наем, който е предоставил остарял или невалиден DNS сървърен адрес.
• Дефектен Ethernet кабел или деградирал Wi-Fi сигнал, причиняващ загуба на пакети специално на UDP порт 53.

Неправилни конфигурации на ниво хост

• Повреден или отровен локален DNS кеш, съдържащ остарели отрицателни отговори.
• Ръчно въведен DNS адрес, който е грешен или вече не е достъпен.
• Запис в hosts файла, който влиза в конфликт с очаквания DNS отговор.

Намеса на софтуер за сигурност

• Защитни стени или инструменти за защита на крайни точки, които блокират изходящ UDP/TCP порт 53 или прихващат DNS заявки за проверка и след това ги отхвърлят.
• VPN клиенти, които пренасочват DNS трафика през тунелна крайна точка, която в момента е недостъпна.
• Софтуер за родителски контрол, който действа като локален DNS прокси и се срива безшумно.

Проблеми с драйвери и ОС

• Остарял или повреден NIC драйвер, който неправилно обработва UDP дейтаграми.
• Услугата DNS Client на Windows (Dnscache) в заседнало състояние.
• Процес mDNSResponder на macOS, който е консумирал прекомерно количество памет и е спрял да отговаря.

Стъпка по стъпка: Решения, наредени по усилие и вероятност

Преминете през тях по ред. Всяка стъпка отнема по-малко от пет минути и елиминира конкретен слой от проблема.

Стъпка 1: Първо проверете обхвата на проблема

Преди да промените каквито и да е настройки, извършете бърза диагностика, за да потвърдите, че DNS е действително точката на повреда, а не общата свързаност:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Ако ping 8.8.8.8 успее, но nslookup example.com се провали, DNS разрешаването е категорично проблемът. Ако ping 8.8.8.8 също се провали, проблемът е по-дълбок — вероятно маршрутизиране или физическа свързаност — и DNS е симптом, а не причина.

Стъпка 2: Рестартирайте рутера и модема

Изключването от захранването изчиства вътрешния DNS релеен кеш на рутера, нулира DHCP наемите и възстановява WAN връзката с нови DNS сървърни назначения от вашия ISP.

1. Извадете захранващия кабел от модема и рутера.
2. Изчакайте пълни 30 секунди (кондензаторите се нуждаят от време за разреждане).
3. Включете модема първи; изчакайте да се синхронизира напълно (стабилна WAN светлина).
4. Включете рутера втори; изчакайте да завърши последователността на зареждане.
5. Свържете отново устройството си и повторете теста nslookup от Стъпка 1.

Краен случай: Ако рутерът ви работи седмици без рестартиране, DNS релето му (dnsmasq или подобно) може да има пълен кеш или изтичане на памет. Някои рутери, предоставени от ISP, имат известни грешки, при които DNS релето спира да препраща заявки след определен праг на работно време. Рестартирането е най-бързото решение.

Стъпка 3: Изчистете локалния DNS кеш

Остарели или повредени кеш записи карат ОС да връща лоши резултати или да генерира грешки при търсене, преди заявката дори да е напуснала машината.

Windows:

ipconfig /flushdns

Трябва да видите: Successfully flushed the DNS Resolver Cache.

macOS (специфично за версията — използвайте правилната команда за вашата ОС):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Стъпка 4: Преминете към надежден публичен DNS резолвър

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

Cloudflare 1.1.1.1 последователно измерва най-ниската средна глобална латентност на заявките в независими тестове. Quad9 е по-добрият избор, ако искате пасивно блокиране на домейни със зловреден софтуер без управление на отделен DNS филтър.

Промяна на DNS в Windows 10/11:

1. Отворете Настройки > Мрежа и интернет > Промяна на опциите на адаптера.
2. Щракнете с десен бутон върху активния адаптер и изберете Свойства.
3. Изберете Интернет протокол версия 4 (TCP/IPv4) и щракнете върху Свойства.
4. Изберете Използвай следните адреси на DNS сървъри.
5. Въведете избраните от вас основен и вторичен IP адреси на резолвъра.
6. Щракнете върху OK, след което изпълнете ipconfig /flushdns, за да изчистите остарелите кеш записи.

За IPv6 мрежи повторете процеса за Интернет протокол версия 6 (TCP/IPv6), като използвате IPv6 адресите на резолвъра (напр. Cloudflare: 2606:4700:4700::1111 и 2606:4700:4700::1001).

Промяна на DNS в macOS:

1. Отворете Системни настройки > Мрежа.
2. Изберете активната си връзка и щракнете върху Детайли.
3. Отидете в раздела DNS.
4. Премахнете съществуващите записи с бутона –, след което добавете избраните от вас IP адреси на резолвъра с +.
5. Щракнете върху OK и Приложи.

Промяна на DNS в Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Стъпка 5: Рестартирайте услугата DNS Client (Windows)

Услугата DNS Client на Windows (Dnscache) кешира разрешени имена и управлява stub резолвъра. Ако влезе в заседнало състояние, всички DNS заявки се провалят безшумно.

net stop dnscache
net start dnscache

Алтернативно, чрез конзолата за услуги: натиснете Win + R, въведете services.msc, намерете DNS Client, щракнете с десен бутон и изберете Рестартиране. Имайте предвид, че при някои версии на Windows 11 опцията за рестартиране е сива в GUI — вместо това използвайте метода от командния ред.

Стъпка 6: Временно деактивирайте защитната стена или софтуера за сигурност

Защитни стени на трети страни и пакети за защита на крайни точки понякога прихващат DNS трафика за проверка и, поради конфликт на правила или грешка в двигателя, изцяло отхвърлят пакетите.

Windows Defender Firewall (само за временен тест):

netsh advfirewall set allprofiles state off

Активирайте отново веднага след теста:

netsh advfirewall set allprofiles state on

macOS:

Отидете в Системни настройки > Поверителност и сигурност > Защитна стена и я изключете за целите на тестването.

Ако деактивирането на защитната стена реши проблема, не я оставяйте деактивирана. Вместо това отворете редактора на правила на защитната стена и потърсете правила, блокиращи изходящия трафик на UDP порт 53 и TCP порт 53. Добавете изрични правила за разрешаване за избраните от вас IP адреси на DNS резолвъра.

VPN клиентите заслужават специално внимание тук. Много VPN приложения инсталират локален DNS прокси на 127.0.0.1:53 и пренасочват всички заявки през тунела. Ако VPN сървърът е недостъпен, всяка DNS заявка се проваля. Прекъснете VPN връзката, тествайте DNS, след което се свържете отново и проверете настройките за DNS течове на VPN клиента.

Стъпка 7: Опитайте с различен браузър

Определени разширения за браузър — особено блокери на реклами, инструменти за поверителност и приставки за сигурност — прихващат DNS-over-HTTPS (DoH) заявки или променят поведението на системния резолвър. Ако DNS работи в един браузър, но не в друг, проблемът е на ниво разширение, а не на ниво ОС.

Тествайте първо в частен/инкогнито прозорец (разширенията обикновено са деактивирани). Ако това реши проблема, деактивирайте разширенията едно по едно, за да идентифицирате виновника. Ако проблемът продължава във всички браузъри, повредата е на ниво ОС или мрежа.

Стъпка 8: Актуализирайте или върнете назад мрежовите драйвери

Повреден NIC драйвер може да причини непостоянна обработка на UDP пакети, което се проявява като периодични DNS грешки дори когато TCP връзките работят.

Windows — актуализиране чрез Диспечер на устройствата:

1. Натиснете Win + X и изберете Диспечер на устройствата.
2. Разгънете Мрежови адаптери.
3. Щракнете с десен бутон върху адаптера и изберете Актуализиране на драйвер > Автоматично търсене на драйвери.
4. Рестартирайте след инсталацията.

Windows — връщане назад на наскоро актуализиран драйвер:

Ако DNS грешката се е появила веднага след актуализация на Windows, новият драйвер може да е регресията. В Диспечера на устройствата щракнете с десен бутон върху адаптера, изберете Свойства > Драйвер > Върни назад драйвера.

macOS: NIC драйверите са включени в macOS. Приложете всички чакащи системни актуализации чрез Системни настройки > Общи > Актуализация на софтуера.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Стъпка 9: Проверете физическите мрежови връзки

Ако използвате кабелна връзка, деградирал Ethernet кабел причинява периодична загуба на пакети, която непропорционално засяга UDP-базирани протоколи като DNS (който няма вградено повторно предаване на ниво приложение).

• Поставете отново двата края на Ethernet кабела.
• Заменете кабела с такъв, за който знаете, че работи.
• Тествайте различен порт на рутера или суича.
• Проверете LED индикаторите за връзка на NIC — стабилна зелена или кехлибарена светлина потвърждава физическа връзка; мигаща или липсваща светлина показва проблем на ниво 1.

Стъпка 10: Стартирайте инструмента за отстраняване на неизправности в мрежата на Windows

Windows включва автоматизирана диагностика, която може да открие и поправи често срещани DNS неправилни конфигурации, включително нулиране на DNS клиента и изчистване на кеша.

Отидете в Настройки > Система > Отстраняване на неизправности > Други инструменти за отстраняване на неизправности > Интернет връзки и стартирайте съветника. Той ще се опита да извърши автоматични поправки и ще докладва какво е открил. Въпреки че не улавя всеки сценарий, е полезна проверка, която отнема по-малко от минута.

Стъпка 11: Проверете и редактирайте файла Hosts

Повреден или злонамерено модифициран файл hosts може да замени DNS за конкретни домейни, причинявайки грешки при разрешаване, които изглеждат идентично с грешка на DNS сървъра.

Windows — отворете с повишени привилегии:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Потърсете записи, които пренасочват общи домейни към 0.0.0.0 или 127.0.0.1. Софтуер за сигурност, блокери на реклами и зловреден софтуер — всички те модифицират този файл. Премахнете всички подозрителни записи, запазете и изчистете DNS кеша.

Стъпка 12: Нулирайте TCP/IP и Winsock стека (Windows)

Ако множество мрежови компоненти са неправилно конфигурирани, пълното нулиране на стека е по-бързо от търсенето на отделни настройки:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Рестартирайте машината след изпълнение на всичките пет команди. Това нулира TCP/IP параметрите в регистъра и каталога Winsock до тяхното състояние по подразбиране, без да засяга драйверите на мрежовия адаптер.

Стъпка 13: Нулирайте рутера до фабричните настройки

Използвайте това като последна мярка преди да се обадите на вашия ISP. Фабричното нулиране изтрива цялата персонализирана конфигурация — Wi-Fi SSID-и, пароли, правила за пренасочване на портове и всякакви персонализирани DNS настройки — и възстановява рутера до първоначалното му състояние.

Повечето рутери имат вдлъбнат бутон за нулиране. Задръжте го с игла за 10–15 секунди, докато LED индикаторите за статус не се завъртят. След като рутерът се рестартира, конфигурирайте мрежата си отново от нулата. Ако DNS работи веднага след нулирането, неправилно конфигурирана настройка на рутера е причината.

Стъпка 14: Свържете се с вашия ISP

Ако всяка стъпка по-горе се провали и проблемът засяга всички устройства в мрежата ви, проблемът почти сигурно е upstream от вашия рутер — или в рекурсивната резолвърна инфраструктура на ISP, или на самата WAN връзка. Свържете се с техническата поддръжка на вашия ISP със следната информация готова:

• Резултати от nslookup example.com с използване на DNS на вашия ISP и публичен резолвър като 8.8.8.8.
• Дали проблемът е периодичен или постоянен.
• Дали преминаването към мобилна гореща точка (заобикаляйки изцяло вашия ISP) решава проблема.

Последният тест е окончателната проверка за изолиране на ISP.

DNS конфигурация за администратори на сървъри

Ако управлявате среда за VPS хостинг или Dedicated сървър, DNS грешките придобиват допълнителни измерения. Неправилно конфигуриран резолвър на сървър засяга всяко приложение, работещо на него — уеб сървъри, доставка на поща, мениджъри на пакети и агенти за мониторинг — всички те зависят от надеждното разрешаване на имена.

Проверете конфигурацията на резолвъра на Linux сървъри:

cat /etc/resolv.conf

Здравият файл трябва да съдържа поне два реда nameserver, сочещи към надеждни резолвъри:

nameserver 1.1.1.1
nameserver 8.8.8.8

На системи, използващи systemd-resolved, /etc/resolv.conf е символна връзка. Директното му редактиране няма ефект. Вместо това използвайте resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Тествайте латентността на разрешаване от сървър:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Ако времето за заявки постоянно надвишава 200ms, резолвърът е географски отдалечен или е под натоварване. Преминете към резолвър с точка на присъствие, по-близо до центъра за данни на вашия сървър.

За сървъри, работещи в среди cPanel VPS, DNS конфигурацията се управлява и чрез страницата Basic cPanel & WHM Setup в WHM. Уверете се, че резолвърите, изброени там, съответстват на тези в /etc/resolv.conf, за да избегнете проблеми с разделено разрешаване.

DNS и регистрация на домейни: Upstream връзката

Грешката „DNS сървърът не отговаря” за вашия собствен домейн — а не на чужд — често се проследява до конфигурацията на nameserver на ниво регистратор. Ако наскоро сте регистрирали домейн или сте сменили nameserver-и чрез Регистрация на домейни, разпространението отнема до 48 часа. През този период някои резолвъри по света все още съхраняват старите NS записи.

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

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Несъответствията между отговорите на резолвърите по време на разпространение са нормални. Ако отговорите все още са непоследователни след 48 часа, NS записите при регистратора вероятно са неправилно конфигурирани.

Защита на DNS: DNSSEC и DNS-over-HTTPS

Стандартните DNS заявки пътуват в открит текст по UDP порт 53, което ги прави уязвими към атаки за DNS подправяне и отравяне на кеша. Две допълващи се технологии адресират това:

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

DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) криптират цялата DNS заявка, предотвратявайки подслушване и манипулация по пътя. Съвременните браузъри поддържат DoH нативно. За да го активирате в целия Windows 11, отидете в Настройки > Мрежа и интернет > [вашият адаптер] > Назначаване на DNS сървър > Редактиране и задайте криптирането на Само криптирано (DNS over HTTPS).

За сървъри конфигурирайте systemd-resolved да използва DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Ако управлявате имейл хостинг или собствен пощенски сървър, правилната DNS конфигурация — специално SPF, DKIM и DMARC записите — е от критично значение за доставяемостта. DNS грешките на пощенски сървър не само прекъсват изходящото сърфиране; те причиняват отложена или върната поща и неуспешна TLS валидация на сертификати.

SSL сертификати и зависимост от DNS

Издаването и подновяването на TLS сертификати зависят изцяло от DNS. Сертифициращите органи, извършващи валидиране на домейн (DV) чрез DNS-01 ACME предизвикателство, трябва да разрешат TXT записа _acme-challenge на вашия домейн. Ако DNS е нарушен по времето на подновяване, автоматизирани инструменти като Certbot ще се провалят безшумно и вашите SSL сертификати ще изтекат — сваляйки HTTPS заедно с тях.

Настройте мониторинг едновременно за здравето на DNS разрешаването и изтичането на сертификати. Проста проверка, базирана на cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Матрица за вземане на решения: Изолиране на слоя на DNS повредата

Използвайте тази матрица, за да идентифицирате слоя на повредата, преди да губите време за решения, които не се прилагат за вашата ситуация.

Технически контролен списък с ключови изводи

• Изпълнете ping 8.8.8.8 първо. Ако се провали, DNS не е основният ви проблем — първо поправете маршрутизирането или физическата свързаност.
• Винаги изчиствайте локалния DNS кеш след промяна на настройките на резолвъра; остарелите записи ще маскират дали поправката е проработила.
• Преминете към Cloudflare 1.1.1.1 или Quad9 9.9.9.9 като първа промяна на резолвъра — и двата са по-бързи и по-надеждни от повечето ISP резолвъри.
• В Windows, ако GUI на Services изсивява опцията за рестартиране на DNS Client, използвайте net stop dnscache && net start dnscache от повишен команден ред.
• На Linux сървъри никога не редактирайте /etc/resolv.conf директно на systemd-resolved системи — промените се презаписват при рестартиране на мрежата. Използвайте resolvectl или nmcli.
• VPN клиентите са чест безшумен виновник. Винаги тествайте с изключен VPN, преди да ескалирате.
• За вашите собствени домейни, dig +trace заобикаля всички кешове и показва точно какво връщат авторитативните сървъри — използвайте го, преди да приемете, че има проблем с резолвъра.
• Активирайте DNSSEC валидиране и DNS-over-TLS/HTTPS на производствени сървъри, за да елиминирате цял клас DNS грешки, базирани на подправяне.
• На сървъри наблюдавайте едновременно здравето на DNS разрешаването и изтичането на SSL сертификати — DNS грешка ще причини безшумно провал на подновяването на сертификата дни по-късно.

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

Защо DNS се проваля, въпреки че имам работеща интернет връзка?

DNS разрешаването използва UDP пакети до порт 53, което е отделно от TCP връзките, които браузърът ви използва за зареждане на страници. Правило на защитната стена, срив на DNS релето на рутера или спрял резолвър могат да блокират порт 53 специално, докато оставят целия останал трафик незасегнат. Изпълнете ping 8.8.8.8, за да потвърдите IP свързаността, след това nslookup example.com, за да потвърдите, че DNS е изолираният проблем.

Безопасно ли е постоянно да използвам Google или Cloudflare DNS вместо резолвъра на моя ISP?

Да, за повечето потребители и случаи на употреба. И Google Public DNS, и Cloudflare 1.1.1.1 поддържат DNSSEC валидиране и предлагат по-високи SLA за наличност от типичните ISP резолвъри. Компромисът е, че вашите DNS заявки се обработват от доставчик на инфраструктура на трета страна, а не от вашия ISP. Cloudflare публикува строга политика за нерегистриране на заявки; Google съхранява анонимизирани логове до 48 часа.

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

Изчистването на кеша изтрива локално съхранените резултати от разрешаване, принуждавайки ОС да изпраща нови заявки до конфигурирания резолвър. Промяната на DNS сървъра пренасочва накъде се изпращат тези заявки. Ако кешът ви съдържа отровен или остарял запис, изчистването го поправя, без да сменяте резолвъра. Ако самият резолвър е спрял или е бавен, промяната на адреса на сървъра го поправя, без да докосвате кеша. На практика, правенето и на двете заедно след DNS грешка е най-чистият подход.

Защо nslookup успява, но браузърът все още показва DNS грешка?

Браузърите все повече използват собствена DNS-over-HTTPS имплементация, която заобикаля изцяло ОС резолвъра. Ако конфигурираната DoH крайна точка на браузъра е недостъпна, той може да се провали дори когато системният резолвър работи добре. Проверете настройките за поверителност или сигурност на браузъра за опция „Сигурен DNS” или „DNS over HTTPS” и или я деактивирайте, или я насочете към достъпен DoH доставчик.

Как да диагностицирам DNS проблеми на Linux VPS без GUI?

Използвайте dig, nslookup и resolvectl от командния ред. Изпълнете dig @1.1.1.1 example.com, за да тествате конкретен резолвър директно, заобикаляйки изцяло локалната конфигурация. Изпълнете resolvectl status, за да видите кой резолвър системата използва в момента и дали DNSSEC е активен. Проверете /etc/resolv.conf, за да потвърдите конфигурираните nameserver-и, и проверете дали файлът не е счупена символна връзка с ls -la /etc/resolv.conf.