Firefox begint deze maand met uitrol van dns-over-https

Firefox begint met de uitrol van dns-over-https voor Amerikaanse gebruikers. Dns-queries worden in de browser voortaan omgeleid en versleuteld via Cloudflare, zodat niet meer te achterhalen is welke websites een specifieke gebruiker opvraagt.

Mozilla zegt dat het later deze maand begint met de verdere uitrol van de configuratie. De browsermaker werkt al sinds 2017 aan dns-over-https, en begon vorig jaar een uitgebreidere test onder gebruikers. Die experimenten waren bedoeld om te kijken of gebruikers tegen problemen aanliepen, maar dat lijkt volgens Mozilla mee te vallen. Het bedrijf zegt dat slechts 4,3 procent van de gebruikers ouderlijk toezicht of safe search aanzet. Die processen gaan onder andere op basis van dns-verzoeken. Dns-over-https zou dat moeilijker maken. Ook zag Mozilla een paar problemen bij websites met niet-publieke toevoegingen in de domeinnaam.

De functie wordt nu standaard ingeschakeld, maar gebruikers kunnen via een opt-out kiezen er geen gebruik van te maken. Op dit moment is het tegenovergestelde mogelijk in Firefox. In zakelijke configuraties staat dns-over-https standaard uit zodat systeembeheerders niet in de problemen komen. Als er problemen ontstaan voor gebruikers kan Firefox daarnaast terugvallen op de standaard dns-instellingen van het besturingssysteem.

Firefox maakt voor de dienst gebruik van de 1.1.1.1-dns-resolver van Cloudflare. Daar werkte het bedrijf in tests ook al mee samen. Het bedrijf zegt echter dat dat mogelijk verandert als er andere geschikte domein-resolvers beschikbaar komen.

Bij dns-over-https wordt een dns-query versleuteld met tls-encryptie. Daardoor kunnen andere partijen zoals providers niet meer meekijken naar welke webpagina's specifieke gebruikers opvragen. Er is ook een alternatief, dns-over-tls, maar dat is minder populair. Daarvoor moet namelijk een specifieke tls-poort worden gebruikt die makkelijk af te sluiten is door bijvoorbeeld een provider. Dns-over-https loopt net als al het tls-verkeer over poort 443, dat daardoor niet zo makkelijk te blokkeren is.

Hoewel de beslissing op het eerste gezicht goed lijkt voor de privacy van gebruikers is niet iedereen even blij met de beslissing. In Engeland, waar strengere internetregels gelden, waren internetproviders lange tijd niet blij met het plan. Ook wijzen critici op het feit dat Cloudflare een Amerikaans bedrijf is en daarom onder de regels van dat land valt, en dat dns-over-https mogelijk trager zou zijn dan gewoon verkeer.

Reacties (164)

Bij dns-over-https wordt een dns-query versleuteld met ssl-encryptie. Daardoor kunnen andere partijen zoals providers niet meer meekijken naar welke webpagina's specifieke gebruikers opvragen. Er is ook een alternatief, dns-over-tls, maar dat is minder populair. Daarvoor moet namelijk een specifieke tls-poort worden gebruikt die makkelijk af te sluiten is door bijvoorbeeld een provider. Dns-over-https loopt net als al het ssl-verkeer over poort 443, dat daardoor niet zo makkelijk te blokkeren is.

Ja. Leuk, die marketing. Echter, om bijvoorbeeld tegemoet te komen aan bedrijfsnetwerken waar men een split-dns configuratie draait wordt DoH niet gebruikt als het domeinnaam use-application-dns.net een NXDOMAIN teruggeeft. Iedere provider die dus de controle die 'ie nu heeft wil behouden hoeft dus alleen maar dat domeinnaam in z'n eigen nameservers te blokkeren en het blijft gewoon bij het oude.

Daarnaast gaat Firefox nu dus een Cloudflare dienst gebruiken. Die is weliswaar gratis, en zal vast ook een goede uptime hebben, maar het is wel een commercieel Amerikaans bedrijf. Het mooie aan het internet zoals we dat nu hebben is dat de infrastructuur gedecentraliseerd is en niet afhankelijk van specifieke commerciële partijen.

Ik snap dan ook niet waarom men niet veel meer inzet op DNSSEC en DNS over TLS. Dat heeft op z'n minst dezelfde voordelen als DoH, is niet afhankelijk van een enkele commerciële partij, en performt doogaans beter.

Wil je dit gedrag voor nu en in de toekomst uitzetten, dan kan je in about:config network.trr.mode op 5 zetten (trr = Trusted Recursive Resolver). Vermoedelijk zullen distro's als OpenBSD en Debian dit standaard al doen omdat zij het als bug beschouwen als een applicatie niet de standaardresolvers die in /etc/resolv.conf geconfigureerd staan gebruiken.

Edit: Ik kom net ook dit artikel tegen: Malware die DoH gebruikt om allerlei detectie te kunnen omzeilen.

[Reactie gewijzigd door Freeaqingme op 10 september 2019 12:46]

OpenBSD is er al mee bezig geweest:
otto@ modified www/mozilla-firefox: Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. [..]

Ja. Leuk, die marketing. Echter, om bijvoorbeeld tegemoet te komen aan bedrijfsnetwerken waar men een split-dns configuratie draait wordt DoH niet gebruikt als het domeinnaam use-application-dns.net een NXDOMAIN teruggeeft. Iedere provider die dus de controle die 'ie nu heeft wil behouden hoeft dus alleen maar dat domeinnaam in z'n eigen nameservers te blokkeren en het blijft gewoon bij het oude.

Nuttige info. Dan ga ik die ook maar in mijn DNS-server blokkeren. Sowies heb ik verbindingen naar 8.8.8.8, 8.8.4.4,, 1.1.1.1 en 1.0.0.1 al dichtgezet in de firewall - die Amerikaanse bedrijven moeten eens ophouden alles naar zich toe te trekken. Centralisatie van het gedecentraliseerde internet is een zeer kwalijke zaak.

Net als bijvoorbeeld de DNS resolver van systemd op Linux die 8.8.8.8 en 8.8.4.4 als fallback DNS servers gebruikt

Ik weet niet waar jij die informatie vandaan haalt. Maar de fallback stel je gewoon zelf in. Anders heeft de distro die jij gebruikt dit voor je gedaan (tijd voor een nieuwe distro?).

Zie ook: https://wiki.archlinux.or...Systemd-resolved#Fallback

Los daarvan zie ik niet waarom je 1.1.1.1 zou willen verbannen. Het is een van de snelste dns resolvers. Ik kan me inleven dat je Google niet wilt als DNS provider. Als er een partij is die ik meer toevertrouw met m'n DNS queries is het Cloudflare wel.

Falback instellen op tweakers wel maar als de massa firefox gebruikt update krijgt en dan 1.1.1.1 standaard ingesteld staat weten ze ook niet beter.

Schreef het hieronder al 1.1.1.1 word dan nu ook meteen een goed doel voor aanval. Leg je 1.1.1.1 plat dan leg je in de toekomst meteen alle firefox gebruikers plat.

Leg je 1.1.1.1 plat dan leg je in de toekomst meteen alle firefox gebruikers plat.

Nee hoor, met het platleggen van de cloudfare dns leg je niet alle firefoxgebruikers plat, omdat Firefox nogaltijd terug kan vallen op je reguliere dns-settings. Firefox heeft in de about:config nog een setting genaamd "network.trr.mode" waarbij ingesteld is hoe het resolven moet lopen.
https://wiki.mozilla.org/Trusted_Recursive_Resolver
Set `network.trr.mode` to 2 to make DNS Over HTTPS the browser's first choice but use regular DNS as a fallback (0 is "off by default", 1 lets Firefox pick whichever is faster, 3 for TRR only mode, 5 to explicitly turn it off).

m.a.w het is ook nog eens schijnveiligheid, want een aanvaller hoeft alleen maar jou verkeer naar de Cloudflare DoH servers te blokkeren en Firefox valt, gebruiksvriendelijk en geheel automatisch, terug naar de normale DNS.

Dit is dus net goed genoeg om de lichtste aanvallen (snoopers) te weerstaan, maar niet nuttig als een serieuze beveiliging nodig is.
Je kan ook stellen dat dit een contraproductieve oplossing is omdat de aanwezigheid van een halfwas oplossing de adoptie van een echt goede oplossing zal vertragen.

Wat schiet een aanvaller die jouw verkeer naar de cloudflare servers kan blokkeren er mee op wanneer je webbrowser terug moet vallen op je normale DNS? Als de aanvaller dns servers kan blokkeren dan ben je toch al dusdanig gehackt dat de aanvaller veel meer kwaad kan dan dat? Daarbij kan je het zo instellen dat geen andere dns server wordt gebruikt door Firefox of je kunt cloudflare DoH of een andere DoH server gebruiken als je normale DNS.

[Reactie gewijzigd door sampoo op 10 september 2019 15:19]

Een aanvaller kan bij een ISP iemands toegang tot de Cloudflare DoH server blokkeren en dan het normale DNS verkeer bij de ISP afluisteren. Daar hoef je zelf niet voor gehacked te zijn.
De gebruiker merkt dankzij de default instellingen van Firefox niks.

Wat ik al eerder zij: zwakke oplossing, voor low-level risico's, maar wat door zijn bestaan wel betere oplossingen zal vertragen.

