Android 13 lijkt ondersteuning voor dns-over-https op systeemniveau te krijgen

Android 13 krijgt mogelijk ondersteuning voor dns-over-https op systeemniveau. Nu nog ondersteunt Android die vorm van dns-versleuteling alleen in de Chrome-browser. Ondersteuning voor dns-over-tls is er op systeemniveau sinds Android 9.

XDA Developers zag de wijziging op de site van het Android Open Source Project: "Default enable DoH feature in T", waarbij T de volgende letter van het alfabet is na Android 12 Snow Cone. T staat overigens vermoedelijk voor Tiramisu. Een releasedatum voor Android 13 is er nog niet. Sterker nog, een defintieve releasedatum voor Android 12 is er ook nog niet, maar volgens XDA komt die mogelijk op 4 oktober uit.

Dns-over-https verschilt van dns-over-tls in de voornaamste zin op het gebied van welke poort gebruikt wordt voor de dns-verzoeken. Bij DoH gaat deze door poort 443, waar al het overige https-verkeer ook doorheen gaat. Een partij die versleutelde dns-verzoeken wil blokkeren, zal dat dus moeilijk kunnen doen zonder al het https-internetverkeer te blokkeren. Dns-over-tls gebruikt poort 853 voor de dns-verzoeken, waardoor het makkelijker tegen te gaan is.

Volgens Cloudflare is DoH dan niet per definitie beter dan DoT. "DoT geeft netwerkbeheerders de mogelijkheid om dns-verzoeken te controleren en te blokkeren, wat belangrijk is voor het identificeren en stoppen van kwaadaardig verkeer." Voor de privacy van de individuele gebruiker zou DoH wel beter zijn.

Tweakers schreef in 2019 een uitgebreid achtergrondverhaal over dns-over-https, waarin de voors en tegens behandeld worden.

Reacties (88)

[mutley69]

DoH is een trojaans paard - zowel voor malwaremakers als voor machtswellustelingen zoals Google, Amazon, Microsoft, Apple en ALLE sociale media - is DoH een natte droom. Je schakelt veel mogelijkheden van controle door de gebruiker uit - je degradeert uw gebruiker tot slaaf.

[GekkePrutser]

Het is in Amerika zeer populair omdat de ISP's daar hun eigen gebruikers tracken met DPI. Een beetje extra winst bijsnoepen met de data van hun klanten . Dat mag hier helemaal niet, gelukkig. Dat ze zich met DoH nog dieper in de armen van big IT storten, boeit ze blijkbaar minder. Weer een stukje decentralisatie weg . Ondertussen loopt een kern protocol van het internet verstoppertje te spelen om een probleem op te lossen dat veel beter gewoon juridisch aangepakt kan worden.

Ik vind het ook heel vervelend om de controle over mijn DNS kwijt te zijn. Mijn pihole is een groot goed en ik gebruik hem ook als lokale DNS server voor lokale servers.

Maar het probleem is wel: wat doe je er aan, met name op mobiel? Elk appje kan nu al zijn eigen DoH resolver opzetten. Omdat het niet te onderscheiden is van ander https verkeer, kan je het niet blokkeren zonder MITM achtige trucjes en die zijn op Android vrijwel onmogelijk nu vanwege certificate pinning en de onmogelijkheid sinds Android 7 om een eigen root CA in de "System" lijst te stoppen. En de "User" lijst kan door elke app genegeerd worden. Dus dat wordt ook steeds lastiger.

Misschien is een DoH instelling op systeem niveau dan toch wel slim omdat je dan tenminste nog je eigen kan instellen en de meeste apps hier uit gemak gebruik van zullen maken.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 20:55]

[Bein Stuyle]

Vaak komt in de URL wel "/dns-query" te staan bij de, of staat het woord "DNS" wel ergens in vermeld.

Hier staat alvast een mooie lijst om toe te voegen aan een block list:
https://github.com/curl/curl/wiki/DNS-over-HTTPS

[GekkePrutser]

Ja maar hoe wil je de URL gaan zien als het gaat om een TLS verbinding?

De DNS naam zie je wel maar de rest van de URL niet.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 20:55]

[Bein Stuyle]

Ja inderdaad, je kan thuis altijd wel een SSL decryptor in-line tussen zetten die tegelijkertijd ook webfiltering kan doen.

Wij passen dit toe op het werk om bepaalde categorieën te decrypten en tegen te houden. Dat werkt zeer goed. Maar alle gebruikers moeten wel het private certificaat aanvaarden in hun browser uiteraard.

Voor mobiel data gebruik is dit waarschijnlijk geen optie, tenzij er op Android ook decryptor-apps bestaan...

[Rob Coops]

