Виправлення DNS у Windows: перестаньте використовувати «flushdns» як ритуал

February 25, 2026 • February 25, 2026 • Читання: 4 хв • Views: 1

Було корисно?

Якщо ви читаєте це, ймовірно, бачили, як хтось з впевненістю мага вводить ipconfig /flushdns. Іноді це «працює», іноді нічого не змінюється, а іноді ситуація стає гіршою, бо зникає єдина корисна підказка: що машина вважала істинним п’ять секунд тому.

Проблеми з DNS у Windows рідко вирішуються однією командою. Вони вирішуються розумінням того, який резолвер працює, який кеш бреше і який мережевий компонент «допомагає» вам потрапити в пастку. Давайте припинимо влаштовувати екзорцизм DNS і почнемо діагностику.

Що насправді робить `flushdns` (і чого не робить)

ipconfig /flushdns очищає кеш резолвера служби DNS Client у Windows. І тільки це. Воно не:

Змінює, які DNS-сервери ви використовуєте.
Виправляє зламану DNS-політику VPN.
Відміняє неправильний список пошукових суфіксів.
Видаляє застарілий запис із серверу DNS вашої компанії.
Скидає Winsock, правила фаєрволу або налаштування проксі.
Виправляє додаток, який виконує власний DNS (багато так роблять).

Воно може допомогти, коли кеш містить неправильну відповідь або негативний запис (NXDOMAIN), який ви хочете перевірити негайно. Також воно може приховати докази, коли ви намагаєтесь визначити, чи є відмова «локальним кешем», чи «вихідним DNS». Не видаляйте докази, поки не зрозумієте, що саме дивитесь.

Дві важливі реалії:

Проблеми з DNS часто є проблемами політик. Машина робить саме те, що їй наказали, а наказ виявився неправильним.
Windows — не єдиний ваш резолвер. Браузери, VPN-клієнти, агенти безпеки та інструменти управління кінцевими точками можуть вводити власні кеші та поведінку DNS.

Операційний підхід: ставтеся до flushdns як до перезапуску сервісу. Іноді це корисний крок в кінці. Це не перший крок. Якщо ваша перша дія — видалити стан, ви обрали сліпоту.

Швидкий план діагностики

Це послідовність «ви в дзвінку, хтось кричить і вам потрібен сигнал за 90 секунд». Виконуйте по порядку. Не імпровізуйте, поки не зрозумієте категорію відмови.

1) Це DNS чи не-DNS?

Чи можете ви досягти IP-адреси, але не імені?
Чи це лише одне ім’я хоста чи всі імена?
Чи це лише корпоративні домени (наприклад, corp.example)?

2) Визначте активний DNS-шлях

Який інтерфейс використовується (Wi‑Fi, Ethernet, VPN, віртуальний адаптер)?
Які DNS-сервери налаштовані на цьому інтерфейсі зараз?
Чи VPN нав’язує DNS або використовує split tunneling?

3) Порівняйте резолвери

Чи nslookup успішний, тоді як браузер — ні?
Чи PowerShell Resolve-DnsName дає інші результати, ніж nslookup?

4) Перевірте кешування та негативне кешування

Чи локальний кеш тримає NXDOMAIN?
Чи ви змагаєтесь з TTL (відповіді змінюються під час інциденту)?

5) Лише тоді: скидання/очищення як контрольований експеримент

Очистіть кеш і повторно запитайте те саме ім’я.
Задокументуйте, що змінилося. Якщо нічого не змінилося — припиніть чистити.

Парафраз з David J. Wheeler: Усі проблеми в обчислюванні можна вирішити, додавши ще один шар інденфікації — окрім проблем, спричинених інденфікацією. DNS — це інденфікація з почуттями.

Як Windows вирішує імена: реальний порядок дій

Коли хтось каже «DNS не працює», зазвичай мають на увазі «не працює резолювання імен». У Windows резолювання імен може включати:

Файл hosts (C:\Windows\System32\drivers\etc\hosts)
Служба DNS Client (кеш + запити до налаштованих DNS-серверів)
Список пошукових суфіксів DNS (перетворення app на app.corp.example)
LLMNR (Link-Local Multicast Name Resolution) та NetBIOS в деяких середовищах
mDNS для сценаріїв .local (залежить від встановлених компонентів)
Проксі та PAC-скрипти (не DNS, але створює видимість «неможливо дістатися за іменем»)
Резолвери додатків (браузери та рантайми можуть кешувати або використовувати DoH)