Waarom zou je een betere oplossing die nu beschikbaar is verkiezen boven minder veilig browsen totdat er iets beter voorbij komt?

Firefox had dit zelf niet kunnen introduceren als Cloudflare de functionaliteit niet aanbood en de capaciteit niet had om alle extra dns aanvragen te verwerken. Firefox heeft hier dus ook handig ingespeeld op een bestaande oplossing, en daarmee het internet voor vele gebruikers iets veiliger gemaakt. Misschien niet de beste oplossing, maar zeker een die relatief weinig moeite kost.

[Reactie gewijzigd door sampoo op 10 september 2019 20:55]

Het is natuurlijk afhankelijk van hoe je Firefox instelt, maar de standaard is inderdaad om op de reguliere dns terug te vallen mocht DoH niet lukken, maar als je wilt kan je dit ook anders instellen.

Het is ook geen echte oplossing, maar dat stelt men ook niet, de echte oplossing zou het zijn van de ondersteuning van versleutelt dns verkeer met de reguliere dns instellingen van je systeem. De technieken en software zijn er, alleen moeten de dns servers en clients het gaan ondersteunen.

Dit enorme vat heeft denk ik wel honderd gaatjes, sommige op lastig te vinden plekken. Laat ik daarom het vrij grote gat dat zich recht voor mijn neus bevindt maar niet stoppen.

De meeste hebben dan nog gewoon Edge en velen hebben daarnaast nog IE en Chrome geïnstalleerd staan... Maar ik vind de directie van Firefox steeds meer vraagtekens opwerpen, het is nog steeds mijn primaire browser, maar met dit soort (en vorige) acties vraag ik me af of dat niet eens moet wijzigen...

Chrome heeft het plan het in versie 78 te testen en dan later volledig uit te rollen. En dat heeft reden ook, DNS over TLS is nog niet echt klaar, en dit is the next best thing.

[Reactie gewijzigd door EraYaN op 10 september 2019 14:52]

1.1.1.1 is een anycast adres, met zeer veel verschillende eindpunten. Uiteraard is het niet onmogelijk, maar wel onwaarschijnlijk. Als je toch persé DNS wil aanvallen kan je beter proberen een paar van de root-nameservers plat te leggen. Dan leg je effectief het hele internet plat.

Omdat het een Amerikaanse provider is. DNS is net als veel andere core protocols van het internet gedistribueerd. Google of Cloudflare daarvoor inschakelen brengt een stuk centralisatie terug wat een zeer slechte zaak is.

Overigens, wat betreft systemd: die link die je geeft geeft het toch precies aan: fallback naar CloudFlare en Google DNS. Er zou geen fallback moeten zijn, tenzij je het zelf configureerd. Zeker niet naar een externe server. Dan zou hij beter een fallback naar de rootservers kunnen doen. Geen DNS is geen DNS. Hetzelfde geintje flikken ze met de NTP-daemon die ze ook al proberen te assimuleren in SystemD - lekker synchroniseren me de afwijkende "Google Time" als er niet expliciet tijdservers zijn ingesteld.

[Reactie gewijzigd door MadEgg op 10 september 2019 09:43]

Ik weet niet hoor, maar het hele internet draait om Amerika.. het hoofdkantoor van de IETF (Internet Engineering Task Force, de groep die alle internetstandaarden bijhoudt) staat ook in Amerika, het internet op zich is al zo Amerikaans als het maar zijn kan, Microsoft waar praktisch alles ter wereld op draait is Amerikaans...

[Reactie gewijzigd door DigitalExorcist op 10 september 2019 09:05]

Ik weet niet hoor, maar het hele internet draait om Amerika.. het hoofdkantoor van de IETF (Internet Engineering Task Force, de groep die alle internetstandaarden bijhoudt) staat ook in Amerika, het internet op zich is al zo Amerikaans als het maar zijn kan, Microsoft waar praktisch alles ter wereld op draait is Amerikaans...

Het grootste deel van de websites wordt nog altijd geserveerd vanaf *nix-machines. Microsoft is heer en meester op de desktop. Alsnog wás Windows redeijk gedecentraliseerd - het draait op je eigen machine, onafhankelijk van het internet. Helaas gaat MS ook daar steeds meer richting centralisatie waarbij je geduwd wordt in de richting van lokaal aanmelden met je online Microsoft-account, en er steeds meer vanaf MS-servers geregeld wordt.

Niet zozeer de desktop, maar denk aan Azure, Office 365, alle clouddiensten waar MS zich in nestelt inderdaad. Desktop is irrelevant aan het worden.

Maar goed, dat zie je de afgelopen 50 jaar in golfbewegingen: mainframes met terminals, toen met PC's alles lokaal, toen Winframe/Citrix/terminals, toen weer even alles lokaal begin 21e eeuw, nu weer clouddiensten...

[Reactie gewijzigd door DigitalExorcist op 10 september 2019 09:14]

... en uiteindelijk als de public cloud onveilig blijkt krijg je weer "Local Network Clouds" of "Private Virtual Clouds" of een of ander buzzwoord voor een cloud-achtige dienst die vanuit je eigen datacenter gehost wordt.

Ja, private cloud is nu ook weer een dingetje. Maar Azure dringt zich wel flink op.

Mja, maar ik denk dat dat systemd gedoe voor maar heel weinig mensen een issue is.
Men vindt Whatsapp buurtpreventie al normaal, wat nog veel erger is dan dit. Wil je goed geinformeerd zijn mbt "gevaren" in je bloedeigen straat, dan is er 1 advertentiebedrijf in de VS waar je dan zaken mee moet doen.

In het systemd geval, meestal krijg je via DHCP een (andere lokale) DNS, voor het zeldzame geval dat dat niet werkt heeft de doorsnee noob dan alsnog werkende DNS om te kunnen...Googlen...naar een oplossing.
Degenen die de defaults onwenselijk vinden, zijn vrij om iets anders te kiezen.
En (iig) in Debian staat zelfs dat hele subsystem standaard uit.

