DNS преко TLS-а уз VPN: који део је заштићен

DNS преко TLS-а шифрира размену између клијента и resolver-а који је одабрао, а resolver и даље чита име. Та реченица решава већину забуне око DoT-а уз VPN. Тунел одлучује којим путем иде шифрирани упит, док resolver и даље сазнаје шта је питано. Ниједан механизам не замењује други и ниједан не чини други сувишним.

Четири провере одлучују да ли је уређење које имате оно за које мислите да га имате.

Провера 1: шта шифрирање покрива

DoT замотава DNS размену у TLS, па посматрач на путу види везу према адреси и порту, а не име у упиту. Сам resolver дешифрује и одговара. Упоредите са DNS-ом преко HTTPS-а: оба шифрирају и користе различите транспорте, па мрежа која дозвољава веб саобраћај не дозвољава аутоматски DoT везу.

Та разлика је важна кад captive portal или филтрирајући међусклоп дозвољава 443 и блокира 853. Алат који је тамо радио није доказ да ће други радити.

Провера 2: којом рутом иде упит

Рута је питање клијентске политике. До DoT resolver-а може се доћи кроз тунел, изван њега или путем који се мења са мрежом. Који ће се догодити зависи од рута и од тога штити ли клијент свој DNS сокет. Тунел који хвата сав саобраћај обично понесе упит са собом, шта год адреса resolver-а говорила.

Видети адресу resolver-а треће стране у тесту не доказује заобилажење, а видети шифрирање не доказује жељеног примаоца. Читајте resolver и пут одвојено, па одлучите да ли је пар оно што сте пројектовали.

Провера 3: интерна имена

Организација која објављује интерна имена треба resolver који држи те записе. Јавна DoT услуга не познаје ваш приватни простор имена, а усмеравање клијента на њу јамчи да ће та имена пропасти. То је најчешћа практична регресија кад неко укључи шифрирани DNS на управљаном уређају.

Задржите интерни resolver за интерне суфиксе и шифрирајте тај скок ако политика то захтева, уместо да га замените јавним пружаоцем.

Провера 4: понашање при квару

Строга поставка resolver-а без доступног resolver-а даје квар разрешавања имена док тунел остаје подигнут. Гледајте начин рада платформе и њен документовани резервни пут, уместо да дирате кључеве или сертификате.

Резервни пут који тихо користи обичан DNS је одлука политике, а не погодност. Одлучите да ли квар треба да буде видљив или да се спусти на нешто слабије, и запишите одговор.

Верујте сертификату, а не одговору

Користите име хоста пружаоца и конфигурацију провере документовану за услугу. Искључивање TLS провера да би непознат resolver одговорио даје вам шифриран канал према непровереној крајњој тачки, што је горе од обичног упита који је заменио, у једном конкретном погледу: изгледа безбедно. Спецификација DNS-а преко TLS-а излаже очекивање провере аутентичности иза те контроле.

Одговор resolver-а који не можете проверити је тврдња, а не резултат.

Шта ово оставља необјашњеним

DoT не скрива име од resolver-а, не скрива адресу одредишта везе од мреже и не одлучује да ли је упит ишао кроз тунел. То су три одвојена питања са три одвојена одговора.

Запишите идентитет resolver-а, транзитни пут и политику интерних имена као три ретка. Следеће DNS питање које добијете биће једно од њих.