Google test dns-over-https bij Chrome met zes dns-providers

Google experimenteert met dns-over-https bij Chrome 78 op desktop en mobiel met in eerste instantie zes dns-providers, waaronder Google zelf. Als de dns-aanbieder van de gebruiker op de lijst staat, schakelt de browser automatisch over naar dns-over-https.

De dns-providers waarmee Google samenwerkt, zijn Cleanbrowsing, Cloudflare, DNS.SB, OpenDNS en Quad9. Deze zijn volgens het bedrijf gekozen vanwege hun ferme standpunt op het gebied van privacy en beveiliging, en hun compatibiliteit op het gebied van dns-over-https, of doh. Niet bekend is of Google de lijst wil uitbreiden. Het Nederlandse PowerDNS staat bijvoorbeeld niet op de lijst.

Bij de implementatie van Google kijkt de browser of de dns-aanbieder van de gebruiker op de lijst staat om van een doh-dienst gebruik te kunnen maken. Is dat niet het geval, dan verloopt de verbinding als vanouds. Omdat Chrome de standaard ingestelde dns-provider verkiest en alleen dns-over-https activeert als die provider dit aanbiedt, ervaren gebruikers geen problemen met door de aanbieder aangeboden functies voor parenting control en malwarebescherming, aldus Google.

Daarmee wijkt de implementatie af van die van Mozilla. Die organisatie kiest vooralsnog voor de 1.1.1.1-dns-resolver van Cloudflare en schakelt deze vanaf eind september standaard in voor Amerikaanse gebruikers.

Google test de doh-implementatie bij een fractie van de Chrome 78-gebruikers op alle ondersteunde platforms op Linux en iOS na. Op Android 9 en latere versies van het besturingssysteem kan Chrome gebruikmaken van een doh-aanbieder die door de gebruiker bij de dns-instellingen is ingesteld. ZDNet publiceerde eerder deze week de stappen die een gebruiker moet doorlopen om de desktopversie van Chrome buiten de test om van dns-over-https gebruik te laten maken.

Google en Mozilla testen het gebruik van doh uit privacy- en beveiligingsoverwegingen. De techniek versleutelt een dns-query met tls-encryptie, waardoor partijen zoals providers niet meer kunnen zien welke webpagina's specifieke gebruikers opvragen. Google wijst erop dat de techniek bijvoorbeeld voorkomt dat derde partijen bij het gebruik van publieke hotspots kunnen zien welke websites door gebruikers worden bezocht.

Reacties (117)

[Lethalis]

Kleven hier geen grote privacy bezwaren aan?

Ik heb denk ik liever dat KPN weet welke sites ik bezoek, dan dat Google of een ander Amerikaans bedrijf dit weet.

[mroz]

Zoals er in het artikel staat schakelt Chrome alleen over op DoH als de DNS provider die je al gebruikt dit ondersteund en op de whitelist van Chrome staat.
Dit heeft dus geen impact op je privacy, als je KPN DNS servers gebruikt blijf je die gewoon gebruiken.
Als je Quad9 of een andere provider op de whitelist van Chrome gebruikt, zal er DoH gebruikt worden.

De manier waarop Firefox dit gaat doen (standaard DoH inschakelen en CloudFlare als DoH provider gebruiken) is echter wel een privacy issue (wat mij betreft dan).

[HyBridLaN]

Ik wil niet vervelend doen maar tenzij dit veranderd in toekomstige versies van Firefox, momenteel kan ik standaard de CloudFlare kiezen of zelf een intypen(custom). Als ik dit verkeerd begrijp hoor ik het graag hoor.

[Archcry]

"Daarmee wijkt de implementatie af van die van Mozilla. Die organisatie kiest vooralsnog voor de 1.1.1.1-dns-resolver van Cloudflare en schakelt deze vanaf eind september standaard in voor Amerikaanse gebruikers."

Bron: Dit artikel

[Reactie gewijzigd door Archcry op 23 juli 2024 12:53]

[HyBridLaN]

Om toch maar even te reageren; uit de blog post waar vaak naar wordt verwezen "our plans for enabling DoH for some users in the USA. & Our plan is to start slowly enabling DoH for a small percentage of users while monitoring for any issues before enabling for a larger audience." Zo ver ik weet is Nederland geen onderdeel van de USA. Hier in Nederland / Europa is de wetgeving veel anders dus deze implementatie zo als hij hier wordt benoemd is niet van toepassing. Daarnaast blijft het gewoon mogelijk zonder dns-over-https te blijven werken.

[mroz]

Nergens in dit artikel staat dat het hier over Nederland gaat

"In the US, Firefox by default directs DoH queries to DNS servers that are operated by CloudFlare, meaning that CloudFlare has the ability to see users' queries."
Bron: https://support.mozilla.org/en-US/kb/firefox-dns-over-https

Dus, als/zodra dit in de USA standaard aangezet wordt: dan wordt er standaard CloudFlare gebruikt.
En 99 van de 100 gebruikers zullen zich niet realiseren dat dit impact op hun privacy heeft of weten dat dit aan te passen is.

Of Mozilla dit in landen waar de GDPR van kracht is mag doen weet ik niet, wellicht kan @Arnoud Engelfriet daar antwoord op geven.