Деякі з цих механізмів «допомагають», поки не почнуть заважати. Наприклад:

Якщо файл hosts перевизначає ім’я, очищення кешу DNS цього не змінить. Перевизначення переможе.
Якщо ваш браузер використовує DNS over HTTPS (DoH), очищення кешу Windows DNS може не вплинути на шлях резолюції браузера.
Якщо DNS-сервер нормальний, але ви звертаєтесь до неправильного (VPN-адаптер набув пріоритету), очищення не змінює пріоритети.

Ще одна нюанс: nslookup не є «Windows resolver». Це діагностичний інструмент, який звертається до DNS-сервера. Він може обходити частини стека резолюції Windows і кешування. Коли nslookup працює, а додаток — ні, це не суперечність — це ваша підказка.

Жарт #1: Очищати DNS, щоб виправити все — це як перезапускати принтер, щоб виправити податкову декларацію. Це змінює настрій, а не факти.

Цікаві факти та історичний контекст (тому що з часом це стало дивним)

DNS старіший за веб. DNS був спроєктований на початку 1980-х, щоб замінити ручні файли HOSTS.TXT, які не масштабувалися.
Негативне кешування — свідоме рішення. Кешування NXDOMAIN запобігає повторним запитам на неіснуючі імена, які могли б навантажувати авторитарні сервери.
Кеш клієнта DNS у Windows «липкий» за дизайном. Кеш існує для зменшення затримки та навантаження, що робить його підозрюваним під час швидкозмінних інцидентів.
Пошукові суфікси створювались для людей. Підприємствам потрібно, щоб mail або intranet працювали без введення повного домену щоразу.
Split DNS існувало ще до сучасного хайпу VPN. Великі організації давно потребували внутрішніх відповідей для внутрішніх зон і різних відповідей поза мережею.
LLMNR існує, бо люди не люблять вводити текст. Це протокол зручності для локальних мереж, але він також становить ризик безпеці і часто вимикається в захищених середовищах.
DoH частково реакція на ворожі мережі. Шифрування DNS-запитів зменшує підслуховування і підміну на шляху, але може ускладнити корпоративну політику та розслідування інцидентів.
EDNS0 і великі відповіді змінили режими відмов. Відповіді DNS стали більшими (подумайте DNSSEC, багато записів), і проблеми з MTU/фрагментацією почали проявлятися як «рандомні таймаути DNS».
«DNS server not responding» часто бреше. DNS-сервер може бути робочим; клієнт може бути заблокований у доступі до нього по UDP/TCP 53, або він звертається через неправильний інтерфейс.

Практичні завдання: команди, виходи та рішення (12+)

Кожне завдання нижче включає команду, що означає вихід і яке рішення прийняти. Використовуйте їх як набір інструментів. Не виконувати як скрипт з форуму.

Завдання 1: Підтвердіть, якими DNS-серверами Windows фактично користується

cr0x@server:~$ ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . : LPT-0442
   Primary Dns Suffix  . . . . . . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter VPN:

   Connection-specific DNS Suffix  . . : vpn.corp.example
   DNS Servers . . . . . . . . . . . : 172.16.50.53

Значення: У вас може бути кілька адаптерів, кожен з різними DNS-серверами. Windows вибиратиме залежно від метрик інтерфейсу та політик.

Рішення: Якщо VPN-адаптер активний і має DNS-сервер, перевірте, чи має він бути авторитетним для імен, що падають. Якщо ні — ви маєте справу з проблемою пріоритету/метрики або політикою VPN, а не з кешем.

Завдання 2: Визначте, який інтерфейс переважний (метрики)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 | Format-Table -AutoSize"

ifIndex InterfaceAlias     AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp   ConnectionState
------- --------------     ------------- ------------ --------------- ----   ---------------
24      VPN               IPv4          1400         5               Enabled Connected
12      Ethernet          IPv4          1500         25              Enabled Connected
9       Wi-Fi             IPv4          1500         55              Enabled Connected

Значення: Менша метрика перемагає. Тут VPN переважає для IPv4-трафіку і часто для поведінки DNS.

Рішення: Якщо проблеми з DNS виникають тільки коли VPN підключений, зосередьтесь на DNS-серверах VPN, конфігурації split DNS і політиках NRPT. Поки що не чіпайте flushdns.