Misschien is een DoH instelling op systeem niveau dan toch wel slim omdat je dan tenminste nog je eigen kan instellen en de meeste apps hier uit gemak gebruik van zullen maken.

Mooi idee, maar het zijn juist de apps die er geen gebruik van zullen maken die daar een (niet zo) goed reden voor hebben. Denk je niet dat als ik malware zou schrijven dat ik dan de moeite zou nemen om mijn eigen resolver te gebruiken in plaats van de systeem resolver? Of als ik Google/FB of een van de andere in jouw ogen slechte bedrijven ben dat ik de user instellingen zou negeren voor bepaalde lookups?

Het is niet alleen Amerika dat DPI toestaat het zijn met name landen waar de overheid een stuk minder vertrouwen heeft in de burgers waar dit ook toegepast wordt om burgers met verkeerde ideeën te identificeren. En juist in deze landen in een oplossing zo als DoH een geweldige oplossing omdat het voor de zittende macht een heleboel lastiger wordt om mensen op deze manier in de gaten te houden.
En als ik moet kiezen tussen een gewelddadige dictator of Facebook dat mijn DNS verzoeken kan zien dan weet ik wel wie ik liever die data aan overhandig.

Veel mensen zijn onredelijk bang voor bedrijven als Google en Facebook omdat ze data verzamelen over hen. Iedereen doet dat tegenwoordig, of het nu de Wit Russische of Nederlandse overheid is of Albert Hein allemaal willen ze zo veel mogelijk van je weten omdat dit soort profielen helpen met het bepalen hoe men dingen aan je kan verkopen, dan wel of je de regeltjes wel netjes na leeft of welke politieke stroming je toe behoort en wat de redenen daar achter zijn zodat men kan bepalen hoe dat (in de betere landen zonder dwang) aangepast kan worden mocht dat nodig zijn.
Google en Facebook hebben er weinig aan om jouw data aan alles en iedereen te verkopen. Die data is namelijk waar ze hun geld mee verdienen. Door het aan andere te geven lopen zij het risico minder geld er mee te kunnen verdienen omdat het nu niet langer informatie is maar kennis. Zij bieden dus alles en iedereen aan om via hun gebruik te maken van deze informatie maar het verkopen van deze informatie is iets wat ze maar zeer weinig doen en als ze het doen gaat het om data die niet al te moeilijk te verkrijgen is (en kost het als nog een fortuin)

De enige uitzondering op deze regel is dat men dankzij lokale wetten de data vaak wel moet delen met de diensten, en omdat men nu eenmaal allemaal in Amerika huist zijn dat de Amerikaanse diensten. Waardoor er een kans bestaat dat dankzij de goede samenwerking tussen bepaalde landen de data of een deel er van ook in handen zal vallen van bijvoorbeeld de Nederlandse diensten.

Al met al is de angst voor de grote tech bedrijven grotendeels overtrokken, ja men weet een heleboel meer van je dan je lief is maar men weet ook maar al te goed dat dat het geen is waarmee ze hun geld verdienen en zal er dus alles aan doen om die data geheim te houden. Natuurlijk mogen andere er gebruik van maken maar het wordt ze moeilijk gemaakt om een vergelijkbaar profiel op te bouwen om zo te voorkomen dat de informatie aan waarde verliest en eigenlijk iedereen wel via hun diensten moet werken om er gebruik van te maken.

[GekkePrutser]

Ik denk niet dat je mijn bedenkingen helemaal snapt. Ik ben het er wel mee eens dat ik er (vooralsnog) weinig nadeel van zal ondervinden dat alles verzameld wordt door FB en Google.

Maar daar gaat het me niet (alleen) om. Ik vind het uberhaupt slecht dat ze dit doen, en het geeft een verelend gevoel van overal bij stilstaan wat ik doe, want alles wordt opgesnoept door het big data monster. Dat inlichtingendiensten meesnoepen is inderdaad extra bezwaarlijk.

Maar ook het feit dat ik geen slaaf wil zijn van het neofeodaal corporatisme. Dat de grote databoeren uit de goedheid van hun hart nu weinig kwaads uithalen, zegt niks over de toekomst. Je zag met het hele Cambridge Analytica al de scherpe kantjes daarvan opduiken. Er werd geen gebruik gemaakt van herleidbare data van jou of mij, maar er werd wel heel fijntjes gebruik gemaakt van de geldende publieke opinie om het debat te sturen en zo de Brexit en Trump door te drukken. Hele grote gevolgen.

Ik doe een hoop moeite om zoveel mogelijk hun hongerige klauwen te blijven en zal dat ook blijven doen. Helemaal lukken doet dat zeker niet maar het is de moeite wel waard. En ik ben zeker niet de enige die er zo over denkt, er is een behoorlijke basis die onder andere tot GDPR en het recht op vergeten heeft geleid.