[Tokkes]

"World wide, browsers by default direct DNS queries to whatever server is configured, meaning whoever operates said server has the ability to see users' queries"

DoH doet daar echt niets aan.

[mroz]

Dat klopt, je kunt zelf ook Unbound gaan draaien..

[Ramon]

Als je Chrome gebruikt dan weet Google dat allang.

[ApexAlpha]

Bij de implementatie van Google kijkt de browser of de dns-aanbieder van de gebruiker op de lijst staat om van een doh-dienst gebruik te kunnen maken. Is dat niet het geval, dan verloopt de verbinding als vanouds.

Zoals hier staat: Chrome kijkt of de DNS die je gebruikt geschikt is voor DNS-over-HTTPS. Als dat zo is, dan wisselen ze van van protocol. Ze wisselen dus (in tegenstelling tot Mozilla) NIET van DNS provider.

[Anoniem: 470811]

Vraag me wel af hoe het vastgesteld wordt.

Standaard worden op thuis routers die router IP als DNS doorgegeven. De router resolved dan verder (naar de ISP, Google, of whatever).

Wanneer Chrome naar IP van je netwerk adapter kijkt, dan zal je nooit profiteren hiervan, want een DoT of DoH is er niet voor je thuisrouter.

Dit betekent dat Chrome een externe (soort van) leak-test moet doen om te zien waar uiteindelijk je DNS verzoek terecht komt.

Dit is de reden waarom ik in de DHCP zelf rechtstreeks de externe DNS publiceer.

[jaenster]

Helemaal mee eens.

In america is het helaas zo dat de providers niet te vertrouwen zijn, en juist je dns requests gebruiken voor reclame doeleinde.

Dus, daar snap ik waarom mensen hier behoefte aan hebben, alleen zoals vrijwel altijd zijn de americanen en hun bedrijven nogal kortzichtig en enkel gebouwt op hun eigen markt. En ja, ik vertrouw _random nederlandse provider_ meer als welk americaans gebaseerd bedrijf dan ook.

[The Zep Man]

Kleven hier geen grote privacy bezwaren aan?

Als privacy een punt op de agenda was dan gebruikt men geen Chrome.

Verder lijkt juist Google wat voorzichtiger te zijn met DNS over HTTP gebruik t.o.v. Firefox, die binnenkort DNS over HTTP standaard gaat gebruiken.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:53]

[Blokker_1999]

Niet met de implementatie van Google. Zij respecteren de keuze die je zelf gemaakt hebt en gaan enkel over op DoH als je ingestelde DNS provider op hun lijst staat.

[Anoniem: 368883]

Dat is inderdaad een van de redenen dat Paul Vixie (1 van de founders van DNS) zo tegen het gebruik van DoH is. Al je DNS queries bij 1 grote partij wil je gewoon niet.

Een betere oplossing zou zijn, als bestaande DNS servers DoT (DNS over TLS) zouden ondersteunen, en gewoon een eigen resolver gebruiken. Zo komt je DNS data nooit allemaal bij 1 partij terecht, en ben je toch beschermd tegen snooping door je provider.

[Tokkes]

ik snap het hele punt van 'queries inzien' al helemaal niet.

Dat is momenteel gewoon ook het geval, over UDP DNS. Waarom doet iedereen er ineens zo moeilijk over.

[Sharkoon]

Als firefox dit doet dan is het allemaal geweldig. Doet google het dan is het weer privacy shit.

[Blasterxp]

nee, nee, nee. Ik schreef de vorige keer al; dat dit gedoe 'gefilterd' internet oplevert. Elke browser zou dezelfde pagina moeten laten zien. Dat is dus niet meer zo.

[misterbennie]

Wat heeft een DNS request met de getoonde pagina te maken?
Je gaat nog steeds naar dezelfde server en vraagt nog steeds dezelfde pagina op.
DNS vertaalt alleen jouw URL naar een IP adres.
Die zou (en is) niet anders of je nu naar je provider z'n DNS server gaat of naar die van Google.

[StefanTs]

DNS heeft alles met de getoonde pagina te maken. Zet de volgende regel maar eens in je hostsfile:
66.254.114.41 tweakers.net

Als de beheerder van de DNS server besluit dat een query wel een ander resultaat oplevert dan die van je provider dan kan dat gewoon. 64% van de wereldbevolking even via een DNS dienst laten gaan (marktaandeel Chrome aldus Google zelf) levert toch wel een interessante positie op. Zelfde geldt overigens voor Firefox. Straks bepaalt een van de DNS providers dat bedrijf X niet aan hun eisen voldoet en weigeren ze hun diensten. Kijk bijvoorbeeld hoe banken, Paypal, etc met sommige klanten omgaan. Blokkeren bijvoorbeeld donaties aan legitieme (F)OSS projecten.

[MoonRaven]

Hoewel het een sterk voorbeeld is, zitten er nu genoeg mensen op het werk waardoor het fijner was geweest om een ander ip te gebruiken als voorbeeld...

[StefanTs]

