Google biedt ondersteuning voor DNS-over-HTTP/3 vanaf Android 11

Google geeft recente versies van Android ondersteuning voor DNS-over-HTTP/3 op 'servers die dit ondersteunen'. DoH3 maakt voortaan standaard een onderdeel uit van Android 11 en hogere versies.

In eerste instantie leek Android 13 native ondersteuning voor de nieuwste standaard van DNS-over-HTTPS te krijgen, maar dat bleef uit. In plaats daarvan heeft Google nu een update uitgebracht voor de DNS Resolver-module, een verplichte Android-module die voor alle toestellen met Android 11 en nieuwer geldt. Ook enkele Android 10-smartphones maken gebruik van deze module, schrijft Espers Mishaal Rahman.

Gebruikers kunnen in de internetinstellingen van compatibele Android-toestellen onder 'Privé-DNS' instellen om websites te bezoeken die DNS-over-HTTP/3 ondersteunen. Google noemt in de bijbehorende blogpost twee prominente DNS-servers die standaard ondersteund worden. Dat zijn Cloudflares resolver en Googles eigen publieke DNS-dienst.

Android ondersteunt al sinds de negende hoofdversie van het besturingssysteem privé-DNS-verbindingen. Aanvankelijk werkte dat vooral via DNS-over-tls, maar de laatste jaren wint DNS-over-HTTPS aan populariteit. DNS-over-HTTP/3 verbindt zoals de naam al zegt met de HTTP/3-standaard. Die ondersteunt QUIC, dat meerdere UDP-streams ondersteunt. DNS-over-HTTP/3 zou daarom volgens Google voor snellere verbindingen moeten zorgen, al zegt het bedrijf niet om hoeveel winst het gaat.

De laatste jaren biedt het grootste deel van de DNS-resolvers een versleutelde versie van DNS-queries aan. Dat betekent dat een provider of netwerkonderschepper geen zicht heeft op de DNS-verzoeken die een gebruiker uitvoert. Niet iedereen is daar blij mee; critici zijn bang dat gebruikers hun DNS-verkeer verplaatsen van isp's naar commerciële bedrijven zoals Google of Cloudflare. Tweakers schreef in 2019 een achtergrondartikel over de opkomst van, en kritiek op, DNS-over-HTTPS.

Reacties (80)

[detrukurke]

Dat betekent dat een provider of netwerkonderschepper geen zicht heeft op de dns-verzoeken die een gebruiker uitvoert. Niet iedereen is daar blij mee; critici zijn bang dat gebruikers hun dns-verkeer verplaatsen van isp's naar commerciële bedrijven zoals Google of Cloudflare.

Wat is daarmee precies het probleem dan?

[The Realone]

Een partij als Google heeft doorgaans meer baat bij het weten naar welke domeinen jij verbindt dan jouw eigen provider bijvoorbeeld. Of je je daar zorgen over maakt is een persoonlijke afweging, maar als dat niet het geval is kun je je ook afvragen of je hier überhaupt baat bij hebt.

[detrukurke]

Dan hebben we het specifiek over Google, maar in de basis lijkt me weinig mis met gebruikers die hun eigen dns server kiezen.

[Zer0]

In basis is er ook niks mis mee, maar DoH heeft ook het gevolg dat devices en zelfs applicaties zelf hun eigen DNS resolving kunnen gaan doen zonder dat je daar als gebruiker controle over hebt. Standaard DNS request kun je blokkeren of omleiden naar een eigen (gekozen) server, voor DoH is dat veel lastiger omdat het "gewoon" https(3) verkeer is.

[Reactie gewijzigd door Zer0 op 27 juli 2024 20:41]

[Z80]

DoH heeft 1 heel groot privacy probleem. Namelijk dat elk apparaat exact te tracen is. Ook door firewalls en NAT systemen.
Elk apparaat zet namelijk een eigen versleutelde verbinding op, met een eigen sleutelpaar.
Om het een en ander sneller te maken en minder rekenkracht op de servers te hoeven inzetten bij elke nieuwe verbinding wordt dit sleutelpaar hergebruikt.