Завдання 3: Запит через Windows resolver (не nslookup)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName app.corp.example -Type A"

Name           Type TTL Section IPAddress
----           ---- --- ------- ---------
app.corp.example A   30 Answer  10.30.40.25

Значення: Це показує, що повертає Windows resolver і який TTL бачить.

Рішення: Якщо Resolve-DnsName не вдається, а nslookup працює, ймовірно, маємо локальну політику/кешування або проблему з порядком резолюції. Якщо обидва не працюють — підозрюйте вихідний DNS або доступність мережі.

Завдання 4: Запит конкретного DNS-сервера, щоб обійти «те, що обрав Windows»

cr0x@server:~$ nslookup app.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    app.corp.example
Address: 10.30.40.25

Значення: Це підтверджує, чи може цільовий DNS-сервер відповісти правильно.

Рішення: Якщо запит до відомо робочого DNS-сервера працює, але запити за замовчуванням — ні, зосередьтесь на тому, який DNS-сервер фактично використовує клієнт (порядок адаптерів, VPN, DHCP, статичний DNS, агент безпеки).

Завдання 5: Перевірте негативне кешування і що знаходиться в кеші

cr0x@server:~$ ipconfig /displaydns

    app.corp.example
    ----------------------------------------
    Record Name . . . . . : app.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 18
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . . : 10.30.40.25

Значення: Ви можете побачити, що Windows кешував і скільки часу він планує тримати це.

Рішення: Якщо кеш містить NXDOMAIN або стару IP, яка більше не маршрутизується, очищення може бути виправданим. Але запитайте: чому він неправильний? Поганий upstream? Split brain? Застарілі записи? Виправляйте джерело.

Завдання 6: Очищення кешу DNS (як контрольований тест)

cr0x@server:~$ ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Значення: Кеш очищено. Немає гарантії, що наступна відповідь буде кращою.

Рішення: Негайно повторно виконайте той самий запит і порівняйте. Якщо відповідь не змінилася — кеш не був проблемою.

Завдання 7: Перевірте, що служба DNS Client запущена

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-List Status,Name,StartType"

Status    : Running
Name      : Dnscache
StartType : Automatic

Значення: Служба DNS Client надає кешування і частину логіки резолюції.

Рішення: Якщо вона зупинена/відключена (іноді через «гайди з тюнінгу»), очікуйте дивну поведінку і низьку продуктивність. Поверніть її, якщо у вас немає дуже специфічного контрольованого середовища.

Завдання 8: Перевірте поведінку пошукових суфіксів (чому короткі імена не працюють)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientGlobalSetting | Format-List SuffixSearchList"

SuffixSearchList : {corp.example, prod.corp.example}

Значення: Коли ви вводите app, Windows може спробувати app.corp.example та інші суфікси.

Рішення: Якщо користувачі повідомляють «короткі імена раніше працювали», перевірте розповсюдження списку суфіксів (GPO, DHCP опція 15/119, політика VPN). Виправляйте список суфіксів, а не кеш.

