Do­main Na­me Ser­vi­ce: be­scherm zelf je pri­va­cy

Do­main Na­me Ser­vi­ce: da­ta­be­vei­li­ging zelf ma­ken

C’t Magazine - - Inhoud - Car­sten Strot­mann

Als je op in­ter­net rond surft, laat je spo­ren ach­ter. Bij al­le net­werk­knoop­pun­ten kun je bij­voor­beeld een­vou­dig uit­le­zen wie wel­ke web­si­tes be­zoekt. Er zijn ech­ter mid­de­len om je pri­va­cy te waar­bor­gen en je surf­doe­len te be­scher­men te­gen nieuws­gie­ri­ge blik­ken. We la­ten zien hoe je dat doet met de klei­ne DNSre­sol­ver Un­bound.

Al­le ge­brui­kers la­ten tal­rij­ke spo­ren na over hun in­te­res­ses bij hun in­ter­net­ac­ti­vi­tei­ten. De na­me-re­sol­ving van het Do­main Na­me Sy­s­tem (DNS) is daar­bij een hoofd­bron, want dat werkt door­gaans zon­der ver­sleu­te­ling. In­ter­net­pro­vi­ders, ex­ploi­tan­ten van DNS-ser­vers en so­wie­so el­ke open­ba­re of pri­vé-snif­fer die zich op het tra­ject naar de DNS-ser­vers be­vindt, kan dat mak­ke­lijk af­tap­pen.

Er zijn ver­schil­len­de ma­nie­ren om de in­kijk in het DNS-ver­keer in te dam­men en je per­soon­lij­ke ge­ge­vens daar­mee te be­scher­men. Je kunt bij­voor­beeld ex­ter­ne DNS-re­sol­vers van ex­ter­ne aan­bie­ders ge­brui­ken die ga­ran­de­ren dat ze de langs­ko­men­de da­ta niet log­gen – maar dat helpt niet te­gen even­tu­eel af­luis­te­ren on­der­weg. Een voor­beeld daar­voor staat in on­ze ba­sis­con­fi­gu­ra­tie voor een lo­kaal te in­stal­le­ren DNS-re­sol­ver Un­bound [1]. Dat opens­our­ce­pro­gram­ma is be­schik­baar voor al­le gang­ba­re Li­nux-dis­tri­bu­ties en voor Win­dows. Bij macOS kun je een ac­tu­e­le ver­sie krij­gen met de op­ti­o­ne­le pak­ket­ma­na­gers MacPorts en Ho­me­brew. In dit ar­ti­kel gaan we in op uit­brei­din­gen van het con­cept. Daar­bij re­du­ce­ren we de hoe­veel­heid met­a­da­ta die de Un­bound­re­sol­ver bij DNS-re­quests pro­du­ceert (QNAME mi­ni­mi­sa­ti­on). Om­dat dat al­leen helpt te­gen snif­fers bij de root- en top-le­veldo­mei­nen, la­ten we bo­ven­dien zien hoe je Un­bound op drie ma­nie­ren kunt in­rich­ten voor een ver­sleu­tel­de com­mu­ni­ca­tie met an­de­re DNS-ser­vers (up­stream-for­ward­re­sol­vers). Daar­bij gaat het om DNSCrypt, DNSTor en het nieu­we DNS-over-TLS.

We gaan daar­bij uit van de ba­sis­con­fi­gu­ra­tie in een vo­ri­ge c't voor de Li­nux­dis­tri­bu­te De­bi­an – zie www.ct.nl/soft­link/1707138. Je kunt Un­bound ook op Win­dows en macOS ge­brui­ken, en zelfs op de be­perk­te hard­wa­re van bij­voor­beeld een ener­gie­zui­ni­ge Rasp­ber­ry Pi. Het groot­ste deel van het in­stel­len ge­beurt met het in­ty­pen van com­man­do's op een com­mand­line. We heb­ben ech­ter een hand­vol con­fi­gu­ra­tie­be­stan­den ge­maakt, zo­dat je niet al­les zelf he­le­maal in hoeft te ty­pen. Het ar­chief met uit­ge­brei­de in­for­ma­tie over dit on­der­werp en de down­lo­ad­links voor al­le ge­bruik­te tools staan bij de link on­der­aan dit ar­ti­kel.