In plaats van dat een dns weet dat vanuit bijvoorbeeld een kpn mobiel netwerk tweakers.net ip wordt opgevraagd. Weet een DoH server exact wel apparaat op dit kpn netwerk het verzoek doet.
Zolang er geen gekke wetgeving of andere ongein zit aan te komen is het enkel een privacy probleem.
Woon je in de USA in een staat waar abortus verboden is kan het wel een probleem gaan worden.

[YangWenli]

Ik meen mij te heugen dat "deep packet inspection" legaal is in Amerika dus daar heb je providers die leuk advertenties injecteren.
Daarom willen veel mensen DNS via Google of cloudflare.

[Blokker_1999]

Groot probleem is dat er zeer weinig DoH servers bestaan daar ze een zeer stuk complexer zijn dan de klassieke DNS server. Je krijgt daarmee dus net een enorme verschraling van het aanbod.

[Sando]

Groot probleem is dat er zeer weinig DoH servers bestaan

Waarschijnlijk meer dan je denkt: 344.

edit:
Oké, pakweg de helft is DoH, de andere helft is DNSCrypt.

[Reactie gewijzigd door Sando op 27 juli 2024 20:41]

[thijsjek]

Nouja, niks houdt je tegen om thuis of op een vps Adguard home te installeren. Port openzetten, certificaat, domein naam, toegangslijst maken en tada. Je eigen doh (doq) server met adblocker voor je gehele smartphone.

Doh is gemaakt voor Google, dat ze het pushen is alleen maar handig voor hun. Vroeger had Google ook al je gehele dns verkeer (8.8.8.8) maar niet per device. Nu met doh, heeft Google je dns per device. Ga nu meer eens googlen op onderbroeken op je telefoon, en die advertenties zie je dadelijk niet meer op je pc.

Ja, het is veiliger dat je dns verkeer niet afgeluisterd kan worden, maar als jij een website bezoekt over https, iedereen met Wireshark kan die uitlezen.

[Yggdrasil]

Ja, het is veiliger dat je dns verkeer niet afgeluisterd kan worden, maar als jij een website bezoekt over https, iedereen met Wireshark kan die uitlezen.

Dit moet je denk ik wat nuanceren. Ook wireshark kan geen versleuteld verkeer uitlezen. Alleen wordt momenteel nog bij https de server naam onversleuteld verzonden (omdat de server die moet weten voordat de versleutelde verbinding opgezet kan worden). Men kan dus zien met welk hostname je verbindt, maar niet wat je daar doet.

Overigens is dat in de toekomst ook niet meer mogelijk. In TLS 1.3 wordt ESNI (Encrypted Server Name Identification) geïmplementeerd.

[whiner]

De meeste mensen weten helemaal niet wat DNS is. Die zullen dus ook geen bewuste keuze hierin kunnen maken.

[jozuf]

Voor Google bv nog meer metadata om advertenties op te baseren en een profiel op te bouwen.

[Sando]

Maar dat was met de "gewone" DNS-servers van Google die standaard actief waren in Android ook al zo. Waarom is dit (dns-over-https) specifiek een probleem?

edit:

Blijkbaar gebruikt Android niet standaard Google DNS, tenzij je voor 'static DNS' kiest. Dan worden wel standaard de Google DNS services ingevuld.

[Reactie gewijzigd door Sando op 27 juli 2024 20:41]

[kodak]

Omdat miljoenen gebruikers gewoonlijk standaard op Android de vele verschillende dns services van hun provider gebruiken, tenzij die gebruikers zelf moeite doen of voor ze is gedaan om een keuze voor de dns services van google te maken. Terwijl deze oplossing van google dat compleet omdraait. Standaard heb je dan wat Google als dns goed uit komt, tenzij de miljoenen gebruikers zelf moeite doen om uit alternatief te kiezen. Als google zo begaan was met privacy dan hadden ze de keuze direct aan de miljoenen gebruikers gegeven en hun eigen keuze voorkeur standaard gemaakt. Want voor een gebruiker zijn die keuzes van google niet zomaar beter dan de duizenden alternatieven waar google weinig of niets aan heeft.

