TLS үстіндегі DNS және VPN: қай бөлігі қорғалған
DoT таңдалған resolver-ге дейінгі секірісті шифрлайды, атаудың өзін емес. Төрт тексеру: resolver сәйкестігі, транзиттік маршрут, ішкі атаулар және қосалқы жол.
TLS үстіндегі DNS клиент пен ол таңдаған resolver арасындағы алмасуды шифрлайды, ал resolver атауды әлі де оқиды. Бұл сөйлем DoT пен VPN төңірегіндегі шатасудың көбін шешеді. Туннель шифрланған сұраудың қай жолмен жүретінін шешеді, ал resolver не сұралғанын әлі де біледі. Екі механизмнің ешқайсысы екіншісін алмастырмайды және ешқайсысы екіншісін артық етпейді.
Төрт тексеру сіздегі конфигурация өзіңіз ойлаған конфигурация ма екенін шешеді.
Тексеру 1: шифрлау нені қамтиды
DoT DNS алмасуын TLS ішіне орайды, сондықтан жолдағы бақылаушы сұраудағы атауды емес, мекенжай мен портқа қосылымды көреді. Resolver өзі шифрды ашады және жауап береді. Оны HTTPS үстіндегі DNS-пен салыстырыңыз: екеуі де шифрлайды және әртүрлі көліктерді пайдаланады, сондықтан веб-трафикке рұқсат беретін желі DoT қосылымына автоматты түрде рұқсат бермейді.
Бұл айырмашылық тұтқын порталы немесе сүзгілейтін аралық блок 443-ке рұқсат беріп, 853-ті бөгеттегенде маңызды. Онда жұмыс істеген құрал екіншісінің жұмыс істейтініне дәлел емес.
Тексеру 2: сұрау қай маршрутпен жүреді
Маршрут клиент саясатының мәселесі. DoT resolver-іне туннель арқылы, оның сыртында немесе желімен бірге өзгеретін жолмен жетуге болады. Қайсысы болатыны маршруттарға және клиенттің өз DNS сокетін қорғайтынына байланысты. Барлық трафикті ұстайтын туннель әдетте сұрауды өзімен бірге алып кетеді, resolver мекенжайы не десе де.
Сынақта үшінші тарап resolver-інің мекенжайын көру айналып өтуді дәлелдемейді, ал шифрлауды көру мақсатты алушыны дәлелдемейді. Resolver мен жолды бөлек оқыңыз, содан кейін жұп өзіңіз жобалаған жұп па екенін шешіңіз.
Тексеру 3: ішкі атаулар
Ішкі атауларды жариялайтын ұйымға сол жазбаларды ұстайтын resolver қажет. Ашық DoT қызметі сіздің жеке атау кеңістігіңізді білмейді, ал клиентті соған бағыттау бұл атаулардың сәтсіз болатынына кепілдік береді. Басқарылатын құрылғыда біреу шифрланған DNS-ті қосқандағы ең жиі практикалық регрессия осы.
Ішкі жұрнақтар үшін ішкі resolver-ді сақтап, саясат талап етсе, сол секірісті шифрлаңыз, оны ашық провайдермен алмастырудың орнына.
Тексеру 4: сәтсіздік кезіндегі мінез-құлық
Қолжетімді resolver жоқ қатаң resolver параметрі туннель көтерілген күйде атауды шешу сәтсіздігін тудырады. Кілттерге немесе сертификаттарға тиюдің орнына платформа режиміне және оның құжатталған қосалқы жолына қараңыз.
Қарапайым DNS-ті үнсіз пайдаланатын қосалқы жол саяси шешім, ыңғайлылық емес. Сәтсіздік көрінуі керек пе, әлде әлсізірек нәрсеге төмендеуі керек пе, соны шешіп, жауапты жазыңыз.
Сертификатқа сеніңіз, жауапқа емес
Қызмет үшін құжатталған провайдердің хост атауын және тексеру конфигурациясын пайдаланыңыз. Белгісіз resolver жауап берсін деп TLS тексерулерін өшіру сізге тексерілмеген соңғы нүктеге шифрланған арна береді, бұл орын басқан қарапайым сұраудан бір нақты жағынан нашар: ол қауіпсіз көрінеді. DNS-тің TLS үстіндегі спецификациясы сол тексерудің артындағы аутентификация күтуін баяндайды.
Аутентификациялай алмайтын resolver-дің жауабы нәтиже емес, мәлімдеме.
Бұл нені түсіндірілмеген күйде қалдырады
DoT атауды resolver-ден жасырмайды, қосылымның межелі мекенжайын желіден жасырмайды және сұраудың туннельден өткенін шешпейді. Бұлар үш бөлек сұрақ және үш бөлек жауап.
Resolver сәйкестігін, транзиттік жолды және ішкі атау саясатын үш жол етіп жазыңыз. Келесі алатын DNS сұрағыңыз солардың бірі болады.