Ik kan geen statistieken aanhalen, maar zover mij bekend is de gebruikerstevredenheid van die site bijzonder hoog dus ik denk dat een andere site al snel minder fijn zou zijn. Volgende keer 85.159.98.33 doen?

[GateKeaper]

NSFW! Het genoemde IP verwijst naar pornhub. Test/open op eigen risico.

Waarom hebben we op tweakers nog geen 'report' optie?

[Reactie gewijzigd door GateKeaper op 23 juli 2024 12:53]

[DutchManticore]

Nou zijn punt is goed en duidelijk maar ik heb nu inderdaad wel een visit aan Pornhub in m'n werklaptop staan...

[GateKeaper]

Ja, zijn punt is goed en duidelijk. Maar hij had ook een ip van google, youtube, wikipedia, of nu.nl kunnen pakken. Dat had het net zo duidelijk gecommuniceerd.

[Tokkes]

Jij kan op je werklaptop zomaar de hostsfile aanpassen?
Jij gaat op je werklaptop zomaar naar onbekende IP adresjes?
Jij gaat gewoon naar onbekende IP adressen zonder ze even op te zoeken?
Pornhub ip ranges zijn niet geblokkeerd in de firewall?

[Reactie gewijzigd door Tokkes op 23 juli 2024 12:53]

[DutchManticore]

Nee, bedankt dat je direct alles in het ridicule trekt.
Wat denk je nou....

Ik zat op mijn werklaptop, waarop ik een VM en een VPN draai, en in die VM heb ik natuurlijk niet de hosts file aangepast...Ik wilde het IP adres Googlen, door het te selecteren, en dan met rechtermuis tweede optie te klikken.

Normaal staat daar, als je iets selecteert "Google doorzoeken op".
Nu, omdat het geïnterpreteerd werd als adres werd dat automatisch "Ga naar".
Daar had ik in de muscle memory geen rekening mee gehouden.

En nee Pornhub is niet geblokkeerd in de Firewall, blijkt.

[Tokkes]

Nee, bedankt dat je direct alles in het ridicule trekt.
Wat denk je nou....

wel, gezien veel comments, en sommige forum posts - het is goed genoeg mogelijk.

[MadEgg]

Sorry, maar ik zou op Tweakers toch wel verwachten dat je eerst een background check doet voordat je verbinding maakt met willekeurige IP-adressen.. Ik vind hem wel sterk

[GateKeaper]

Jij en ik misschien wel. Maar wij zijn al lang niet meer de doelgroep van T.net

[MaxKorlaar]

Ik ben dus mooi in je voorbeeld getrapt

[Blasterxp]

bingo, jij snapt het. DNS is de key om verkeer om te leiden, of weg te houden.

[misterbennie]

Natuurlijk heeft DNS met de getoonde pagina te maken, DUH

Er werd echter het volgende geschreven:
"Elke browser zou dezelfde pagina moeten laten zien. Dat is dus niet meer zo."

En als je een normale DNS server gebruikt, (je provider, Google, etc) is dat ook zo.
Dus dat "dit gedoe" gefilterd internet oplevert is onzin, want dan doet de DNS niet wat hij zou moeten doen.

[die4ever]

Dat is toch al lang niet meer zo, in België (weet niet of het voor Nederland ook zo is) worden een hoop "illegale sites" geresolved naar bijvoorbeeld (http://networkmsg.telenet.be/blocked/fccu/ als je Telenet klant bent). pas je DNS server aan en dat probleem is van de baan...

[misterbennie]

Daar heb je gelijk in.
Hierbij doet de DNS dus niet wat deze zou moeten doen.
Maar daar heeft "dit gedoe" niets mee te maken.

[Roel911]

... (weet niet of het voor Nederland ook zo is) ...

In Nederland krijgt men voor bepaalde sites een provider pagina te zien dat de site geblokkeerd is. Zie ook: https://www.tele2.nl/pira...-geblokkeerde-subdomeinenBijvoorbeeld een grote download site voor magnets (vroeger torrent bestanden).

[Reactie gewijzigd door Roel911 op 23 juli 2024 12:53]

[deadinspace]

DNS heeft alles met de getoonde pagina te maken. Zet de volgende regel maar eens in je hostsfile:
66.254.114.41 tweakers.net

Dan krijg ik, zoals het hoort:

NET::ERR_CERT_COMMON_NAME_INVALID

De servers van pornhub hebben namelijk niet (de private key van) het certificaat van tweakers.net.

Als de beheerder van de DNS server besluit dat een query wel een ander resultaat oplevert dan die van je provider dan kan dat gewoon.

Nee, dat kan dus niet. Althans, niet als er HTTPS gebruikt wordt, en daar zijn Chrome en Firefox (met hulp van Let's Encrypt) hard voor aan het pushen.

Begrijp me niet verkeerd, je hebt gelijk met de privacy-zorgen (de DNS providers ziet welke sites je bezoekt), en blokkeren (verkeerd DNS resultaat teruggeven) is inderdaad ook mogelijk.

Maar daadwerkelijk een andere pagina weergeven kan op dit moment niet zolang HTTPS geforceerd wordt, en dat is steeds meer het geval.

[StefanTs]

Een partij als Google is zelf CA. En tuurlijk, ze zullen vast geen fratsen van dat kaliber uithalen. Toch?

Alles van A tot Z is straks Google, wie reguleert dat?

[deadinspace]

Een partij als Google is zelf CA. En tuurlijk, ze zullen vast geen fratsen van dat kaliber uithalen. Toch?

Klopt, en in theorie kan Google daarmee een pagina vervalsen als ze ook DNS in handen hebben natuurlijk. Ze zouden wel geband worden van andere CA root trust stores, want dit is tegen de regels voor CAs.

Maar waarom zouden ze dat doen? Als Google zo graag wil aanpassen wat je ziet, dan kunnen ze dat natuurlijk gewoon in Chrome zelf vervalsen; geen DNS-over-HTTP of certificaat-vervalsing nodig.

[ViTO_xp]

Het gaat in dit geval niet over de private key, maar juist over de public key ;-)

[deadinspace]

Het gaat in dit geval niet over de private key, maar juist over de public key ;-)