[Sando]

Maar dan is het probleem dus niet met Secure DNS, maar met het al dan niet standaard configureren van een Google DNS-server, secure of niet secure?

[kodak]

Het protocol is niet ontworpen om privacy-vriendelijk te zijn door standaard maar te vertrouwen op wat Google (of welke andere leverancier of provider) bevalt. Het protocol kan privacy leveren, maar dat kan niet zomaar als privacy vriendelijk gezien worden met standaard dns-services die Google voor gebruikers kiest als privacy-vriendelijk. Klanten hebben niet opeens meer of evenveel privacy als dat versleutelde verkeer naar een keuze van een bedrijf of provider gaat, dat was juist een van de belangrijke argumenten om rekening mee te houden. Maar google stelt wij bepalen wel wat standaard voor miljoenen klanten privacy-vriendelijk en betrouwbaar is, waarmee het dus niet lijkt te doen wat bij het protocol de bedoeling is.

[whiner]

Omdat je nu geen DNS filters kan toepassen voor adblocks, volgens mij

[kodak]

Omdat bedrijven en organisaties daarmee minder controle hebben over wat er binnen hun netwerk gebeurt, terwijl ze daar vaak wel verantwoordelijk voor zijn naar de eigenaren en gebruikers en handhaving. Terwijl het een paar bedrijven juist heel veel inzicht en controle geeft terwijl dat ook nog eens waardevol voor die bedrijven is en ze niet zomaar dezelfde belangen hebben als die bedrijven en organisaties. Google toont met deze implementatie aan dat ze er zelf belang bij hebben om dat verkeer liever te hebben dan hun concurrenten, door hun eigen services als standaard in te stellen en de gebruikers en bedrijven waar ze het dns verkeer van wille maar moeite moeten doen dat het ergens anders heen gaat. Google en cloudflare helpen daarbij ook niet zomaar die bedrijven of de gebruikers dat te voorkomen of om verantwoordelijkheid te laten nemen.

[thijsjek]

Precies, al die servers 1.1.1.1 of 8.8.8.8 of dot/doh draaien gratis voor jou. Meestal als iets gratis is, ben jij het product, waar zij aan verdienen.

[Martin.Air]

Daar is echter wel een groot onderscheid te maken: hoe geanonimiseerd is de data?
Als je moet kiezen tussen:

• X mensen vroegen www.tweakers.net op gisteren
• X mensen vroegen www.tweakers.net op gisteren, uit Nederland
• X mensen vroegen www.tweakers.net op gisteren, uit Flevoland
• X mensen vroegen www.tweakers.net op gisteren, uit Lelystad
• X mensen vroegen www.tweakers.net op in de afgelopen 5min, uit Lelystad

(je ziet waar ik heen ga)

En dat is nog groep data, dit zou je zelfs met lijsten aan IP adressen kunnen delen met je 3e partijen/andere afdelingen. Dat Google dus veel informatie over je verzameld en dit zou kunnen gebruiken voor reclame is 'ongewenst' voor velen.
Dat mijn data onderdeel is van een groep "Nederland" acht ik prima, maar niet in zeer gedetailleerd niveau. Daar moet ik dus mijn DNS provider op uitkiezen, ik hoop dat anderen hier ook over nadenken.

[Crew One]

Zoals altijd: tracking.

[mailis]

Waarom Google dit gratis wil aanbieden in ruil voor ads kan ik mij voorstellen, maar welk belang heeft Cloudflare precies? Kan mij een aantal zaken bedenken:

• Reclame voor hun diensten
• Overtollige resources (zoals Stack van Trans IP vroeger)
• Tracking van data stromen voor andere diensten