Het be­wa­ken van het in­ter­net­ver­keer is voor een groot deel ge­ba­seerd op het ana­ly­se­ren van met­a­da­ta – bij­voor­beeld in­for­ma­tie over wel­ke host wan­neer en hoe lang met wel­ke ser­ver con­tact heeft ge­had. DNS-re­quests zor­gen voor een groot deel van die met­a­da­ta.

Met­a­da­ta klei­ner ma­ken

Bij een tra­di­ti­o­ne­le con­fi­gu­ra­tie stuurt een DNS-re­sol­ver al­tijd de com­ple­te do­mein­naam van een DNS-re­quest van een client naar al­le ser­vers bin­nen de DNS-hi­ë­rar­chie. Die ma­nier van wer­ken had in het be­gin van het in­ter­net voor­de­len, maar van­daag de dag is het uit het oog­punt van pri­va­cy na­de­lig. De re­quest kan door el­ke DNS­ser­ver die hem ont­vangt ge­logd wor­den en aan een ge­brui­ker wor­den toe­ge­we­zen. Om­dat ze bo­ven­aan in de hi­ë­rar­chie zit­ten, krij­gen root-ser­vers en top-le­vel-ser­vers in­zicht in het groot­ste deel van het in­ter­net­ver­keer over de he­le we­reld.

De In­ter­net En­gi­nee­ring Task For­ce heeft met de RFC 7816 over QNAME mi­ni­mi­sa­ti­on (waar­bij QNAME een sa­men­trek­king is van Qu­ery Na­me) een spe­ci­fi­ca­tie uit­ge­bracht waar­mee dit ge­drag is uit te zet­ten [2]. Als QNAME mi­ni­mi­sa­ti­on in­ge­scha­keld is, krij­gen de ser­vers al­leen nog de re­quests waar­voor ze zelf ver­ant­woor­de­lijk zijn en niet voor al­le de­len van de do­mein­na­men. Daar­door krijgt een re­sol­ver eerst van een root-ser­ver het adres van de DNS-ser­ver die ver­ant­woor­de­lijk is voor .nl. Ver­vol­gens krijgt hij daar­van het adres van de ser­ver die ver­ant­woor­de­lijk is voor ct.nl, en­zo­voort.

Bij het tes­ten met QNAME mi­ni­mi­sa­ti­on heb­ben deel­ne­mers van de IETF ge­con­sta­teerd dat de na­me-re­sol­ving bij re­gu­lie­re do­mei­nen (zo­als ct.nl) snel­ler ge­beurt dan op de tra­di­ti­o­ne­le ma­nier. Al­leen bij heel die­pe DNS-hi­ë­rar­chie­ën die zel­den voor­ko­men, zo­als ca­me­ra01.vi­deo­stu­dio. be­ne­den.re­dac­tie.ct.nl, treedt er snel­heids­ver­lies op om­dat daar­voor meer re­quests moe­ten wor­den ver­zon­den dan no­dig.

De RFC-spe­ci­fi­ca­tie 7816 heeft op dit mo­ment nog een ex­pe­ri­men­te­le sta­tus. Er zijn nog pro­ble­men met DNS-load-ba­lan­cers die bij do­mein­on­der­de­len zon­der DNS-re­cords abu­sie­ve­lijk NXDo­main in de DNS-re­ply's le­ve­ren. Daar­om is QNAME mi­ni­mi­sa­ti­on bij Un­bound in eer­ste in­stan­tie uit­ge­scha­keld. De­ze con­fi­gu­ra­tie­re­gel is ech­ter vol­doen­de om de tech­niek te ac­ti­ve­ren:

ser­ver: qname-mi­ni­mi­sa­ti­on: yes