Nee, het gaat om de private key. Om te bewijzen dat je browser met https://tweakers.net/ praat moeten de webservers van Tweakers de private key van het certificaat hebben. En die hebben de PornHub servers niet (hoop ik).

De public key van https://tweakers.net/ kan iedereen triviaal aankomen, die staat namelijk gewoon in het certificaat. Hier, ik heb hem zelfs:

Modulus (4096 bits):
D2 AF 8F C4 1F C5 24 E3 04 8A CB 47 C5 CF 16 B4 D9 7E EC 1A 80 EE 0A D0 A8 A2 7E B3 B4 E6 16 DD DD 9F 82 18 83 C7 3E 8B EE 17 0F D0 CE 67 3D 0C 23 59 5F 54 BA FB E0 D3 5C 1F 5B 15 EA 9C 2A C9 3A C0 5D 46 43 F7 88 D0 9A C9 82 14 5F BF 2F 2A BD E0 A9 25 27 69 C1 87 18 B4 44 3E 7A AC 8A 4F E9 50 60 B5 5C B3 D8 0D 7C E3 06 68 63 6E C2 CC 4F AD A2 7F A7 5B E7 22 AC AF 07 C4 C9 D4 BA 14 97 AE D5 31 9B 6D D0 7F 28 B7 1B 5A 5D 45 CB F6 75 7F D5 1A EF 67 9E 5D 57 E8 0F 73 C3 C8 68 25 9D 7C 56 D3 C4 C9 40 04 00 04 AF E6 41 9D 96 AF 89 47 51 24 B2 82 E2 57 F9 A8 D3 C5 9F 0C 17 35 56 AD AB 36 51 B3 36 B3 69 FA CE 04 31 AC 30 F2 DA 9F C3 94 F6 C7 D0 B8 48 07 FC 33 51 3D 9D EB D2 F9 9B DE 1D 4A BD EB 1B FE 56 2D 4D D5 21 CB 14 F9 51 79 98 54 D7 FA 39 D0 29 AF 37 E5 EF ED EE FE 20 C6 0D 7C BE 39 94 F7 C0 0A CE EE EE 24 55 C8 22 97 F4 A6 F1 93 16 BA 6E F8 13 C9 1E 1C C8 C9 E1 48 5D 96 89 D2 B7 1D 37 B6 94 8F 91 D5 11 B4 8E 79 1B F4 F3 B6 D6 D3 30 D9 71 EB 45 31 1E E3 74 C6 29 81 A8 80 AB 90 B4 CC D5 A3 CD 00 C1 93 3B 20 5D 38 EB BE 9B 62 16 05 44 6E 91 64 17 E0 C3 84 D8 48 8B 09 57 01 D9 D3 7F FD 37 E7 66 70 9C 24 A7 7C 4F 97 6C 6A E3 E2 4D 11 F2 58 F8 6A A4 9B A0 F9 A7 13 1A 86 01 34 69 13 FC D7 66 22 DB 53 41 C2 9D AC 35 DA 0B B5 C1 FC 36 32 DD 4F E7 A5 45 86 06 8F EC BC 99 AB 37 B1 86 A7 E7 33 1D C7 4E 29 07 59 C0 35 F9 70 85 93 11 E9 DF 7E 97 9D DD 46 3F 9B D8 D4 DC 50 2D AB 58 56 5A 7F 64 73 63 BE 98 FE 5C 3F 49 C2 7A F3 44 E1 CE E9 DB B5 94 1D 54 96 50 B8 1B F9 A3 C3 EF D2 E3 0C F5 46 B7 6E 37 19 FD 14 18 67 41 69 72 A3

Public Exponent (24 bits):
01 00 01

[Reactie gewijzigd door deadinspace op 23 juli 2024 12:53]

[ViTO_xp]

Eh...

Het betrof zijn uitleg van de foutmelding: NET::ERR_CERT_COMMON_NAME_INVALID

JIj als client kunt de private key niet checken (duh).

Die kun je dus alleen checken op de public key die aan jou gegeven wordt ter identificatie

[Archcry]