En dit wordt door Amerikanen echt wel voornamelijk om hun eigen doeleinden gepusht. Amerikanen geven er doorgaans sowieso weinig om wat in de rest van de wereld gebeurt. Zie hoe ze zelfs een van hun eigen gebieden als Puerto Rico als een baksteen laten vallen als er een serieuze aardbeving gebeurt. Trump deed er ff een photo op door wat WC rollen te gooien maar serieuze hulp ho maar, en een week later is het alweer vergeten. Alle oorlogen en "bevrijde" volken ging het ze meer om geopolitieke doeleinden dan een daadwerkelijke interesse in het welvaren van die mensen (zie nu ook weer hoe ze Afghanistan als een blok laten vallen).

En echt effectief zal het ook niet zijn. Die regimes zullen dan gewoon HTTPS verbieden. Je ziet dit al steeds meer met bijvoorbeeld Chinese sites, externe sites van een bedrijf zijn gewoon HTTPS standaard, maar de .cn domeinen serveren alleen HTTP. Op een soort zieke manier van 'kijk maar, we hebben niks te verbergen'.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 20:55]

[bvdli]

DoH biedt je als gebruiker veel meer beveiliging. Het biedt data-integriteit, privacy door middel van encryptie, je weet met welke server je praat en beschermt je tegen man-in-the-middle attacks.
Als je de DNS servers van genoemde partijen niet vertrouwt kun je andere servers gebruiken, of zelf je DoH DNS server draaien.

[anboni]

De cynicus in mij vraagt zich af of dit niet gewoon een poging van Google is om zaken als pihole te omzeilen en zo meer advertenties te kunnen pushen.

[bytemaster460]

Maar je mag toch wel je eigen DNS-server kiezen? Pihole ondersteunt dit gewoon.

[jcbvm]

Het hele ding is juist dat je dit niet per device wilt doen… bij sommige apparaten is het wijzigen zelfs flink dichtgetimmerd.

[bytemaster460]

Thuis stel je dat toch gewoon via DHCP in?

[gedonie]

Ja en nee. Dat zou voor de meeste apparaten moeten werken. Echter zijn er ook, waaronder de chromecast, die de DNS servers hard hebben ingesteld. Die gebruikt dus niet wat de dhcp server zegt.

[bytemaster460]

Ja, klopt, maar daarvoor werkt Pihole dan nu ook niet (tenzij je het DNS-verkeer omleidt). Het gebruik van DoH gaat hier niets aan veranderen.

[latka]

DoH omleiden lukt niet lekker (zeker niet als er ook certificate pinning gebruikt wordt wat tegenwoordig ook al veel te veel gebeurt).

[JeroenED]

Bij mij heb ik een aantal DNS-servers gewoon geblokkeerd. Dit geeft ook als gevolg dat DOH voor die provider is geblokkeerd. Een dns lookup naar dns.google verwijst gewoon naar 8.8.8.8 en 8.8.4.4. is iets dat ze volgens mij niet snel zullen aanpassen.

Probleem daarbij is natuurlijk wel als er een eigen DNS server is opgezet of andere dns dan google of cloudflare is ingesteld door de app

[Z80]

alle server van Google zijn DoH.
dit is een van de probleem. blokkeren van DoH is dan ook zo goed als onmogelijk.
En aangezien elke app of browser een dns buiten het os kan ge/misbruiken kan dit nog eel eens een probleem gaan worden.

[Verwijderd]

Gelukkig heeft nextdns deze optie,

Blokkeer bypass-methoden
Voorkom of belemmer het gebruik van methoden die kunnen helpen om NextDNS-filtering op het netwerk te omzeilen. Dit bevat VPN's, proxy's, Tor-gerelateerde software en gecodeerde DNS-providers.

[pe0mot]

Helaas kunnen ze DOH niet blokkeren.

[Verwijderd]

Waarom zou dat niet kunnen?

[pe0mot]

Poort 443 met https is dezelfde poort met het zelfde protocol als je normale webbrowser.
Blokkeren zal ook browsen blokkeren.

[Verwijderd]

Domein gewoon blokkeren? Van het DOH domein

[ari3]

Domein gewoon blokkeren? Van het DOH domein

Ja, dat kan, maar Google zal DoH op een continu veranderde hostname hostname hosten, bijvoorbeeld 92sjkhdchv98y.google.com en een uur later weer 2x8s8klsl34.google.com. Als je google.com blokkeert werkt een deel van de services van Google niet meer.

[Verwijderd]

Huh?

https://dns.google/dns-query

https://dns.google/resolve?

Enkel dit blokkeren ben je klaar?

[pe0mot]