QNAME mi­ni­mi­sa­ti­on werkt ech­ter al­leen goed als een re­sol­ver al­le na­men zelf re­sol­vet. Als hij de re­quests van clients in plaats daar­van naar een up­stream-DNS-re­sol­ver door­stuurt (for­war­ding-con­fi­gu­ra­tie), dan is de in­stel­ling on­gel­dig. Om dat uit te pro­be­ren, moet je in de ba­sis­con­fi­gu­ra­tie de for­war­ding naar DNS Watch, Xia­la en cen­sur­frid­ns uit­scha­ke­len. Open daar­voor een ter­mi­nal en be­werk het be­stand 01_ Ca­cheFor­war­der.conf:

su­do pi­co /etc/un­bound/un­bound.d/—

01_Ca­cheFor­war­der.conf

Zet com­men­taar­te­kens voor de re­gels van­af for­ward­zo­ne: tot en met de re­gel for­wardad­dr:89.233.43.71 # cen­sur­frid­ns.dk en sla het be­stand op met Ctrl+X en Yes.

Down­load het ar­chief met de con­fi­gu­ra­ti­euit­brei­din­gen bij de link aan het eind van dit ar­ti­kel, pak het uit op de desktop en ga in de ter­mi­nal naar de ar­chief­di­rec­to­ry. Zet qname-Mi­ni­mi­sa­ti­on.conf in de juis­te di­rec­to­ry: cd ~/Desktop/1712-124 cp qname-mi­ni­mi­sa­ti­on.conf

/etc/un­bound/un­bound.d

Kijk met un­bound-check­conf of de con­fi­gu­ra­tie­syn­taxis geen fou­ten heeft en start Un­bound dan op­nieuw op:

su­do ser­vi­ce un­bound restart

DNS-ver­sleu­te­ling

We gaan aan de hand van drie voor­beel­den met DNS-over-TLS, DNSCrypt en DNSTor la­ten zien hoe je Un­bound re­de­lijk di­rect of in­di­rect voor ver­sleu­tel­de DNS-re­quests kunt in­stel­len. De drie con­fi­gu­ra­ties slui­ten el­kaar uit, er kan er al­tijd maar één van de drie ac­tief zijn. Bo­ven­dien slui­ten al­le drie het ge­bruik uit van an­de­re open­ba­re DNSre­sol­vers, zo­als bij­voor­beeld Xia­la. Als je

ver­schil­len­de con­fi­gu­ra­ties wilt uit­pro­be­ren, zet je de con­fi­gu­ra­tie­be­stan­den in apar­te sub­di­rec­to­ry's, bij­voor­beeld etc/un­bound/ dns­overtls, en voeg je in /etc/un­bound/ un­bound.conf na het eer­ste in­clu­de-com­man­do een twee­de in. Voor DNS over TLS ziet dat er als volgt uit als je de con­fi­gu­ra­tie in de di­rec­to­ry dns­overtls ge­zet hebt:

in­clu­de: "/opt/lo­cal/etc/un­bound/—

