Шифрован DNS без VPN скрива заявката, а не адреса ви

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

Запишете целта, преди да стартирате какъвто и да е тест.

Стъпка 1: назовете защитата, която всъщност искате

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

VPN обслужва третата и, в зависимост от доставчика, първата. Нито един инструмент не е надмножество на другия.

Стъпка 2: изберете резолвер и проверете самоличността му

DNS over TLS обвива заявката в TLS сесия с резолвера, а DNS over HTTPS я обвива в HTTP заявка; RFC 7858 и RFC 8484 описват двете и нито едно не се нуждае от тунел. Оперативно важно е сертификатът да се проверява спрямо името, което сте конфигурирали, защото шифрована сесия с грешната страна е по-лоша от открит текст с правилната. Това означава строг режим там, където платформата го предлага, а не опортюнистичен режим, който се отказва при неуспешна проверка. Проверете сесията директно, преди да се доверите на настройката: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Ръкустиската трябва да назове резолвера, който сте конфигурирали, и да върне верига, която можете да проверите.

Стъпка 3: решете поведението при отказ

Всяка реализация има политика за недостъпен шифрован резолвер и тази политика е решението за поверителност. Строгият режим проваля търсенето, което е видимо и дразнещо. Опортюнистичният режим опитва отново с открит текст, което е невидимо и обезсмисля целта точно в деня, в който тя е важна. Изберете съзнателно, след това запишете избора до изискването.

На systemd-resolved това означава DNSOverTLS=yes вместо opportunistic; а на Android означава режим на име на хост за Private DNS вместо автоматичен.

Проверете какво всъщност е в сила с resolvectl status | grep -i -A1 "dns over tls", защото drop-in файл, който никога не е презареждан, не променя нищо.

Стъпка 4: проверете дали приложенията следват системния резолвер

Браузър със собствена настройка за сигурен DNS напълно заобикаля системната конфигурация, а също и контейнерен runtime с вграден резолвер или runtime на език, който чете твърдо зададен списък. Или ги накарайте да следват системата, или ги конфигурирайте явно и го запишете. След това погледнете поведението при отказ на всяко едно, защото не всички се провалят затворено. Инвентарът на практика е кратък: браузър, контейнерен runtime и всеки VPN клиент, който също пускате.

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

Стъпка 5: четете теста за изтичане спрямо изискването

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

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

Запишете реда за приемане на езика на целта: тези търсения използват този проверен резолвер при тези условия. Всичко по-широко е твърдение, което не можете да тествате.