Volgens mij verandert er niks aan de huidige situatie hoor. Zoals in het artikel beschreven wordt er gebruik gemaakt van de DNS server die jij ingesteld hebt als gebruiker. Kies je er echter voor om een van de ondersteunde DNS servers te gebruiken dan wordt er gebruik gemaakt van DOH. Met andere woorden, voorheen had je de keuze, nu heb je nog steeds de keuze.

[Lethalis]

Nee, wat Firefox doet is zelfs erger (het standaard instellen, gelukkig alleen in de VS voorlopig).

[Reactie gewijzigd door Lethalis op 23 juli 2024 12:53]

[kozue]

Onzin. Dan moet je de reacties op het Firefox artikel eens lezen. Die waren helemaal niet zo positief. Ik heb na het lezen van dat artikel gelijk iets in de about:config veranderd om het helemaal uit te zetten.

Maar behalve dat, zelfs al zou er bij Google artikelen meer geklaagd worden over privacy: dat heeft Google helemaal aan zichzelf te danken. Mozilla is over het algemeen veel privacy-vriendelijker. Alhoewel ik net niet eens ben met Mozilla’s keuze, snap ik wel dat het voor bepaalde gebruikers de privacy kan vergroten. Vooral voor Amerikanen met een ISP die hun DNS requests datamined... (volgens mij is dat in NL niet gebruikelijk, ik ken geen ISP waarvan bewezen is dat ze het doen)

[Reactie gewijzigd door kozue op 23 juli 2024 12:53]

[Anoniem: 58485]

Als je de DNS van google nu gebruikt dan is dit al zo. Ik heb vaak genoeg gehad met gebruik van Google DNS dat een dev omgeving van een website ineens geindexeerd stond in de search. Ik kon niet anders concluderen dat Google DNS in combinatie met Google Search werkt.

[Lethalis]

Daarom gebruik ik de Google DNS ook niet. Sowieso gebruik ik mijn eigen DNS server (resolver op PfSense).

Nooit gezeur met DNS servers die down zijn En zonder dat Google elke DNS query van mij indexeert.

Website suggesties zet ik ook altijd uit... zodat dingen die ik in de adresbalk intik ook niet bij Google eindigen.

Maar goed, als het allemaal zo doorgaat, stap ik wel over op open source Chromium. Dan heb ik er alle controle over.

En daar heb ik desnoods ook wel 5 uur lang zelf compileren voor over

[Reactie gewijzigd door Lethalis op 23 juli 2024 12:53]

[Anoniem: 58485]

Als je de DNS van je ISP gebruikt, en wat vroeger zo bij Ziggo / voorheen @ home zo was, dan kon je er vanuitgaan dat iedere zondag websites gewoon zienbaar trager waren. Mijn conclusie is dat de openbare DNS van die ISP een extreem veel aantal DNS queries voor hun kiezen kreeg en daarom de neiging naar een andere (en wel snellere) DNS wenselijk was. Of gewoon de First / Secundaire omwisselen met elkaar.

Maar dit applaudiseer ik eigenlijk toe, dat ook de websites en URL's die je bezoekt over DNS 'beschermd' zijn. We hoeven ons niet langer meer te verbergen achter een TOR als het allemaal echt zo spannend en secret moet zijn.

[dasiro]

blijf dan maar al ver weg van chrome, 8.8.8.8 en 8.8.4.4 en alle andere alternatieve DNS-providers dan die van je provider

[Lethalis]

Ik draai dan ook mijn eigen DNS server.

Chrome niet gebruiken is moeilijker. Om de simpele reden dat ik nooit echt vriendjes met Firefox ben geworden en te arm ben om een Mac te kopen.

Over Edge wil ik niet eens praten.

[olson]

Kijk eens naar Vivaldi?

[Anoniem: 470811]

En waar resolved jouw DNS server naar toe? Naar een andere DNS-server? Of rechtstreeks naar de root-servers van alle tld's?

[Lethalis]

Rechtstreeks.

[4x4]

Onze staat geeft jouw gegevens met het grootste gemak aan de VS.
Google anders op 5 eyes, 9 eyes en 14 eyes.

[Lethalis]

Dat geloof ik zomaar.

Alleen Google en consorten maken er ook meteen gebruik van op een commerciële manier.

[grimlock]

Interessante ontwikkeling, welke DNS forward settings zou je nu in je organisatie willen aanbevelen om zo veilig mogelijk het internet op te gaan?

[PD2JK]

PiHole, Sophos UTM of XG als gateway, OpenDNS FamilyShield

Mogelijkheden genoeg.

[well0549]

NextDNS

[dehardstyler]

Zelf een DNS server draaien?

[Rob]

Een eigen DNS server krijgt zijn informatie van andere DNS servers.

[-iemand-]

Niet helemaal.
Je kunt inderdaad alles vragen aan je provider, maar je kunt natuurlijk kaal beginnen en alleen een (hardcoded) lijstje met servers voor de TLDs gebruiken.

Vanaf daar vraag je voor iedere TLD aan die root servers op welke DNS server het TLD kan resolven. Vanaf die DNS server krijg je dan weer terug wat je provider je anders verteld had.

Mocht je je afvragen hoe je aan die initiele lijst met rootservers komt, die zit meegeleverd wanneer je bijvoorbeeld bind9 installeerd