Op Google een zoekmachine kon ik niet direct iets terugvinden, dus ben benieuwd

[Reactie gewijzigd door mailis op 27 juli 2024 20:41]

[Verwijderd]

Google doet nog wel meer: crawlen welke websites jij precies bezoekt.

Het is me ook opgevallen dat websites bij mij onder een dev stonden voor amper 10 minuten, en na 10 minuten al volledig geindexed stonden in Google search. Enige herleiding die ik had was Google DNS.

Als website bouwer heeft het voordeel; extra snelle indexing, maar er leest of kijkt wel iemand altijd met mij mee.

[mailis]

Bedoelde dat ik probeerde te achterhalen ("Googlen") waarom Cloudflare dit juist gratis aanbiedt, maar lees nu dat dit wat verwarrend staat

[OruBLMsFrl]

CloudFlare krijgt beeld op waar potentiële klanten zitten voor hen en hoeveel geschat volume daarheen gaat. In plaats van enkel hun eigen klanten traffic, zien ze dan alle bestemmingen waar miljoenen consumenten heen surfen. Vele malen interessanter en natuurlijk ook weer te verkopen zulke datasets, in plaats van dat ze via derde partijen alles moeten inkopen. Win-win voor CloudFlare.

[!mark]

Voo bedrijven als Brein en overheden wordt het blokkeren van bepaalde websites lastiger. De blokkades van o.a. ThePirateBay werken bij in ieder geval Ziggo allemaal op DNS niveau van de isp.

Richting een mondiaal megabedrijf kan ik me zo voorstellen dat dit soort dingen veel lastiger af te dwingen zijn voor een klein land als NL dan richting de Nederlandse isps.

Of dit een voordeel of nadeel is laat ik maar even in het midden

[dieAndereGozer]

Nog meer data voor google.

[switchboy]

RIP pihole

Wordt gebracht als anti tracking dingetje maar dit is de doodsteek voor dns filtering. Over https kan je geen dns request meer onderscheiden van andere verkeersstromen. Dus kan je niet meer filteren

[Prince]

Op dit moment is dit een issue, maar geef het wat tijd.
Je ziet dat er al mensen aan bezig zijn om oplossingen te vinden.

Ook is PiHole een lokale DNS; elke gebruiker kan nu reeds eenvoudig een andere DNS configureren om jouw systeem te omzeilen.
Het bestaan van DOT en DOH3 belemmert niet dat jij op kantoor of thuis een PiHole draait en met DHCP meestuurt als de default DNS. (of later dus als de default DOT / DOH3)

[Zer0]

Je ziet dat er al mensen aan bezig zijn om oplossingen te vinden.

Dat is geen oplossing voor DoH issues, dat is gewoon een manier DoT te implementeren op Pihole.

Het bestaan van DOT en DOH3 belemmert niet dat jij op kantoor of thuis een PiHole draait en met DHCP meestuurt als de default DNS. (of later dus als de default DOT / DOH3)

Het probleem is dat gebruiker, applicaties en devices die default DNS kunnen negeren en DoH(3) kunnen gebruiken om de filtering te omzeilen.
Gaat je TV toch opeens ad's tonen....

[ari3]

Ik denk dat de oplossing zal zijn:
- Transparent een (Socks-achtige) proxy instellen voor al je HTTPS verkeer
- Voor communicatie met de client vervangt de proxy het remote certificaat met een eigen certificaat
- Voor communicatie met de server gebruikt de proxy het remote certificaat
- De proxy kan het HTTP-verzoek dus inhoudelijk lezen
- Indien een DOH-verzoek wordt gevonden redirect de proxy naar je eigen (filterende) DOH-server zoals AdGuard of PiHole.

Deze oplossing wordt al in veel bedrijfsnetwerken gebruikt. Het is effectief een soort van man-in-the-middle en niet goed voor de privacy van gebruikers, maar kan wel effectief zijn in het filteren van HTTPS-verkeer.

