Хто керує 1.1.1.1? Перевірка DNS-адреси, перш ніж їй довіряти

Ви вставили 1.1.1.1 у поле DNS VPN, сторінка завантажилася, і посібник тепер виглядає підтвердженим. Це спостереження вужче, ніж здається: застосунок повівся інакше, а зміна поки нічого не каже про те, хто відповів на запит або чому стара конфігурація не спрацювала. Скопійований посібник часто називає відому публічну адресу «DNS VPN», і це твердження про власність, а не про доступність. Перевірка того, що представляє адреса, займає п’ять хвилин і запобігає постійній зміні, зробленій із хибної причини.

Робоче налаштування не є ідентичністю

Адреса в полі налаштувань — це кінцева точка, а кінцева точка має оператора. Ці два факти окремі, і другий люди зазвичай пропускають. Для найчастіше скопійованої пари відповідь публічна: Cloudflare публікує 1.1.1.1 і 1.0.0.1 як адреси свого резолвера та перелічує їх у своєму офіційному довіднику адрес. Тому ім’я оператора належить поруч з адресою, а не в окремому посібнику.

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

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

Порівняйте три речі, які потрібні запису

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

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

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

Локальний пересилач приховує справжнє джерело

Пристрій, налаштований використовувати свій маршрутизатор як DNS, вказує на пересилач. Ця адреса визначає наступного отримувача запиту, а не резолвер, який зрештою відповідає. Локальний stub-резолвер додає той самий додатковий крок, і його легко сплутати зі справжнім, бо він з’являється в кожному виводі стану.

Stub пересилає до джерел, які той самий вивід також перелічує, зазвичай нижче. Прочитайте весь ланцюжок, перш ніж робити висновки про оператора, бо перший рядок — не вся відповідь. Інакше ви називаєте рецепцію компанією.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

Друга команда використовує луна-ім’я резолвера, якщо оператор його публікує, щоб повідомити вихідну адресу, яку він бачить. Третя називає сервер, що відповів, і це часто не та адреса, яку ви налаштували. Порівняйте всі три виводи, перш ніж записати оператора.

Зашифрований DNS змінює те, що видно, а не те, хто це бачить

DNS over HTTPS і DNS over TLS захищають обмін між клієнтом і резолвером. Резолвер усе ще читає кожне ім’я, про яке його питають, бо відповідати — це його робота. Змінюється те, хто може спостерігати за обміном: локальна мережа бачить з’єднання з однією кінцевою точкою замість потоку запитів у відкритому тексті.

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

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

Тримайте спостереження вузьким

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

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

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