Ik zou geen "DoH" gebruiken, want het is een (non-)oplossing voor een probleem dat hier niet speelt.

Toch "DoH" gebruiken betekent dat je nu al je queries aan een (Amerikaans) bedrijf uit een veel kleiner lijstje weggeeft, dus waar de trade-off in de VS al niet erg smakelijk was, hier is'ie bijkans volstrekt onzinnig.

Dus ik zou gewoon de DNS-servers gebruiken die de ISP me aanreikt en eventueel een DNS-cache op m'n eigen netwerkje draaien.

Dat je toch tegen alle indicaties in met "DoH" wil spelen moet je zelf weten maar er zijn geen beste keuzes met dit ding, anders dan het gewoon niet te gebruiken.

OpenDNS met allerlei filters. Ik gebruik het al eeuwen.

Ik merk wel dat niet alle apparaten/software zich netjes houden aan de opgegeven DNS dienst. Mijn Chromecast maakt regelmatig verbinding met GoogleDNS en mijn Android telefoon is een stuk trager als ik 8.8.8.8 en 8.8.4.4 blokkeer.

Draai je eigen recursive DNS server met bijvoorbeeld Unbound of Knot. Unbound heeft ook ondersteuning voor DoT en volgens mij kan Knot zowel DoT als DoH praten. Waarom een overzicht van alle websites die je bezoekt naar een derde partij versturen voor iets wat je ook zelf kan draaien?

Dat betekent dat er minder gecached wordt en dus de werkdruk op (oa de root)servers verhoogt. Oftewel, dat is een prima optie als je a) weet wat je doet en b) je netwerkje toch een beetje grootte heeft. Voor verreweg de meeste mensen is dat niet echt het geval, dus als algemeen advies is het minder geschikt.

Voor "DoH"-providers is dat inderdaad precies de vraag. Je ISP kan het ook wel uit je verdere verkeer trekken als ze het echt willen weten. En als je je ISP niet vertrouwt, wat doe je dan nog bij ze? Dat is wat "DoH" tot zo'n ontzettende non-oplossing maakt.

Waarom ze het in de VS dan toch willen? Nou, omdat browserknutselaars graag met browsers knutselen en daar liefst zoveel mogelijk andere dingen ook in willen betrekken, en omdat in de VS je vaak helemaal geen keuze hebt qua ISP. Ondanks "vrije markt" en alles, ha ha, het ISP-gebeuren is gewoon een regionaal monopolie. Dus die kunnen zich ook veel makkelijker misdragen, advertenties in je web-connecties injecteren, geintjes uithalen met DNS, en zo verder. Maar dat is hier veel minder. Hier kun je toch nog vrij makkelijk van ISP wisselen als ze er een zooitje van maken.

In jouw lijstje missen de meestgebruikte dns servers: Die van kpn, ziggo etc, want de meeste mensen gebruiken die van hun ISP.

Volgens mij is lezen ook een vak, het lijstje begint:

Je kunt in je eigen router (als dat een beetje een fatsoenlijk ding is) de queries vanuit je eigen netwerk naar een andere
DNS server dan je zelf instelt omleiden naar je eigen voorkeur. Dwz je eigen router of die OpenDNS adressen.

Nu het nog kan. Want als "men" straks forceert dat we allemaal naar DoH gaan dan is dat niet meer mogelijk.

DNS server van mijn VPN provider.

Ik schaam me diep. Het bericht is ook niet bewerkt, dus ik was echt blind.


Als je de server in je router aanpast, betekent het nog niet dat hij altijd gebruikt wordt. In mijn nas zie ik in sommige config bestanden de waarde 8.8.8.8 als backup dns server ingevuld. En als ik de ervaring van 'anoniem 12:40' zie, dan negeert bepaalde software op zijn telefoon ook de DNS server die via dhcp doorgegeven wordt.


DoH forceren zonder alternatief zal nooit gebeuren. Er zijn genoeg bedrijven die met eigen DNS servers werken om een intranet te beheren. Dat hele intranet zou onbereikbaar worden als je DoH forceert. Dat kan nu al gebeuren met DoH als default, maar de aanwezigheid van een, op een bepaalde manier geconfigureerde DNS server, zorgt ervoor dat DoH uitgeschakeld wordt.

Ik heb goede verhalen gelezen over Cloudflare. Cloudflare biedt een eigen DNS service aan die naar eigen zeggen zorgt voor de snelste response tijd (reactietijd), ongeëvenaarde redundantie en geavanceerde veiligheidsmaatregelen zoals een ingebouwde DDoS blokker en DNSSEC.

