Практична технічна підтримка
DNS пояснено, без здогадок
Зрозумійте назви, записи, кеши і розв’ язувачі DNS, з розв’ язанням проблем тільки для читання і чіткою відмінністю між розв’ язанням назви і завантаженням сайту.
Останній перегляд:
DNS - це один крок на шляху до веб- сайту
Коли ви вводите назву вузла, наприклад www.example.com, пристрою потрібна інформація, щоб дістатися місця призначення. DNS надає записи, пов’ язані з назвами. Запис A може надати адресу IPv4, а запис AAAA може надати адресу IPv6. Інші типи записів підтримують інші завдання.
Відповідь не є доказом того, що веб- сайт працює. Пристрій все ще потребує маршруту, з’ єднання з сервером і чинного зашифрованого сеансу для HTTPS. Після цього програма може повернути помилку або запитати розпізнавання. « DNS розв’ язує » і « завантаження сторінки » - це різні результати.
Ця спрощена діаграма відокремлює запит на назву від з’ єднання з веб- сайтом. Кеш може вже надати відповідь. Переглядач може використовувати інший розв’ язувач, ніж операційна система, отже, локальні команди і переглядач не обов’ язково слідуватимуть одному і тому ж шляху DNS.
Розв’ язувачі, авторитетні сервери і кеши
Рекурсивний розв’ язувач знаходить відповіді для клієнтів, використовуючи інформацію DNS, якщо у кеші немає відповіді. Авторитетний сервер імен публікує записи для зони. Домашній маршрутизатор може пересувати запити до розв’ язувача у іншому місці, замість того, щоб публікувати записи самого веб- сайту.
Кешування дозволяє уникнути повторення роботи. Час життя запису, або TTL, впливає на те, наскільки довго можна зберігати відповідь. Різні розв’ язувачі можуть зберігати відповіді, отримані у різні часи, що допомагає пояснити, чому одне з’ єднання бачить змінений запис раніше за інше.
« Розповсюдження » не означає, що всесвітній switch перевертається у певний час. Запис, його попередній TTL, зміни делегування і поведінка розв’ язувача впливають на те, що бачать люди. Повторне редагування під час тестування може ускладнити інтерпретацію доказів.
Почати з керованого порівняння
- Записати точну назву вузла, помилку переглядача і час. Перевірити правопис і чи адреса вимагає
www. - Спробуйте не пов’ язаний сайт на тому ж пристрої.
- Порівняти з іншим переглядачем і, якщо можливо, з іншим пристроєм, з’ єднаним за допомогою того самого з’ єднання.
- Спробувати інше дозволене з’ єднання, якщо це корисно. Записати параметри VPN і безпечного DNS переглядача.
Порівняння мобільних даних змінює мережевий шлях і, ймовірно, DNS. Успішне порівняння сужає коло проблем, але не доводить, що причиною проблеми є DNS. Інший переглядач також може відрізнятися за додатками, сеансами або налаштуваннями проксі.
Використовувати пошук тільки для читання для підтвердження доказів
У Windows, nslookup можна запитати у налаштованого сервера DNS назву. Деякі інші операційні системи також надають такий запит. Якщо його немає, скористайтеся інструментами, які вказано у документації системи, замість того, щоб встановлювати невідомі програми для розв’ язання проблем.
nslookup www.example.comЗа допомогою цього пункту можна надіслати запит DNS для домену документації. Замініть цей запит на загальну назву вузла, яку ви вивчаєте. Не надсилайте конфіденційні внутрішні назви до загальних розв’ язувачів або мережевих інструментів. Компанія може навмисно використовувати внутрішній або розділений DNS у своїй мережі або VPN.
Зчитувати помилки, а також відповіді. Для розподіленої служби використання декількох адрес може бути нормальним. Відповідь IPv6 не підтверджує, що з’ єднання IPv6 можна використовувати, а відповідь IPv4 не підтверджує, що сервер приймає з’ єднання.
Порівняти публічний перегляд з переглядом вашого пристрою
Пошук домену і DNS Надає вам інший загальнодоступний перегляд, у тому числі інформацію про реєстрацію, якщо вона доступна. Його розташування і розв’ язувач не належать до вашого пристрою, і програма не перевіряє ваш домашній кеш DNS.
Якщо цей перегляд виглядає коректно, але навігація зазнає невдачі, порівняйте результати локального пошуку і точну помилку переглядача. Можливо, це пов’ язано з проксі- сервером, VPN, проблемою зі сертифікатом або заблокованим з’ єднанням. Зверніться до наших фахівців з цих питань, замість того, щоб оголошувати, що весь сайт працює нормально, оскільки віддалений пошук повернув адресу.
Розглядати зміну DNS як експеримент
У вашій власній мережі, інший респектабельний розв’ язувач може допомогти вам дослідити деякі помилки розв’ язання назв. Запишіть старі автоматичні або ручні параметри і дізнайтеся, як їх відновити. Запитайте у відділу інформаційних технологій перед зміною керованого пристрою, оскільки DNS може надавати внутрішні назви або фільтрування.
Повторіть попереднє порівняння, якщо це необхідно. Також може бути, що термін дії кешу закінчився або адреса призначення була відновлена. Не змінюйте маршрутизатор, переглядач і пристрій одночасно, а потім припускайте, що ця зміна виправила проблему.
Сира IP- адреса не є надійною заміною назви веб- сайту. Сертифікати HTTPS і спільний хостинг залежать від назв вузлів. Ніколи не ігноруйте попередження про сертифікат лише тому, що адреса виглядає правдоподібною.
Якщо ви керуєте веб- сайтом
Спочатку визначте активного авторитетного постачальника DNS. Реєстрація, хостинг DNS і хостинг веб- сайтів можуть бути окремими службами. Редагування панелі неактивного постачальника не призведе до зміни активної зони.
Після запланованої зміни перевірте точну назву вузла, тип запису і місце призначення. Зберігайте записи, які не пов’ язані з цим, наприклад, параметри пошти. Робоча пошта не встановлює робочий веб- DNS, і навпаки.
Корисний квиток містить публічну назву вузла, очікувану відповідь, спостережену помилку, час, з’ єднання і стан VPN. Для наступного етапу після розв’ язання назви скористайтеся the website- not- loading guide.