Завдання 9: Підтвердіть, які DNS-сервери встановлені на інтерфейсах (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet       {10.20.0.10, 10.20.0.11}
VPN            {172.16.50.53}
Wi-Fi          {192.168.1.1}

Значення: Це робить очевидним, коли вдома Wi‑Fi DNS або DNS готелю потрапляє в мікс.

Рішення: Якщо ви бачите публічний або споживчий DNS на інтерфейсі, який не повинен бути авторитетним для внутрішніх зон, використовуйте split DNS правильно (VPN) або відрегулюйте пріоритет інтерфейсу.

Завдання 10: Перевірка досяжності DNS-серверів (не припускайте, що «відповідає»)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.0.10 -Port 53"

ComputerName     : 10.20.0.10
RemoteAddress    : 10.20.0.10
RemotePort       : 53
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Значення: DNS переважно використовує UDP, але TCP 53 важливий для великих відповідей і повторних спроб. Це хоча б доводить шлях до TCP 53.

Рішення: Якщо TCP 53 не працює, можливо, у вас правила фаєрволу, ACL VPN або програмне забезпечення безпеки блокує DNS. Це мережеве/безпекове виправлення, а не очищення кешу.

Завдання 11: Виявлення, чи проксі/PAC маскує проблему як DNS

cr0x@server:~$ netsh winhttp show proxy

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.example:8080
    Bypass List     :  (none)

Значення: Деякі додатки використовують налаштування WinHTTP proxy. Зламаний проксі може виглядати як «проблема DNS», бо додаток не може отримати нічого по імені.

Рішення: Якщо ім’я резолюється, але HTTP не працює, перевіряйте проксі/PAC і автентифікацію. Не продовжуйте копирсатися в DNS.

Завдання 12: Перевірте файл hosts на мінах

cr0x@server:~$ type C:\Windows\System32\drivers\etc\hosts

# Copyright (c) Microsoft Corp.
# ...
10.30.40.99   app.corp.example

Значення: Одна стрічка в файлі hosts перекриває DNS. Назавжди. Поки хтось не згадає про її існування.

Рішення: Якщо hosts фіксує стару адресу, видаліть її і задокументуйте, навіщо вона була. Якщо вона потрібна (рідко), керуйте нею централізовано, а не плеканням племінних знань.

Завдання 13: Скидання Winsock (лише коли симптоми підходять)

cr0x@server:~$ netsh winsock reset

Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Значення: Це ремонтує деякі проблеми на рівні сокетів, спричинені LSP або мережевим ПЗ, а не «DNS-записи».

Рішення: Використовуйте, коли декілька мережевих операцій відмовляють дивним чином (не лише одне ім’я хоста). Очікуйте потреби в перезавантаженні. Якщо DNS — єдиний симптом, це навряд чи виправлення.

Завдання 14: Скидання стеку IP (коли поведінка інтерфейсу пошкоджена)

cr0x@server:~$ netsh int ip reset

Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.

Значення: Скидає конфігурацію TCP/IP до значень за замовчуванням.

Рішення: Використовуйте, коли підозрюєте, що стек був отруєний драйверами, VPN-клієнтами або ручними правками. Якщо проблема явно в upstream DNS, це не допоможе.

Завдання 15: Випустити/оновити DHCP (коли DNS-сервери прийшли з DHCP)

cr0x@server:~$ ipconfig /release

Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Значення: Тут Ethernet не підключений, тому release не застосовується. Це саме по собі підказка.

Рішення: Виконуйте це на активному інтерфейсі. Якщо DNS-сервери неправильні через опції DHCP, renew може отримати правильні налаштування — якщо DHCP налаштований коректно. Якщо DHCP неправильний, виправляйте DHCP, а не кінцеві точки.

Завдання 16: Перевірте, чи ім’я повертає кілька адрес (і чи одна з них мертва)

cr0x@server:~$ nslookup api.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    api.corp.example
Addresses: 10.30.40.10
          10.30.40.11
          10.30.40.12

Значення: Round-robin або multi-A записи можуть створювати враження «періодичних» відмов, якщо один бекенд не працює.

Рішення: Якщо одна IP не відповідає, не очищайте кеші на клієнтах. Видаліть/перевірте цей запис, виправте стратегію балансування або відновіть мертвий бекенд.

Поширені помилки: симптом → корінна причина → виправлення

Тут більшість команд втрачає час: вони ставлять симптом за діагноз. Ось повторювані випадки.

1) «DNS не працює», але не працює тільки один сайт

Симптом: Лише app.corp.example відмовляє; все інше резолюється і працює.

Корінна причина: Застарілий DNS-запис, неправильні очікування TTL або багатозаписне ім’я, де одна IP мертва.

Виправлення: Запитуйте авторитарні DNS-сервери напряму і перевіряйте записи. Видаліть погані записи, зменшіть TTL перед міграціями, слідкуйте, щоб моніторинг видаляв мертві кінці з DNS або ставте навколо них балансувальник навантаження.

2) `nslookup` працює, браузер — ні

Симптом: nslookup показує правильну IP, але Chrome/Edge кажуть, що ім’я не може бути розв’язане або не можна підключитися.

Корінна причина: Увімкнений DoH у браузері, застарілий кеш DNS у браузері, проблема з проксі/PAC або браузер спочатку пробує IPv6 і зазнає невдачі.

Виправлення: Перевірте налаштування DNS браузера (включно з secure DNS/DoH), очистіть кеш DNS браузера за потреби, перевірте проксі і порівняйте IPv4 проти IPv6 резолюції та підключення.

3) Працює через VPN, не працює без VPN (або навпаки)

Симптом: Внутрішні імена резолюються лише коли VPN підключений, або VPN ламає розв’язування публічних імен.