Correct, indien uniek.

[Jerie]

Maar je hoeft niet al het verkeer op port 443 te blokkeren.

[urf]

Als je de Google dns servers helemaal blokkeert, pakt hij volgens mij alsnog de ingestelde dns.

Maar kan zijn dat dit inmiddels is aangepast, dus zou je even moeten testen dan.

[pe0mot]

Klopt, de juiste poort dicht zetten op de router werkt prima bij alle mij bekende apparatuur.
Heel veel meuk staat standaard op 8.8.8.8, en gaat de router gebruiken als je de DNS poort blokkeert.
Bypass via DOH blijft echter altijd mogelijk.

[glatuin]

Erg vervelend, heb het opgelost middels iptables in de router. Ik vervang 8.8.8.8 door mijn eigen DNS. Werkt goed trouwens maar niet weggelegd voor de minder technische medemens.
Alleen blokkeren bleek niet goed te werken trouwens, dan zoekt de chromecast een alternatief en niet perse diegene die jij hebt ingesteld. Ik heb dus 8.8.8.8 geforward naar mijn eigen dns (ik heb geen PiHole wel Adguard Home). Nu zien de Google devices een werkende 8.8.8.8 dns terwijl dat mijn eigen servertje is. Geweldig pingtijden nu ook

[Reactie gewijzigd door glatuin op 26 juli 2024 20:55]

[Verwijderd]

Erg vervelend, heb het opgelost middels iptables in de router. Ik vervang 8.8.8.8 door mijn eigen DNS. Werkt goed trouwens maar niet weggelegd voor de minder technische medemens.

De minder technische medemens houdt zich er ook niet echt mee bezig en vind het best zolang alles werkt. De gemiddelde consument gebruikt bijvoorbeeld al geen Pi-Hole, laat staan alternatieve DNS servers.

[Lawrentium]

Je komt een heel eind door poort 53 te forwarden naar je eigen DNS server/pi-hole.

Dan rest je alleen nog poort 853 outbound volledig te blokkeren (DoT) en DoH server IP blocklists te gebruiken voor poort 443 outbound.

[JackBol]

Als je geen volledige controle over een apparaat kan krijgen moet je die sowieso niet kopen.
Je kiest hiermee zelf voor een Google lockin. Er zijn voldoende alternatieven voor een Chromecast.

[wauwwie]

Daarom routeerd mijn firewall alle DNS request die niet vanaf mijn Pihole lopen naar Pihole zelf. Alle apparaten die een eigen dns server hebben ingesteld gaan zo toch via Pihole.

Maar het is wel jammer dat je dit moet doen. DoH is daarmee ook niet tegen te houden, tenzij je een apparaat helemaal toegang tot internet ontzegt of proxies met whitelist gaat bijhouden.

[7ven]

Je router doet helemaal niks (anders) met DNS over HTTPS requests. Dat is het idee achter DNS over HTTPS, je weet niet wanneer er een DNS request in de HTTPS zit, die is versleuteld.

Deze techniek is zowel een mooie stap vooruit op gebied van privacy (bijv. via wifi verbonden met een hotspot) als ook een stap achteruit qua filtering van DNS meuk (vaak gebruikt een bedrijf/virusscanner) dit ook om bijv. NFSW te filteren (wat gelijk ook een hoop digitale elende voorkomt).

[rene_fb]

Je kunt wel de DoH service op IP niveau blokkeren, dus dat de DoH server niet meer bereikbaar is, en hopen dat het device dan de DNS server van de DHCP overneemt.

[pe0mot]

Maar DoH is vaak een url, waar heel veel wisselende IP nummers aan kunnen hangen.

[Verwijderd]

Maar DoH is vaak een url, waar heel veel wisselende IP nummers aan kunnen hangen.

Klopt, daarom kan je gelukkig in veel routers ook gewoon een domeinnaam invoeren die je wilt blokkeren. Wil je google DNS's blokkeren, klop je gewoon dns.google in, en resolved deze niet langer.

[pe0mot]

Klopt, maar je kan niet meer generiek alle SMTP blokkeren.
Chinese junk kan dus een phone home starten met een eigen DNS zonder dat je hier grip op hebt.
Monitoren en dan pas blokkeren als het te laat is. Tenzij je IP en URL blocklists (zoals Spamhaus) kan toepassen, maar dat is voor de meeste routers een maatje teveel.

[Reactie gewijzigd door pe0mot op 26 juli 2024 20:55]

[JackBol]

ook een stap achteruit qua filtering van DNS meuk (vaak gebruikt een bedrijf/virusscanner) dit ook om bijv. NFSW te filteren (wat gelijk ook een hoop digitale elende voorkomt).