De enige manier voor een app om dit te omzeilen is als de app de vertrouwde certificaatuitgevers van het besturingssysteem niet vertrouwt en zijn eigen lijst van certifaatuitgevers hanteert. Daarnaast zijn sommige apparaten (smart TVs) zodanig gesloten dat het toevoegen van een eigen certificaatautoriteit niet mogelijk is.

[Zer0]

De enige manier voor een app om dit te omzeilen is als de app de vertrouwde certificaatuitgevers van het besturingssysteem niet vertrouwt en zijn eigen lijst van certifaatuitgevers hanteert.

Diverse apps gebruiken eigen certificaat stores, en zoals je zelf al aangeeft, op veel apparatuur is dit niet mogelijk.

[switchboy]

Je kan op je router met een simpele firewall rule AL het DNS verkeer ONGEACHT het doel IP adres naar je Pihole loodsen. Door al het verkeer op de DNS port af te vangen. Voor https werkt dit trucje niet meer.

[WoutervOorschot]

Het blokkeert het wel wanneer google besluit op bijvoorbeeld android dit te forceren. Op de chromecast forceren ze 8.8.8.8 al, maar die kan je rerouten naar je eigen resolver. Als ze daar dot/doh forceren kun je niet meer zomaar even makkelijk het onderscheppen omdat het geen dns verkeer meer is.

Het is iets dat google pusht, in de VS kunnen ze nog zeggen dat het goed is omdat providers daar DNS verkeer mogen doorverkopen, maar voor hier is het beter om zelf of via je provider te laten lopen dan via google.

[sjongenelen]

Je kunt naar je eigen dns server thuis connecten. Adguardhome server en inderdaad men kan het niet blocken.
Ik zie dit juist als een verbetering van de huidige verouderde implementatie

[x86dev]

Uitgaande DoH poorten blokkeren op je firewall.

[Zer0]

Lol, en vrijwel geen enkele website meer kunnen bezoeken..... DNS over HTTPS

[x86dev]

Lol, dan heb je iets niet goed ingesteld.

[Zer0]

DoH, DNS over HTTPS, betekent dat het verkeer over HTTPS gaat, dus over poort 443. Als je dat verkeer blokkeert blokkeer je dus ook gewoon https verkeer....

[x86dev]

Ik was even verward met poort 853, ze verzinnen ook altijd weer wat nieuws om je te volgen.
Dan blokkeren via IDS / IPS mits je router/firewall dat heeft. :-)

[Zer0]

Poort 583 is DoT, DNS over TLS.
Blokkeren via IPS... gaat niet zonder een https-proxy op te zetten en certificaten op je apparatuur te zetten, wat op lang niet alle apparatuur/applicaties kunnen.... een paar posts hierboven al voorbij gekomen.
DoH is niet zo simpel even te blokkeren/filteren.

[kuurtjes]

-verwijderd-

[Reactie gewijzigd door kuurtjes op 27 juli 2024 20:41]

[Verwijderd]

Pihole? Dat is ouderwets

[dieAndereGozer]

Verhelder ons.

[Verwijderd]

Adguard dns beta en nextdns.io zijn de toekomst alternatieve

[dieAndereGozer]

En waarom zijn die beter?

[Verwijderd]

Is er voor apache2, nginx al ondersteuning voor http/3?

[Verwijderd]

Ga daar (voorlopig) nog maar niet vanuit tenzij je wilt experimenteren met een alternatieve SSL, OpenSSL zelf ondersteund als het goed is nog steeds geen QUIC.

NGINX heeft overigens wel quic.nginx.org voor Apache is er volgens mij geen lopend project.

Zonder QUIC geen http/3 dus neen... out-of-the-box is er eigenlijk nog helemaal niets.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 20:41]

[JeroenED]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64462 => nee dus

[zx9r_mario]

OpenLiteSpeed en Caddy ondersteunen http/3 al een tijdje.

[kodak]

