DNSSEC vai VPN: kumpi piilottaa DNS-kyselysi?

Kaksi mekanismia saa saman tehtävän, eikä kumpikaan suorita sitä. DNSSEC vastaa siihen, tulivatko saamasi tiedot todella siitä vyöhykkeestä, joka ne julkaisee, ja VPN päättää, minkä reitin pakettisi kulkevat. Kumpikaan ei piilota kysymääsi nimeä kaikissa tapauksissa, ja asetukset, jotka näyttävät siltä kuin niiden pitäisi, koskevat yleensä siirtoa tai reititystä eikä validointia. Kun nimeät kerroksen ensin, epämääräinen yksityisyyttä koskeva kysymys muuttuu täsmälliseksi.

Kolme väitettä, jotka sulautuvat yhdeksi

Aitous on väite, että vastaus on se, jonka vyöhyke julkaisi, eikä sitä muutettu matkalla. Luottamuksellisuus on väite, että kukaan reitillä ei voi lukea kyselyä tai vastausta. Reititys on väite, että paketit seuraavat valitsemaasi reittiä, ja juuri sen tunneli tarjoaa.

DNSSEC käsittelee ensimmäistä eikä sano kahdesta muusta mitään. DoT ja DoH käsittelevät toista hyppylle ratkaisijaan. VPN käsittelee kolmatta ja voi vaikuttaa myös toiseen, mutta vain sivutuotteena siitä, minne liikenne menee.

Sovellusliikenne on neljäs tapaus: HTTPS suojaa ja todentaa verkkotapahtuman asiakkaasi ja sivuston välillä, eikä mikään DNS-kerros korvaa sitä.

Mitä allekirjoitusten validointi voi tehdä ja mitä ei

Validoiva ratkaisija tarkistaa allekirjoitusketjun vyöhykkeestä määritettyyn luottamusanakkoon ja palauttaa sitten vastauksen, jossa on todennettujen tietojen lippu asetettuna, kun tarkistus onnistuu. Lippu on todiste tiedoista, ei yhteydestä tai kohteen aikomuksista.

Se ei voi estää laillista vyöhykkeen omistajaa julkaisemasta aitoja tietueita palvelulle, johon sinun ei pitäisi luottaa. Oikein allekirjoitettu vastaus kompromettoidusta verkkotunnuksesta on edelleen oikein allekirjoitettu, eikä DNSSECillä ole mielipidettä siitä, ansaitseeko se verkkotunnus tunnuksesi.

Se ei myöskään piilota mitään. Kysely ja vastaus kulkevat verkon läpi muodossa, jonka ratkaisija ja kuka tahansa kyseisen reitin tarkkailija voi lukea, ellei jokin toinen kerros suojaa siirtoa. Allekirjoitettu vastaus ja yksityinen vastaus ovat eri ominaisuuksia, ja käyttöönotossa voi olla vain toinen. Testaa molempia, jos jompikumpi on sinulle tärkeä.

Mistä luottamuksellisuus oikeastaan tulee

Salattu ratkaisijasiirto käärii DNS-tapahtuman TLSään, joten ratkaisija näkee yhä kysymyksen mutta sinun ja sen välinen reitti ei. Tämä siirtää luottamusta sen poistamisen sijaan: luotat ratkaisijaan enemmän ja paikallisverkkoon vähemmän.

VPN voi kuljettaa kyselyt toisella puolella olevalle ratkaisijalle, mikä muuttaa sekä reittiä että ratkaisijaa, joka ne näkee. Se on reitityspäätös, jolla on yksityisyysseuraus, ja hallitussa verkossa sisäinen ratkaisija voi olla ainoa, joka pystyy vastaamaan sisäisiin nimiin.

Yhdistelmä, jota ihmiset todella haluavat, on yleensä kolme asiaa yhtä aikaa: validointi päällä, salattu siirto valitsemaansa ratkaisijaan ja sovelluksen TLS kohteessa. Jokainen on riippumaton, ja yhden väliin jättäminen jättää erilaisen aukon.

Tarkista validointi ja siirto erikseen

Kaksi testiä ratkaisee suurimman osan sekaannuksesta. Ensimmäinen kysyy, validoiko ratkaisija vastauksen; toinen kysyy, oliko siirto suojattu. Ne epäonnistuvat eri tavoin eikä kumpikaan edellytä toista.

Nämä komennot tulostavat validoivan kyselyn liput, toistavat kyselyn tarkistus poistettuna käytöstä ja suorittavat paikallisen validoinnin komennolla delv:

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

Vastaus, jossa on todennettujen tietojen lippu ja allekirjoitus, osoittaa validoinnin kyseisessä ratkaisijassa. Validoinnin epäonnistuminen komennolla delv osoittaa katkenneen ketjun jossain vyöhykkeen ja luottamusanakan välillä, mikä on julkaisuongelma eikä tunneliongelma. Aikakatkaisu ilman mitään lippuja on siirto- tai tavoitettavuusongelma, ja sen käsitteleminen allekirjoitusvirheenä vie sinut väärään kerrokseen.

Mitä tehdä, kun VPN rikkoo haut

Jos haut toimivat ennen tunnelia ja pysähtyvät sen jälkeen, vertaa ratkaisijaa, jota kukin reitti käyttää. Jaettu tunnelointi, vain tunnelin kautta tavoitettava sisäinen ratkaisija ja asiakas, joka kirjoittaa ratkaisijan asetukset uudelleen, muuttavat kaikki vastausta koskematta DNSSECiin.

Validoinnin poistaminen käytöstä maailmanlaajuisesti on väärä ensimmäinen askel, koska se poistaa ainoan mekanismin, joka ilmoittaa peukaloinnista, eikä korjaa ratkaisijaa, jota ei voi tavoittaa. Rajaa vika ensin: ratkaisu, siirto, validointi ja sitten käytäntö. Vain kolmas kuuluu DNSSECille ja vain toinen salatulle siirrolle.