Шыфраваны 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 ніколі б гэтага не забяспечыла.

Запішыце радок прыняцця на мове мэты: гэтыя пошукі выкарыстоўваюць гэты правераны рэзолвер пры гэтых умовах. Усё шырэйшае — гэта заява, якую вы не можаце праверыць.