Waarom zouden ze? Die zijn vooral gemaakt voor webservices, geen dns-services. Dat dns-over-https/3 ook het https-protocol (gedeeltelijk) handig lijkt maakt die software er niet zomaar meer geschikt voor, of het de moeite waard om daar dan ook maar weer tijd en geld in te investeren om te maken en onderhouden. Daarbij zijn die webservices niet gemaakt om als dns-service te dienen en dat protocol helemaal te ondersteunen, wat juist een heel belangrijk onderdeel is van dns-service software als Bind, Powerdns of Unbound. Die dns-software is meestal al in gebruik voor het oorspronkelijke dns-verkeer en heeft inmiddels ook ondersteuning voor DoH. En voor clients als android hoeft dat niets uit te maken.

[Reactie gewijzigd door kodak op 27 juli 2024 20:41]

[devilkin]

Ik gebruik hier thuis blacklists van DoH en DoT servers, puur omdat ik niet wil dat enig iot of ander device op m'n netwerk zomaar even rond m'n adguard en blocking lists kan.

Ik beslis zelf wel wat hier buiten gaat... m'n eigen ad guard instances mogen wel naar buiten over DoH. Dus als toestellen m'n via dhcp / RA meegeleverde dns servers gebruiken hebben ze geen problemen. Anders...pech.

[Yucko]

hoe kom je aan die lijst van DoT en DoH servers?

DoT kun je trouwens toch simpelweg blokkeren door poort 853 naar buiten ontoegankelijk te maken

[devilkin]

Ik gebruik https://github.com/dibdot/DoH-IP-blocklists als bron, plus nog wat dat ik hier en daar bijeen gesprokkeld heb.

Je loopt inderdaad achter de feiten aan, maar menig device wordt ofwel niet geupdate door de manufacturer of gebruikt iets vanop die lijsten.

Chromecasts zijn bvb zo van die rottige dingen die altijd naar de google DNS gaan, tenzij ze er niet geraken... En ze werken perfect zonder.

Er zijn trouwens ook al tools op de markt (ik vind ze niet direct, maar ben ze wel al tegengekomen) die als proxy fungeren voor https verkeer. Wat het doet is zelf een https query lanceren naar de target, en kijken of daar iets deftigs terugkomt. Indien niet... block.

[Reactie gewijzigd door devilkin op 27 juli 2024 20:41]

[Zer0]

Dat lukt nu miscchien nog wel, maar het is niet heel moeilijk voor bijvoorbeeld Google om DoH niet meer op https://dns.google/dns-query te hosten maar op https://mail.google/dns-query

[orvintax]

Maar gebruiken ze dan DNS als fallback? Anders werken er dadelijk dingen niet meer.

[mutley69]

DoT is ruim te prefereren over DoH. reden: het ondscheid kunnen maken tussen legitiem web-verkeer vs. malware. Wat gaat u doen als men DoH-dns-verkeer gaat meesturen met https-verkeer? Dan wordt u een speelbal van Google, Microsoft, Apple en vooral echte rotzakken zoals Facebook en TikTok. We zwijgen dan nog over malware.
DoT gaat over een aparte poort - en DoT kan u zelf instellen - met een veilige gateway er dus tussen!
Nee aan DoH!

[trixwood]

Stel je voor je gebruikt je isp dns.

Het enige verschil tussen normaal dns en dot doh is dat het verkeer verplaats naar de speelbal tech bedrijven.

En dat isp dns buiten spel worden gezet zodat ze zelf kunnen monitoren. Buiten spel is niet dat de isp je niet kunnen monitoren. Dat kunnen ze wel... hebben ze geen dns voor nodig..

Nu zijn er ineens 2 partijen die dat doen ipv een. Plus je hebt zelf geen controle meer over je eigen netwerk... dus voordeel grote tech bedrijven veel, voordeel gebruikers in de min...

Ik heb argumenten gezien van "repressive regimes", "geen isp trcking" etc... gewoon onzin. Dit heeft niks met security te maken.

Kort door de bocht wat ik ervan begrepen heb.