dns­overtls/*.conf"

DNS over TLS

DNS-over-TLS is een pro­to­col­uit­brei­ding van de IETF-werk­groep DPRIVE [3]. Daar­bij stuurt een client zijn DNS-re­quests niet zo­als ge­brui­ke­lijk via het snel­le User Da­ta­gram Pro­to­col (UDP) naar een re­sol­ver, maar ver­sleu­teld met TLS (Trans­port Lay­er Se­cu­ri­ty). Dat be­te­kent wel meer pro­to­co­lover­head, maar op die ma­nier zijn DNSre­quests on­der­weg niet meer lees­baar voor an­de­ren.

Er is al een aan­tal open­ba­re re­sol­vers die DNS-over-TLS aan­bie­den. Een over­zicht daar­van wordt ver­zorgd door de DPRIVEwerk­groep op hun web­si­te. Daar staat ook óf en in wel­ke om­vang de ser­ver­ex­ploi­tan­ten de toe­gang log­gen.

We ge­brui­ken in het con­fi­gu­ra­tie­voor­beeld twee ser­vers van SurfNET. De ip-adres­sen van de bei­de ser­vers staan in het con­fi­gu­ra­tie­be­stand tls-for­ward.conf:

for­ward-zo­ne: na­me: "." for­ward-ad­dr: 145.100.185.15@853 for­ward-ad­dr:

2001:610:1:40ba:145:100:185:15@853 for­ward-ad­dr: 145.100.185.16@853 for­ward-ad­dr:

2001:610:1:40ba:145:100:185:16@853 for­ward-first: no for­ward-ssl-up­stream: yes

De for­ward-zo­ne geldt voor de root-zo­ne (.) en al­le do­mei­nen die bij die hi­ë­rar­chie ho­ren. Bij die glo­bal-for­war­ding ge­noem­de con­fi­gu­ra­tie wor­den al­le DNS-re­quests via TLS naar de up­stream-for­war­der ge­stuurd. In RFC 7858 is daar poort 853 voor ge­spe­ci­fi­ceerd. Poort 53 blijft aan de ge­brui­ke­lij­ke on­ver­sleu­tel­de DNS-re­quests via UDP voor­be­hou­den (of TCP, als de DNS-re­ply te groot is voor een UDP-pak­ket).

Het ip-adres en poort­num­mer moet je met een @ schei­den. De op­tie for­ward­first: no sluit on­ver­sleu­tel­de DNS-re­quests uit. De re­gel for­ward-ssl-up­straem: yes be­paalt dat de Un­bound-ser­ver de re­quests met TLS ver­sleu­telt. Het be­stand tls-for­ward.conf moet in de di­rec­to­ry /etc/ nbound/dns­overtls staan. Zorg er­voor dat je con­fi­gu­ra­tie­syn­taxis klopt (un­bound­check­conf ) en her­start Un­bound.

Om te tes­ten of Un­bound de da­ta zo­als ge­wenst ver­sleu­telt, kun je het com­man­do if­top of net­werk­snif­fers als tc­pdump of Wi­reshark ge­brui­ken. De com­pu­ter waar Un­bound op draait, moet TCP-ver­bin­din­gen naar de bei­de SurfNET-re­sol­vers op poort 853 ope­nen, maar geen op UDP of TCP ge­ba­seer­de op poort 53.

Als de DNS-re­sol­ving het niet doet, ligt dat waar­schijn­lijk aan een fi­re­wall die het ver­keer via poort 853 blok­keert. In der­ge­lij­ke ge­val­len kun je re­sol­vers bij de con­fi­gu­ra­tie toe­voe­gen die met TLS ver­sleu­tel­de re­quests via poort 443 kun­nen ont­van­gen (bij­voor­beeld 199.58.81.218). Zet na het ipadres en het @-te­ken dan 443. Die poort is nor­maal aan het HTT­PS-ver­keer voor­be­hou­den en wordt door fire­walls nau­we­lijks ge­blok­keerd.

Ver­sie 1.6.0 tot en met 1.6.5 van Un­bound is niet ge­op­ti­ma­li­seerd op snel­heid. Hij ge­bruikt bij­voor­beeld bij­voor­beeld een TLS/TCP-ver­bin­ding niet meer­vou­dig, maar opent voor el­ke DNS-re­quest een nieu­we. Dat kun je met de DNS-for­war­der dnsfwd voor­ko­men: die maakt in plaats van Un­bound een TLS/TCP-ver­bin­ding met de DNS-re­sol­ver en houdt die open voor ver­de­re re­quests. Op die ma­nier krijg je ver­ge­lijk­baar snel­le DNS-re­ply's als bij het ge­wo­ne DNS via UDP. Een voor­beeld­con­fi­gu­ra­tie voor dnsfwd staat in het be­stand dnsfwd-dns-over-tls.conf.

Als je als ad­mi­ni­stra­tor een open­ba­re re­sol­ver op poort 443 wilt draai­en en op een in­ter­ne­t­aan­slui­ting een web­ser­ver die die poort al ge­bruikt, kun je de door Da­niel K. Gilm­o­re ont­wik­kel­de hd­de­mux ge­brui­ken. Dat is een pro­to­col-de­mul­ti­plexer voor ip­ver­keer op poort 443. Dan is hd­de­mux bij­voor­beeld in­ge­steld op de ser­ver dns. cm­rg.net en werkt daar­ach­ter een open­ba­re DNS-re­sol­ver op poort 443.

DNS met DNSCrypt

Het be­drijf OpenDNS (dat in­mid­dels on­der­deel is van Cis­co) heeft met DNSCrypt een ei­gen tun­nel­pro­to­col ont­wik­keld voor het ver­stu­ren van DNS-da­ta tus­sen de client (dnscrypt-proxy) en een re­sol­ver. De re­sol­ver wordt met een cryp­to­gra­fi­sche sleu­tel ge­au­then­ti­ceerd om man-in-the-middle­aan­val­len af te we­ren.

DNSCrypt is opens­our­ce en de client dnscrypt-proxy kun je met de pak­ket­ma­na­ger van de mees­te Li­nux- en BSD-sys­te­men in­stal­le­ren. Gra­fi­sche DNSCrypt-clients zijn er voor Win­dows en macOS. Som­mi­ge Cis­co-rou­ters heb­ben DNSCrypt stan­daard al.

Een lijst van open­ba­re DNSCrypt-re­sol­vers staat op de web­si­te van het pro­ject en in het DNSCrypt-pak­ket (als csv-be­stand). Let er daar­bij op dat som­mi­ge van de re­sol­vers een al­ter­na­tie­ve DNS-na­mes­pa­ce ge­brui­ken en daar­om niet al­le do­mei­nen van het of­fi­ci­ë­le in­ter­net-DNS kun­nen re­sol­ven [4]. Der­ge­lij­ke re­sol­vers moet je ver­mij­den. Je kunt ze her­ken­nen als het com­man­do dig ns . niet de­zelf­de root-ser­ver meldt als bij de IANA-con­fi­gu­ra­tie staat.

Op De­bi­an ver­wacht dnscrypt-proxy de DNS-re­quests op het lo­ka­le adres 127.0.2.1 op poort 53. De client geeft die dan ver­sleu­teld aan een DNSCrypt-re­sol­ver door. Hij com­mu­ni­ceert met de re­sol­ver via poort 443 met het ei­gen DNSCrypt­pro­to­col.

Als je de client in­stal­leert, is hij nor­maal ge­spro­ken met­een ac­tief. Dat is op De­bi­an met het com­man­do sys­temctl sta­tus dnscrypt-proxy te tes­ten

Als dat het ge­val is, zet je de lo­ka­le re­sol­ver-con­fi­gu­ra­tie (nor­maal ge­spro­ken

in /etc/sy­s­temd/re­sol­ved.conf) op het adres 127.0.2.1. Voeg bij de con­fi­gu­ra­tie van de DHCP-client /etc/dhcp/dh­client de­ze re­gel toe:

su­per­se­de do­main-na­me-ser­vers 127.0.2.1;

Die re­gel zorgt er­voor dat de DHCP-client de lo­ka­le DNS-re­sol­ver aan het sys­teem toe­voegt en dat de via DHCP ge­kre­gen ser­ver wordt over­schre­ven. Start het net­werk dan op­nieuw op (ser­vi­ce net­work restart).

Zorg er­voor dat in het be­stand /etc/ re­solv.conf de re­gel na­me­ser­ver 127.0.0.1 staat en de DNS-re­sol­ver de al­ter­na­tie­ve DNS-root-zo­ne 'open­nic.glue' ge­bruikt. Of dat het ge­val is, kun je ach­ter­ha­len met het dig-com­man­do:

dig ns .

Als DNSCrypt in­ge­steld is, le­vert het com­man­do bij het deel 'Ans­wer sec­ti­on' niet de ge­brui­ke­lij­ke DNS-root-zo­ne (13 items on­der het do­mein 'root-ser­vers.net'), maar al­leen acht root-ser­vers on­der het do­mein 'open­nic.glue'.

De client maakt maar één en­ke­le ver­bin­ding met de ge­se­lec­teer­de DNSCrypt-re­sol­ver. Als de DNS-re­sol­ver niet be­schik­baar is, mis­lukt de na­me-re­sol­ving. Je kunt de be­schik­baar­heid wel ver­ho­gen door dnscrypt-proxy va­ker te star­ten en Un­bound daar als lo­ka­le re­sol­ver voor te zet­ten. Un­bound scha­kelt snel om naar een an­de­re als een DNSCryp­tre­sol­ver mocht uit­val­len. Om dat in te stel­len, stop en mas­keer je de DNSCrypt­ser­vi­ce eerst, zo­dat hij niet per on­ge­luk op­nieuw start: sys­temctl stop dnscrypt-proxy.ser­vi­ce sys­temctl disa­ble

dnscrypt-proxy.ser­vi­ce sys­temctl mask dnscrypt-proxy.ser­vi­ce sys­temctl stop dnscrypt-proxy.so­c­ket sys­temctl disa­ble dnscrypt-proxy.so­c­ket sys­temctl mask dnscrypt-proxy.so­c­ket

Om meer­de­re in­stan­ties te kun­nen star­ten, is een aan­ge­pas­te sy­s­temd-unit no­dig. In prin­ci­pe wordt in de sy­s­temd-unit met een @-te­ken aan­ge­ge­ven dat de ser­vi­ce va­ker mag star­ten. Een kant-en-klaar be­stand staat in het ar­chief. Zet dat in de di­rec­to­ry /etc/sy­s­temd/sy­s­tem.

Daar­bij zorgt de pa­ra­me­ter -R random er­voor dat dnscrypt-proxy uit de lijst van be­schik­ba­re re­sol­vers een wil­le­keu­ri­ge pikt, die in elk ge­val via IPv4 be­reik­baar moet zijn, on­der­te­ken­de DNS-re­ply's va­li­deert en vol­gens de ex­ploi­tant zelf geen DNSre­quests logt. Met de pa­ra­me­ter -a krijg je van sy­s­temd het lo­ka­le ip-adres waar­op de ser­vi­ce werkt. Om­dat dnscrypt-proxy va­ker start, is op de­ze plek de in­stan­tie­va­ri­a­be­le %i nood­za­ke­lijk: als een nieuw pro­ces start, wordt die ver­van­gen door zijn (nieu­we) loop­back-ip-adres. Op de­ze ma­nier start je de ser­vi­ce op drie loop­back-ip-adres­sen:

sys­temctl start

dnscrypt-mul­ti-proxy@127.0.2.1 sys­temctl start

dnscrypt-mul­ti-proxy@127.0.3.1 sys­temctl start

dnscrypt-mul­ti-proxy@127.0.4.1

Of dat cor­rect werkt, kun je zien met het com­man­do ss -tu­pl | grep do­main.

Stel dan een for­ward-zo­ne-con­fi­gu­ra­tie in zo­dat Un­bound al­le drie de in­stan­ties ge­bruikt. We heb­ben daar­voor het be­stand dnscrypt.conf ge­maakt, dat in de di­rec­to­ry /etc/un­bound/dnscrypt moet ko­men te staan. Daar­mee stuurt Un­bound al­le DNSre­quests naar het loop­back-adres en daar­mee naar de DNSCrypt-proxy's:

ser­ver: do-not-qu­ery-lo­cal­host: no for­ward-zo­ne: na­me: "." for­ward-ad­dr: 127.0.2.1 for­ward-ad­dr: 127.0.3.1 for­ward-ad­dr: 127.0.4.1

Un­bound va­li­deert on­der­te­ken­de DNS-re­quests lo­kaal te­gen het ver­trou­wens­an­ker (trust an­chor) van de IANA-root-zo­ne. Bij DNSCrypt komt het voor dat er re­sol­vers ge­se­lec­teerd wor­den die wel ge­schikt zijn voor DNSSEC, maar een ei­gen root-zo­ne met ei­gen sleu­tels ge­brui­ken. Om er­voor te zor­gen dan Un­bound ook in die si­tu­a­ties va­li­deert, zet je het ver­trou­wens­an­ker van de af­zon­der­lij­ke root-zo­nes ook in de Un­bound­con­fi­gu­ra­tie. Ach­ter­haal dan de key-sig­ning­key (KSK) van de DNSCrypt-re­sol­ver met dig

@127.0.2.1 dns­key | grep 257. Daar is per DNSCrypt-re­sol­ver een re­quest voor no­dig, in dit voor­beeld dus drie re­quests. Zet de DNS­KEY-in­for­ma­tie die het dig-com­man­do op­le­vert in de Un­bound-con­fi­gu­ra­tie met het sleu­tel­woord trust-an­chor: "<KSK>". Ver­vang <KSK> daar­bij door de in­for­ma­tie van de dig-re­quest. Zijn er ver­schil­len­de DNSroot-KSK's, dan voeg je het sleu­tel­woord meer­de­re ma­len toe.

Als je daar­en­te­gen al­leen be­paal­de DNSCrypt-re­sol­vers wilt ge­brui­ken, ko­pi­eer dan het be­stand /usr/sha­re/dns­crypt­proxy/dnscrypt-re­sol­vers.csv naar de di­rec­to­ry /etc/dnscrypt-proxy en ver­wij­der de re­gels die daar­in niet no­dig zijn. Om de lijst uit te pro­be­ren, start je dnscrypt-proxy met de pa­ra­me­ter -L /etc/dnscrypt-proxy/ dnscrypt-re­sol­vers.csv.

Als het werkt zo­als het zou moe­ten, zet je het con­fi­gu­ra­tie­be­stand in /etc/dnscrypt-proxy/dnscrypt-proxy.conf en start je de ser­vi­ce on­nieuw op:

Re­sol­versList /etc/dnscrypt-proxy/—

dnscrypt-re­sol­vers.csv

DNS via Tor

Het ano­ni­mi­se­rings­net­werk Tor biedt een DNS-for­war­ding-func­tie met de naam TorDNS. Daar­bij leidt een Tor-client een DNS-re­quest door het Tor-net­werk naar een Tor-exit-no­de, die dan van de naam een ip-adres maakt. Tor (The Onion Rou­ter) is een net­werk van ver­sleu­teld ver­bon­den com­pu­ters (Tor-cir­cuit). Da­ta van Tor-clients wor­den ver­sleu­teld via meer­de­re tus­sen­com­pu­ters (Tor-re­lay-no­des) ver­stuurd om de her­komst van het com­mu­ni­ca­tie-eind­punt te ver­hul­len.

DNS-re­quests zijn ano­niem en las­tig op ba­sis van met­a­da­ta aan een client toe te ken­nen – bij Tor kan dat al he­le­maal bij­na niet meer om­dat de ge­brui­ke­lij­ke met­a­da­ta ont­bre­ken. Je moet er wel re­ke­ning mee hou­den dat vol­gens een on­der­zoek meer dan 30 pro­cent van de Tor-exit-no­des hun DNS-re­quests door Goog­le-re­sol­vers la­ten uit­voe­ren. Dat maakt het voor Goog­le wel­licht mo­ge­lijk een deel van de re­quests te­rug te her­lei­den naar hun bron.

TorDNS le­vert al­leen IPv4-adres­sen en geen an­de­re DNS-re­cords. Daar­om is TorDNS voor­na­me­lijk ge­schikt om te sur­fen, maar niet om ser­vers te la­ten draai­en. Ook kun je geen DNSSEC-re­quests ge­brui­ken, zo­dat Un­bound on­der­te­ken­de re­ply's niet kan va­li­de­ren. De ex­ploi­tan­ten van kwaad­wil­len­de Tor-exit-no­des kun­nen DNS-re­ply's dus on­ge­merkt ver­val­sen.

Om DNS-re­quests via Tor te la­ten lo­pen, moet de Tor-ser­vi­ce ge­ïn­stal­leerd en ge­start zijn: su­do apt in­stall tor. Scha­kel in de Tor-con­fi­gu­ra­tie /etc/tor/tor­rc de DNS-for­war­der-func­tie in – de re­gel die met DNSPort be­gint en de bei­de daar­on­der moe­ten er als volgt uit­zien:

DNSPort 9053 Au­to­mapHost­sOnRe­sol­ve 1 Au­to­mapHost­sSuf­fixes .exit,.onion

De Tor-soft­wa­re ver­wacht DNS-re­quests op de UDP-poort 9053. Her­start de Tor-dienst en test hem:

dig -p 9053 @127.0.0.1 +noed­ns ct.nl

Het dig-com­man­do stuurt de re­quest voor het do­mein ct.nl naar het lo­ka­le ip-adres 127.0.0.1 en poort 9053. De Tor-dienst moet in de ans­wer-sec­tie net als voor­heen het ip-adres 213.207.93.230 te­rug­le­ve­ren. DNS-re­quests zijn met een lo­ka­le DNS­ca­che snel­ler te ma­ken. Voor Tor stel je Un­bound net zo in als bij de for­war­ding­voor­beel­den voor DNS-over-TLS of DNSCrypt. Een kant-en-klaar be­stand met de naam tor-for­ward.conf staat in het down­lo­a­dar­chief. Zet dat in de map /etc/ un­bound/tordns.

Per­for­man­ce

De snel­heid van de DNS-re­sol­ving is be­lang­rijk voor de to­ta­le snel­heid van een in­ter­ne­thost om­dat DNS de ba­sis is voor al­le net­werk­com­mu­ni­ca­tie. Web­si­tes zijn op­ge­bouwd uit veel af­zon­der­lij­ke ele­men­ten die van ver­schil­len­de ser­vers moe­ten ko­men, en voor elk ele­ment is dan een DNS-re­quest no­dig. Daar­om zijn zelfs de klein­ste la­ten­ties van be­lang en is een ver­ge­lij­king tus­sen de gang­ba­re DNS-tech­niek en die met ver­sleu­tel­de me­tho­den van be­lang.

Bij de re­sul­ta­ten moet je er re­ke­ning mee hou­den dat niet al­le nieu­we im­ple­men­ta­ties ge­op­ti­ma­li­seerd zijn. Maar bij de gang­ba­re DNS-re­quests is te zien dat DNS-over-TLS on­danks ver­sleu­te­ling en TCP-ver­bin­din­gen mee kan met het klas­sie­ke DNS.

Bij een eer­ste test moesten de ver­schil­len­de Un­bound-con­fi­gu­ra­ties 1000 do­mei­nen van de Alexa-top­lijst om­zet­ten naar de bij­be­ho­ren­de IPv4-adres­sen. Om ca­che-ef­fec­ten uit te slui­ten, heb­ben we vóór el­ke me­ting de Un­bound-ca­che leeg­ge­maakt. De test le­vert daar­om al­leen de snel­he­den van de ver­schil­len­de trans­port­pro­to­col­len en ver­sleu­te­lin­gen.

Bij een twee­de test heb­ben we 1000 DNS-re­quests van een ty­pisch kan­toor­net­werk af­ge­speeld en met tc­pdump ge­re­gi­streerd. In dat sce­na­rio werd de ca­che al­leen voor het star­ten van de 1000 re­quests leeg­ge­maakt, zo­dat daar van ge­pro­fi­teerd kan wor­den – en de ge­tal­len la­ten zien dat dit loont. (nkr)

Com­pu­ters waar­op Un­bound zijn DNS-pak­ket­ten ver­sleu­telt, ope­nen TCP-ver­bin­din­gen op poort 853 en niet op 53.

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.