DNS TLS-en keresztül plusz VPN: melyik rész védett

A DNS TLS-en keresztül titkosítja a kliens és az általa választott resolver közötti cserét, és a resolver továbbra is olvassa a nevet. Ez a mondat elrendezi a DoT és a VPN körüli zavar nagy részét. Az alagút dönti el, melyik úton megy a titkosított lekérdezés, miközben a resolver továbbra is megtudja, mit kérdeztek. Egyik mechanizmus sem helyettesíti a másikat, és egyik sem teszi feleslegessé a másikat.

Négy ellenőrzés dönti el, hogy a meglévő elrendezés az-e, amiről azt hiszi, hogy van.

1. ellenőrzés: mit fed le a titkosítás

A DoT TLS-be csomagolja a DNS-cserét, így az úton lévő megfigyelő egy címhez és porthoz tartó kapcsolatot lát, nem egy nevet a lekérdezésben. A resolver maga fejti vissza és válaszol. Hasonlítsa össze a DNS over HTTPS-szel: mindkettő titkosít, és különböző átviteli módokat használnak, ezért egy webes forgalmat engedélyező hálózat nem engedélyez automatikusan DoT-kapcsolatot.

Ez a különbség akkor számít, amikor egy captive portal vagy egy szűrő köztes doboz engedélyezi a 443-at és blokkolja a 853-at. Az ott működő eszköz nem bizonyítja, hogy a másik is működni fog.

2. ellenőrzés: melyik útvonalon megy a lekérdezés

Az útvonal kliensszabályozási kérdés. A DoT resolver elérhető az alagúton keresztül, azon kívül, vagy olyan úton, amely a hálózattal változik. Melyik történik, az útvonalaktól és attól függ, hogy a kliens védi-e a saját DNS-csatlakozóját. Az összes forgalmat elkapó alagút általában magával viszi a lekérdezést, bármit is mond a resolver címe.

Egy harmadik féltől származó resolver címének látása egy tesztben nem bizonyít megkerülést, a titkosítás látása pedig nem bizonyítja a szándékolt címzettet. Olvassa külön a resolvert és az útvonalat, majd döntse el, hogy a pár az-e, amit tervezett.

3. ellenőrzés: belső nevek

A belső neveket közzétevő szervezetnek olyan resolverre van szüksége, amely ezeket a rekordokat tartja. Egy nyilvános DoT-szolgáltatás nem ismeri a privát névterét, és a kliens ráirányítása garantálja, hogy ezek a nevek meghiúsuljanak. Ez a leggyakoribb gyakorlati visszaesés, amikor valaki titkosított DNS-t kapcsol be egy felügyelt eszközön.

Tartsa meg a belső resolvert a belső utótagokhoz, és titkosítsa azt az ugrást, ha a szabályzat megköveteli, ahelyett hogy nyilvános szolgáltatóval helyettesítené.

4. ellenőrzés: viselkedés hiba esetén

A szigorú resolver-beállítás elérhető resolver nélkül névfeloldási hibát okoz, miközben az alagút állva marad. Nézze a platform módját és a dokumentált tartalékát, ahelyett hogy kulcsokhoz vagy tanúsítványokhoz nyúlna.

A csendesen sima DNS-t használó tartalék szabályzati döntés, nem kényelem. Döntse el, hogy a hibának láthatónak kell-e lennie, vagy gyengébb valamire kell visszaesnie, és írja le a választ.

A tanúsítványban bízzon, ne a válaszban

Használja a szolgáltató dokumentált gazdagépnevét és a szolgáltatáshoz dokumentált ellenőrzési beállítást. A TLS-ellenőrzések kikapcsolása, hogy egy ismeretlen resolver válaszoljon, titkosított csatornát ad egy nem ellenőrzött végponthoz, ami egy konkrét szempontból rosszabb, mint a lecserélt sima lekérdezés: biztonságosnak látszik. A DNS over TLS specifikáció kifejti az ellenőrzés mögötti hitelesítési elvárást.

Egy olyan resolver válasza, amelyet nem tud hitelesíteni, állítás, nem eredmény.

Mit hagy ez magyarázat nélkül

A DoT nem rejti el a nevet a resolver elől, nem rejti el a kapcsolat célcímét a hálózat elől, és nem dönti el, hogy a lekérdezés az alagúton ment-e át. Ez három külön kérdés három külön válasszal.

Írja le a resolver identitását, a tranzitútvonalat és a belső névszabályzatot három sorban. A következő DNS-kérdés, amit kap, ezek egyike lesz.