Ze zouden in pihole een distributed doh scan in moeten bouwen!

[trixwood]

stel je voor google chrome besluit we doen alles over doh naar google... fark your dhcp settings...
en verbergen de optie van een andere doh servers ergens ver weg in vage settings... zodat geen normale gebruiker het zou veranderen.... en dan niet alleen met chrome maar met android... etc... betekend straks ook dat google bepaald hoe het internet eruit ziet. sinds het hun dns servers zijn die bepalen of iets een ip heeft of niet...

Toekomst...

krijg je straks per app een verschillend internet... word ook lekker met troubleshooting. Want het is and was https://www.jeffgeerling....les/images/it-was-dns.jpg ... dns... waarom doet het het niet... de server is bereikbaar... na maar niet voor die app...

Waarom is het internet zo traag voor deze app... nou de app moet downgraden van doh of dot naar dns op 53... en zo'n timeout is traag... als er al een downgrade mogelijk is.

[Reactie gewijzigd door trixwood op 27 juli 2024 20:41]

[syl765]

Tsja google weet al heel veel van je en dat laatste beetje dat ze niet weten, dat halen ze op die manier wel naar boven. Google chrome heeft ook al DoH, duurt niet lang voordat dat default aan gaat. Nu heet de optie Use secure DNS. Dus als je als leek een beetje zit rond te klikken in de settings dan zet je dat vinkje natuurlijk aan. DoT, DNS over TLS is wat je wilt gebruiken. Dat is gewoon een 'normale' DNS server die verkeer encrypt en praat op poort 853 dat kun je dus goed firewallen. Tsja de grote patijen drukken hun zin wel door. Kan het niet linksom dan gaan we rechtsom.

Het meest vervelende zoals al eerder genoemd is wel dat applicaties hun eigen DNS server kunnen gaan kiezen. En dit zijn dan ook nog eens programma's die heel veel internet content aanraken, het is wachten op de dag dat deze software een exploit bevat waarmee de aanvaller een malafide DoH server opgeeft en dan heb je de poppetjes aan het dansen. En jij als engineer ziet alleen maar https verkeer en niet opeens DNS verkeer naar een exotische DNS server.

Naar mijn bescheiden mening mag DoH snel ter ziele gaan.

[Reactie gewijzigd door syl765 op 27 juli 2024 20:41]

[sympa]

Als een applicatie een eigen DoH implementatie heeft, dan maakt het niet uit of het OS wel of niet DoH aanbiedt, toch?

[syl765]

Presies daarom is DoH een gedrocht. Als mijn applicatie een eigen DNS implementatie heeft dan kan men proberen een eigen DNS server op te geven, maar daarmee kom je met regulier DNS verkeer niet naar buiten omdat ik alleen DNS verkeer toe sta naar mijn vertrouwde DNS servers. Gebruik je echter DNS over HTTPS dan kan ik dat niet meer blokkeren omdat 99% van de websites die mijn bedrijf bezoekt ook dat protocol gebruiken. Er is niets zo waardevol voor een hacker om controle te hebben over DNS. En met DoH word die drempel wel erg laag.

Voor nu is het eigenlijk ook helemaal niet van toepassing om voor je eigen applicatie een aparte DNS implementatie te schrijven omdat je in veel gevallen toch niet naar buiten komt en het meer werk is om je eigen implementatie te schrijven. Laat dat maar lekker over aan het OS. Maar ja in het geval van de browsers valt er dus een hoop data te vergaren. En wat kun je dan het beste als protocol gebruiken .... presies HTTPS, niemand die de ip adressen van zijn favoriete sites opzoekt en alleen die op de whitelist zet.
Geniaal bedacht. We noemen het secure DNS dan valt het ook nog eens goed.

[Reactie gewijzigd door syl765 op 27 juli 2024 20:41]

[sympa]

Zondr DoH zou een hacker toch een eigen protocolletje kunnen maken? Desnoods een VPNetje over https.

[syl765]