Корінна причина: Split DNS налаштовано неправильно; VPN штовхає DNS-сервер для всього; метрики інтерфейсів змушують DNS віддавати перевагу неправильному адаптеру.

Виправлення: Виправте split tunnel і DNS-політики в клієнті/профілі VPN. Забезпечте, щоб внутрішні зони йшли до корпоративного DNS, публічні — до локального резолвера (або схваленого резолвера), і метрики працювали за задумом.

4) Випадкові таймаути після «підсилення безпеки»

Симптом: DNS іноді таймаутить; повторні спроби успішні; великі відповіді частіше падають.

Корінна причина: Фаєрвол блокує TCP 53 або фрагментацію; DNS-відповіді перевищують MTU; програмне забезпечення для інспекції DNS перехоплює запити.

Виправлення: Дозвольте UDP і TCP 53 там, де потрібно, перевірте MTU (особливо з VPN), і переконайтесь, що продукти інспекції DNS сумісні та налаштовані правильно.

5) Короткі імена перестали працювати

Симптом: intranet раніше резолювався; тепер лише intranet.corp.example працює.

Корінна причина: Список пошукових суфіксів змінився (GPO, DHCP опція, політика VPN) або ви перейшли в мережу з іншими політиками суфіксів.

Виправлення: Відновіть правильний список пошукових суфіксів і зробіть його детерміністичним (GPO для доменних пристроїв, чіткі DHCP опції, узгоджені налаштування VPN).

6) «Flushdns виправив вчора» стає процесом команди

Симптом: Люди щоденно очищують кеш; в нотатках інциденту пишуть «вирішено через flushdns».

Корінна причина: Фонова мінливість DNS-записів, низькі TTL під час міграцій або періодичні upstream відмови — очищення просто примушує новий запит, який іноді влучає в робочий сервер.

Виправлення: Додайте телеметрію: логування здоров’я DNS-серверів, вимір NXDOMAIN, перевірку реплікації/zone transfer, і припиніть використовувати кінцеві точки як канарки.

Три корпоративні міні-історії (як це ламається в реальному житті)

Міні-історія 1: Інцидент, спричинений неправильною припущенням

У середньому підприємстві команда мігрувала внутрішній сервіс з однієї підмережі в іншу. Вони оновили A-запис, на своїх ноутбуках побачили нову IP і оголосили про перемогу. Через кілька годин половина звернень до служби підтримки була «не можу увійти», а інша половина — «в мене працює». Найгірший тип відмови: Шредінгер-аутадж.

Неправильне припущення було простим: «Після оновлення DNS всі побачать зміни швидко». TTL був не маленьким, і деякі клієнти тримали старі відповіді. Гірше того, кілька серверів додатків використовували локальний DNS-кеш в рантаймі з дефолтним TTL, який ігнорував TTL запису. Вони найчастіше падали, і їх ніхто не перевірив першими.

Команда реагування почала з порад для кінцевих точок. Очищення DNS. Перезапуск браузерів. Ребут. Природно, це «виправило» деякі машини і не допомогло серверам, які мали значення. Кожне очищення робило розслідування гучнішим, бо кешевий стан постійно руйнувався і відтворювався.

Виправлення було нудним: вони перевірили TTL, ідентифікували авторитетні сервери, підтвердили реплікацію, потім провели міграцію з запланованим періодом перекриття. Також вони документували налаштування кешування на рівні рантайму і налаштували їх так, щоб вони поважали TTL або використовували бібліотеку резолвера з адекватним кешуванням.

Після розбору команда заборонила писати «flushdns вирішив» у нотатках інциденту. Якщо ви не можете сказати, що було не так — ви цього не виправили, ви просто припинили дивитися.

Міні-історія 2: Оптимізація, що влетіла в голову

Команда безпеки впровадила базову політику «покращення конфіденційності»: віддавати перевагу зашифрованому DNS. Гарна ідея без контексту. Вони ввели політику, яка спрямовувала клієнтів до DoH з невеликим набором схвалених резолверів. На папері це зменшувало ризик на ворожих Wi‑Fi. У виробництві це ламало split DNS для внутрішніх зон, бо зовнішні резолвери нічого не знали про внутрішні імена.