De root zone, mocht iemand zich afvragen hoe dat er uit ziet: https://www.internic.net/domain/root.zone
(En als je die link aanklikt doe je zelf ook een beetje dns-over-https , zo ingewikkeld is het dus niet)

[Reactie gewijzigd door -iemand- op 23 juli 2024 12:53]

[L0g0ff]

Die link van jou is dns-over-http

[-iemand-]

Oh ja, inderdaad ... (fixed)

[Jerie]

Blijft een rommeltje al die TLDs die niemand gebruikt.

[richard1074]

Je internetprovider heeft altijd een DNS server die je kan gebruiken I.p.v. dit. Ik zet het gelijk uit als het standaard aan staat.

[dehardstyler]

De vraag gaat over een "organisatie". Wij draaien onze eigen DNS server, vandaar dat ik dat aangaf.

@Rob Dat klopt en wij kiezen dan op onze eigen server welke websites allemaal op 127.0.0.1 gevonden kunnen worden.

[Rob]

Klinkt als een PiHole constructie

[dehardstyler]

Ja, alleen dan voor 16.000 werknemers, verspreid over de hele wereld.

edit: typo

[Reactie gewijzigd door dehardstyler op 23 juli 2024 12:53]

[bbob]

De ontwikkeling is interessant alleen dat men zoals firefox maar 1 dns provider heeft ook google nu 6. Dit zou je gewoon zelf moeten instellen, dus ook dns provider die reclame er al uit filteren, iets dat google natuurlijk liefst niet wil. Als ik het vanuit die achtergrond bekijk zullen er dus niet snel dns providers op de lijst komen die reclame er standaard uit halen.

[Anoniem: 1322]

Latency is het belangrijkste in ieder netwerk. Je gebruikt dus altijd de DNS servers van je eigen provider.
Wanneer je een **** provider hebt en geen gebruik wilt maken van hun DNS servers dan is CloudFlare meestal de best optie. Zie ook: https://www.dnsperf.com/
Gezien CloudFlare ook een goede privacy policy heeft gebruik ik deze vaak als fallback.

Wil je zelf testen dan kan dat met deze tool:
https://www.grc.com/dns/benchmark.htm

[Lethalis]

Wij draaien PfSense met de DNS resolver. Dat is in feite gewoon een geïntegreerde DNS server.

Draai ik thuis ook. Als je een managed switch met vlan tagging hebt, kun je van elke NUC een router maken.

[HellStorm666]

Hoe gaat dit icm Pihole?
Ik heb Pihole draaien welke 1.1.1.1 en 8.8.8.8 en OpenDNS gebruikt als resolvers.
Maar m'n PC/browser gebruikt natuurlijk de Pihole als DNS.
Gaat dit dns verkeer dan alsnog over HTTPS (al dan niet vanaf Pihole)?

[Fonta]

Je kan op de machine waar je pihole draait bijvoorbeeld cloudflared als een service draaien waarna je pihole instelt om daar zijn dns request te doen wat dan vervolgens via https naar bijvoorbeeld 1.1.1.1 gaat.

https://docs.pi-hole.net/guides/dns-over-https/

Aangezien pihole geen doh aanbied, zal de verbinding tussen jou en de pihole gewoon via het dns protocol blijven gaan.

[Reactie gewijzigd door Fonta op 23 juli 2024 12:53]

[L0g0ff]

De implementatie van chrome zal gewoon blijven gaan zoals het nu gaat (je pihole zal gewoon dns server blijven en die blijft gewoon zijn data via poort 53 naar cloudflare of Google sturen). Gebruik je echter Firefox dan zal die je pihole straks compleet bypasssen en gooit hij al je dns verkeer via DoH naar 1.1.1.1.

Maar in de volgende release van je pihole zal er voor gezorgd worden dat de DoH van Firefox uitgezet wordt. Een update is dan voldoende.

[Jerie]

Maar in de volgende release van je pihole zal er voor gezorgd worden dat de DoH van Firefox uitgezet wordt. Een update is dan voldoende.

Bron? Volgens mij moet je in Firefox network.trr.mode op 5 zetten om DoH nu (en in de toekomst) uit te schakelen.

[L0g0ff]

Medetweaker @jpgview melde dit op GoT: https://gathering.tweaker...message/59939326#59939326

Bron: https://github.com/pi-hole/pi-hole/pull/2915/files

[Jerie]

Nice, dankjewel. Toch moet het in een andere config file dan 01-pihole.conf. Zie de comments op https://github.com/pi-hol...r/advanced/01-pihole.conf

[jpgview]

Net pihole v4.3.2 (gisteren gereleased) geinstalleerd van scratch (nieuwe installatie). De firefox fix is NIET opgenomen in deze release. Het is dus nog steeds noodzakelijk de setting manueel toe te voegen!!!

meer info, zie forum post...

[mkools24]

Voor mij hoeft dit allemaal niet, het wordt wel heel verwarrend zo, je browser die dan wellicht een andere DNS server gebruikt dan je ingesteld hebt staan. Net als Windows die gewoon de hosts file negeert voor Microsoft adressen.

Ok geldt nu nog niet voor Chrome maar dat is natuurlijk de volgende stap.

