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

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

Четири проверки одлучуваат дали поставеноста што ја имате е онаа што мислите дека ја имате.

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

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

Таа разлика е важна кога заробен портал или филтрирачка средна кутија дозволува 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 прашање што ќе го добиете ќе биде едно од нив.