Шифровани 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 подешавање то никада не би пружило.

Запишите линију прихватања на језику циља: ове претраге користе овај проверени резолвер под овим условима. Све шире је тврдња коју не можете тестирати.