Dat kan inderdaad, maar dat is heel wat meer werk. Nu kan je met een exploit heel makkelijk een browser jou DNS server laten gebruiken. Alle logica zit al in die browser, het enige wat je hoeft te doen is zorgen dat hij jou DoH server gaat gebruiken. Dan zeg je tegen de browsers die je hebt, microsoft.com, ing.nl, rabobank.nl enz heeft IP bla bla en je bent een man in the middle. (even simpel gebracht.)

[wizzkizz]

En daat is dus precies HTTPS voor, want de aanvaller heeft daarmee nog geen vertrouwd certificaat voor die domeinen. Dus het is nog wel degelijk van belang om te letten op het "groene slotje".

Een gelijkend domein of wazig UTF-8 IDN dat goed lijkt op het westerse alfabet is een groter risico.

Neemt niet weg dat het vervelend kan zijn als een onvetrouwde partij je DNS replies gaat geven, maar je moet nu ook al aannemen dat het gebeurt of kan gebeuren.

[analog_]

Applicaties konden altijd zelf al kiezen hun resolving af te handelen. Je bent niet verplicht de os resolver te gebruiken. (edit: traditioneel dns)

[Reactie gewijzigd door analog_ op 27 juli 2024 20:41]

[CyBeR]

Dat is op zich waar, alleen met traditioneel DNS over UDP is dat vrij simpel te voorkomen door uitgaand poort 53 te blokkeren of om te leiden naar je eigen DNS servers. Met DoH kan dat effectief gewoon niet.

[Kabouterplop01]

Ik denk wel dat het kan, maar of je dat wilt. (alle DOH/DOT servers blokkeren op laag 3 in de FW)
Heel bewerkelijk.

[trixwood]

denk dat weinige de ernst inzien dat internet bestaat uit de naampjes die uit dns komen... niemand typt in een ip address om naar tweaker.net te gaan. iedereen gebruikt naampjes. daarom is dit zo'n grove schending.

zoals met spice in dune... "he who controls the names controls the internet".

...the internet has suddenly become centralized in the hands of a few.

[syl765]

Met zo'n blacklist loop je achter de feiten aan. Het is zeker beter dan niets maar als iemand zijn eigen DoH server op weet te geven middels een exploit dan ga je dat heel moeilijk zien.

[trixwood]

of doh sterft een stille dood... of er gaan een paar mensen in het begin rijk worden met doh server scanning op het internet, en die lijsten verhuren/verkopen voor security. na een tijdje krijg je apps die een normale https get doen om de ip aan de doh server whitelist toe te voegen voordat je doh uberhaubt kan doen...

beste een stille dood... helaas denk ik dat pandoras box al open is.

[trixwood]

https://www.youtube.com/watch?v=8SJorQ9Ufm8&t=3000s

Er zijn al enkele sysadmin en security gasten bezig met een scan op doh (jah je moet het volledige internet scannen). Zodat je dat met je firewall
kan blokkeren.

Hij praat ook ervoor waarom doh nogal brak is. En dat het een boel breekt...

[Reactie gewijzigd door trixwood op 27 juli 2024 20:41]

[syl765]

Die video geeft het goed aan inderdaad.

[Ursie74]

Voor mensen die geen gebruik willen maken van Cloudflare en/of Google. Er bestaat ook zoiets als Quad9 wat als IP adres 9.9.9.9 gebruikt.

Quad9 is een wereldwijde openbare recursieve DNS-resolver die tot doel heeft gebruikers te beschermen tegen malware en phishing. Quad9 wordt beheerd door de Quad9 Foundation, een Zwitserse stichting zonder winstoogmerk met als doel de privacy en cyberbeveiliging van internetgebruikers te verbeteren, met het hoofdkantoor in Zürich.

Deze biedt ook DoH diensten aan!

[hahaha2223]

Ik snap alleen niet zo goed dat het perse via http moet. DNS over QUIC is ook gewoon in development en biedt dezelfde voordelen.