Bedrijfsassets zitten (als je je zorgen maakt over digitale ellende) onder een centrale MDM, en daarmee kun je DoH voorkomen voor whitelisted domains.

[rscheper]

Maar zelfs dan zijn er apparaten die een adres gebruiken staat ingesteld op het apparaat zelf. Dus die omzeilen de DNS in je netwerk. En dus wordt de Pi-Hole wel eens omzeild.

[bytemaster460]

Ja, maar daar verandert DoH toch niets aan? Dat gebeurt zonder DoH nu ook al.
Overigens kun je dit in je router gewoon ondervangen door het DNS verkeer om te leiden en alsnog via PiHole te laten lopen.

[NielsFL]

Mag wel, maar menigeen zal dat niet snappen. Nadat Firefox DoH standaard aanzette voor Amerikanen regende het bij ons e-mail dat allerlei zaken niet meer werkte.

DoH is prima. Maar de via DHCP uitgedeelde DNS zou niet genegeerd mogen worden.

[GekkePrutser]

Dat wel maar self signed certificaten zijn tegenwoordig drama op mobiele apparaten. Apps kunnen kiezen of ze ze toestaan of niet.

[evonck]

Je kunt je Pi-Hole instellen als eigen DNS-resolver toch? (mag hier helaas geen Youtube links plaatsen) maar heb dit zelf gedaan op die manier.
Is dan het hele euvel niet omzeild?
Misschien denk ik te makkelijk.

[Reactie gewijzigd door evonck op 26 juli 2024 20:55]

[bytemaster460]

Dat is het hele idee van PiHole...
Echter, met DoH wordt dit wel wat lastiger, maar ik ga ervan uit dat de makers van Pihole dit uiteindelijk wel weten op te lossen.

[evonck]

