DNS праз TLS разам з VPN: якая частка абаронена

DNS праз TLS шыфруе абмен паміж кліентам і рэзалверам, які ён абраў, а рэзалвер усё роўна чытае імя. Гэты сказ здымае большую частку блытаніны вакол DoT разам з VPN. Тунель вырашае, які шлях пройдзе шыфраваны запыт, а рэзалвер усё роўна даведваецца, што было запытана. Ні адзін механізм не замяняе другі, і ні адзін не робіць другі залішнім.

Чатыры праверкі вызначаюць, ці тое размяшчэнне ў вас, пра якое вы думаеце.

Праверка 1: што пакрывае шыфраванне

DoT заварочвае абмен DNS у TLS, таму назіральнік на шляху бачыць злучэнне з адрасам і портам, а не імя ў запыце. Сам рэзалвер расшыфроўвае і адказвае. Параўнайце з DNS праз HTTPS: абодва шыфруюць і выкарыстоўваюць розныя транспарты, таму сетка, якая дазваляе вэб-трафік, не дазваляе аўтаматычна злучэнне DoT.

Гэта розніца важная, калі палонны партал або фільтравальны прамежкавы блок дазваляе 443 і блакуе 853. Інструмент, які там працаваў, не з'яўляецца доказам, што другі будзе.

Праверка 2: які маршрут бярэ запыт

Маршрут — пытанне палітыкі кліента. Да рэзалвера DoT можна дабрацца праз тунель, па-за ім або шляхам, які змяняецца разам з сеткай. Што менавіта адбудзецца, залежыць ад маршрутаў і ад таго, ці кліент абараняе свой DNS-сокет. Тунель, які захоплівае ўвесь трафік, звычайна забярэ запыт з сабой, што б ні казаў адрас рэзалвера.

Бачыць у тэсце адрас старонняга рэзалвера не даказвае абыход, а бачыць шыфраванне не даказвае патрэбнага атрымальніка. Чытайце рэзалвер і шлях асобна, потым вырашыце, ці пара — гэта тое, што вы распрацавалі.

Праверка 3: унутраныя імёны

Арганізацыя, якая публікуе ўнутраныя імёны, мае патрэбу ў рэзалверы, які трымае гэтыя запісы. Публічная паслуга DoT не ведае вашай прыватнай прасторы імён, і накіраванне кліента на яе гарантуе, што гэтыя імёны не спрацуюць. Гэта найчасцейшая практычная рэгрэсія, калі хтосьці ўключае шыфраваны DNS на кіраванай прыладзе.

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

Праверка 4: паводзіны пры збоі

Строгая налада рэзалвера без дасяжнага рэзалвера дае збой развязання імёнаў, пакуль тунель застаецца ўзнятым. Глядзіце на рэжым платформы і яго дакументаваны рэзерв, а не чапайце ключы або сертыфікаты.

Рэзерв, які моўчкі выкарыстоўвае звычайны DNS, — гэта рашэнне палітыкі, а не зручнасць. Вырашыце, ці збой павінен быць бачным або павінен зніжацца да чагосьці слабейшага, і запішыце адказ.

Давярайце сертыфікату, а не адказу

Выкарыстоўвайце імя хоста пастаўшчыка і канфігурацыю праверкі, дакументаваныя для паслугі. Адключэнне праверак TLS, каб незнаёмы рэзалвер адказаў, дае вам шыфраваны канал да неправеранай канчатковай кропкі, што горш за звычайны запыт, які ён замяніў, у адной канкрэтнай рысе: гэта выглядае бяспечна. Спецыфікацыя DNS праз TLS выкладае чаканне аўтэнтыфікацыі, што стаіць за гэтай праверкай.

Адказ ад рэзалвера, які вы не можаце аўтэнтыфікаваць, — гэта заява, а не вынік.

Што гэта пакідае нявытлумачаным

DoT не хавае імя ад рэзалвера, не хавае адрас прызначэння злучэння ад сеткі і не вырашае, ці запыт ішоў праз тунель. Гэта тры асобныя пытанні з трыма асобнымі адказамі.

Запішыце ідэнтычнасць рэзалвера, транзітны шлях і палітыку ўнутраных імёнаў як тры радкі. Наступнае пытанне пра DNS, якое вы атрымаеце, будзе адно з іх.