Nog even en je kunt zelf geen DNS provider meer kiezen.

[Djordjo]

Voor mij hoeft dit allemaal niet, het wordt wel heel verwarrend zo, je browser die dan wellicht een andere DNS server gebruikt dan je ingesteld hebt staan.

Heb je het artikel wel gelezen?

Bij de implementatie van Google kijkt de browser of de dns-aanbieder van de gebruiker op de lijst staat om van een doh-dienst gebruik te kunnen maken. Is dat niet het geval, dan verloopt de verbinding als vanouds.

[mkools24]

Ja dat heb ik zeker gelezen maar ik zeg al dat is de eerste stap, daarna wordt ook dat genegeerd.

[DarkForce]

Dat heb je voor een (groot) deel ook zelf nog in de hand.
Als jij verkeer op poort 853 blokkeert, dan werkt DoH al niet meer voor zover ik begrepen heb.

In dat geval wordt dan alsnog teruggevallen op de wel bereikbare DNS Servers die gebruik maken van poort 53.

[Dutch2007]

DoH werkt over port 443 ;-) e.g. zoals https ook over werkt

zie: https://labs.ripe.net/Mem...-dns-over-https-explained (en dan onderaan). --> Experimenting with DOH

[Reactie gewijzigd door Dutch2007 op 23 juli 2024 12:53]

[DarkForce]

Ah wacht, DoT werkt over 853 inderdaad ...

In dat geval kan het internet (op termijn) nog wel eens flink gaan veranderen als browsermakers gaan bepalen hoe maar vooral ook WIE als resolver gaan fungeren.

[Sleurhutje]

Mijn idee. Dit is Google's manier om DNS Blockers buiten spel te zetten zodat ze je weer advertenties aan kunnen bieden en tracking efficiënter kan werken. Je encapsulate gewoon DNS verkeer in https zodat je er minder invloed op uit kunt oefenen.

[poktor]

Vreemde gang van zaken. Negeert firefox dan gewoon de ingestelde dns-setting in je netwerkomgeving? Ik neem aan dat je dat dan kunt aanpassen?

[Uchy]

Ja, dat kan inderdaad makkelijk. Ik verwacht ook uiteindelijk via policies

[GertMenkel]

Je kunt een eigen DoH server instellen of DoH uitzetten. Ook wordt DoH in Firefox uitgeschakeld als de beheerder van de lokale DNS-server een NXDOMAIN antwoord op een bepaalde domeinquery instelt.

[Anoniem: 1322]

Met Chrome for business kun je de ingebouwde DNS client uitschakelen.

[Caayn]

Bij de implementatie van Google kijkt de browser of de dns-aanbieder van de gebruiker op de lijst staat om van een doh-dienst gebruik te kunnen maken. Is dat niet het geval, dan verloopt de verbinding als vanouds.

Ik vind Google's implementatie van DoH dan netter gedaan dan die van Mozilla. Hanteer de DNS van de gebruiker en schakel over naar DoH indien mogelijk.

Had het wel nog een stukje beter gevonden als de browser gewoon controleert of een DNS provider DoH ondersteunt in plaats van met een whitelist te werken.

[davekok]

Gaat waarschijnlijk in de toekomst ook gebeuren. Maar voor nu is het even marketingtechnisch handig om je partners te benoemen. Daarnaast is het voor debuggen handig om te weten wie er mee doen aan de test. Zodat je snel kunt schakelen tussen de devteams.

[BernardV]

Ik vraag me af hoe Chrome weet welke DNS-server(s) ik gebruik. Ik dacht altijd dat er een request bij het OS gedaan werd en dat de browser dus niet zelf de server benaderd.
Ook aangezien een hosts-file op systeem werkt in een browser.

Dus als Chrome kan weten welke servers ik gebruik zullen ze misschien een DNS request doen waarop de verschillende DNS-providers anders reageren?

[mozoa]

Denk dat de voornaamste reden waarom bijvoorbeeld PowerDNS niet op de lijst staat is omdat ze geen normale DNS servers aanbieden, enkel DoH.

En juist omdat Chrome controleert welke DNS servers er bij de gebruiker staan ingesteld, en, PowerDNS dus niet als DNS server kan worden ingesteld kan er hiervoor niet op DoH worden overgeschakeld. (Wat ook weer niet nodig is want als je PowerDNS gebruikt gebruik je al DoH op een andere manier)

Verder wel een mooiere implementatie dan dat Mozilla dat heeft gedaan, standaard voor 1 provider kiezen terwijl gebruikers mogelijk hun keuze al hebben gemaakt is een beetje jammer.

[Reactie gewijzigd door mozoa op 23 juli 2024 12:53]

[Ventieldopje]

Meh, waarom doen ze niet zoiets?

Check of huidige DNS DOH ondersteunt, zo ja dan hup gaan met die banaan. Zo niet, pak een DOH provider uit de lijst.

Lijkt mij een beetje onnodig moeilijk doen om ook verplicht te stellen dat de DOH provider ook normale DNS ondersteunt. Wat zijn de andere criteria, of ze wel bonen koffie hebben daar?

[Reactie gewijzigd door Ventieldopje op 23 juli 2024 12:53]