Had het niet over pihole als DNS-filter/blocker (de standaard manier), maar dat hij zijn eigen DNS recursive server wordt. Dit doe je door Unbound te installeren (met bijbehorende poort openen). Kan het even niet anders uitleggen. Maar wat hij doet is de stap naar de intermediate servers overslaan, dus niet een externe DNS als cloudflare of google servers oid, dit uncheck je in je Pihole settings.
Je verwijst hem vervolgens naar je local host: 127.0.0.1 (+ #gekozen poort) en bouwt na verloop van gebruik ook nog uiteindelijk zijn eigen cache op.
Dat is de Full-recursive DNS Server vs de standard Pihole DNS-Filtering.

[davekok]

Gaat denk ik vooral om de Amerikaanse markt.

Persoonlijk vind ik het wel interessant als de technische laag volledig van de applicatie-laag gescheiden wordt. Biedt weer allemaal mogelijkheden tot innovatie. Waaronder een private cluster van je eigen apparaten over het internet.

Op de korte termijn zal het allemaal niet direct interessant zijn. Maar goed dat is het kip en ei probleem.

[goarilla]

Persoonlijk vind ik het wel interessant als de technische laag volledig van de applicatie-laag gescheiden wordt. Biedt weer allemaal mogelijkheden tot innovatie.

Kan je dat wat verduidelijken ?

[davekok]

Op dit moment hebben we de OSI-stack. Wat ik voor mij zie is dat deze in tweeën gaat. En software zich of alleen met de onderkant bezig houdt of alleen met de bovenkant. Maar dat niet steeds alles op een hoop wordt gegooid. HTTP/3 is hier eigenlijk al een start van.

[goarilla]

Maar hoe wordt alles op een hoop gegooid ? End user software moet zich toch niet bezig houden met ARP/Ethernet/IP/TCP/UDP/etc ..., dat doet de kernel toch ? De software zelf gebruikt toch socket API's en/of abstracties daarbovenop (TLS/SSL libraries, ....). Wat wil jij dan concreet nog gescheiden zien ?

[davekok]

Software gaat steeds meer richting asynchroon. De huidige socket API is niet vanuit asynchroon bedacht. Het is veel makkelijker als elk programma gewoon een IP-adres krijgt (of intern IP-adres) en vandaar alles door libraries wordt afgehandeld. Toevallig weer eens de afgelopen weken mee bezig geweest https://github.com/davekok/stream.

[GertMenkel]

Android heeft al lang een secure DNS optie, die werkt momenteel met DNS over TLS. Ze hebben nu alleen het protocol gewijzigd naar iets dat vaker wordt gebruikt.

[Azbest]

Jup, dat is exact waar dit om gaat. Maar de betere firewalls hebben al oplossingen om het te blokkeren.
https://forum.opnsense.org/index.php?topic=19349.0

Dan heb je natuurlijk nog je mobiele verbinding, daar is nu nog niet veel aan te doen. Ik vermoed dat er op de betere android roms wel een mogelijkheid komt DoH en dergelijken te blokkeren.

[singingbird]

Wat betekent dit concreet voor mijn pihole? Als alle DNS verzoeken versleuteld verstuurd worden, wordt mijn pihole dan waardeloos?

[bytemaster460]

Nee, de DNS-query is versleuteld, maar die kan je nog steeds via je pihole laten lopen.

[Tom Paris]

Als Android een directe TLS verbinding legt met 8.8.8.8 zonder DNS query gaat die volkomen langs je PiHole hoor... DoH onderscheppen werkt alleen als voordat de TLS verbinding gelegd wordt, er een DNS query gedaan wordt voor het IP van de DoH server. Je zult dus in je firewall verkeer op poort 443 naar bekende DoH servers moeten gaan blokkeren. Dat is exact het probleem wat in het artikel wordt genoemd.

[bytemaster460]

Er staat toch nergens dat er standaard 8.8.8.8 (of een ander veelgebruikte DNS-server) gebruikt gaat worden?

[Tom Paris]

Het hele idee van DoH en DoT is juist om lokale DNS servers te negeren. Alles wat nu DoH/DoT doet, doet dat door direct te verbinden met een DNS server buiten het lokale netwerk (Google, Cloudflare, Quad 9, etc).

[Reactie gewijzigd door Tom Paris op 26 juli 2024 20:55]

[bytemaster460]

Het idee erachter is dat DNS-queries versleuteld worden verstuurd. Dat kan nog steeds als jij de DNS-verzoeken via je lokale PiHole laat lopen.
Dat Google je mogelijk geen keuze meer laat heeft niets met DoH of DoT an sich te maken.

[Tom Paris]

Maar het effect is alsnog dat je Android telefoon z'n DNS requests niet meer naar je PiHole stuurt tenzij je maatregelen neemt in je firewall om DoH/DoT verkeer te blokkeren.

[bytemaster460]

Dat kan ik uit het artikel niet opmaken. Ik zie nergens staan dat je zelf geen vat meer hebt op welke DNS-servers je wil gaan gebruiken.

[Tom Paris]

Default gaat steeds meer op DoH/DoT, zoals het artikel ook stelt. Ook al heb je er zelf vat op, je moet dus op elk device op meerdere punten DoH/DoT actief disabelen of naar je eigen DNS server sturen. Op systeemniveau, op applicatieniveau... Dat lukt je op een pc en telefoon nog wel, maar je smart tv, Chromecast etc. gaan die vrijheid niet allemaal geven. Alleen als je dus actief DoH/DoT blokkeer in je firewall kun je garanderen dat alles in je netwerk gebruik maakt van je PiHole zonder elk device individueel te moeten managen.

Daarnaast, als je op elk device handmatig DoH/DoT moet uitschakelen of omleiden naar je eigen DNS server, wat weerhoud een slim kind er dan van om het weer aan te zetten? En zo parental filters op je PiHole te omzeilen?

[Cyb]

De default staat op DoH/DoT omdat dat voor de meeste gebruikers in de VS gewoon beter is kwa privacy. In de VS verkopen sommige ISPs namelijk DNS geschiedenis van klanten aan derden. Het uitgangspunt is dat Google dat niet zo snel zal doen, tenzij ze klanten willen weghalen van de naam Google en alles wat daar mee te maken heeft. Ook is het gemakkelijker om in censurende landen toegang te krijgen tot websites.

Wel ben ik het met je eens dat het by default negeren van DNS instellingen die door een DHCP server zijn afgegeven, storend kan zijn voor beheerders. Maar dat probleem je sowieso al, los van of DoH/DoT op systeemniveau geimplementeerd wordt. Chrome, Edge en Firefox hebben namelijk ook DoH support.

[bytemaster460]

Maar het negeren van DNS-instellingen staat toch helemaal los van de inzet van DoH? DoH kan prima werken met een DNS-server naar keuze die het ondersteunt. Dat bedrijven als Google en mogelijk anderen misbruik maken van de situatie en eigen DNS-server gaan raadplegen is kwalijk maar heeft niets met de implementatie van DoH te maken.
Of dit in Android wel of niet gebeurt kan niet worden opgemaakt uit het artikel.

[Cyb]

Ik weet niet of we langs elkaar heen spreken, ik ben het namelijk eens met je reacties in dit draadje.
In mijn laatste alinea bedoel ik dat DoH voor netwerkbeheerders storend kan zijn, omdat ze per device wijzigingen moeten maken indien ze DNS queries van alle apparaten volledig in beheer willen hebben.

DoH op zichzelf heeft inderdaad niets te maken met het wel of niet negeren van DNS instellingen. Maar in DoH implementaties gebeurt dat meestal wel. Dat komt omdat DHCP zover ik weet nog geen extensie heeft voor DoH, en omdat browsers zelf nu vaak ook een DoH client hebben.

In Android kan je wel de instellingen wijzigen, zodat je eigen DNS server gebruikt wordt, maar het gemak van dat automatisch via DHCP laten doen, gaat niet echt meer zo gemakkelijk.

[GertMenkel]

Het idee is dat je een versleutelde DNS-server in kan stellen.

Dat kan nu ook. Ga op je telefoon naar Instellingen -> Netwerk en Internet en druk op "privé-DNS". Kies vervolgens "uitgeschakeld", "automatisch" (de server van je provider of (waarschijnlijker omdat Nederlandse providers die niet hebben) Google) of "hostnaam opgeven" en vul je eigen DNS over TLS server in.

Als Google hier DoH aan toevoegt in plaats van DoT zie ik het probleem niet.

[Tom Paris]

De vraag was wat de impact was op het gebruik van een PiHole.

[GertMenkel]

Ah, in dat geval kun je dit redelijk eenvoudig oplossen door een eigen DoH-server te draaien en die in te stellen. Een bijkomend voordeel van die aanpak is dat je Pihole ook buitenshuis werkt, omdat je DoH relatief veilig open kan zetten voor de rest van de wereld (want TCP is niet kwetsbaar voor een multiplication attack, en HTTPS is versleuteld). Je kunt dezelfde server ook instellen in browsers als Firefox en Edge op je PC en laptop, zodat die ook altijd via je Pihole werken.

[Crahsystor]

De aanname daarbij is dus dat er geen andere DoH servers gebruikt worden door systemen. Flinke aanname. Gezien de verzamelwoede en lucratieve handel in gegevens over apparaten en activiteit, zou ik er niet van uit gaan dat er géén andere DoH servers ingesteld zijn. Zolang je niet kunt whitelisten, blijft het een gok. Een groot deel van de apps en systemen zal zich wel aan de DNS instellingen houden, want dat is gewoon makkelijk vanuit de ontwikkelaar. Maar iedereen met de middelen en de motivatie om zelf (grootschalig) DNS verzoeken te loggen, zal maar wat graag jouw DoH server negeren.

[GertMenkel]

Daar heb je natuurlijk gelijk in, maar dat heeft erg weinig te maken met het wel of niet toevoegen van DoH aan Android of andere besturingssystemen. Als apps er hun eigen DNS-servers of -protocollen op nahouden, is de enige methode om dat te voorkomen het constant analyseren van netwerkverkeer en applicaties dat zich niet laten analyseren weigeren te gebruiken.

Zoals ik elders ook al gezegd heb, DoH doet niets wat in het verleden al niet mogelijk was. Het legt de vinger op de de zere plek, waarbij de zere plek is dat zowel gesloten software als gesloten IoT-hardware niet te vertrouwen zijn, maar ik vind het gek om DoH daar dan de schuld van te geven. Wil je de baas zijn over je eigen netwerk, moet je nu eenmaal de baas zijn over je eigen software, en bij die mentaliteit passen de meeste spelletjes, apps (behalve die uit F-Droid, dan), smartphones (LineageOS-met-trucjes daargelaten) en commerciële besturingssystemen tegenwoordig niet meer door de datahonger van de bedrijven die ze maken.

Persoonlijk had ik om complexiteits- en protocoltechnische redenen veel liever gezien dat iedereen DNS over TLS gebruikte in plaats van DNS over HTTPS, maar het zij zo.

[bvdli]

DNS is een erg oud protocol met verschillende beveiligingsproblemen. Verkeer wordt niet versleuteld, je weet niet van wie je antwoord krijgt, je weet niet of het antwoord klopt en je verkeer is af te luisteren.
Verder zijn veel implementaties kwetsbaar voor amplification attacks.

DoT, DoH en DoQ lossen deze problemen op.

Zie de RFC voor meer details over de ideeen en architectuur achter DoH:
https://datatracker.ietf.org/doc/html/rfc8484

Bijvoorbeeld sectie 9 voor Security Considerations

[Tom Paris]

Ik ben zeer bekend met de werking van DoH/DoT en waarom dit beter is dan DNS. De vraag was wat de impact was op het gebruik van een PiHole.

[singingbird]

Oke, dank voor het antwoord! Ik kan wel een pihole instellen, maar eerlijk gezegd gaat de achterliggende techniek mijn pet te boven.

[kodak]

Dat zal er vanaf hangen of Google haar klanten mogelijkheden wil geven om zelf over het DNS verkeer te beslissen en welke mogelijkheden dat zijn. Maar aangezien ze dit waarschijnlijk niet zonder volledige eigen keuze voor gebruikers (zoals bedrijven die zelf controle willen waar hun netwerkgegevens belanden) kunnen verkopen, lijkt het te verwachten dat ze keuze gaan geven.

Maar als je je zorgen maakt kun je natuurlijk alvast een feature request indienen bij de android ontwikkelaars. Gewoon melden dat je controle wil, in plaats van dat zij beslissen wat het beste voor jou persoonsgegevens is.

[mocem]

Laat me raden dat dit bij default 8.8.8.8 is.

[jcbvm]

Waarschijnlijk https://dns.google/dns-query 😉

[PrinsPace]

Precies mijn gedachte. Anderzijds je telefoon loopt al in zijn geheel op google, dus wat privacy betreft zal de dns server niet echt de doorslag geven.

[TheVivaldi]

“Anderzijds je telefoon loopt al in zijn geheel op google”

Behalve als je een degoogled-rom gebruikt, zoals LineageOS bijv.

[PrinsPace]

True, maar de lieden die daartoe overgaan zullen vermoedelijk überhaupt geen chrome gebruiken.

[patrieckske]

Ik wacht eerst Android 12 maar af.

[Verwijderd]

nextdns is een heel tof systeem voor dit soort dingen, en geen gekloot met installatie
gewoon een pihole of adguardhome voor geinstalleerd op servers en geen onderhoud nodig.

heb hiervoor pihole en adguard home gehad maar dat systeem is toch wel heel verlossend

[jcbvm]

Nextdns is inderdaad een goede optie voor als je zelf geen installatie en beheer wilt doen. De gratis variant is alleen wel beperkt, dus in de meeste gevallen zal je dan moeten betalen wil je al je devices hier gebruik van laten maken.

[Verwijderd]

veel mensen doen/deden het op cloudservers waar je dus al snel 5eur voor kwijt was, dat hoeft dus nu niet meer en ben je voor 1,99 klaar, toch wel een verbetering in dat opzichte

[tom.cx]

Mijn ervaring is dat een device prima gaat. Echter wanneer je meerdere apparaten gebruikt kan je beter updaten. Ik gebruik het nu al een tijdje voor mijn netwerk en ben erg tevreden.

[VisionMaster]

Dit heeft ook de nodige nadelen. Mindere controle opties.

[GertMenkel]

Ik zou zeggen dat je die controle al niet had als DoH je controle uitzet. Er is helemaal niks dat apps forceert DNS te gebruiken, diverse Chinese libraries doen al via HTTPS (niet eens DoH) requests naar een DNS-server.

Zonder dichte firewall met handmatige of transparante TLS-intercepting proxy is alle controle die je denkt te hebben een illusie. Diverse applicaties hard-coden IP-adressen of doen zelfs via HTTP en JSON DNS-lookups om DNS-filters te omzeilen.

Kwaadwillenden kunnen DNS-filters al triviaal omzeilen sinds DNS bestaat. Microsoft en Google doen dit op het moment al met gehardcode IP-adressen voor bepaalde servers. Vage DNS-workarounds zitten ook al langer in apparaten als Chromecasts en hun concurrenten.

Over je eigen apparatuur heb je nog steeds volledig beheer, want net zoals met DNS over TLS kun je hier je eigen server in gaan vullen op systeemniveau. Als het apparaat niet onder je eigen beheer valt, hoort dat apparaat eerlijk gezegd niet thuis op je netwerk of heb je er niks op te controleren.

[Triblade_8472]

Ik hoop alleen dat je nog steeds zelf je dns servers mag kiezen, en Google standaard beloofd de gegevens niet te gebruiken. En dit ook daadwerkelijk niet doet. Fat chance, I know.

Ik weet niet wat ik ervan moet vinden, de DoH...
Aan de ene kant is het perfect dat bijna niemand kan tracken waar jij naar gaat internetten.
Aan de andere kant al die data bij alleen Google te leggen vind ik misschien nog wel minder prettig.

Ik denk dat het systeem ok is, zolang het een opt-in is. Dus het gaat dan alleen aan als je het wil, en zo niet blijft het traditioneel werken.

Is het niet mogelijk om regelmatig alle 1st level, of 2nd level domains te downloaden? Zo groot zal die lijst toch ook niet zijn...? Als je dan 'dieper' wil kan je altijd nog naar de nameserver van het betreffende domein, en dan regelmatig delta's van die lijst binnen hengelen.

[basfriends]

Even puur vanuit een technisch oogpunt, omdat ik het echt niet snap: Wat is nou precies het probleem? DNS werkte altijd al op basis van "goodwill", Big Tech of Malware providers hadden toch altijd al de mogelijkheid om via een encrypted service IP adressen op te halen die horen bij de services die ze nodig hebben?