Спочатку симптоми були тонкими. Публічні сайти працювали. Внутрішні додатки періодично падали, особливо коли користувачі були поза мережею. Люди звинувачували VPN. Служба підтримки звинувачувала ноутбуки. Команда VPN звинувачувала DNS. Усі були праві в найбільшому можливому ступені.

Тим часом деякі додатки використовували OS resolver; інші — вбудовані резолвери. Тож і та ж машина могла резолювати git.corp.example в одному інструменті, але не в іншому. Інженери під тиском зробили свою «фікс»-стрічку, що очищувала кеші, перезапускала служби і перемикала адаптери. Це зменшило кількість звернень, але ускладнило кореневий аналіз.

Кінцеве виправлення не полягало в «повному відключенні DoH назавжди». Воно складалося у впровадженні політики, що поважає split DNS: внутрішні зони через корпоративний DNS (зазвичай через VPN), зовнішні — через зашифрований DNS, якщо дозволено. Також покращили телеметрію: «який резолвер фактично обробив цей запит?» виявився відсутньою метрикою.

Жарт #2: DNS over HTTPS — чудово, поки не потрібно DNS over «Чому нічого не резолюється?»

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансова компанія мала строгий процес змін для DNS. Інженерам це не подобалось, бо вимагався тикет, peer review і обов’язкове поле «TTL та план відкату». Здавалося бюрократією, поки одного дня внутрішня зона випадково не оновилася з опечаткою, яка спрямувала критичне ім’я сервісу на неіснуючу IP.

Інцидент почався як шквал оповіщень: помилки підключення, повторні спроби, часткові відмови. Хтось запропонував очищувати кеші на дзвінку. Керівник інциденту сказав ні — зберігайте стан, збирайте докази. Ось де дисципліна окупилася.

Вони витягли поточний набір записів з авторитетних серверів, порівняли з затвердженим запитом на зміну і відразу побачили невідповідність. Оскільки процес змін вимагав запису попередніх значень, відкат пройшов чисто. Оскільки вимагали план TTL, зона впливу була передбачуваною. І коли у них був рукопис «перевірити авторитетні сервери» на початку, вони не витратили 45 хвилин на суперечки про те, який ноутбук має який кеш.

Виправлення зайняло хвилини не тому, що вони були геніальними, а тому, що були послідовними. «Нудно» — комплімент в операціях.

Контрольні списки / покроковий план

Це план, який можна передати команді і очікувати приблизно однакових результатів. Він уникає забобонів і змушує приймати рішення на основі доказів.

Контрольний список A: Коли користувач каже «DNS упав»

Отримайте точні імена, що відмовляють, і повідомлення про помилку. Одне ім’я чи багато?
Запитайте, чи відмовляє на VPN, поза VPN чи обидва варіанти.
Запустіть ipconfig /all і зафіксуйте DNS-сервери та суфікси.
Запустіть Resolve-DnsName the.name і збережіть вихід.
Запустіть nslookup the.name configured-dns-server, щоб перевірити upstream.
Якщо результати різняться, визначте, який шлях резолвера використовує додаток (DoH у браузері, проксі).
Лише після цього: розгляньте ipconfig /displaydns і /flushdns як контрольований тест.

Контрольний список B: Коли не працюють лише внутрішні імена

Підтвердіть, що користувач використовує корпоративні DNS-сервери (а не DNS домашнього роутера).
Перевірте метрики адаптера VPN і DNS-сервери.
Переконайтесь, що список пошукових суфіксів включає внутрішній домен.
Запитайте авторитетний сервер для внутрішньої зони напряму.
Перевірте, чи ім’я ненавмисно існує в публічному DNS (ризик split-brain).

Контрольний список C: Коли відмови періодичні

Запитуйте кілька разів і записуйте відповіді та TTL. Шукайте ротацію адрес.
Тестуйте доступність кожної повернутої IP (ping недостатньо; тестуйте реальний порт/протокол).
Шукайте один мертвий бекенд у наборі multi-A записів.
Перевірте досяжність UDP і TCP 53 до DNS-серверів (особливо через VPN).
Перевірте, чи програмний продукт безпеки перехоплює DNS-запити або переписує відповіді.

Покроковий план «зупиніть кровотечу» для служби підтримки

