DNSSEC срещу VPN: кое скрива DNS заявките ви?

Два механизма получават една и съща задача и нито един от тях не я изпълнява. DNSSEC отговаря дали данните, които сте получили, наистина идват от зоната, която ги публикува, а VPN решава по кой път минават пакетите ви. Нито един от тях не скрива поисканото име във всички случаи, а настройките, които изглеждат сякаш трябва да го правят, обикновено се отнасят до транспорта или маршрутизацията, а не до валидирането. Ако първо назовете слоя, смътният въпрос за поверителност става конкретен.

Три твърдения, слети в едно

Автентичността е твърдението, че отговорът е този, който зоната е публикувала, и не е бил променен по пътя. Поверителността е твърдението, че никой по пътя не може да прочете заявката или отговора. Маршрутизацията е твърдението, че пакетите следват избран от вас път, което е точно това, което дава тунелът.

DNSSEC се занимава с първото и не казва нищо за другите две. DoT и DoH се занимават с второто за отсечката до резолвера. VPN се занимава с третото и може да повлияе и на второто, но само като страничен ефект от това накъде отива трафикът.

Трафикът на приложенията е четвърти случай: HTTPS защитава и удостоверява уеб обмена между вашия клиент и сайта и никой DNS слой не го замества.

Какво може и какво не може валидирането на подписи

Валидиращият резолвер проверява веригата от подписи от зоната до конфигурирана котва на доверие, след което връща отговор с вдигнат флаг за удостоверени данни, когато проверката успее. Този флаг е доказателство за данните, а не за връзката или за намеренията на дестинацията.

Той не може да спре законен собственик на зона да публикува автентични записи за услуга, на която не бива да се доверявате. Правилно подписан отговор от компрометиран домейн все още е правилно подписан и DNSSEC няма мнение дали този домейн заслужава данните ви за вход.

Той също не скрива нищо. Заявката и отговорът преминават през мрежата във вид, който резолверът и всеки наблюдател по този път могат да прочетат, освен ако друг слой не защитава транспорта. Подписаният отговор и частният отговор са различни свойства и едно внедряване може да има само едно от двете. Тествайте и двете, ако някое от тях ви е важно.

Откъде всъщност идва поверителността

Криптираният транспорт до резолвера обгръща DNS обмена в TLS, така че резолверът все още вижда въпроса, но пътят между вас и него не. Това мести доверието, вместо да го премахва: доверявате се повече на резолвера и по-малко на локалната мрежа.

VPN може да пренася заявки до резолвер от другата страна, което променя както пътя, така и резолвера, който ги вижда. Това е решение за маршрутизация с последица за поверителността, а в управлявана мрежа вътрешният резолвер може да е единственият, който може да отговори на вътрешни имена.

Комбинацията, която хората всъщност искат, обикновено е три неща наведнъж: включено валидиране, криптиран транспорт до избран от тях резолвер и TLS на приложението към дестинацията. Всяко е независимо и пропускането на едно оставя различна празнина.

Проверявайте валидирането и транспорта поотделно

Два теста изясняват по-голямата част от объркването. Първият пита дали резолверът е валидирал отговора; вторият пита дали транспортът е бил защитен. Те се провалят по различен начин и нито едното не предполага другото.

Тези команди отпечатват флаговете от валидираща заявка, повтарят заявката с изключена проверка и стартират локално валидиране с delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Отговор с флаг за удостоверени данни и наличен подпис показва валидиране при този резолвер. Провал на валидирането с delv показва счупена верига някъде между зоната и котвата на доверие, а това е проблем с публикуването, а не с тунела. Изтичане на времето без никакви флагове е проблем с транспорта или достъпността и третирането му като проблем с подписа ви праща на грешния слой.

Какво да правите, когато VPN счупи търсенето

Ако търсенето е работело преди тунела и спре след него, сравнете резолвера, който използва всеки път. Разделното тунелиране, вътрешен резолвер, достъпен само през тунела, и клиент, който преписва настройките на резолвера, всички променят отговора, без да пипат DNSSEC.

Изключването на валидирането глобално е грешен първи ход, защото премахва единствения механизъм, който съобщава за намеса, и не поправя резолвер, който не може да бъде достигнат. Първо стеснете повредата: резолюция, транспорт, валидиране, после политика. Само третото принадлежи на DNSSEC и само второто — на криптирания транспорт.