Doordat het Cloudflarenetwerk verspreid is over 200 servers wereldwijd is er een 100% uptime (bron: https://www.hipex.io/cloudflare/)

In een onderzoek over de snelheid van DNS providers werden grote DNS registrars als Quad9, Google, Norton DNS, Yandex, Comodo en dus ook Cloudflare met elkaar vergeleken en getest.

Cloudflare bleek in 72% van de gevallen de snelste te zijn met een gemiddelde van 4.98 ms.

Krijg je ook betaald voor deze sluikreclame of laat je je gewoon geheel belangeloos als reclameman inzetten?

Dat klinkt leuk tot je snapt hoe robuust DNS eigenlijk is, en dan is het om en nabij compleet betekenisloos.

Dat zijn hele leuke cijfertjes, alleen heb je er als eindgebruiker he-le-maal niets aan.

Bijvoorbeeld een kabelmodem moet voor elk te versturen pakketje toestemming vragen aan het head-end en dat betekent dat er op elk te versturen pakketje minimaal 4-tot-8 ms wachttijd voor dat toestemming vragen bijkomt. Dus dat getal zal niet op een thuisaansluiting gemeten zijn. En als je provider z'n huiswerk goed gedaan heeft dan zitten hun servers dichter bij jou op het netwerk dan alles wat in dat "gemeten" lijstje staat en dan zijn ze al gauw sneller.

En het snelste is altijd het antwoord dat je "toch al" hebt, oftewel de cache op jouw computertje of op je eigen netwerkje.

Ik betwijfel of het zo'n verschil gaat maken. Allereerst kan je vrij eenvoudig een lokale kopie van de root zone file gebruiken (en elke 24 uur verversen). Daarnaast zullen grote DNS providers ook niet altijd een antwoord paraat hebben, helemaal als ze gebruik maken van EDNS Client Subnet (ECS) zoals Google (Cloudflare niet overigens). Als laatste is het mogelijk om een eigen minimale TTL in te stellen voor andere queries (niet altijd aan te raden, maar het overwegen waard). Het gebruik van prefetching (i.c.m. lokale root zone) zorgt er voor dat het performance/latency verlies minimaal is. Het instellen van een eigen recursive zal wel meer inspanning vereisen dan al je gegevens direct naar Google te sturen, wat dat betreft heb je zeker gelijk.

De DDoS blokker zal in dit geval betekenen dat jou queries geen antwoord krijgen. DNSSEC heeft pas een echte meerwaarde als je de validatie zelf uitvoert. Anders is het altijd mogelijk dat Cloudflare jou de verkeerde antwoorden geeft, dat is precies wat je wilt voorkomen.

Verkijk je niet op dit soort getallen. Caching van veel gebruikte queries op je eigen pc heeft gemiddelde snelheid van 0.00 ms. Wat dat betreft is het leuk voor de statistiek maar zegt het niet direct iets over hoeveel sneller je internet gaat voelen in de praktijk. Helemaal als je bedenkt dat Cloudflare niet goed samen (schijnt) te gaan met geografische load balancing via DNS. Met andere woorden je DNS antwoord is snel binnen maar de server waar je verbinding maakt staat verder weg dan nodig is. Zie ook deze blogpost: https://www.sajalkayan.com/post/cloudflare-1dot1dot1dot1.html

<samengevoegd met eerdere reactie>

PowerDNS

Info : https://powerdns.org/
DoH service: https://doh.powerdns.org/

Daarom zeg ik ook "Je kunt in je eigen router (als dat een beetje een fatsoenlijk ding is) de queries vanuit je eigen netwerk naar een andere DNS server dan je zelf instelt omleiden".
Dwz als er vanaf je LAN een query naar 8.8.8.8:53 gestuurd wordt dan zegt je router "hebbes" en vervangt die 8.8.8.8 door zijn eigen IP adres (DNAT) en handelt em zelf af.
Daar heeft je client geen zeggenschap in.
Behalve als die DoH ingesteld heeft want dan kun je dit omleiden niet zomaar doen.


DoH forceren zonder alternatief zal nooit gebeuren. Er zijn genoeg bedrijven die met eigen DNS servers werken om een intranet te beheren. Dat hele intranet zou onbereikbaar worden als je DoH forceert. Dat kan nu al gebeuren met DoH als default, maar de aanwezigheid van een, op een bepaalde manier geconfigureerde DNS server, zorgt ervoor dat DoH uitgeschakeld wordt.[/quote]
Het weghalen van Java support uit browsers gaat ook nooit gebeuren, want er zijn genoeg bedrijven en consumenten
die nog applicaties of spullen hebben die ooit met als uitgangspunt de beschikbaarheid van Java in de browser gemaakt
zijn. Ook http gaat nooit problemen geven (zoals browsers die http als VERDACHT markeren of zelfs zelfstandig
naar https omzetten).

Nee, als er IETS is wat browsermakers niks kan schelen dan is dat wel de compatibiliteit met lokale situaties en andere
opstellingen dan ze zelf op hun bureau hebben. Dan migreren ze de boel maar!
(en oja, een lokaal netwerk met een intranet server erop die alleen op een interne DNS beschikbaar is, dat is ouderwets)

https://blog.uncensoreddns.org Is een privé-initiatief en gebruik het om mijn provider niet een kant-en-klaar lijstje te bezorgen.

Onze vrienden van Google wensen zich niet aan standaarden te houden en willen heel graag jouw DNS data verzamelen. Dat is de reden dat ze in veel van hun producten (alle?) ALTIJD 8.8.8.8 en/of 8.8.4.4 (ja die dingen van Google) gebruiken.
Je weet toch wel dat Google devices ontworpen zijn om data te verzamelen voor Google, dit is zo'n maatregel dat je geen andere DNS kunt gebruiken.

Da's interessant. Ik draai hier ook een eigen DNS server en poort 53 naar buiten is geblokkeerd (dus niet 8.8.8.8/8.8.4.4 in zijn geheel, alleen de DNS poort). Als blokkeren van de google DNS IP adressen je toestel trager maakt, dan lijkt het erop dat er op andere poorten verbinding wordt gemaakt.

Binnenkort eens loggen wat er naar deze Google adressen gaat.

Aha, dat verklaart waarom kabelinternet een relatief hoge latency heeft. Het valt mij altijd op dat bij mensen met kabelinternet de ping tijden relatief hoog zijn en inderdaad zo'n 5 a 6 ms hoger liggen dan ik van de wat snellere netwerken gewend ben.

Waarmee je de werkdruk verplaatst, en relatief nog verder verhoogt.

Nee, maar daar zit wel degelijk een groot gradatieverschil tussen.

Ze zien namelijk veel meer queries en hebben dus veel meer materiaal om te cachen. En laten we wel wezen, verreweg de meeste van ons gebruiken voor het overgrote deel van de tijd maar een kleine handvol aan websites en daarmee een iets grotere handvol aan hostnamen en dus DNS-queries. Dus zo'n grote provider heeft een veel grotere kans om in de laatste paar minuten al iets vergelijkbaars gevraagd te hebben zien worden.

Het gaat dus ook niet om wat je zelf als eindgebruiker direct kan merken, maar om dat als heel erg veel mensen dit geintje uit gaan halen dat dat wel eens een probleem kon gaan worden. Zeker je ISP vindt het wat minder leuk want hun caching servers reduceren ook hun verkeer op de uplink en dus hun verkeerskosten.

Als je zelf een recursor gaat draaien, begeef je je op het vlak van wat een netwerk-administrator normaliter doet, en daar komen dit soort bedenkingen ook bij kijken. Dus ietsje verder kijken dan je neus lang is en een beetje rekening houden met wat de ISP en de rest van de wereld belangrijk vinden.

In die zin is het ontstaan van "DoH" een backfire tegen de Amerikaanse ISPs zelf die zich nogal misdroegen in het beantwoorden van de DNS-queries van hun klanten. Dat gebeurt, zoals opgemerkt, hier te lande niet dus is "DoH" een oplossing zonder probleem, en wel redelijk wat vervelende bij-effecten.

En google is een notoire datagraaier. Je ISP kan je iets meer vertrouwen. In Nederland toch wel, en anders is het tijd om van ISPs te veranderen, en dat kan ook in Nederland toch wel.

Ook erg slecht voor die "100% uptime".

Wat dat betreft is de opzet van DoH echt een ontzettend slecht idee. De "DoH"-provider kan nog zo hard volhouden echt alles nagekeken te hebben, jij kan het niet verifiëren.

Dat kost weer extra miliseconden op elke volgende http(s)-verbinding, waarvan je soms wel honderden nodig hebt om een hele pagina te laden. Best kans dat elke "DoH"-aanbieder dat probleem heeft.

Anders: https://docs.pi-hole.net/guides/unbound/

Ja, ieder apparaat op je lokale netwerk kan men zelf laten bepalen welke DNS-server het gebruikt.
Soms is het van fabriekswege ingesteld en kan je het in het apparaat niet of in ieder geval niet gemakkelijk aanpassen.
Hoewel i.g.v. Google zou je misschien je router/gateway IP op 8.8.8.8 kunnen configureren in je router,
waarmee je de router toch weer bepalend laat zijn als een apparaat zijn DNS-request rechtstreeks naar 8.8.8.8/53 probeert te sturen. (officieel niet aanbevolen, maar het hoeft er niet minder om te werken als de router niet tegenstribbelt bij het configureren van 8.8.8.8 als router/gateway IP en je geen DMZ oid aan hebt staan. En verder moet je er wel even rekening mee houden dat 8.8.8.8 van Google dan vanaf je lokale netwerk totaal onbereikbaar wordt, maar dat is misschien juist wel gewenst. Echter ook andere 8.8.8.xxx adressen op internet kan je dan niet meer bereiken. Maar het zou wel toevallig zijn
als je die net nodig zou hebben.
8.8.4.4 is dan overigens niet onbereikbaar, maar die kan je eventueel blokkeren met een IP-filter als je kan en wil)

Maar voor de rest: een apparaat kan dus zijn DNS request naar je router gateway sturen (bijv. 192.168.0.1/53)
zodat de DNS-instellingen van je router de DNS-server zullen bepalen, óf het apparaat kan zelf de DNS-server kiezen
door de DNS-aanvraag "direct" naar de gekozen DNS-server te sturen, bijv. 8.8.8.8/53.
(in dit laatste geval dient je router/gateway slechts als doorgeefluik)

Dit is geen slim plan. Als je DNS queries naar je provider stuurt weet niemand (behalve de provider mits die query logging heeft aanstaan) wat je interesses zijn. Draai je je eigen name server dan typeert dat jou bij uitstek. Alle name servers waarvan je iets opzoekt kennen zo je IP nummer en er kan makkelijk aan profiling worden gedaan.

Wat je wel kan doen is zelf een caching DNS server draaien met eigen parameters die het aantal queries naar de provider beperkt. Maar ook daar moet je de consequenties begrijpen. Load balancing mechanismen werken dan niet meer zo goed en DNS wijzigingen worden niet doorgevoerd.

Sowieso geen "gratis" diensten van derden gebruiken. Dat gratis bestaat doorgaans uit het feit dat jij je profiel weggeeft en dat die vervolgens doorverkocht kan worden.

Een besturingssysteem als Windows heeft een eigen DNS cache.

Een (vooralsnog) aan te raden DoH resolver: Nextdns.io (tweede prior DoH resolver in Firefox bijv.)
Het bedrijf heeft een gezond verdienmodel dmv ad- en track blockers en/of analytics over hun eigen dns servers wereldwijd (low latency) met een goede privacy policy (wetgeving California). Zeer overzichtelijke site. *DoH is uiteraard zónder de ads-/trackers block/analyse en gratis te gebruiken*

Ik zal ook niet beweren dat het helemaal geen verschil zal zijn, maar dat het verschil te overzien is. Vergeet bovendien niet dat een ISP, bij het gebruik van EDNS Client Subnet (ECS) ook slechts een cache zal hebben voor een subnet van /24 (255 hosts). Dat caching lijkt mij dus wel mee te vallen, helemaal als je zelf lokaal ook een cache hebt.
Daarnaast zal een zelfrespecterende ISP een goed peering beleid hebben om zo direct te kunnen verbinden met een netwerk waar de root servers te vinden zijn. Of zelf een server hosten, wat volgens mij kan bij het gebruik van anycast. Ik verwacht, zonder dat met harde cijfers te kunnen onderbouwen, dat de bandbreedte van DNS verkeer echt in het niet valt vergeleken met ander verkeer. De gehele root zone is op dit moment 2,2 MB, wat je dus 1x per 24 uur zou downloaden. (Voor zones als .nl is het volgens mij ook mogelijk deze via anycast binnen het eigen netwerk aan te bieden als ISP.)

Nogmaals ik heb geen harde cijfers, maar mijn inschatting is niet dat het hele internet op zijn gat komt te liggen als je zelf een recursive resolver gaat draaien. Helemaal wanneer je ISP of DNS provider gebruik maakt van ECS en zelf via anycast enkele authoritative zones beschikbaar stelt (zoals de root of .nl zone).


Als je van plan bent om een verbinding op te zetten maakt het niet heel veel uit dat er aanvullend aan die verbinding ook nog een DNS query in de logging komt te staan. Zoals eerder geschreven kunnen de grote DNS providers (m.u.v. Cloudflare) ook jou IP 'geanonimiseerd' doorgeven via de Client Subnet extensie. 'Geanonimiseerd' omdat dit voor IPv4 op /24 en voor IPv6 op /48 plaatsvindt. Bij een consumenten aansluiting is dat dus je eigen subnet of een gedeelt met max 255 anderen. Zonder de garantie dat die anderen ook gebruik maken van dezelfde DNS provider. Het argument dat de website - waar je toch al verbinding mee gaat maken - dus niet weet dat een query bij jou vandaan komt, is dus niet zo evident en valt in de praktijk best wel mee (bij het gebruik van ECS).

Aanvullend hier op is het met linux is het mogelijk gebruik te maken van systemd-resolved (wel een gedrocht van een stuk software) of een andere resolver als unbound in forwarding mode. Naar mijn weten is er anders standaard geen cache aanwezig.

Waarschijnlijk niet. Maar zoals gezegd, je gaat dan wél op de stoel van de netwerkbeheerder zitten, en dat betekent toch een beetje verder kijken dan alleen je eigen directe belang. Het internet was historisch altijd een coöperatief iets, en dat hoor je als netwerkbeheerder te begrijpen en er naar te handelen.

Dus als algemeen advies, waaronder aan mensen die geen kaas gegeten hebben van de techniek en al helemaal niet van hoe je goed beheer doet, is het minder geschikt. Het is veel meer een kwestie van houding dan van de techniek.

Hoewel de techniek ook wel parten speelt. Zo was daar het gevalletje D-link en hun ongevraagd gebruik van een hobby-ntp-server die daar expliciet niet voor bedoeld was, en oh ja, die altijd een tikje jammere software van een wereldwijde gigant die ineens met miljoenen installaties tegelijk alleen nog maar a.root-servers.net bevroeg. Dat waren wel even probleempjes.


systemd is wel enorm jammere software, ja. Het is wellicht het simpelst te typeren als "linux" (poettering en crew, betaald door red hat) die denken dat zoveel mogelijk bekende problemen van windows overnemen een goed idee is. Ook een hele interessante studie in (hobby)techneuten (zoals bij debian) die zich door de politieke machinaties met open ogen in de luren laten leggen en jaren later nog steeds niet snappen waar ze nou eigenlijk ingetrapt zijn. Maar zich ondertussen maar wel berust hebben in alle problemen die systemd over ze uitstort, en zelfs met hart en ziel de "voordelen" tegen alle kritiek verdedigen.

Het is op een willekeurige Unix (waar practisch gezien linux minus systemd ook onder valt) niet heel veel werk een DNS-cache te installeren en te configureren, ongeveer net zoveel werk als een willekeurig ander stuk niet-standaard geinstalleerde software. En op verschillende *BSDs zat named (BIND) in het base systeem, tegenwoordig unbound*. Die stond die niet standaard aan, maar was dus wel aanwezig.

* Omdat deze generatie developers graag allerlei wielen heruitvindt, en omdat ze graag DNSsec ondersteuning wilde hebben, en serversoftware op FreeBSD-installaties maar wat raar vindt want al hun eigen masjientjes zijn toch desktops, en omdat het ISC met BIND 10 zich op een andere manier niet helemaal lekker meer toonde, en zo verder. "Unbound" heeft zoals nogal wat recente FreeBSD-project-software last van second system effect en myopic developer syndrome. Jammer, maar helaas.

Ik draai lekker m'n eigen DNS server... waarom alles naar een andere partij sturen als dat niet hoeft?

Nou dat weet je nu dan! "omdat als je zelf een DNS server draait je alles naar andere partijen stuurt terwijl dat niet hoeft".
Terwijl als je de DNS server van je provider gebruikt, je alles maar naar 1 partij stuurt en niet naar allerlei anderen.

Tja, er zijn vergelijkingen geweest tussen de diverse DNS providers.
Over het algemeen heeft quad9 de beste cijfers voor het blokkeren van gevaarlijke sites. 9.9.9.9 is makkelijk te onthouden.
Als je liever zelf aan het stuur zit is nextdns.io een hele mooie oplossing. Je kan zelf kiezen uit heel veel blocklists waardoor ook advertenties wordt geblokkeerd.