Зберіть: ім’я, що відмовляє, чи підключений VPN, і позначку часу.
Запустіть і вставте: ipconfig /all.
Запустіть і вставте: nslookup failing.name і nslookup failing.name <dns server from ipconfig>.
Якщо DNS-сервер в ipconfig неправильний (наприклад, домашній роутер під час підключеного VPN), ескалюйте до VPN/мереж з цими доказами.
Якщо DNS-сервер правильний, але відповіді неправильні, ескалюйте до операцій DNS з доказами записів.
Лише якщо кеш явно тримає неправильну відповідь: запустіть ipconfig /flushdns і повторно перевірте. Документуйте до/після.

FAQ

1) Чому `ipconfig /flushdns` іноді «виправляє»?

Тому що ви примусили повторний запит, і наступний запит випадково потрапив на інший DNS-сервер, інший шлях (VPN підключився), або запис щойно був виправлений upstream. Це кореляція, а не довговічне виправлення.

2) Якщо очищення не перший крок, то який?

Визначте DNS-сервери та інтерфейс у використанні (ipconfig /all плюс метрики інтерфейсу), потім порівняйте результати резолвера ОС (Resolve-DnsName) з прямими запитами до серверів (nslookup name server).

3) Чому `nslookup` не погоджується з тим, що роблять додатки?

nslookup звертається напряму до DNS-сервера і не завжди відображає повну поведінку резолюції Windows, пошукові суфікси або DNS додатків (наприклад DoH). Це корисний інструмент, але не завжди репрезентативний для «що зробить додаток».

4) У чому різниця між очищенням кешу DNS та скиданням Winsock?

Очищення кешу DNS видаляє закешовані відповідності імен→IP. Скидання Winsock ремонтує конфігурацію сокетного шару і каталогу провайдерів. Скидання Winsock призначене для ширших симптомів «стек мережі пошкоджено», а не для одного застарілого DNS-запису.

5) Чи може відключення служби DNS Client спричинити проблеми?

Так. Відключення може порушити кешування і продуктивність, і вплинути на спосіб обробки резолюції імен. Якщо у вас немає суворо протестованої причини — тримайте її увімкненою.

6) Чому внутрішні імена не працюють, коли я поза VPN?

Тому що ваші поточні DNS-сервери (домашній роутер, ISP, публічний резолвер) не знають про внутрішні зони. Виправлення — коректний split DNS і маршрутизація через VPN, а не багаторазове очищення кешу.

7) Як дізнатися, чи задіяно DNS over HTTPS?

Якщо браузери резолюють інакше, ніж інструменти ОС, підозрюйте DoH. Перевірте налаштування «secure DNS» в браузері та корпоративні політики. Порівняйте результати між Resolve-DnsName і поведінкою браузера.

8) Що, якщо DNS резолюється, але з’єднання все одно падає?

Тоді це, ймовірно, не DNS. Це може бути маршрутизація, фаєрвол, проксі, TLS-інспекція або сам сервіс. Перевірте доступність до розв’язаної IP і порту та інспектуйте налаштування проксі.

9) Чи слід знижувати TTL, щоб зміни DNS розповсюджувалися швидше?

Іноді так — перед запланованою міграцією зменшіть TTL заздалегідь, потім підніміть його назад. Але не вважайте низький TTL «миттєвою реплікацією», і не забувайте, що кешування на рівні додатків може ігнорувати TTL.

10) Чи редагування файлу hosts — дійсне виправлення?

Як тимчасовий екстрений обхід для однієї машини — інколи. Як загальне рішення — ні. Воно обходить централізований контроль, ускладнює інциденти і зазвичай залишається довше, ніж причина його створення.

Висновок: наступні кроки, що дійсно працюють

Перестаньте дозволяти ipconfig /flushdns бути способом виживання вашої команди. Це інструмент, а не лікування. Лікування — це з’ясувати, який шлях резолвера відмовляє і чому.

Практичні наступні кроки:

Прийміть швидкий план діагностики. Використовуйте його для кожного тикета «DNS не працює», поки він не стане м’язовою пам’яттю.
Стандартизуйтесь щодо доказів, які ви збираєте: ipconfig /all, Resolve-DnsName і прямий nslookup name server.
Зміцніть процес змін DNS: вимагайте план TTL і значення для откату. Зробіть його нудним навмисно.
Аудитуйте split DNS і політики DoH разом. Якщо безпека і мережі не координуються, користувачі стануть вашим інтеграційним тестом.
Коли ви очищуєте кеші — документуйте до/після і гіпотезу, яку тестували. Інакше ви просто натискаєте кнопки.