Кой управлява 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

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