[gertvdijk]

PowerDNS levert software, geen publieke dienst. Ja, er is een publiek bereikbare DoH resolver, voor testing purposes om te stimuleren dat mensen met DoH via dnsdist aan de slag gaan.

quote: https://mailman.powerdns....t/2018-August/000466.html

we are also offering our own experimental DoH service through https://doh.powerdns.org

Voor implementatie in een browser/device zijn er andere garanties nodig natuurlijk.

[freaky]

De toegevoegde waarde ontgaat me een beetje. Snap sowieso niet waarom je DNS in HTTPS zou willen tunnelen, kunt net zo goed SSL over DNS gooien (op UDP wellicht wel wat lastiger).

Roept wel direct wat vragen op:
1) Hoe gaat ie die HTTPS host vinden die de DNS tunneling regelt? Hardcodec op basis van IP? Anders moet ie eerst een reguliere DNS query doen lijkt me.
2) Geen idee hoe dit afvangt dat ze niet meer kunnen zien welke website bezocht worden Wellicht voor SNI, maar gezien met SNI tegenwoordig eerst de domeinnaam overlegt wordt voor encryptie gestart wordt zodat het juiste certificaat overhandigt kan worden in het geval van vhosts is het nog steeds zichtbaar m.i., of is dat inmiddels ook dicht getimmerd?

[EraYaN]

DNS over TLS is gewoon nog iets minder volwassen, dat zal de end game wel worden denk ik zo.

[beerse]

De reden voor dns over https is vooral voor alles wat onderweg wordt meegelezen. Als je dns via het dns protocol gebruikt, dan kan iedereen dat heel eenvoudig mee lezen op basis van het poort nummer en het verzoek/antwoord. In het slechtste geval kan het worden onderschept en beantwoord met iets heel anders dan van de echte dns server.

Zodra je dns over https gebruikt kan onderweg niet eens gezien worden dat het dns verkeer is. Alleen het feit dat het naar een dns-over-https provider gaat geeft een idee. Maar dan moet het nog worden uitgepakt om de gewenste info te krijgen en daar is de s in https de volgende horde die genomen moet worden.

Hier in Europa en vooral in NL zijn de dns servers van de providers goed te vertrouwen. In andere delen van de wereld is dat vaak minder. Als je dan een andere dns server gebruikt zou de provider of ieder ander ergens onderweg dat signaal kunnen oppakken en zelf beantwoorden zonder dat je het door hebt.

[Tetraquark]

hier even weer een voorbeeld hoe google GDPR omzeilt. Dus ik moet altijd hardop lachen als hier op tweakers weer zonder enige kritische noot Googles propaganda wordt geplaatst
https://brave.com/google-gdpr-workaround/

[P_Tingen]

Ik gebruik Blokada om advertenties te weren op mijn telefoon. Bij het lezen van dit bericht vroeg ik me af of die blijft werken met dit soort technieken. Heb ik het goed dat dit straks dan nog steeds werkt omdat Blokada lokaal draait op mijn telefoon en dus al de uitgaande calls blokkeert nog voordat die geresolved zijn door een DNS service?

[Anoniem: 169091]

Blokada simuleert een VPN (weliswaar naar de eigen telefoon).

Bij firefox gaat Blokada sowieso niet werken omdat Firefox de gebruikelijke DNS volledig buitenspel zet. Blokada ziet dan alleen een https request naar CloudFlare en kan daar dus helemaal niets mee. Je zult dan DoH in firefox uit moeten zetten.

Voor Chrome durf ik het niet te zeggen.

[well0549]

NextDNS instellen op je telefoon

[telenut]

Kan je hiermee dan voorkomen dat uw werkgever ziet naar waar je surft?
En omgekeerd: kan je als werkgever dit tegenhouden zodat je nog altijd ziet naar waar iedereen surft?

[Brahiewahiewa]

Tuluk niet. Nadat je de DNS query hebt gedaan, maak je toch contact met de website in kwestie?

[[Roland]]

Ja, dat voorkomt dat je werkgever ziet waar je naar surft..

waarschijnlijk kan je werkgever dit tegen houden door instellingen in Chrome te managen en het instellen van DoH uit te zetten. Niet elke werkgever doet dat.

Ik geloof trouwens niet de meeste werkgevers het internet gebruik van werknemers in de gaten houden. Dit zullen ze pas doen wanneer daar reden voor is dan heb je denk ik een ander probleem (maar dat staat los van je vraag).

[Trommelrem]

Het heeft ook geen zin. Niemand verbindt z'n telefoon nog met bedrijfsnetwerken. Met ongelimiteerde 4G abonnementen kun je veel sneller internetten dan over Wireless Fidelity. Via MDM kun je veel dingen niet monitoren.

[Archcry]

Je werkgever kan er natuurlijk altijd voor kiezen om verkeer binnen het bedrijf via hun eigen DNS server te laten verlopen en te forwarden naar aan DNS server buiten het bedrijf. Al dan niet met DoH.

[beerse]

De zaak kan dit blokkeren door het http en https verkeer naar de dns providers te blokkeren, zoals ze mogelijk ook porno en zo blokkeren.