VPN-DNS versus DoH in die blaaier: wat ’n lektoets jou nie kan vertel nie

Die lektoetsblad sê jou DNS is in orde, die blaaierkenteken sê veilig, en die interne wiki laai steeds nie. Al drie kan gelyk waar wees, want die adres van ’n resolveerder is nie dieselfde ding as die beleid wat dit gekies het of die pad wat die navraag gevolg het nie. Wat mense ’n DNS-lek noem, is eintlik een vraag: watter resolveerder het die naam ontvang, en was daardie keuse opsetlik? Om dit uit te sort verg drie kontroles, en net die laaste een behels die verandering van ’n instelling.

Mite een: die kenteken noem jou resolveerder

’n Lektoets los ’n toetsnaam op en rapporteer die adres wat geantwoord het. Dit rapporteer nie die beleid wat daardie resolveerder gekies het nie, en wanneer die navraag in DNS oor HTTPS toegedraai is, kan ’n middelkas op die pad die naam glad nie sien nie. Twee heel verskillende masjiene lewer dieselfde gerusstellende kenteken: een waar die VPN 10.8.0.1 gestoot het en die blaaier dit gebruik, en een waar die blaaier die stelsellys geïgnoreer en die naam deur die tonnel na sy eie versleutelde verskaffer gestuur het.

Die onderskeid maak saak die oomblik wanneer ’n private naam misluk. In die eerste opset antwoord die VPN-resolveerder vir die korporatiewe sone; in die tweede het die blaaier hom nooit gevra nie, so die kort gasheernaam los nie op nie en die mislukking lyk soos ’n stukkende VPN. Die kontrole is nie nog ’n lektoets nie, dit is ’n opsoek teen ’n naam wat net een resolveerder ken.

Mite twee: die blaaier verlaat die tonnel

DNS kies ’n adres, roetering dra die verbinding, en die twee is aparte lae. ’n Navraag wat na ’n openbare DoH-verskaffer gestuur word, is steeds TCP poort 443 na ’n roeteerbare adres. As jou roetetabel die verstekroete in die tonnel instuur, gaan daardie navraag ook deur die tonnel. Die resolveerder se handelsmerk bepaal nie die pad nie.

Wat blaaier-DoH verander, is die ontvanger van die name. Dit is ’n werklike privaatheidsbeslissing en ’n werklike beleidsbeslissing, maar dit is nie ’n roetering-omseiling nie. As jou vereiste is dat name by die VPN-operateur bly, dan faal ’n versleutelde navraag na iemand anders daardie vereiste terwyl dit steeds die tonnel vir die werklike verbinding gebruik.

Mite drie: elke VPN oorheers elke blaaier

Veilige DNS in ’n blaaier het modusse, nie ’n skakelaar nie: af, ’n verstekverskaffer met terugval, ’n pasgemaakte sjabloon, of ’n beleid wat deur die bedryfstelsel of die organisasie afgedwing word. Die terugvalgeval is die een wat ongereelde verslae oplewer. Wanneer die versleutelde eindpunt onbereikbaar is, kan die blaaier na die stelselresolveerder terugval, so dieselfde skootrekenaar los ’n private naam Maandag korrek op en Dinsdag nie.

Terselfdertyd stel die meeste VPN-kliënte die stelselresolveerder in wanneer die verbinding opkom en herstel die vorige een wanneer dit val. ’n Blaaier met ’n pasgemaakte versleutelde resolveerder merk daardie herstel glad nie. Dit is hoekom dieselfde profiel op twee skootrekenaars anders optree en hoekom resolv.conf korrek lyk terwyl die blaaier steeds iemand anders vra.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Voer dié uit terwyl jy verbind is, let op watter domeine elke resolveerder opeis, en vergelyk dit met wat die blaaier oor sy eie modus rapporteer. Mozilla se DoH-dokumentasie is ’n redelike beskrywing van hoe ’n blaaier se verstek- en terugvalgedrag veronderstel is om te werk.

Die beslissing het drie insette, nie een nie

Private name, operateurvertroue en bereikbaarheid bepaal die regte reëling. Name wat net die VPN-resolveerder ken, dwing gesplete DNS af: die private agtervoegsel gaan na die gestoorde resolveerder, alles anders volg watter beleid jy ook al vir openbare name gekies het. Operateurvertroue bepaal of openbare name ook na daardie resolveerder of na ’n aparte diens moet gaan. Bereikbaarheid bepaal of jou gekose versleutelde resolveerder hoegenaamd op hierdie netwerk bruikbaar is.

Nie een van hierdie rye is ’n universele aanbeveling nie. ’n Resolveerder wat deur die VPN bedryf word, konsentreer waarnemings by daardie operateur; ’n aparte diens voeg nog ’n ontvanger van navraagname by. Nie een van die reëlings bewys iets oor bewaring nie, tensy jy die beleid lees.

Skryf die beslissing per profiel neer, want hierdie instellings dryf. ’n Profiel wat verlede maand ’n resolveerder gestoot het, stoot vandag dalk niks, en die blaaier sal met graagte ’n ou pasgemaakte eindpunt hou wat steeds antwoord. Wat in die nota hoort, is die resolveerder se adres, die agtervoegsels wat dit besit en die blaaier se modus, nie die handelsmerk van die diens nie.

Toets die beleid wat jy dink jy opgestel het

Toets op naam, nie op kenteken nie. Los ’n openbare naam en ’n private naam deur die stelselresolveerder op, en herhaal dit dan in die blaaier met sy eie veilige DNS-instelling op die modus wat jy van plan is om te gebruik. As die private naam net in die blaaier misluk, het jy die ontvanger-wanverhouding gevind sonder om enige VPN-instelling te raak.

Herverbind dan en kontroleer herstel, want dit is waar oordragfoute woon: ontkoppel, bevestig dat die vorige resolveerder teruggekeer het, herverbind, bevestig dat die gestoorde een terug is. Toets laastens ’n blaaier met ’n bestuurde beleid as jy een het, want daardie modus kan jou verandering heeltemal weier en stilweg die vorige resolveerder hou.

Begin met die naamruimtevraag en jy sal die meeste hiervan vermy. As die masjien interne name moet bereik, is die blaaier se versleutelde resolveerder ’n beslissing oor net die openbare helfte, en die private helfte bly by wat die VPN ook al gestoot het.