Як виправити повільний DNS-пошук

Що насправді вимірює повільний пошук

Завантаження сторінки починається із запиту на визначення імені, потім TCP-з'єднання, потім TLS-рукостискання, потім власний час на роздуми сервера. DNS - лише перше з цього, і це єдина частина, яку часто можна покращити, взагалі не чіпаючи сам сайт.

Тут плутають два числа. Кешований пошук коштує майже нічого, бо відповідь уже на вашій машині чи за один стрибок від неї. Холодний пошук може включати запит до кореня, ще один - до домену верхнього рівня, і ще один - до власних nameserver-ів домену, і кожен - це кругова подорож на будь-яку відстань, що відділяє вас від цих серверів. Менш як 20 мс на теплому і менш як 100 мс на холодному - нічого особливого. Усе, що наближається до секунди, означає, що один зі стрибків далеко, перевантажений або впирається в тайм-аут і повторюється.

Сучасні сторінки погіршують це, маючи багато імен хостів. Шрифти, аналітика, зображення й платіжні віджети - кожному потрібен власний пошук, і браузер, що визначає десять імен хостів по 300 мс кожне, витратив три секунди на DNS ще до того, як відрендерив хоч щось корисне.

Підтвердьте, що саме DNS - повільна частина

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

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Якщо time_namelookup - лише невелика частка від загального часу, DNS не ваша проблема, і вам варто читати про час відповіді сервера. Якщо це третина чи більше, читайте далі. Для самого пошуку окремо dig виводить витрачений час:

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

У Windows PowerShell дає те саме значення:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Порівняйте свій типовий резолвер із публічними. Велика різниця каже, що виправлення - на вашому боці. Схожий час усюди вказує на власні nameserver-и домену.

Один результат повністю виключає цей посібник. Якщо резолвер миттєво відповідає NXDOMAIN, ім'я не опубліковане, і ви дивитеся на іншу проблему, описану в DNS_PROBE_FINISHED_NXDOMAIN.

Чому це трапляється

• Віддалений резолвер. Публічні сервіси працюють через anycast, тож та сама адреса відповідає з найближчої локації. Резолвер провайдера чи один офісний сервер так не вміють, і кожен запит платить за повну кругову подорож.
• Перший сервер у списку мертвий. Клієнт вичікує свій тайм-аут, а тоді запитує другий. У системах на glibc типовий тайм-аут перед першою повторною спробою - 5 секунд, і це якраз та пауза, яку люди описують як "зависає, а тоді завантажується".
• Дуже низький TTL. TTL у 30 чи 60 секунд означає, що майже кожен відвідувач платить за свіжий пошук, бо кешована копія вже застаріла.
• Довгі ланцюжки CNAME. Кожна ланка - це ще один пошук. Ланцюжки з трьох чи чотирьох ланок - звичайна справа за CDN і маркетинговими інструментами.
• Повільні авторитетні nameserver-и. DNS-провайдер із небагатьма локаціями відповідає швидко для частини світу й повільно для решти.
• Валідація DNSSEC. Перевірка ланцюжка додає запитів. Зазвичай це дешево, але частково зламаний ланцюжок спричиняє повторні спроби, що виглядають як повільність.
• Пошукові домени. Резолвер, налаштований із суфіксами, спершу пробує example.com.corp.local, а вже потім example.com, витрачаючи невдалий запит на кожен суфікс.
• Запити AAAA без IPv6. Система запитує обидва типи записів і чекає на відповідь, якою не може скористатися.
• VPN чи фільтрувальний проксі, що пропускає кожен запит через тунель до резолвера на іншому континенті.
• Роутер, що працює як форвардер із крихітним кешем і слабким процесором.

Як це виправити

На вашому пристрої

1. Очистіть кеші, щоб ваші вимірювання були чесними: ipconfig /flushdns у Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder у macOS, sudo resolvectl flush-caches у Linux.
2. Подивіться, які сервери налаштовані й у якому порядку: Get-DnsClientServerAddress, scutil --dns або resolvectl status. Приберіть будь-який запис, що більше не відповідає, бо мертвий перший запис коштує вам тайм-ауту на кожному холодному пошуку.
3. У Linux скоротіть очікування на час розслідування, додавши options timeout:2 attempts:2 у /etc/resolv.conf, і приберіть невикористані суфікси search.
4. Вимкніть VPN і виміряйте знову. Якщо число зменшується вдвічі, причина - тунель, і саме його налаштування резолвера варто змінити.

У вашій мережі

1. Встановіть резолвер у DHCP на роутері, а не на кожному пристрої окремо, щоб кожен клієнт отримував ту саму швидку пару.
2. Дайте власному форвардеру роутера публічний резолвер вище за потоком замість типового провайдерського, або взагалі обійдіть форвардер, видавши клієнтам публічні адреси напряму.
3. У бізнес-мережі з власним DNS-сервером перевірте, що він пересилає запити, а не виконує повну рекурсію з однієї точки, і що його кеш достатньо великий, аби пережити робочий день.

На вашому власному домені

1. Підніміть TTL для записів, що рідко змінюються. П'ять хвилин - розумний мінімум для запису, який може знадобитися швидко перенести; година чи день підходить для всього стабільного.
2. Сплющте ланцюжки CNAME, де можете. Спрямуйте запис на кінцеву ціль замість ланцюжка псевдонімів: dig www.example.com CNAME +short показує, наскільки глибокий ваш.
3. Використовуйте DNS-провайдера з anycast-серверами й тримайте щонайменше два nameserver-и в окремих мережах.
4. Перевірте, що DNSSEC валідується. Порівняйте звичайний запит з тим, що пропускає валідацію: dig example.com @1.1.1.1 проти dig +cd example.com @1.1.1.1. Велика різниця, або SERVFAIL лише в першому, означає, що ланцюжок зламаний.

Перевірте це ззовні

Ваші власні вимірювання описують одну мережу в один момент, а це найменш корисний зразок, який можна взяти. Резолвер, що відповідає вам за 8 мс, може відповідати клієнту з іншого регіону за 400 мс, і саме цей клієнт скаржиться.

Почніть із вимірювання авторитетних серверів напряму, що прибирає будь-який кеш між вами і джерелом:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

Вивід +trace проходить делегування крок за кроком, тож стрибок, що зависає, стає видимим, а не усередненим. Далі запустіть перевірку DNS-запиту, яка визначає ім'я з контрольних точок у різних країнах і звітує по кожній окремо. Це те вимірювання, яке неможливо зняти з ноутбука: воно показує, чи ваші nameserver-и повільні всюди, що вказує на провайдера, чи повільні лише з одного континенту, що вказує на його мережеве покриття. Якщо якісь локації повертають іншу відповідь, а не просто повільнішу, питання вже в поширенні, розглянуто в посібнику як перевірити поширення DNS.

Затримка, що дрейфує, а не ламається

DNS-затримка рідко ламається очевидним чином. Вона дрейфує: nameserver втрачає локацію, TTL знижують під час міграції й забувають підняти назад, і через шість тижнів сайт відчувається млявим із причин, на які ніхто не може вказати. Одне вимірювання не може показати тренд, тому час пошуку варто фіксувати за розкладом із регіонів, де перебувають ваші відвідувачі. HostTracker моніторить вебсайти з 2004 року і зараз стежить за понад 500 000 вебсайтів із контрольних точок у 158 містах, зберігаючи історію, що робить повільний дрейф видимим. Інші посібники тут - у розділі виправлень, а випадок, коли не приходить нічого взагалі, - це DNS server not responding.