Rootservers enzo lijken mij hier niet voor bedoeld, ik dacht dat hun officieuze taak is om goed werkende caching nameservers te "seeden", en ze niet dienen te worden belast door alle crappy geconfigureerde netwerken/devices ter wereld (die beter zo'n caching nameserver kiezen, van de ISP of Cloudflare/Google bijv).

Ja die "WhatsApp Buurtpreventie"-bordjes zijn me ook een doorn in het oog. Dan nog liever een app als Nextdoor. Gelukkig hebben mijn buren Signal dus red ik het prima zonder WhatsApp.

Systemd-perikelen zullen inderdaad niet voor veel mensen een issue zijn. Maar het feit dat ze een default hebben voor iets kritieks DNS-servers vind ik zeer kwalijk. Als je geen DNS instelt, waarom gaat je systeem dan uit zichzelf maar wat invullen? Geen DNS is geen DNS. Dan krijg je dus een 'Host not found'-foutmelding. Niet opeens je gegevens bij Google.

"Googlen naar een oplossing" kunnen de "slachtoffers" ook wel via een telefoon doen. Als ze er tegenaan lopen zitten ze in ieder geval al dermate diep in een technisch Linux-moeras dat ze daar niet zouden moeten zitten als ze naar een oplossing moeten Googlen. Dus heb je hier alleen de technisch onderlegde gebruiker maar mee die bewust géén DNS-server heeft ingesteld en alsnog met DNS-resultaten geconfronteerd wordt.

Stop nu toch eens met ip4, voor de volledigheid:

• For IPv4: 1.1.1.1 and 1.0.0.1
• For IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001

* Ik ken deze dns trouwens niet, ik gebruik die van mijn ISP.

[Reactie gewijzigd door g4wx3 op 10 september 2019 09:39]

Helemaal gelijk, een provider is niet alleen voor de bandbreedte maar ook voor de nodige internet services:
- dns (het telefoonboek van internet)
- ntp (De provider moet wel bij de tijd zijn)
- dhcp (in ieder geval werkbare ip adressen)
- routering (niet via Aken en Keulen maar als het even kan direct op AMS-IX)

En mogelijk ook 'secundaire' services zoals
- nntp
- hosting
- voip

Welke DNS-servers gebruik je zelf dan?

Welke DNS-servers gebruik je zelf dan?

Een eigen recursing DNS-server, met een flinke blacklist.

Maar kijk bijv. naar wat Windows 10 doet: je kan *.microsoft.com blacklisten maar Windows zélf heeft de IP adressen hardcoded gewoon in DLL'etjes staan. Die trekt zich al niks aan van DNS voor systeemkritieke toepassingen.

[Reactie gewijzigd door DigitalExorcist op 10 september 2019 09:18]

I know. Daarvoor heb ik ook een aantal adressen in de firewall geblokkeerd. Jammer dat het allemaal zo moet.

En welke externe dns-server gebruik je op je interene dns-server?

De root-servers. Dat + caching zorgt voor een redelijke afdekking. Je zult uiteindelijk toch ergens het juiste IP-adres vandaan moeten halen.

Blokkeer je dan ook alle smartphones in je bedrijf? En e-mail? Wie weet welke hops je mail allemaal neemt voordat het afgeleverd wordt

Beter blokkeer je ook *alle* telemetrie van Microsoft, Google én Apple voor de zekerheid, net zoals clouddiensten, Azure, AWS en wat dies nog meer zij.

Telemetry wordt inderdaad ook geblokkeerd. Niet in mijn bedrijf overigens - gewoon thuis.

Hoe heb je de updates van microsoft software geregeld? De ultime telemetrie gaat via microsofts update servers.

Niet / amper. Windows Update Service is gewoon volledig uitgeschakeld. Een keer per zoveel maanden (of vlak nadat een patch voor een kritiek lek gepubliceerd is) trek ik de firewall even los en zet de service aan en installeer beschikbare updates. Mogelijk dat er dan in burst verzamelde data verstuurd wordt, maar het houdt helaas ergens op.

Ik gebruik WIndows ook amper - het is voor mij niet meer dan een veredelde game launcher. Alles daar omheen gaat op Linux.

Tja. de telemetrie van mswindows naar microsoft is inderdaad het beste uit te zetten door mswindows uit te zetten. Daar kan niets tegenop.

Voor gaming zou ik van windows eventueel via de xbox naar playstation overstappen. Of nintendo of zo.

ik snap niet waarom je dat in jou ? DNS server wil blokkeren. Wie gebruikt Jouw DNS server dan die die andere instellingen niet zou mogen gebruiken.of wat het nu firewall ?

Om te voorkomen dat dergelijke streken als Firefox hier nu uithaalt opeens als gevolg hebben dat mijn gegevens ongevraagd naar de VS gestuurd worden. Straks gaat een of andere app op mijn smartphone bedenken dat ze wel DoH kunnen gebruiken om te voorkomen dat ik advertenties via mijn DNS-server blokkeer.

Ja de VS overheid staat ook te trappelen om je gevens te mogen hebben. Als je echt zeker wilt weten dat dat niet gebeurd. hebt dan ook geen smartphone, of een computer, beter nog geen internet dat lijkt me toch betere oplossing dan een halfbakke oplossing. Maar goed, Zelf vind ik dit wel erg overdreven. uiteindijk komt elk verzoek van een DNS toch wel is bij een DNS server in de VS terecht, zeker als jou DNS niet weet waar het domein moet vinden, vraag aan de toplevel DNS, die stuurt het weer door aan de geautoriseerde DNS en die kan best in de VS staan ook moet juw dns na the halverings tijd van de ttl het weer opnieuw vragen. die stuurt het weer naar jouw DNS en ja jouw computer krijgt het weer van jouw DNS. dus nu weten ze wie die ene website opvroeg. dan moet je voorkomen dat alle domein namen die je bezoekt niet op VS servers staan, dat is ondoenelijk. Dus nee ik vind dit verspilde moeite.
bovendien is je eigen land meer in ons geintreseerd dan Amerika naar ons, bovendien mag in Amerika veel meer dan Europa.

DNSSEC heeft niks met dit systeem te maken, dat valideert alleen de authenticiteit maar doet verder niks met versleuteling, DNS over TLS natuurlijk wel. Maar ik heb ooit uit een vergelijking begrepen dat DoH verder was. Uiteindelijk maakt het niet zoveel uit welk systeem groot gaat worden, dat ze nu kiezen voor cloudflare is logisch omdat ze een grote partner willen hebben om dit er door te drukken. Over een tijdje kun je je eigen DoH of DNSoTLS server draaien en instellen.

En besef dat ze aan de hand van de IP's nog altijd kunnen zien naar welke server of site je gaat.

DNSSEC heeft hier weldegelijk mee te maken. Met DNSSEC kan je bepalen of iemand de responses onderweg aangepast heeft. Eén van de doelstellingen van DoH is om dat ook te kunnen voorkomen.

Maar ik heb ooit uit een vergelijking begrepen dat DoH verder was. Uiteindelijk maakt het niet zoveel uit welk systeem groot gaat worden

Waarom maakt dat niet uit?

dat ze nu kiezen voor cloudflare is logisch omdat ze een grote partner willen hebben om dit er door te drukken. Over een tijdje kun je je eigen DoH of DNSoTLS server draaien en instellen.

Die kan je nu ook al draaien als je wilt. Je doet net alsof het er door heen drukken van een bepaalde standaard wenselijk is. Dat lijkt mij niet.

Waarom maakt het wel uit, beide systemen kunnen prima werken. Een ieder zal zijn eigen voorkeur hebben en daar zit het probleem. Als je het aan de IT community over laat zijn we 30 jaar verder en nog aan het zeuren wat het beste systeem is, gewoon zo snel mogelijk door drukken. Dan gebeurt er tenminste wat. Er is nog genoeg te doen in de strijd om het gehele internet versleuteld te krijgen.

Het eerste waar ik aan dacht is dat een gerichte aanval op de 1.1.1.1 dns server dus meteen alle firefox browser die dit gebruiken plat legt.
Dat een toch populaire browser voor dns van 1 partij afhankelijk wil zijn lijkt me geen goed idee.

Hier kan je leren waarom het niet zo makkelijk zal zijn om 1.1.1.1 plat te leggen: https://www.cloudflare.com/learning/dns/what-is-anycast-dns/

DDoS protection is Cloudflare's core business...

Zal best core business zijn maar punt blijft je bent als browser dan van 1 dns systeem afhankelijk. ddos is en blijft kat en muisspel en wie weet straks weer een slimmerik die het toch lukt,

cloudflare is in ieder geval een doel en heel veel potentieel als je het ook maar tijdelijk plat krijgt.

Niet echt, Mozilla is niet dom, natuurlijk is er een fallback gebruikers zullen het niet eens merken denk ik zo.

Je hoeft 1.1.1.1 niet aan te vallen om ze plat te krijgen. Een hack in de routering naar 1.1.1.1 (of naar het hele 1.0.0.0/8 subnet) kan genoeg zijn. Dan ligt 1.1.1.1 in ieder geval in jou deel van de wereld plat.

Gezien de status van 1.1.1.1 zal je nooit 'de' server plat kunnen krijgen, ze zijn creatief over de wereld verdeeld en de routering is overal zodanig dat je naar de 'lokale' 1.1.1.1 routeert.

Overigens is met 8.8.8.8 en 8.8.4.4 het zelfde uitgehaald. Daarvan zijn er over de hele wereld ook meerdere.

Als ik het goed begrijp is op zich network.trr.mode op 0 zetten ook OK, omdat hij dan DNS over TLS als fallback gebruikt.

Op https://wiki.mozilla.org/Trusted_Recursive_Resolver (die Rudie_V eerder gaf) staat "0 is "off by default"". Dan staat DNS-over-https dus uit (maar laat je Mozilla de keuze om het binnenkort aan te zetten?), met 5 zet je het uit en geef je Mozilla ook die vrijheid niet.
In beide gevallen gebruik je de reguliere DNS. Dat zijn de DNS's die jij -als tweaker- hebt ingesteld op je device* of je router*. Of de default dns van je provider, als je niets instelt.

Er staat NIET dat dan DNS-over-TLS wordt gebruikt, het concurrerende alternatief voor DNS-over-https.

* Wat je reguliere dns betreft, tweakers hebben vast ooit https://www.grc.com/dns/dns.htm en vervolgpagina's al eens gelezen. Maar misschien is het vermelden van deze link een aanleiding om de tests van pag 2,3 en 5 nog eens te herhalen, zoals Steve aanbeveelt.

[Reactie gewijzigd door Ron020 op 10 september 2019 14:35]

Jammer dat ze niet de optie geven het als fallback te gebruiken. Dan maar uit, al ben ik benieuwd wat int value 4 doet.

Ik gebruik een VPN naar mijn router toe. Die router draait een DNS server die allereerst wat adblocking doet, en ten tweede DNS over TLS doet middels Quad9 (wat ik meer vertrouw dan Cloudflare of Google).

"Steve" gebruikt gewoon https://www.ipleak.net via JS IPleak is inderdaad heel goed voor dit soort zaakjes...

... al ben ik benieuwd wat int value 4 doet.

staat inderdaad niet vermeld ...

"Steve" gebruikt gewoon https://www.ipleak.net via JS

"Hmm. We’re having trouble finding that site" Maar https://ipleak.net/ werkt wel.
Ik kan me niet herinneren zoiets eerder gezien te hebben, het ongekeerde juist wel, dat een url zonder "www" niet werkt.

De andere tools van GRC kunnen ook nuttig zijn, bijv. https://www.grc.com/dns/benchmark.htm

[Reactie gewijzigd door Ron020 op 10 september 2019 17:58]

Ik kan me niet herinneren zoiets eerder gezien te hebben, het ongekeerde juist wel, dat een url zonder "www" niet werkt.

Ach, sorry. Dit is 1 van die websites die geen www cname heeft. Vroeger was dat normaal. Dat www er voor gezet moet worden is eigenlijk een defacto standaard. Enige nut van www. is dat het een cname kan zijn. Zie bijv https://www.freecodecamp....-be-a-cname-8cbab38e5f5c/

Verder jat GRC vanalles van derden. Ik leer liever de techniek erachter om het zelf te begrijpen/kunnen. Maar ieder z'n ding. Bedankt iig voor de heads up van value 0 tov 5.

Ik begrijp je punt, maar wat vind je van FireFox ten op zichte van Chrome als je het over privacy en security hebt. Ik ben geen expert op dit gebied, maar ik denk dat Chrome vele malen erger is en dat FireFox wat dat betreft in ieder geval een alternatief is. Maar ik hoor graag je mening, want ik weet het niet

Lang verhaal kort; met diezelfde argumenten ben ik inderdaad ook Firefox gebruiker. Maar dan wel met een rits plugins om e.e.a. nog net iets strakker te zetten (uBlock origin, DuckDuckGo privacy essentials, CanvasBlocker, Privacy Badger, Https Everywhere, Facebook Container). Doorgaans vind ik dat Firefox een hoop goed doet, alleen specifiek dit vind ik een bijzondere stap.

Dan zal het je vast verheugen dat Chrome (en dus Edge waarschijnlijk ook) dit ook op de planning heeft staan. Het is ook alleen maar goed, het slaat nergens op dat DNS nog steeds niet versleuteld is.

Daarnaast gaat Firefox nu dus een Cloudflare dienst gebruiken. Die is weliswaar gratis, en zal vast ook een goede uptime hebben, maar het is wel een commercieel Amerikaans bedrijf.

Wellicht ook de reden dat men dit naar Amerikaanse gebruikers uitrolt. Overigens is Mozilla zelf ook een Amerikaanse organisatie, weliswaar niet met winstoogmerk maar nog steeds van belang in de context.

Ik snap dan ook niet waarom men niet veel meer inzet op DNSSEC en DNS over TLS. Dat heeft op z'n minst dezelfde voordelen als DoH, is niet afhankelijk van een enkele commerciële partij, en performt doogaans beter.

Commerciële doeleinden waarschijnlijk. Uiteindelijk bepalen financiële belangen voor een groot deel welke tech we grootschalig gebruiken.
Zie je eigen quote, i.c.m. de waarde van "data" tegenwoordig;

Iedere provider die dus de controle die 'ie nu heeft wil behouden hoeft dus alleen maar dat domeinnaam in z'n eigen nameservers te blokkeren en het blijft gewoon bij het oude.

[Reactie gewijzigd door Luftbanana op 10 september 2019 09:03]

DNSSEC en DoH hebben vrij weinig met elkaar te maken. Ze vullen elkaar juist erg goed aan:
Kort-door-de-bocht en zeer versimpelt: DNSSEC controleert dat de resolving klopt (dus dat er geen DNS-kaping heeft plaatsgevonden). DoH zorgt er voor dat niemand mee kan kijken met de resolving.

"Die is weliswaar gratis, en zal vast ook een goede uptime hebben, maar het is wel een commercieel Amerikaans bedrijf. Het mooie aan het internet zoals we dat nu hebben is dat de infrastructuur gedecentraliseerd is en niet afhankelijk van specifieke commerciële partijen."

Absoluut, en daar wil nog aan toevoegen dat kritieke internet infrastructuur niet alleen vrij van commercie moet zijn, ook vrij van politiek.

Zo heeft Cloudflare onlangs het extreemrechtse forum 8chan geweerd. Nu zal mij dat persoonlijk een rotzorg zijn, 8chan is een akelige bende, maar de keuze is wel degelijk politiek. Het is niet vergezocht om te veronderstellen dat een partij als Cloudflare ook politiek op DNS gaat loslaten, dat is iets wat we echt niet moeten willen.

Weet jij (of iemand anders) hoe Firefox er mee omgaat als een subdomein publiekelijk niet te resolven is maar wel via lokale DNS?
Voorbeeld: ik werk bij bedrijf.nl dat een bestaand publiek domein is met publiekelijk te resolven records. Onze servers staan echter in subdomein.bedrijf.nl en alle records in subdomein.bedrijf.nl zijn alleen intern te resolven. Cloudflare kan hier dus niet bij, ik wil dan ook niet dat DoH dit stuk maakt

[Reactie gewijzigd door zjeeraar84 op 11 september 2019 15:44]

Ik lees hier:

As a precaution, Firefox features a system that detects if a name can’t be resolved at all with TRR and can then fall back and try again with just the native resolver (the so called TRR-first mode). Ending up in this scenario is of course slower and leaks the name over clear-text UDP but this safety mechanism exists to avoid users risking ending up in a black hole where certain sites can’t be accessed. Names that causes such TRR failures are then put in an internal dynamic blacklist so that subsequent uses of that name automatically avoids using DNS-over-HTTPS for a while (see the blacklist-duration pref to control that period).

Ze doen dus wel hun best dat te detecteren. Als je hier helemaal 0 risico in wil lopen dan kan je natuurlijk je lokale resolver zo configgen dat ie use-application-dns.net niet teruggeeft, waarmee je effectief DoH uitzet.

Thanks. Is gelukkig wel over nagedacht dus

Dns-queries worden in de browser voortaan omgeleid en versleuteld via Cloudflare, zodat niet meer te achterhalen is welke websites een specifieke gebruiker opvraagt.

Niet helemaal correct. SNI (Server Name Indication) wordt gebruikt om meerdere TLS-enabled websites te hosten op dezelfde set IP-adressen. Dit vereist van de client (de browser) dat de hostname van de website waarmee verbonden wil worden meegestuurd moet worden. Deze wordt nog altijd onversleuteld meegestuurd. Zie dit artikel. Cloudflare heeft hierop wel ESNI (Encrypted Server Name Indication) geïntroduceerd, dit is ook al in te schakelen in FireFox als ik het goed heb.

Het nadeel van ESNI is dat je, i.t.t. DoH, afhankelijk bent van de beheerder van elke domeinnaam of dit werkt. Want je kunt het wel aanzetten in je browser maar het gros van de domeinnamen heeft natuurlijk nog helemaal geen public key in z'n DNS records staan.

Ik vind het een nieuw geval van schijnveiligheid. Dit is vergelijkbaar met het idee dat je veilig en anoniem kunt browsen met een VPN verbinding. Het is alleen maar makkelijker voor kwaadwillenden op deze manier. Al het verkeer gaat via NordVPN (bijvoorbeeld) en alle DNS queries gaan via CloudFare straks. Nou lekker veilig en anoniem hoor. Het gaat al die bedrijven maar om 1 ding: data mining. Of was je nog in de veronderstelling dat ze dit soort diensten uit altruïsme bieden? NordVPN is van Tesonet wat een datamining company is.... En de eigenaar is weer gelinkt aan ProtonVPN en ProtonMail etc. Laten we niet naïef gaan doen, als het gratis is dan gaat het ze om de data. Dus voor de veiligheid is dit niet interessant, dan moet je maar je eigen DNS server draaien (en voor VPN TOR als alternatief gebruiken).

Het verkooppraatje van Cloudflare is dat zij als doel hebben om het internet beter te maken. Zij willen uiteraard ook winst maken. Die twee kunnen prima samen.
Hun core business is DDoS-bescherming. Daar hebben zij data voor nodig. Dit mechanisme vult daar natuurlijk goed op aan. Dus hun winst met dit product is inderdaad data. Dat zijn ze ook transparant over. Ze zeggen wat, hoe en hoelang ze die data opslaan en wat ze er mee doen.

DoH voegt daadwerkelijk iets toe aan de veiligheid op internet. Het gaat er nu naar toe dat vrijwel alle communicatie gecodeerd wordt. DNS liep hier op achter. Er was heel lang geen beveiliging op DNS. DNSSEC voegt toe dat DNS-verzoeken ondertekend zijn. DoH voegt toe dat ze gecodeerd zijn op ISP-niveau.

Er wordt nergens gesuggereerd dat je nu in eens helemaal veilig en anoniem bent, al voegt het er wel iets aan toe. De MiTM van het publieke accesspoint ziet nu minder makkelijk wat je aan het doen bent.

Als je je eigen DNS server draait been je juist minder anoniem. Althans. Op minder plaatsen. Met dit systeem weet alleen Cloudflare wat jouw ipadres opvraagt (en je weet wat ze met die data doen). Met je eigen name server, je ISP, iedere schakel tussen jou en de root nameservers en iedere schakel tussen jou en de nameserverbeheerder die je opgevraagde domein serveert.

Voor een ieder die een alternatief zoekt kan ik doh.powerdns.org aanraden. Dit wordt door het Nederlandse PowerDNS aangeboden. Dit is de DNS software provider van KPN, XS4ALL, Deutsche Telekom en nog wat van die clubs. PowerDNS heeft zich ook uitgesproken voor DNS over HTTPS maar tegen Firefox's implementatie van DOH bij Cloudflare. BTW als Nederlander heb je meer veiligheid onder de AVG door gewoon bij je provider te blijven voor DNS. In het buitenste buitenland kan dit echter anders zijn.

Disclaimer, de developers zijn goede vrienden van me. Hun privacy policy is vrij goed te begrijpen @Tijs Hofmans

The PowerDNS DoH Service Privacy Policy
The goal of the PowerDNS DoH service ('doh.powerdns.org') is to provide best effort DNS over HTTPs service without violating your privacy, not now, not ever.

The service:

Does not profile users, networks, clients, domains or browsers
Except during incidents, or when forced by applicable law, the PowerDNS DoH service:

Does not log queries, cookies, versions, headers, IP addresses or any other metadata
Does not analyse traffic
Does not share traffic with any third party
Only if the DoH service is malfunctioning or under attack will we investigate any traffic that might be harming our service. This is the only moment when privacy sensitive data will be analysed or processed by us (or anyone else). Once an incident has been resolved the data will be destroyed.

We do make graphs of the total number of queries, which TLS algorithms and HTTP versions are being used, millisecond response times and similar metrics, but all these counters are global and only measure aggregate traffic.

In addition to not violating your privacy today, we commit to not doing so at a later stage either. We will not in the future be monetizing or sharing your traffic. Should PowerDNS through change of ownership or management come to a different policy, we commit to first shut down this DNS over HTTPs service.

The PowerDNS DoH Service is offered on a best-effort basis and operated by Open-Xchange and its subsidiary PowerDNS.COM BV.

The GDPR grants you certain rights, such as the right to get a copy of the data we have on you, the right to erasure etc. As we don't keep your data, those requests won't produce any data. If you have any questions about this, please do contact us through https://powerdns.com/contact.html. If you feel we fail to protect your rights, we'd like that hear that directly, but the GDPR also gives you the option to lodge a complaint with a GDPR Data Protection Authority.

Zie ook deze recente presentatie van Bert Hubert van PowerDNS over DoH, waarin hij goed op rij zet wat precies de bezwaren zijn van deze actie van Mozilla:

https://www.youtube.com/e...autoplay=1&auto_play=true

(in het kort: je verliest netto zowel performance als anonimiteit)

Ik zou graag de handelsbelangen van PowerDNS kennen. Bij mijn internetaanbieder is dat duidelijk, die is financieel afhankelijk van mij, dus zal normaliter in mijn belang handelen. Een onafhankelijk bedrijf moet op een andere manier geld verdienen en als een gratis dienst aangeboden wordt, speelt een mogelijk belangenconflict om de gegevens die men vergaart te gaan vermarkten. PowerDNS is in deze niet anders dan Google.

PowerDNS maakt DNS software voor telcos, ISPs, hosters etc. Laten zien dat je dit op schaal kunt draaien laat ook zien aan je klanten dat je software klaar is voor de nieuwste ontwikkelingen.

Maar je hebt gelijk, ze hebben een financieel/marketing belang, net als Cloudflare. Alleen zijn ze een Nederlands bedrijf in tegenstelling tot Cloudflare en vallen ze dus onder stringentere wetgeving.

Mgoed, dit had je zelf ook kunnen bedenken.

Niet alleen dat maar ze lijken ook een stuck ethischer zaken te doen dan een hoop (amerikaanse) commerciele bedrijven, net als hun moeder bedrijf Open-Xchange overigens.

Met beide partijen om tafel gezeten (PD en OX) en ze lijken uitstekend te snappen wat op de lange termijn goed voor hun community, en het internet.

Bij mijn internetaanbieder is dat duidelijk, die is financieel afhankelijk van mij, dus zal normaliter in mijn belang handelen.

Nou, ik kan je vertellen dat dat bij Amerikaanse providers niet zo werkt. In een gezonde markt waar voldoende competitie is, wel. Of dat in Nederland het geval is, laat ik geheel aan jou over.

Wat een super slecht idee dit.

Om te beginnen gaat dit problemen opleveren met custom DNS entries. Dit is onder andere bij bedrijven zo’n beetje de standaard (voor interne services), maar ook voor bv thuisgebruikers met een pi-hole of andere DNS blocklist. Firefox omzeilt hiermee dus gewoon de blokkades die ik zelf bewust heb ingesteld. Dan moet ik weer op extensies vertrouwen dat ze al die Google- en andere tracking shit uit m’n browser weg gaan houden.

Maar ze creëren hiermee ook een afhankelijkheid op Cloudflare. Mijn eigen DNS ligt er nooit uit (is altijd up als m’n router up is), terwijl je dat van CF niet kunt garanderen. Die zijn vatbaar voor aanvallen, en met zo’n positie zijn ze natuurlijk een gewild doelwit. Behalve dat is het een Amerikaanse dienst en vallen dus onder de Patriot act. De VS krijgt hiermee weer extra aftapmogelijkheden. Plus dat CF de mogelijkheid krijgt om voor de VS ongewenste domeinen om te leiden, te blokkeren of te monitoren.

Voor de veiligheid van gebruikers in landen met een dictatoriale overheid gaat het in ieder geval niets helpen. Het is triviaal om gewoon 1.1.1.1 in het hele land te blokkeren en dan werkt heel Firefox niet meer totdat gebruikers het zelf uit zetten, of valt automatisch terug op “gewone” DNS.

En voor mijn eigen veiligheid heeft het sowieso een negatief effect. Ik heb liever dat bv google analytics compleet niet bereikbaar is dan dat ik moet hopen dat m’n filterextensies hun werk doen. Eigenlijk vind ik dit gedrag van Firefox gelijk aan dat van spyware met hardcoded adressen om z’n phone-home server te bereiken.

Bij bedrijven is het juist geen probleem. Als zij Firefox accepteren als browser, dan kunnen zij middels group policies deze functionaliteit uitzetten (in elk geval op Windows omgevingen). Thuisgebruikers die de betreffende know-how hebben om pi-hole o.i.d. gebruiken, zullen ook de know-how hebben om dit uit te zetten.

De afhankelijkheid van Cloudflare DNS is er uiteraard, maar het is wel opgezet als een Anycast systeem met een hele vracht eindpunten wereldwijd. Dit zal in de praktijk dus erg loslopen. (uiteraard geen 100% garantie)

Het voegt voor dictoriale overheden inderdaad niks toe, maar het staat daar ook niet in de weg (de situatie veranderd alleen niet)

Ik heb zelf ook een tijdje pi-hole gedraait, maar ik gebruik nu in plaats daarvan dnscrypt-proxy die draait op m'n Unifi router. Deze heeft ook een blacklist voor domeinen, en praat DoH en DNSSEC. Het enige dat het niet heeft een mooie webinterface (die heeft ie helemaal niet) maar daar loop ik in de praktijk nooit tegenaan.

Zoals ook al op het tweakers pihole forum gemeld:

Om ervoor te zorgen dat firefox pihole niet negeert (DoH ingebouwd in firefox), voeg het volgende toe aan /etc/dnsmasq.d/01-pihole.conf:

server=/use-application-dns.net/

en herstart pihole-FTL (sudo service pihole-FTL restart)

referenties:
[pihole support forum en mozilla.

Deze setting zou in een volgende release van pihole standaard opgenomen zijn in de dnsmasq settings (GitHub).

Het is geen goed idee om de setting in een aparte dnsmasq configuratie file te plaatsen. Wanneer pihole dit effectief toevoegd aan /etc/dnsmasq.d/01-pihole.conf, zul je, bij de volgende update van pihole, problemen hebben (pihole-FTL: duplicate setting). De pihole configuratie kan je steeds "syntax checken" met het commando pihole-FTL dnsmasq-test

Enig nadeel aan het plaatsen direct in 01-pihole.conf is dan toch wel dat je bij een update van pihole het ook weer kwijt bent en je deze handmatig moet toevoegen? Overigens staat het wel dus gepland inderdaad voor een volgende release dus die pijn is dan maar tijdelijk.

Er is een machtsstrijd gaande op internet tussen de tech-reuzen, de techneuten en de overheid.
De tech-reuzen schermen de gebruikers af van hun ISPs en de overheid. Ze denken dat ze door alles versleuteld via poort 443 te laten lopen ongemerkte censuur praktisch onmogelijk maken. Dat is mooi als je zo'n bedrijf meer vertrouwt dan je eigen overheid, en er zijn landen/situaties waarin dat een terecht is.

Het kan ook omgekeerd werken. De overheid kan zo'n bedrijf onder druk zetten en toegang eisen tot alle informatie. Nu geloof ik wel dat bedrijven als Google en Cloudflare niet direct zullen instemmen als de dictator van een derdewereldland om informatie vraagt, maar de rijkere en machtigere landen zullen hun zin uiteindelijk wel krijgen. Uiteindelijk hoort dat ook zo, bedrijven moeten naar de regering luisteren, maar tegelijkertijd zet het de deur open voor zeer verregaande surveillance en controle waarmee je mensen van seconde tot seconde kan volgen.
De techreuzen lijken er op te gokken dat ze voldoende weerstand kunnen bieden en er toch geen totaalverbod op hun sites en dienstverlening komt, maar als ik naar China kijk weet ik dat de overheid vroeg of laat toch wel wint.

Bijkomend voordeel voor de techbedrijven is natuurlijk dat ze steeds gedetailleerdere informatie over hun gebruikers verzamelen en steeds grotere stukken van de infrastructuur onder controle krijgen. Daarmee kunnen ze het hun concurrenten erg moeilijk maken.

Maar, als ik het goed begrijp worden DNS queries vanaf dan vanuit de browser gedaan? Is dat niet totaal onwenselijk?

Ik kan me niet voorstellen dat Firefox dan nog interessant is voor bijvoorbeeld bedrijven met een intranet, of mensen met interne DNS servers. Dit werkt dan toch enkel voor het internet? Weet iemand hoe ze dat afvangen?

Voor enterprise is het inderdaad een probleem, maar goed, je kunt opt-out doen. Weet niet hoeveel bedrijven gebruik maken van eigen dns-servers, is dat standaard?

Weet niet hoeveel bedrijven gebruik maken van eigen dns-servers, is dat standaard?

Ja. Tegelijkertijd is dit niet zo'n probleem. Via Server Name Indication kunnen IDS/IPS systemen vaak ook zien welke site een browser poogt te bereiken. Verder kunnen bedrijven DNS-over-HTTP via policies uitschakelen.

Ook kunnen organisaties aangeven dat DNS over HTTPS niet werkt op hun netwerken:

Network administrators may configure their networks as follows to signal that their local DNS resolver implemented special features that make the network unsuitable for DoH:

DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver.

The domain “use-application-dns.net” is referred to as a “canary domain”. Some existing DNS filtering providers already implement similar domains for users to verify that filtering is working. This new domain is different because it is meant to be implemented across many filtering solutions, and also checked by software such as Firefox, rather than checked explicitly by the user. This mechanism was created by Mozilla as an interim measure until a more permanent Internet standard for signaling the presence of DNS-based content filtering can be approved.

(...)

The additional checks that will be performed for private “enterprise” networks are:

• Is the Firefox security.enterprise_roots.enabled preference set to true?
• Is any enterprise policy configured?

Dat zijn voldoende beheeropties op zowel het netwerk als op bedrijfscomputers.

[Reactie gewijzigd door The Zep Man op 10 september 2019 08:41]

Het is nog best moeilijk om een standaard resolver als BIND9 een NXDOMAIN-antwoord te laten genereren voor een domain dat anderszins wel bestaat. (NOERROR, SERVFAIL zijn simpel.)

Mozilla lijkt opt-out expres moeilijk te maken, ook voor technisch onderlegden.

Update: het volgende werkt:

named.conf:

options {
...
response-policy { zone "rpz.local"; };
};
zone "rpz.local" in {
type master;
file "/usr/local/etc/namedb/master/rpz.local";
allow-query { none; } break-dnssec yes;
};

rpz.local:
$TTL 1H

@ SOA localhost. root.localhost. (1 2H 30M 30D 1H)
NS localhost.

use-application-dns.net CNAME .

Met dank aan JP Mens, Stephane Bortzmeyer en de officiële documentatie.

[Reactie gewijzigd door LanTao op 10 september 2019 17:51]

Er zitten een aantal foutjes in je config. De break-dnssec hoort bij de response-policy, niet bij allow-query. Daarnaast is de in bij de zone directive niet per se nodig en ben je in het NS record de @ vergeten (is toch wel handig), ook zou ik als serial niet simpelweg 1 gebruiken. Beter is dus:

# named.conf{.local,.options}
options {
# ...
response-policy { zone "rpz.local"; } break-dnssec yes;
};
zone "rpz.local" {
type master;
file "/usr/local/etc/namedb/master/rpz.local";
allow-query { none; };
};

# rpz.local
$TTL 1H
@ SOA localhost. root.localhost. (2019093001 2H 30M 30D 1H)
@ NS localhost.
use-application-dns.net CNAME .

EDIT: In de ESR versie van Firefox sloopt network.trr.mode=5 blijkbaar heel DNS, dus ik heb gewoon hetzelfde grapje als bovenstaand uitgehaald voor mozilla.cloudflare-dns.com. Oftewel gewoon een regel toevoegen aan rpz.local:
mozilla.cloudflare-dns.com CNAME .

Het lijkt me namelijk dat de browsert alsnog eerst via lokale DNS de naam mozilla.cloudflare-dns.com moet resolven. Of het ook echt werkt kan ik niet zeggen maar het is een kleine moeite om te proberen.

[Reactie gewijzigd door McBacon op 30 september 2019 19:43]

Klopt, ik had dat statement er later tussengekluund, blijkbaar op de verkeerde plek. Maar 1 is wel een werkend zone serial, hoor! En de tweede @ wordt geërfd van de vorige regel.

Ik weet niet zeker of de TRR-implementatie in de ESR-versie compleet is.

Elk bedrijf met een Windows netwerk met een Active Directory domein heeft een eigen DNS.
Die DNS is cruciaal voor de werking van de AD. En zal ook altijd alle DNS queries van de clients moeten verwerken. In die DNS zet je dan forwarders voor die queries die de DNS server zelf niet kan beantwoorden.
Die forwarders kun je zelf kiezen. Of gebruik maken van de DNS root servers.

In mijn geval heb ik een 3-tal AD/DNS servers en als forwarder een PI-Hole DNS draaien, die zelf dan weer forward naar verschillende externe DNS servers.

Naar mijn weten kan Pi-Hole nog niet gebruik maken van DNS over HTTPS.

Indien FireFox zelf DNS queries gaat doen i.p.v. de Windows DNS Client gebruiken dan gaan allerlei interne DNS request natuurlijk in de fout.

Pi-Hole kan zeker DNS over HTTPS gebruiken. Gebruik het zelf thuis namelijk ook.
Installeer Cloudflared, bepaal in de config je gewenste DNS severs, en laat Pi-Hole naar zn lokale adres kijken. (plus 5353 uit mn hoofd)

Performance-wise heeft dit geen impact, terwijl je dns traffic ge-encrypt is.

Dank je voor de tip. Ik zal er zeker naar kijken, alhoewel ik niet super handig ben met Linux.
Pi-Hole installeren en een beetje onderhouden gaat best, maar allerlei extra tools installeren is wat lastiger.

Is goed te doen gelukkig
Hier staat de manual, (beetje copy pasten eigenlijk)

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

Ik snap niet goed hoe dat hier gaat werken.
Je browser gaat DOH requests direct sturen naar clouflare en niet via de pi-hole passeren.
Deze laatste kan sowieso dan toch niet zien welke domains er gerequest worden want die zijn encrypted.

Als ik de manual snel overloop, dan lijkt het eerder dat gewone dns requests naar Pi-hole worden gestuurd, die ze (die niet gedropped worden) dan via DOH naar cloudflare gaat verder sturen.

Als je DoH wil gebruiken op je LAN, kan je ook pi-hole vervangen met dnscrypt-proxy2. Hier kan je ook simpel een blacklists/whitelists in verwerken. Dit scheelt weer een schakel. (van je pi-hole, naar dnscrypt-proxy2 (of cloudflared) naar het internet.

Dank voor de tip, als ik wat tijd heb zal ik er eens even naar kijken.

Heel gebruikelijk in zakelijke omgeving. Verbinding naar je directory (vaak gebaseerd op Active Directory) om zo interne en externe middelen te resolven. Vooral grotere bedrijven hebben grote interne webportals en web apps die niet extern ontsloten zijn.

Er is echter wel een trend gaande om deze te vervangen door public facing ontsluiting/hosting dmv cloud.

Kun je daarbij niet een verschil maken tussen het verkeer naar je intranet (geen DoH) en het externe verkeer (wel DoH)? Dan heb je het beste van beide werelden lijkt me, of zeg ik nou iets doms?

Dan krijg je snel te maken met een dubbele administratie (entries in je interne DNS en het werkplek beleid voor Firefox om daar uitzonderingen op te maken) wat geen voorkeur heeft. In het verleden zag je dit bij proxy instellingen.. al het verkeer via een centrale proxy dienst m.u.v. interne resources. Beheerders werden er gek van.

De ideale situatie zou zijn om de DNS forwarders van je interne DNS servers naar een DoH server te laten wijzen. Dan is je DNS query niet meer te tappen. Dit vereist echter een aanpassing aan de DNS servers zelf. Die ondersteunen dat nog niet.

Het probleem zit in de snelheid. Je wilt niet weten hoeveel websites er worden aangeroepen door één pagina. Iedere opgevraagde URL heeft een DNS query nodig. Als je lokaal een caching DNS server hebt staan gaat dat prima maar als Firefox voor ieder request naar een server op internet moet ga je zitten wachten.

Voor enterprise is het inderdaad een probleem, maar goed, je kunt opt-out doen. Weet niet hoeveel bedrijven gebruik maken van eigen dns-servers, is dat standaard?

Hoeft niet eens een DNS server te zijn: Je exposed hiermee gewoon je hele interne netwerk naar de buitenwereld toe. Een example.lan adres bijvoorbeeld wordt eerst geresolved op cloudflare, alvorens de interne resolver het overneemt...

Klopt helemaal. Ik zie echter vrij veel bij bedrijven dat ze dit ook op andere manieren doen. (van die URL-assistenten in de browser, die effectief iedere toetsaanslag doorsturen naar je ingestelde zoekmachine zodat die aangevuld worden)

Ik vermoed, dat Firefox network.trr.mode op 3 zal zetten.
DoH eerst en normale DNS als backup.

Dit geeft in ons netwerk, waar wij eigen DNS servers hebben voor o.a. interne domeinen geen probleem op dit moment.
Als je, in je firewall 1.1.1.1 zal blokeren, zal bij deze mode, altijd terug vallen op normale DNS.

Ik ben niet blij met deze mode, omdat je dat interne domeinen gaat lekken, Wat voor bedrijven, die het beleid "security by obscurity" hebben een probleem kan zijn.

Mocht het mode 2 gaan worden.
DoH aan, normale DNS uit. Wat ik vanuit privacy zeer kan begrijpen. Leverd dit voor interne DNS wel een probleem.

Maar mijn grootste probleem, is dat ik als netwerk beheerder. Niet meer zou kunnen zeggen via o.a. dhcpd, welke DNS server iemand zou moeten gebruiken, binnen mijn netwerk.
Straks gaan de lookups van de browser via DoH, volgens een setting in de browser en de rest van mijn O.S. pakt de DNS server die door de dhcpd server wordt aangewezen.

Overigens, vind ik DoT (DNS over TLS) een stuk fijner, aangezien dit een toevoeging is op de huidige DNS diensten. Als het O.S. DoT ondersteund. Zal die kijken of de aangeboden DNS server via dhcpd, DoT ondersteunen en vervolgens gebruiken,
Dit wordt door o.a. XS4ALL ondersteund. En ook al zou KPN, XS4ALL de nek omdraaien. Heb ik meer vertrouwen in KPN met de AVG in mijn hand, dan een Amerikaans bedrijf.

[Reactie gewijzigd door wica op 10 september 2019 09:08]

Ik ben niet blij met deze mode, omdat je dat interne domeinen gaat lekken, Wat voor bedrijven, die het beleid "security by obscurity" hebben een probleem kan zijn.

Juist om die reden ben ik wel blij met die mode. "security by obscurity" kan écht niet meer (en kon eigenlijk nooit). Mag wat mij betreft ook veel harder worden aangepakt bij datalekken als blijkt dat ze een "security by obscurity"-beleid voerden.

security by obscurity, kan een aanvullende maatregel zijn. Boven op je normale beveiliging beleid.
Het kan voorkomen, dat een externe partij, zonder jouw weten, je infrastructuur in kaart brengt.

Toen Certificate Transparency (TLS) ingebruik werd genomen, kwamen nog al wat dev, test etc omgevingen van bedrijven in het openbaar. Spijtig genoeg, is een niet prod omgeving vaak minder goed beveiligd dan de prod omgeving.

in grotere bedrijven komt het zeker vaker voor. Het is eenvudiger om aan Jan met de pet uit te leggen dat hij moet surfen naar interncmssysteem.bedrijf.lan dan naar 10.112.1.33:8843 .

Grote bedrijven hebben dat sowieso, die draaien bijvoorbeeld ActiveDirectory, wat DNS zelfs vereist.
DNS is ook wel een redelijk belangrijke dienst om te hebben, dat wil je (zeker voor de wat grotere en complexere netwerken in eigen beheer hebben.

[Reactie gewijzigd door CH4OS op 10 september 2019 09:24]

Veel modem/routers bieden standaard een DNS proxy aan. Dat maakt het makkelijk om interne namen te resolven, en scheelt ook behoorlijk in DNS verkeer als je een paar apparaten hebt. Als je een URL van je telefoon naar je TV stuurt, eindigt de daaruit volgende DNS lookup van je TV al bij je lokale modem, die het antwoord nog in de cache heeft staan van toen je telefoon het vroeg. Dat scheelt toch snel wat milliseconden aan round-trip naar de verre DNS server.

Voor het verbergen van DNS queries voor man-in-the-middle zijn er al bestaande protocollen.

Wat veel beter zou zijn is om het lokale DNS verkeer gewoon te laten wat het is, en pas encryptie toe te passen tussen modem/router en het grote boze internet. Dan heb je lokale caching, geen problemen met lokale lookups en AD, en toch een veilige verbinding naar buiten.

Ik kan het mis hebben hoor, maar volgens mij worden de dns queries altijd vanuit de browser gedaan. Enige is dat het een apart request is.
De dns request wordt via cloudflare gedaan, achter een proxy, zodat deze altijd anoniem zijn, althans...voor iedereen behalve cloudflare . Juist interne dns servers (voor intranetten) is lastiger, omdat je het request niet meer via je netwerk dns gaat. Dus als jij dns intern hebt, zeg 192.168.1.2 (dns server), en die routeerd; ://intranet naar 192.168.1.10, dan is dat lastiger aan het worden. Wellicht zal er vast wel aan gedacht zijn hoe dat moet. Maar initieel zou het request dan wat langer duren. Ook een dns in de browser heeft een korte cache, zodat je niet telkens dit request hoeft te doen.

Dit is hoe mijn idee van dns requests vanuit de browser gaan, correct me if im wrong.

Uiteraard worden de queries vanuit je browser gedaan, maar bijna niemand heeft z'n DNS op z'n clients geconfigureerd. Meestal in bijvoorbeeld een consumenten netwerk loopt dat via je router, maar die kan echt geen queries handlen via port 443

In Enterprise is dat niet veel anders, wel een andere schaal, maar een DNS server is daar niet weg te denken. Ik ben benieuwd hoe ze dat willen afvangen. Ik kan me niet voorstellen dat de dat niet afvangen aangezien een opt-out killing zal zijn voor het marktaandeel van Firefox binnen enterprise.

[Reactie gewijzigd door Johan9711 op 10 september 2019 08:33]

Je kunt enterprise technisch dit ws via een policy uitzetten voor je hele netwerk? Dan is het geen probleem meer lijkt me.

Er is gewoon een GPO om het uit te zetten, dus de sysadmin moet gewoon zijn werk doen, En Chrome krijgt ook zo'n GPO als ze het toevoegen (geplant voor testing in 78 volgens mij). Dus tenzij je IE wil gaan gebruiken binnen de organisatie heb je het er maar mee te doen. En als het allemaal zo erg is fork je de zooi maar, maar zo belangrijk gaat een bedrijf het echt niet vinden.

DNS requests worden door de browser gedaan, maar die gebruiiken daar wel de DNS client van je OS voor. De browser zelf doet dus geen actieve DNS requests, dat doet je DNS client.
Dus browser wil website bezoeken, DNS client resolved IP adres bij website domein, geeft deze terug aan de browser, waarna de browser de verbinding initieerd.

Bij DNS over HTTP, wordt de DNS client van je eigen systeem dus uit deze loop gehaald en wordt er een HTTPS verzoek gedaan naar cloudflare servers, die de DNS qeuery voor je uitvoeren.
Dit kan inderdaad een stuk veiliger zijn, maar ik heb toch de voorkeur aan mijn eigen DNS client.
Die kan ik configureren zoals ik zelf wil.

Bij een grotere bedrijven is dit juist geen probleem. Als die Firefox accepteren als browser, dan zullen zij ook de configuratie met policies afdwingen en dan deze functionaliteit uitzetten.

Ik zie wel eventueel een dingetje voor kleine bedrijfjes die niet (weten hoe ze met) policies (moeten) werken, en voor thuisgebruikers die allerlei domotica hebben die over het lokale LAN gaan.

Slechte zaak, paar maanden geleden al uitgezet. Ik draai een eigen DNS-server, die wordt hierdoor zonder overleg buiten spel gezet ten faveure van een Amerikaanse provider. DNS kan prima over TLS, Firefox trekt hier core OS functionaliteit naar zich toe waar ze verre van moeten blijven.

Als je dit over TLS doet is de kans toch groot dat een land als Engeland (met z'n pornofilter) gewoon isp's verplicht die hele poort dicht te timmeren? Of alle autoritaire landen?

Ja, of tot de VS CloudFlare dwingt bij elke request voor Russische domeinnamen (of ander verdachte activiteiten) even een signaaltje naar de NSA te sturen.

Je kunt DNS ook via een proxy doen. Of via een SSH tunnel. Of op een afwijkende poort.

Standaardconfiguraties die landswetten omzeilen van populaire applicaties gaan toch snel beperkt worden door de betreffende overheden, dus op termijn schiet je hier weinig mee op.

Dat is inderdaad precies de kwestie. Het probleem dat ze proberen op te lossen zie ik niet zo: Ja, mijn internetaanbieder kan zien wat ik browse, maar omdat mijn internetaanbieder financieel afhankelijk van mij is, zal die wel uitkijken rare dingen te gaan doen, bovendien kunnen door de ip-adressen waarmee ik verkeer heb te loggen sowieso al een heel eind komen in mijn gedrag nagaan. Ofwel, dns-over-https verbetert mijn privacy maar beperkt.

Doordat alle verkeer nu met Cloudfare is het voor mijn internetaanbieder niet meer mogelijk mijn browsegeschiedenis te achterhalen, maar wel door Cloudfare, want die moet de DNS-verzoeken uiteindelijk uitvoeren. En Cloudfare staat onder de macht van de Amerikaanse overheid, dus spionage door inlichtingendiensten is een risico. Voor de economische spionage die de Amerikanen soms uitvoeren is dit een goudmijn: Er is altijd wel iemand in een bedrijf die Firefox gebruikt en informatie over werknemers verzamelen staat aan de bron van geslaagde spionage.

Toch is het niet alleen maar nadelig: Voor blokkades als van de Piratebay worden nu de middelen weggenomen. Naast DNS worden ook ip-adressen geblokkeerd, maar dat maakt het kat-en-muisspel al een stuk lastiger, ik kan TPB bijvoorbeeld via ipv6 bereiken, kennelijk is men lui met het actualiseren van de ip-adressen.

Doordat alle verkeer nu met Cloudfare is het voor mijn internetaanbieder niet meer mogelijk mijn browsegeschiedenis te achterhalen, maar wel door Cloudfare, want die moet de DNS-verzoeken uiteindelijk uitvoeren. En Cloudfare staat onder de macht van de Amerikaanse overheid, dus spionage door inlichtingendiensten is een risico. Voor de economische spionage die de Amerikanen soms uitvoeren is dit een goudmijn: Er is altijd wel iemand in een bedrijf die Firefox gebruikt en informatie over werknemers verzamelen staat aan de bron van geslaagde spionage.

Tevens vraag ik me af of het volgens de GDPR wel zou mogen. DNS requests kunnen/zijn best privacy gevoelig zou ik zeggen.

Behalve dat er bijna geen website/applicatie meer is die werkt als je port 443 dicht zet.

Je hoeft niet poort 443 dicht te zetten. Gewoon ip adres 1.1.1.1 blokkeren (redelijk triviaal) is al genoeg. En dan die van Google, OpenDNS en andere providers er gelijk bij voor de volledigheid.

Een poort "dichttimmeren" zou in het genoemde voorbeeld beteken dat ze verkeer op poort 443 (https) moeten blokkeren wat het einde is van veilig internet voor Engeland. Ze zouden blokkades op basis van IP adres kunnen doen maar dat is altijd een kat-en-muis spelletje. Daarnaast kan een DNS blokkade al eenvoudig omzeilt worden door simpelweg een andere DNS server te gebruiken.

Dns-over-tls gaat over poort 853, zoals ik het begrijp wordt die nergens anders voor gebruikt. 443 dichtgooien is idd niet mogelijk.

Dan stel je de dienst op een andere poort beschikbaar (en maakt dat configureerbaar in de client), of gebruikers zorgen ervoor dat ze via een VPN in het buitenland kunnen internetten. Internetfilters werken over het algemeen beroerd, tenzij je maar één (staats)provider hebt in het land dat je onder de duim houden wilt.

Overigens: waar jij hier Engeland schrijft neem ik aan dat je het Verenigd Koninkrijk bedoelt. Het land is al verscheurd, laten we alle landsdelen blijven benoemen voor iets dat weliswaar vanuit Engeland is aangeslingerd, maar consequenties heeft voor alle landsdelen en zeker het eiland Ierland.

Een beetje (zakelijke) firewall stel je in dat alles naar buiten dicht staat *behalve* de poorten die je *wel* nodig hebt: 80, 443, en desnoods wat maildingetjes (poort 25 mag ik hopen staat inmiddels dicht ten gunste van secure varianten). Dus als je een port randomizer gebruikt voor je toepassing heb je met 80 en 443 een kans van 1 op .. 32768? dat je een werkende treft.

65535
Je mag alle 16 bits gebruiken, behalve poort "0", dus 2^16-1.
(Sommige programmeurs vermijden de poorten boven 32767 uit angst voor "sign" problemen. Die problemen zitten niet in de libraries of OSsen, soms wel in brakke socket client code...)

Jaaa maar poort 80 en 443 zijn 2 poorten, dus is de kans 2 op 65536. En vereenvoudigd is dat dus 1 op 32768

En die ene poort die je niet mag gebruiken rondt wat lastig af als je het deelt door 2...

[Reactie gewijzigd door DigitalExorcist op 10 september 2019 12:58]

Uiteraard, ik zat nog met poort 443 voor DoH in mijn hoofd

Volgens mij bedoelt @Tijs Hofmans dat je dan poort 53 zou kunnen dichttimmeren bij de provider. Dan kun je geen andere DNS-server gebruiken zonder maatregelen te nemen, zoals bijvoorbeeld een proxy gebruiken of een DNS-server op een afwijkende poort gebruiken.

Tijs bedoelt het dichttimmeren van de DNS TLS poort, wat juist een stuk makkelijker kan dan het algemenere 443 omdat veel websites het dan überhaupt niet meer doen.

Kunnen ze dat niet ook met de cloudfare DNS server?
Het verzoek is versleuteld, maar er moet iets openbaar zijn om naar Cloudfare te routen natuurlijk.

Blokkeer gewoon het DNS adres (1.1.1.1 geloof ik, die sowieso al niet geliefd is bij providers omdat hij vaak abused wordt voor slecht opgezette interne netwerken), en poef, DNS over HTTPS naar cloudfare is geblokkeerd

ISPs hebben wel wat handigere methoden om blokkades op te werpen dan 'een poort blokkeren'. Als ze hun pornofilter willen handhaven op basis van DNS, dan gaat dat natuurlijk niet zo veel uithalen.

Buiten dat gaat het over DoH (op poort 443). Ze zouden er eventueel voor kiezen om alle verzoeken naar Anycast adres 1.1.1.1 te blokkeren, maar ook dat is maar beperkt effectief (gezien het aantal publieke name servers op internet)

Firefox had een optie moeten geven welke DNS-server de verzoeken moet verwerken want nu krijg je inderdaad die Amerikaanse DNS provider als enige keuze.
Snap dat blinde vertrouwen in die enige Amerikaanse DNS provider ook niet helemaal.

Die mogelijkheid bestaat gewoon.
Onder Opties => Algemeen => Netwerkinstellingen => DNS over HTTPS inschakelen en dan in het dropdown menu "Aangepast" kiezen.

Kortom ze hebben weer gekozen om het opt-out in een obscure menuoptie te stoppen. Volgende stap, als de geschiedenis enige les is, is het onder about:config stoppen en dan na verloop van tijd ook dat niet langer configureerbaar te maken.

Firefox had dit als extensie moeten aanbieden, of in ieder geval als expliciete opt-in. Hoe mooi de woorden van Cloudflare ook zijn, het is een for-profit bedrijf EN Amerikaans dus niet te vertrouwen (net als Mozilla uiteraard, maar er zit een verschil tussen gebruik maken van een product (ik kan controleren wat er gebeurd) of gebruik maken van een service (geen enkele controle)...

Hoe mooi de woorden van Cloudflare ook zijn, het is een for-profit bedrijf EN Amerikaans dus niet te vertrouwen

Kan je daar op uitwijden? De 'dus' vind ik erg interessant. Waarom is ieder Amerikaans bedrijf met winstoogmerk in jouw optiek niet te vertrouwen? (en suggereer je dan dat ieder Nederlands, Canadees of Frans bedrijf met winstoogmerk wel te vertrouwen is of is dat te kort door de bocht?)

Ben het met je eens. Echter is dat, wat Firefox betreft, zeker niet nieuw: doen ze namelijk ook (al langer) met de certificate store (wat je middels about:config kan aanpassen).

Wat bedoel je met de certificate store? Ik weet dat Firefox standaard via OCSP informatie over je browsegedrag lekt mbt certificates,, is dat wat je bedoelt?

Firefox maakt standaard geen gebruik van de certificate store van het OS. Voor gebruik binnen bijvoorbeeld enterprise omgevingen, waar vaak interne certificaten voor intranet sites/omgevingen gebruikt worden en gedistribueerd worden in de images, moet je de flag "security.enterprise_roots.enabled;true" aanzetten.

Docs: https://wiki.mozilla.org/CA/AddRootToFirefox

Browsers that attempt to validate certificates issued by a private CA certificate will display errors unless they are configured to recognize these certificates. Since Firefox does not use the operating system's certificate store by default...

[Reactie gewijzigd door Caayn op 10 september 2019 09:00]

Nee, maar wel van de certificate store op je eigen machine. Deze wordt toch niet live bijgewerkt, maar alleen bij updates van Firefox?

Nee, maar wel van de certificate store op je eigen machine. Deze wordt toch niet live bijgewerkt, maar alleen bij updates van Firefox?

Klopt. Mijn punt is dat ze ook daar echter geen gebruikmaken van faciliteiten die in het OS gebakken zijn maar zelf iets voorzien (wat dan enkel werkt in Firefox).

Pi-Hole zal op deze manier ook niet meer werken, lekker opt-out dus.

Wat gaat dit doen met mijn Pi-hole 'DNS Sinkhole' functionaliteit? Ik heb wel gevonden hoe je Pi-hole van dns over HTTPS gebruik kunt laten maken https://docs.pi-hole.net/guides/dns-over-https/ , maar als de browser zelf via https naar een externe DNS server gaat, kan je dat niet onderscheppen. Iemand die hier meer van weet?

In about:config kun je de server en een bootstrap-IP instellen

Aangezien de DNS verzoeken direct via HTTPS vanuit je browser worden gedaan kan ik me voorstellen dat Pi-Hole wordt omzeild en dus voor Firefox niet meer werkt. Gelukkig is het een opt-out en kan je nog steeds Pi-Hole gebruiken. Mooi dat Pi-Hole ook ondersteuning van DNS-over-HTTPS ondersteund, dat ga ik vanavond eens instellen.

Sowieso is dit in eerste instantie alleen voor Amerikaanse gebruikers. Als ikdit artikel lees lijkt het echter mogelijk te zijn om het netwerk zo te configureren dat DoH uitgeschakeld wordt.

Alternatief: https://discourse.pi-hole...disable-firefox-doh/23243

Ik draai Pi Hole al vrij lang met DoH naar Cloudflare. Dat werkt prima. De router leidt alle DNS requests over de gebuikelijke port 53 die het netwerk willen verlaten om naar de Pi Hole. Dit gebeurt met NAT dus als een interne client bijv een request doet naar 8.8.8.8 dan denkt die ook van 8.8.8.8 antwoord te krijgen.

DoH werkt prima maar tegelijkertijd kun je DoH van interne clients maar moeilijk blokkeren. Je kunt een blacklist gaan bijhouden in de router om dat verkeer te blokkeren maar dan krijg je ook onvoorspelbare resultaten als clients geen fall-back doen naar normale DNS. Omleiden zoals met normale DNS requests gaat helaas niet want het is immers HTTPS.

[Reactie gewijzigd door Anoniem: 1092407 op 10 september 2019 09:31]

Als je die kant op gaat, kan je net zo goed pi-hole vervangen door dnscrypt-proxy2. Die praat native DoH en heeft ook een DNS-blacklist. Dan is je pi-hole alleen maar een extra laagje die niks meer doet dan een GUI toevoegen.