KPN schakelt dnssec in voor alle vaste en mobiele klanten

KPN heeft dnssec ingeschakeld voor alle vaste en mobiele klanten. Met die extensie van het domain name system worden dns-queries digitaal ondertekend. De provider heeft de implementatie stilletjes geactiveerd.

KPN bevestigt aan Tweakers dat het de afgelopen weken is begonnen met het inschakelen van dnssec. "Daar hebben we vanwege de huidige situatie rondom het coronavirus nog niet zoveel ruchtbaarheid aan gegeven", zegt een woordvoerder. Dnssec-validatie is in december al aangezet voor klanten van Telfort. Dat gebeurde omdat Telfort minder gebruikers had. De andere dochteronderneming, Xs4all, heeft al sinds 2016 dnssec standaard aan staan. KPN gebruikt PowerDNS als resolver, zegt een woordvoerder.

Dnssec is een protocol waarbij gebruikers beter beschermd zijn tegen aanvallen via onder andere dns spoofing, bijvoorbeeld wanneer zij slachtoffer worden van een man-in-the-middle-aanval. Websitebeheerders of hostingproviders kunnen een digitale handtekening toevoegen aan hun site, die vervolgens door rootservers wordt gevalideerd. Op die manier kan een provider verifiëren of een gebruiker de juiste website bezoekt. De SIDN biedt sinds 2012 ondersteuning voor dnssec voor .nl-domeinen.

Het dnssec-protocol heeft ook nadelen, bijvoorbeeld wanneer verschillende nameservers verschillende sleutels gebruiken. In een gesprek met de SIDN vertelt KPN dat de implementatie vooralsnog tot weinig klachten en problemen bij gebruikers leidt. "Validatiefouten komen wel voor, maar zijn uitzonderlijk", zegt het bedrijf.

Reacties (83)

[CAPSLOCK2000]

tip: De site https://dnsviz..net/ is van enorme waarde als je ooit iets met DNSSEC te maken hebt of vermoedt dat DNSSEC je probleem is.
Met grote vlakken, pijlen en rode kruizen wordt aangegeven wat er werkt en wat niet.
Zelfs als je niet precies begrijpt wat er staat geeft het je aanknopingspunten waar je mee verder kan.
Het kan ook erg handig zijn om minder technische partners te overtuigen dat er iets mis is. Die reageren nogal eens met "DNSSEC? nooit van gehoord, dat doen wij niet hoor, voor mij werkt alles gewoon!".
Als je die een link kan sturen met een groot rood kruis op hun eigen domeinnaam denken ze toch wat langer na.

Voorbeeldje, Tweakers!
https://dnsviz.net/d/tweakers.net/dnssec/
Het is misschien niet het beste voorbeeld omdat Tweakers nog geen DNSSEC heeft, maar je kan in ieder geval zien dat .net het wel heeft, en twakers.net niet. Dat het er echt niet is (en dus niet stiekem geblokkeerd wordt) zie je aan het NSEC3 record. Daarmee weet je dat Tweakers nog geen DNSSEC heeft.

Vergelijk dat maar eens met freedom.nl dat wel DNSSEC heeft geactiveerd:
https://dnsviz.net/d/freedom.nl/dnssec/

Ten slotte moet je een keer kijken naar een site die (opzettelijk) stuk is:
https://dnsviz.net/d/dnssec-failed.org/dnssec/
De rode pijl maakt vrij duidelijk waar het fout gaat.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 15:30]

[Verwijderd]

Persoonlijk vind ik het nogal vreemd dat providers DNSSEC en zo nog enkele andere opties niet al per default hanteren. Het eerste dat opvalt bij "ALLE" providers is het ontbreken van TLSA, DANE, OCSP en dat soms uitgefaseerde of nog uit te faseren ciphers nog (veelvuldig) worden gebruikt.

Met DNSSEC schep je naar klanten de verwachting dat een provider de veiligheid op orde heeft maar als je verder kijkt kom je toch best gekke verrassingen tegen. Het merendeel gebruikt zelfs geen SPF, domainkeys etc. - terwijl juist met dit laatste veel spam dat afkomstig is van e-mail adressen gebruikt door klanten bij providers (d.m.v. spoofing) kan worden voorkomen.

Is DNSSEC alleen dus eigenlijk wel voldoende?
Freedom @ Internet.NL
XS4aLL @ Internet.NL
KPN @ Internet.NL

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:30]

[CAPSLOCK2000]

Persoonlijk vind ik het nogal vreemd dat providers DNSSEC en zo nog enkele andere opties niet al per default hanteren. Het eerste dat opvalt bij "ALLE" providers is het ontbreken van TLSA, DANE, OCSP en dat soms uitgefaseerde of nog uit te faseren ciphers nog (veelvuldig) worden gebruikt.

Met DNSSEC schep je naar klanten de verwachting dat een provider de veiligheid op orde heeft maar als je verder kijkt kom je toch best gekke verrassingen tegen. Het merendeel gebruikt zelfs geen SPF, domainkeys etc. - terwijl juist met dit laatste veel spam dat afkomstig is van e-mail adressen gebruikt door klanten bij providers (d.m.v. spoofing) kan worden voorkomen.

Is DNSSEC alleen dus eigenlijk wel voldoende?

Het is zeker niet genoeg, het is maar een onderdeel.
Ik word ook wel eens mismoedig over hoe moeilijk het is om iets gedaan te krijgen als het om veiligheid gaat. Er heerst een soort "niemand mag er last van hebben" mentaliteit. Na een grote hack onlangs zag ik dat er ergens opeens wel budget was voor security. Maar alle concrete voorstellen om iets te doen met dat budget werden onmiddellijk afgedaan als te moeilijk of te lastig voor de gebruikers.
Van de ander kant moet ik ook wel zeggen dat beveiliging een enorm breed en complex gebied is. Om alles goed te doen kost bakken met geld en tijd, zoveel dat eigenlijk niemand het zich kan veroorloven om het echt goed te doen.

[Verwijderd]

Kost het invoeren van de door mij eerder genoemde zaken echt zoveel tijd, geld en is het werkelijk zo complex? Als ik zie dat het merendeel binnen een uur gerealiseerd kan zijn "en dan is het ook goed" en heb je de basis in principe al op orde.

DNSSEC kun je voor een website binnen 1 uur helemaal gereed hebben, de rest is in feite puur op de achtergrond en vergt bijna geen tijd. Of je het nu hebt over DANE, TLSA, SPF etc.

Zal de gedachten gang van het bedrijfsleven zelf wel zijn - maken het complexer dan het werkelijk is?

[GeroldM]

Een standaard webservertje wat net is geinstalleerd, is gemakkelijk te beveiligen.
Een standaard DNS servertje wat net is geinstalleerd, is gemakkelijk te beveiligen.
Een standaard mailservertje, wat net is geinstalleerd, is gemakkelijk te beveiligen.

Zie je een patroon? Goed.

Helaas zijn er een boel bedrijven/instellingen die met met allerlei meuk zitten opgescheept, want er zijn over de jaren alleen maar meer regeltjes/afhankelijkheden/ideeen over configuraties doorgevoerd door de voorganger van de voorganger van de voorganger van de admin, waarbij geen van hen ooit aan afdoende documentatie heeft gedaan (of dat van hun baas nooit hebben mogen doen, want tijd is geld...).

Dan heb je ook nog eens verschillende werkwijzes die zijn doorgevoerd over de jaren door verschillende bazen en zit je nu dus wel met een hoop ongedocumenteerde legacy, wat je niet in een uurtje even overzet.

Uithuilen en opnieuw beginnen zou het beste zijn, maar voor de extra computers die daarvoor nodig zijn is geen budget, er is ook geen geld voor extra inhuur, zodat de admin zich volledig op het herbouwen en documenteren kan storten en het oude computerpark mag niet plat, want...zaken.

En ja, des te langer een organisatie/bedrijf bezig is, des te complexer worden zaken, want iedereen dramt er zijn eigen dingetje door, er is altijd verloop en niemand gaat uit eigen wil goed documenteren.

[rant]
Elk bedrijf met 30 personen of meer zou er goed aan doen om een documentalist aan te nemen/in te huren. Kun je stellen dat documentatie er gemakkelijk even bij gedaan worden door de contributeur zelf. Klinkt ook logisch. Maar uiteindelijk levert het veel minder gestructureerde documentatie op en maakt men er al gauw geen gebruik meer van want niemand kan wat hij/zij nodig heeft niet (meteen) vinden en de documentatie word vanzelf irrelevant.

Een documentalist die als een dictator de documentatie doet, daarmee krijg en hou je er structuur in. Heb al genoeg verschillende geautomatiseerde documentatie systemen gezien, ook een dictator documentalist. En zijn documentatie was echt veel beter dan al die geautomatiseerde systemen bij elkaar.

De software architect was een stuk vrolijker met zijn documentatie, de ontwikkelaars konden veel beter inschatten hoeveel tijd ze nodig hadden, de klant had een duidelijk omschreven specificatie en beter besef van benodigde tijd en de testers konden op voorhand al testscenarios gaan bedenken, omschrijven en alvast gaan coderen/opzetten.

Klinkt als 'waterval'? Klopt, maar helaas moest de documentalist met pensioen. En nu zitten we met Agile/Scrum waarbij teveel mensen teveel tegelijkertijd inbrengen, veel te veel bezig moeten zijn via Teams om alle zin/onzin van elkaar te scheiden en veel te veel terugkerende vragen te moeten beantwoorden. Maar het is modern en daarom beter, want iedereen denkt er door druk mee bezig te zijn, ze ook bijdragen. Het neemt allemaal echter zoveel tijd in beslag dat men wel terug moet vallen op meuk als Electron om nog iets enigzins op tijd af te krijgen voordat de sprint is doorlopen.

Ik zou zo 5 coders om willen ruilen om die documentalist uit de motteballen te halen. Helaas is de goede man al enkele jaren terug overleden, dus geen optie en blijven we maar door rommelen op deze weg.

Van 1 ding ben ik absoluut zeker, diegenen die zo anti-'waterval' zijn, die hebben nog nooit met een goede documentalist gewerkt.
[/rant]

[casberrypi]

Makkelijk gezegd, maar als internetprovider kun je zomaar een wijziging doen waardoor bijvoorbeeld mogelijk de alarmknop om de nek van oma niet werkt.

De realiteit is dat er enorm veel afhankelijk is dit soort systemen en dat je dus voorzichtig moet zijn met wijzigingen in de infrastructuur. Jammer dat daardoor veel innovatie stopt inderdaad.

[kodak]

Met DNSSEC schep je naar klanten de verwachting dat een provider de veiligheid op orde heeft

Deze redenatie snap ik niet. Als een provider een beveiligingsmiddel inzet, hoe zou dat volgens jou dan de verwachting scheppen dat die provider de veiligheid op orde heeft?

[Verwijderd]

Als je goed rond kijkt op welke website ook van providers, dan lees je veelvuldig woorden als veilig, veiligheid, privacy etc. Klanten verwachten dit dan dus ook.

DNSSEC inzetten voor veiligheid is natuurlijk uitstekend. Maar dan vervolgens de helft laten liggen klopt natuurlijk niet. KPN zelf (bijvoorbeeld) zegt

Bij KPN gebruiken we standaard DNSSEC om jou veiliger te laten internetten. DNS staat voor Domain Name System en kan je zien als het telefoonboek van het internet. De naam van de site wordt vertaald naar een IP-adres. DNSSEC is een techniek die nog een keer extra checkt of het IP-adres echt klopt met dit telefoonboek. Op die manier krijgen kwaadwillenden geen kans om je stiekem naar een ander IP-adres te leiden.
Bron

Vervolgens laten ze wel DANE en TLSA liggen wat een aanvulling is (voor zover mij bekend) op DNSSEC.

[kodak]

Als er woorden staan gaat het om de context waarin ze staan. Neem het voorbeeld wat je gebruikt:

Bij KPN gebruiken we standaard DNSSEC om jou veiliger te laten internetten

Er staat toch veiliger? Er staat niet veilig of helemaal veilig. Hoe belangrijk die context verder is: het onderwerp is niet alles bij KPN is nu veiliger. Er staat dat het een specifieke vorm van beveiliging is, voor DNS. Er staat niet dat DNS nu veilig is. Er staat al helemaal niet dat alles veilig bij KPN zou zijn. Als je dat er wel in wil lezen verwacht ik een betere verklaring komen dan er staan woorden.

[timvisee]

Inmiddels een beetje te laat. DNSSEC is aardig achterhaald.

Edit ivm controversiële comment score: DNSSEC komt uit 1997, en ik doelde op DoH als alternatief. Zie de comment van @Eloy voor een heldere uitleg.

[Reactie gewijzigd door timvisee op 22 juli 2024 15:30]

[Antrax]

Bijzondere kijk op de zaken. Sure, het implementeren ervan is een behoorlijke bitch en ik kan het weten maar om het nou achterhaald te noemen vind ik een beetje te ver gaan. Het wordt niet door grote bedrijven opgepakt en geimplementeerd omdat het complex is en geld kost en dat willen bedrijven niet.

DNSSEC zorgt ervoor dat het door een resolver geretourneerde record door jouw is ondertekend en dus door niemand wordt vervalst. Ik zie dit als een win gezien de zwakheid van een DNS server zelf.

[Eloy]

Ik ben het volledig eens met timvisee. De ontwikkeling is in de jaren 90 gestart binnen de IETF om het internet te beveiligen en daarbij te beginnen bij DNS. Echter, doordat dit niet op tijd is gelukt hebben mensen het internet weten te beveiligen met de aanname dat DNS insecure is, door middel van TLS en het CA systeem.

> DNSSEC zorgt ervoor dat het door een resolver geretourneerde record door jouw is ondertekend en dus door niemand wordt vervalst. Ik zie dit als een win gezien de zwakheid van een DNS server zelf.

Maar wat heb je hieraan? TLS zorgt ervoor dat het end-user apparaat valideert dat hij praat met de juiste host. Als een aanvaller het IP adres uit de DNS tussendoor aanpast dan wordt het verkeer inderdaad langs een andere host gestuurd, maar doordat deze malafide host niet beschikt over de juiste private key kan er nog steeds geen MITM plaatsvinden.

Het idee is dat DNSSEC signatures toevoegt aan de zogenaamde "resource records" van DNS. Dit levert integriteit op, maar geen confidentialiteit. Een aanvaller kan nog steeds precies zien welke DNS requests je uitvoert.

DNSSEC heeft ook een negatieve impact op de beschikbaarheid van websites. Door een misconfiguratie kan een site plat gaan.

Kortom, het enige geclaimde voordeel is integriteit. Maar dit voegt door TLS helemaal niks toe.

Ben ik dan een tegenstander van meer DNS beveiliging? Zeker niet, DNS over HTTPS zorgt voor meer confidentialiteit zonder negatieve impact op de beschikbaarheid. Ik zou zeggen, deploy DoH, maar laat DNSSEC links liggen.

[niqck]

DNSSEC en DoH of DoT staan compleet los van elkaar. Zoals je zelf aangaf zorgt DNSSEC voor integriteit. DoH/DoT voor beveiligde transport.

Bij DNSSEC ben je zeker dat het antwoord effectief van de domain-owner komt. Ja, DNS-traffic kan nog altijd gesniffed worden maar dat was het doen van DNSSEC niet. Wat beschikbaarheid van websites betreft: ja dit kan een probleem zijn maar dat ligt dan m.i. eerder omwille van ongekend. Een vervallen certificaat kan ook voor onbeschikbaarheid zorgen. Kwestie is van je infrastructuur en de geldigheid van certificaten/DNSSEC-keys in het oog te houden.

Bij DoH/DoT wordt de traffic tussen je host en de recursor encrypted. Idealiter ook tussen de recursor en de authorative DNS-server maar dat lijkt voorlopig nog een droom. Als iemand onderweg (in een niet-beveiligde communicatie) je records wijzigt zal DoH/DoT daar niks aan toevoegen.

Om dus gewoon DNSSEC direct bij het grofvuil te plaatsen vind ik wat kort door de bocht. Draai al meer dan 5 jaar DNSSEC op een aantal domeinen. Ja het is een pest, je moet goed in het oog houden dat je KSK nog steeds geldig is. Maar dezelfde regels gelden ook voor certificaten.

[Eloy]

> Bij DNSSEC ben je zeker dat het antwoord effectief van de domain-owner komt.

Wat is het nut hiervan? Welke risico's mitigeer je?

> Idealiter ook tussen de recursor en de authorative DNS-server maar dat lijkt voorlopig nog een droom.

Er wordt wel degelijk aan gewerkt: https://tools.ietf.org/id...al-considerations-01.html

> Om dus gewoon DNSSEC direct bij het grofvuil te plaatsen vind ik wat kort door de bocht. Draai al meer dan 5 jaar DNSSEC op een aantal domeinen. Ja het is een pest, je moet goed in het oog houden dat je KSK nog steeds geldig is. Maar dezelfde regels gelden ook voor certificaten.

Zeker, die regels gelden ook voor certificaten. Maar die hebben een zeer duidelijk voordeel voor de eindgebruiker. Ik vind het zelf niet kort door de bocht om te stoppen met een complex systeem als er geen duidelijke voordelen zijn.

[Dorank]

Wat is het nut hiervan? Welke risico's mitigeer je?

DNS injection/alteration en rogue (authoritative) DNS servers.

Aanpassing in transport zijn niet meer mogelijk (waarom zou je je DoH server (en alle DNS servers die door deze worden bevraagt) zomaar vertrouwen).
En je kan niet zomaar van DNS server wisselen zonder ook de keys bij de TLD beheerder aan te passen. Dat laatste zal helaas wel geautomatiseerd zijn bij de meeste registrars. Het helpt niets tegen misbruik van de correcte auth. DNS server (tenzij er ergens een key moet worden ingeklopt door een menselijke gebruiker bij aanpassingen van DNS records).

[Eloy]

DNS injection/alteration en rogue (authoritative) DNS servers.

Oke. Maar wanneer heeft dit enig effect op de eindgebruiker? Voor alle records met een hostname maakt het niet uit, want TLS. Als het een ander protocol zonder hostname validatie zoals TLS is dan gaat DNSSEC ook niet helpen om problemen op te lossen.

Een argument wat ik heb gehoord is mailservers. Je kan DNSSEC gebruiken om MX records veilig door te geven. Maar dat is niet nodig als je MTA-STS gebruikt: https://www.hardenize.com/blog/mta-sts

[Dorank]

DNSSEC is een generiek oplossing voor het probleem van hijacking (of het nu via DNS is of een andere MitM methode).

MTA-STS is een heeeel specifieke oplossing indien:

The primary motivation of MTA-STS is to provide a mechanism for
domains to ensure transport security even when deploying DNSSEC is
undesirable or impractical.

Laten we nu gewoon DNSSEC implementeren en daarmee DANE effectief maken.

[Eloy]

Laten we nu gewoon DNSSEC implementeren en daarmee DANE effectief maken.

DANE lijkt me een slecht idee. Wanneer een CA zich nu niet aan de regels houdt, dan kan deze simpelweg worden geblacklist in browsers. Met DANE is dit 1-op-1 gekoppeld aan de bijbehorende TLD. Wat doe je in zo'n geval? DigiNotar kon simpelweg worden verwijderd, maar stel je voor dat SIDN hiervoor verantwoordelijk was in het geval van DANE. Je kan dan niet uitwijken naar een alternatief omdat SIDN een monopolie heeft op het uitgeven van certificaten voor .nl

[niqck]

Wat is het nut hiervan? Welke risico's mitigeer je?

Meerdere beveilingingsmethodes maken gebruik van DNS (CAA, TLSA etc..). Die zijn nutteloos als je niet zeker bent dat die records echt zijn. Brol verstuurd over een beveiligd kanaal blijft brol. Rogue CA's (ooit gehoord van Diginotar...) en je DoH/DoT kan ook compromised zijn.

Zeker, die regels gelden ook voor certificaten. Maar die hebben een zeer duidelijk voordeel voor de eindgebruiker. Ik vind het zelf niet kort door de bocht om te stoppen met een complex systeem als er geen duidelijke voordelen zijn.

Als ik merk hoeveel moeite ik had om 5 jaar geleden DNSSEC op te zetten in vergelijking met vandaag dan vind ik het persoonlijk niet zo'n complex systeem meer. PowerDNS bv. heeft veel van die complexiteit ivm mijn vorige oplossing (NSD + OpenDNSSEC) weggenomen.
Vroeger was het aanvragen van een certificaat ook knap lastig: CSR genereren, opsturen, geldigheid controleren... zorgen dat de complete chain geladen wordt... Vandaag met LE een pak eenvoudiger.

DNSSEC en DoH/DoT zijn 2 oplossingen voor 2 verschillende problemen. Er 1 van afvoeren omdat jij die te complex vindt is 1 van de problemen niet onderkennen.

[Eloy]

Meerdere beveilingingsmethodes maken gebruik van DNS (CAA, TLSA etc..). Die zijn nutteloos als je niet zeker bent dat die records echt zijn. Brol verstuurd over een beveiligd kanaal blijft brol. Rogue CA's (ooit gehoord van Diginotar...) en je DoH/DoT kan ook compromised zijn.

Zeker ken ik DigiNotar. Maar verdwijnt zo'n probleem met DNSSEC of DANE? Je hebt nog steeds een key op TLD niveau die second-level zones moet signen.

DNSSEC en DoH/DoT zijn 2 oplossingen voor 2 verschillende problemen. Er 1 van afvoeren omdat jij die te complex vindt is 1 van de problemen niet onderkennen.

Het is niet alleen omdat ik het te complex vind, ook omdat ik niet denk dat het wezenlijk iets toevoegt aan de beveiliging.

Een betere én simpelere beveiliging is haalbaar door DoH/DoT door te zetten richting de authoritive DNS server, daar wordt momenteel aan gewerkt bij de IETF. Op die manier kan je zelf een recursor draaien die end-to-end een veilige lookup kan doen. Daar ben ik een groot fan van.

[niqck]

Zeker ken ik DigiNotar. Maar verdwijnt zo'n probleem met DNSSEC of DANE? Je hebt nog steeds een key op TLD niveau die second-level zones moet signen.

Met DANE kan je verhinderen dat een rogue CA certificaten voor jouw domain uitgeeft. Afhankelijk van je record kan je het certificate zelf of je CA publiceren in DNS. Maar dit is nutteloos als je niet kan garanderen dat de informatie in DNS echt is. Dit doe je door deze te signeren via DNSSEC.
Je hebt nog steeds je KSK je bij je registrar moet publiceren maar dit is een exta beveiliging. Het is niet OF/OF maar EN/EN.

Het is niet alleen omdat ik het te complex vind, ook omdat ik niet denk dat het wezenlijk iets toevoegt aan de beveiliging.

Een betere én simpelere beveiliging is haalbaar door DoH/DoT door te zetten richting de authoritive DNS server, daar wordt momenteel aan gewerkt bij de IETF. Op die manier kan je zelf een recursor draaien die end-to-end een veilige lookup kan doen. Daar ben ik een groot fan van.

Jij denkt dat het niks toevoegt aan de beveiliging omdat dat ook het doel niet is. Het gaat om de zekerheid dat de record ook echt van de eigenaar is. Zoals je met GPG een mail kan signeren om 2 redenen:

• de mail is niet gewijzigd
• je hebt zekerheid dat de afzender degene is die hij beweert te zijn

Dit is dan ook het doel van DNSSEC. Je zal SMTP over TLS het kanaal beveiligen. Ook hier: 2 verschillende doelen. Enerzijds beveiligd transporteren (TLS), anderzijds de inhoud signeren.
Ga jij zeggen dat (in bepaalde gevallen) het niet nodig is om je mail te signeren want die wordt toch over TLS verstuurd?

edit: stukje overgeslagen. ik ben ook grote voorstander van E2E encryptie voor DNS-lookups maar zoals ik zei: EN/EN en niet OF/OF.

[Reactie gewijzigd door niqck op 22 juli 2024 15:30]

[Eloy]

Met DANE kan je verhinderen dat een rogue CA certificaten voor jouw domain uitgeeft. Afhankelijk van je record kan je het certificate zelf of je CA publiceren in DNS. Maar dit is nutteloos als je niet kan garanderen dat de informatie in DNS echt is. Dit doe je door deze te signeren via DNSSEC.
Je hebt nog steeds je KSK je bij je registrar moet publiceren maar dit is een exta beveiliging. Het is niet OF/OF maar EN/EN.

Oke, maar oa Chrome heeft aangegeven dat ze nooit DANE gaan ondersteunen: https://www.imperialviolet.org/2015/01/17/notdane.html

Ga jij zeggen dat (in bepaalde gevallen) het niet nodig is om je mail te signeren want die wordt toch over TLS verstuurd?

Ik ga zelfs nog verder, ik denk dat e-mail security compleet hopeloos is. MTA-STS is zeker leuk, maar GPG is bijvoorbeeld totaal onbruikbaar. Zie ook deze blog: https://latacora.micro.bl...stop-using-encrypted.html

Ik denk dat we naar een nieuw protocol moeten, zoals Matrix gecombineerd met het Signal protocol.

[Reactie gewijzigd door Eloy op 22 juli 2024 15:30]

[niqck]

Oke, maar oa Chrome heeft aangegeven dat ze nooit DANE gaan ondersteunen: https://www.imperialviolet.org/2015/01/17/notdane.html

Zeg nooit nooit. Google ondersteunde HPKP maar is daarop ook teruggekomen. Als er iets is dat websites platgelegd heeft zal het wel HPKP zijn. Een pest om te implementeren en vergeleken met DNSSEC 10x lastiger. DANE is echter maar een voorbeeld. Ik blijf voorstander van het valideren van records zodat ze weldegelijk van de rechtmatige eigenaar komen en niet gespoofed zijn.

Ik ga zelfs nog verder, ik denk dat e-mail security compleet hopeloos is. MTA-STS is zeker leuk, maar GPG is bijvoorbeeld totaal onbruikbaar. Zie ook deze blog: https://latacora.micro.bl...stop-using-encrypted.html

Ik denk dat we naar een nieuw protocol moeten, zoals Matrix gecombineerd met het Signal protocol.

Hierover ben ik het eens. E-mail is nooit met security in gedachten gebouwd en zal vrees ik nooit secure zijn. Kan het secure gemaakt worden? Ik denk van wel. Kijk naar de adaptie van HTTPS tov HTTP. Voor een groot deel te wijten aan enerzijds het goedkoper en makkelijker verkrijgen van certificaten (LE) en anderzijds de bijna verplichting van browsers om op HTTPS over te stappen. Bij SMTP zou die ook kunnen maar de urgentie is er niet. De druk om het te doen ontbreekt. De technologie is er (grotendeels) maar zolang het niet door iedereen gebruikt wordt is het waardeloos.

Er zijn al verschillende pogingen ondernomen om het te vervangen maar niemand is er tot nu toe in geslaagd. Of het waren open protocols (XMPP, Signal...) waar de adaptie traag van ging wegens meestal populairdere maar gesloten systemen (MSN, Whatsapp...). Ik vrees dat we er nog niet van verlost zijn.

Mijn punt is en blijft en heb ik al in iedere post ten treure herhaald: het volstaat niet om alles te encrypteren als je ook niet zeker bent dat de inhoud geldig is. Als jij je verbindt via DoH/DoT met een recursor, welke garantie heb jij dat die records niet gespoofed zijn? Dat de recursor je geen valse informatie geeft? Dat is het doel van DNSSEC. En tot er een andere technologie is die die garantie kan bieden zullen we het met DNSSEC moeten stellen.

[Eloy]

maar ik zou zo denken dat je gespoofde websites voorkomt.

Helaas, maar dit is simpelweg onzin. Je kan nog steeds een domein registeren en daar op plaatsten wat je wil. Zoals een kopie van de ABN AMRO site

Een "man in the middel" aanval (wat je ook spoofen zou kunnen noemen) is nooit mogelijk geweest door HTTPS. Aannemende dat je geen valse certificaten kan uitgeven of het certificaat van ABN AMRO steelt

[Reactie gewijzigd door Eloy op 22 juli 2024 15:30]

[MainframeX]

DNSSEC heeft ook een negatieve impact op de beschikbaarheid van websites. Door een misconfiguratie kan een site plat gaan.

Hoe is een implementatie fout nou ineens een probleem van DNSSEC? Volgens moet je dan gewoon bij jezelf te rade gaan hoor.

[Eloy]

> Hoe is een implementatie fout nou ineens een probleem van DNSSEC? Volgens moet je dan gewoon bij jezelf ten rade gaan hoor.

Zie ook dit lijstje: https://ianix.com/pub/dnssec-outages.html

Het is complex en complexiteit zorgt voor problemen. Als je daarmee significante problemen de wereld mee uithelpt kan het zeker de moeite waard zijn, maar dat lijkt me niet het geval met DNSSEC.

[MainframeX]

Je bedoeld dus meer dat het veel complexer is en dat een fout zo snel gemaakt is. Daar kan ik het wel mee eens zijn. De implementatie had wat mij betreft een heel stuk simpeler gekunt. Dergelijke complexiteit staat dan eigenlijk ook gelijk adoptie in de weg. In mijn ogen hadden ze er beter aan gedaan om het net zo toegankelijk te maken als bijvoorbeeld Let's Encrypt/certbot.

Edit: rare zin

[Reactie gewijzigd door MainframeX op 22 juli 2024 15:30]

[Eloy]

De implementatie had wat mij betreft een heel stuk simpeler had gekunt? Dergelijke complexiteit staat dan eigenlijk ook gelijk adoptie in de weg. In mijn ogen hadden ze er beter aan gedaan om het net zo toegankelijk te maken als bijvoorbeeld Let's Encrypt/certbot.

Ik ben groot voorstander van een simpel protocol om DNS te beveiligen. Er wordt op dit moment werk verricht om DoH uit te bereiden naar authoritive DNS servers. Dat steun ik volledig.

[CAPSLOCK2000]

Zie ook dit lijstje: https://ianix.com/pub/dnssec-outages.html

Drie storingen in 2020.
2 in vage internationale domeinen, en 1 op het domein van een bekende Security & DNS-specialist.
In dat laatste geval denk ik dat het opzet was, een test, of iets dat de controle nog niet begreep.

In 2019 waren het meer, wel 47.
Ok, soms zijn dat pittige storingen omdat veel domeinen er last van hebben, maar in praktijk worden die snel opgelost.
Vergelijk het eens met hoe vaak grote sites hun SSL verkloten of hoevaak er een belangrijke DNS-server uitligt, dat is ook niet mals.

Ten slotte heb ik een beetje mijn twijfels bij de auteur van die site. Zo staat boven aan die pagina een lijstje klachten: "DNSViz has lost a portion of its archives multiple times, turning many citations on this page into 404s. Currently, the dnssec-deployment.org mailing list archives have been down for several years, and previously for around 5 months, producing more 404s."
Maar die problemen hebben helemaal niks met DNSSEC te maken.

De definitie van grote en kleine sites slaat ook nergens op. Dominoes.com zou te klein zijn voor de lijst, maar ik zie allerlei kleine bedrijven en onbekende universiteiten in die lijst staan. Die lijkt dus nogal gekleurd te zijn.

[Eloy]

Oke, ik kan het wel eens worden over die twijfels. Maar dat er significante storingen waren blijft wel staan.

[CAPSLOCK2000]

Oke, ik kan het wel eens worden over die twijfels. Maar dat er significante storingen waren blijft wel staan.

Ja, er zijn grote storingen geweest, maar in praktijk hebben weinig mensen iets van gemerkt omdat de meeste providers het nog niet ondersteunden. Het gaat steeds beter. Dan nog werd, volgens die site, een storing typisch na zeven dagen verholpen. Ik ken een hoop problemen die veel langer duren, blijkbaar zijn er voldoende mechanismen om mensen op problemen te wijzen, zoals SIDN die op grote schaal waarschuwingen heeft verstuurd.
Ik zie dat vooral als kinderziektes, niet als showstopper. HTTPS is na kwart eeuw werken ook nog niet bepaald fout vrij. Dat is zelfs zo erg dat iedere browser een manier heeft om HTTPS fouten te negeren met een "toch doorgaan" knop.

[CAPSLOCK2000]

hebben mensen het internet weten te beveiligen met de aanname dat DNS insecure is, door middel van TLS en het CA systeem.

Nope, TLS en CA beveiligen andere aspecten van internet.
In praktijk zijn de CA's zelfs zeer afhankelijk van DNS. De controles die worden uitgevoerd om een certificaat te krijgen vertrouwen namelijk in vrijwel alle gevallen op DNS. Alleen als je een duur EV certificaat koopt wordt er meer gedaan. Bij een partij als LetsEncrypt ben je 100% afhankelijk van een betrouwbaar DNS-systeem.

Maar wat heb je hieraan? TLS zorgt ervoor dat het end-user apparaat valideert dat hij praat met de juiste host. Als een aanvaller het IP adres uit de DNS tussendoor aanpast dan wordt het verkeer inderdaad langs een andere host gestuurd, maar doordat deze malafide host niet beschikt over de juiste private key kan er nog steeds geen MITM plaatsvinden.

Als je DNS dan toch al onderschept kun je misschien ook wel een vals certificaat aanvragen.

Het idee is dat DNSSEC signatures toevoegt aan de zogenaamde "resource records" van DNS. Dit levert integriteit op, maar geen confidentialiteit. Een aanvaller kan nog steeds precies zien welke DNS requests je uitvoert.

Dat klopt. Het helpt ook niet tegen aambeien.
Het is één aspect van beveiliging, niet meer.

DNSSEC heeft ook een negatieve impact op de beschikbaarheid van websites. Door een misconfiguratie kan een site plat gaan.

Niet als iedere beveiling. Als je TLS verkeerd configureerd is je site ook niet meer beschikbaar. Als ik mijn huissleutel verlies dan kom ik niet meer binnen. Dat is het inherent aan beveiliging.

Ben ik dan een tegenstander van meer DNS beveiliging? Zeker niet, DNS over HTTPS zorgt voor meer confidentialiteit zonder negatieve impact op de beschikbaarheid.

Als confidentialiteit het enige is waar je om geeft dan heb je gelijk, maar integeriteit is ook best belangrijk.
Trouwens, is DoH echt zo veel beter voor je privacy. De meeste DoH gebruiken namelijk de DNS-servers van Google of een andere Amerikaanse organisatie. De beheerders van die servers kunnen nog steeds precies zien wat je doet. Is het echt beter voor je privacy om Google te vertrouwen dan bv XS4All ?

[Eloy]

Als je DNS dan toch al onderschept kun je misschien ook wel een vals certificaat aanvragen.

Die kan je ook weer direct revoken als je CT logs monitored.

Het is één aspect van beveiliging, niet meer.

Zeker.

maar integeriteit is ook best belangrijk.

De integriteit van de data waar een eindgebruiker zich druk over maakt zit al netjes ingepakt in TLS.

Is het echt beter voor je privacy om Google te vertrouwen dan bv XS4All?

DoH is slechts een protocol. Niks houdt XS4ALL tegen om ook een DoH server voor zijn klanten te hosten. Ik hoop ook dat providers meer DoH gaan uitrollen voor hun klanten

[CAPSLOCK2000]

Die kan je ook weer direct revoken als je CT logs monitored.

Dat kan en moet je zeker ook doen.
Ik ken er alleen niet veel die het doen. Ik doe het in beperkte mate.

De integriteit van de data waar een eindgebruiker zich druk over maakt zit al netjes ingepakt in TLS.

Yup, maar de wereld is groter dan eindgebruikers. Ik maak gebruik van data die direct uit DNS komt en voor mij is het belangrijk dat die klopt.

DoH is slechts een protocol. Niks houdt XS4ALL tegen om ook een DoH server voor zijn klanten te hosten. Ik hoop ook dat providers meer DoH gaan uitrollen voor hun klanten

Dat is helemaal waar en ik hoop met je mee dat de providers dat ook echt gaan doen. Ik heb zelfs goede hoop dat het echt gaat gebeuren.
Maar op dit moment, in praktijk, is dat niet hoe het voor de meeste mensen werkt.

[Eloy]

Yup, maar de wereld is groter dan eindgebruikers. Ik maak gebruik van data die direct uit DNS komt en voor mij is het belangrijk dat die klopt.

Wat is dit zoal voor data en waarom kan je die niet op een HTTPS endpoint hosten? Voor mensen die DNSSEC nog niet hebben gedeployed zal dat veel simpeler zijn

Maar op dit moment, in praktijk, is dat niet hoe het voor de meeste mensen werkt.

DNSSEC bestaat al sinds eind jaren 90, DoH bestaat pas sinds 2018. En DoH wordt als default gebruikt voor Amerikaanse gebruikers van Firefox. Windows heeft/krijgt een DoH compatible DNS forwarder. DoH kan uitgerold worden met een update door een beheerder van een recursor. Mozilla heeft een programma opgezet om extra DoH recursors te keuren en toe te voegen naast Cloudflare, zodat het wat meer distributed gaat worden. Ik verwacht dat dit binnen korte termijn een vlucht gaat nemen

[CAPSLOCK2000]

Wat is dit zoal voor data en waarom kan je die niet op een HTTPS endpoint hosten? Voor mensen die DNSSEC nog niet hebben gedeployed zal dat veel simpeler zijn

In de eerste plaats natuurlijk IP-adressen en hostnames maar ook SPF-records, DKIM, DMARC, TLSRPT, CAA, allerlei validatie-informatie (oa LetsEncrypt) en SSHFP.
Een deel van die informatie zou via HTTPS gedeeld kunnen worden maar dan moet je (onder andere) alle mailservers in de wereld gaan aanpassen. Er is werkende software en een grote userbase. Als je dat wil veranderen zal je al die bestaande software moeten herimplementeren. Dat kan, maar ik heb er geen zin in. Als je gaat herschrijven zorg dan welk ook voor lage response tijden, goede caching, een manier om de integriteit van de data te controleren, een universele interface om die data op te vragen en gedistribueerd beheer. Uiteraard met zo min mogelijk overhead en op een manier die backwards compatible is met 30 jaar aan infrastructuur. De meeste van die dingen zijn wel mogelijk al is backwards compatibility een drama. 10 jaar geleden was TLS1.2 nog uitzonderlijk terwijl het tegenwoordig het minimum is. Als je de snelheid van DNS wil halen zal je toch op z'n minst naar HTTP2 gaan kijken (zoals DoH ook doet). Backwards compatibility kun je dan helemaal vergeten.

Het is allemaal niet onmogelijk, maar wel enorm veel werk waar niemand iets beter van wordt.

[Onno]

Echter, doordat dit niet op tijd is gelukt hebben mensen het internet weten te beveiligen met de aanname dat DNS insecure is, door middel van TLS en het CA systeem.

En hoe valideert die CA of jij de eigenaar van je domein bent? Oh ja, met DNS...

[Eloy]

Nu komt Certificate Transparancy om de hoek kijken

CA's zijn verplicht om te publiceren welke certificaten ze uitgeven voor een bepaald domein. Hiermee kan je checken of de uitgegeven certificaten wel echt door jou zijn aangevraagd.

[Tozz]

Certificate Transparancy is niet verplicht en legt bovendien het initatief bij een domeinhouder. In andere woorden, dat zou het 'oke' maken om certificaten uit te geven voor domeinen die van een ander zijn met het idee 'de echte eigenaar klaagt wel'.

[Eloy]

Certificate Transparancy is niet verplicht

Oh ja? Kijk eens wat de grootste browsermaker ter wereld hier over te zeggen heeft: https://chromium.googleso...arency.md#Chrome-Policies

Dus als je het niet erg vind dat je site onbereikbaar is in de populairste browser ter wereld, dan is CT inderdaad niet verplicht

dat zou het 'oke' maken om certificaten uit te geven voor domeinen die van een ander zijn met het idee 'de echte eigenaar klaagt wel'.

Klopt, je moet het inderdaad zelf monitoren

[Reactie gewijzigd door Eloy op 22 juli 2024 15:30]

[Keiichi]

Hiervoor zou ook CAA gebruikt kunnen worden. Als domein eigenaar geef je aan welke CA een certificaat voor jouw domein uitgegeven mogen worden.

[rhuijben]

DNS over HTTPS is leuk voor de clients maar lost voor zover mij bekend niets aan de server/host/registrar kant op. DNSSEC heeft juist daar nog zeker een functie, en aan de client kant werkt het nu ook zonder dat de gebruiker er wat aan hoeft te doen. Mooi dat ze dit nu aan zetten... juist ook voor clients die in de layer er onder DNS over HTTS willen gebruiken.

[Eloy]

DNS over HTTPS is leuk voor de clients maar lost voor zover mij bekend niets aan de server/host/registrar kant op.

Dat klopt inderdaad, DoH is voor de verbinding tussen de recursor en de eindgebruiker.

Maar, die negatieve impact op de beschikbaarheid is nog steeds van toepassing op DNSSEC. Dit is geen theoretisch risico, zie dit lijstje: https://ianix.com/pub/dnssec-outages.html

Dan de toevoeging voor integriteit van DNSSEC. Die valt nog steeds weg doordat de eindgebruiker TLS gebruikt.

Ik zou een groot voorstander zijn om de verbinding tussen de DoH recursor en authoritieve DNS servers ook te beveiligen met HTTPS/TLS, maar dat gebeurt op dit moment nog niet.

[Reactie gewijzigd door Eloy op 22 juli 2024 15:30]

[CAPSLOCK2000]

Maar, die negatieve impact op de beschikbaarheid is nog steeds van toepassing op DNSSEC. Dit is geen theoretisch risico, zie dit lijstje: https://ianix.com/pub/dnssec-outages.html

Dat heb je met alle beveiliging. Het hele doel van beveiliging is dingen onmogelijk maken. We zouden het er over kunnen hebben of DNSSEC te gevoelig is, maar als het nooit iets stopt dan heeft het ook geen zin.

Dan de toevoeging voor integriteit van DNSSEC. Die valt nog steeds weg doordat de eindgebruiker TLS gebruikt.

Dat snap ik niet, kun je dat uitleggen? Je kan gewoon DNSSEC over TLS doen, die twee zitten elkaar niet in de weg ofzo.

Ik zou een groot voorstander zijn om de verbinding tussen de DoH recursor en authoritieve DNS servers ook te beveiligen met HTTPS/TLS, maar dat gebeurt op dit moment nog niet.

Ja, dat is hoog tijd. DTLS lijkt gelukkig een beetje van de grond te komen en dat lijkt een beter oplossing voor DNS-servers die geen hele HTTPs-engine willen opnemen.

[Eloy]

> Dat heb je met alle beveiliging. Het hele doel van beveiliging is dingen onmogelijk maken. We zouden het er over kunnen hebben of DNSSEC te gevoelig is, maar als het nooit iets stopt dan heeft het ook geen zin.

Het is waar dat het doel van beveiliging is om dingen onmogelijk te maken. Maar wat maakt DNSSEC precies onmogelijk? Als je een site bezoekt over HTTPS kan een aanvaller niks doen door DNS verkeer aan te passen.

> Dat snap ik niet, kun je dat uitleggen? Je kan gewoon DNSSEC over TLS doen, die twee zitten elkaar niet in de weg ofzo.

Klopt. Maar dan nog voegt DNSSEC praktisch niks toe terwijl het wel een nadeel heeft wbt beschikbaarheid in het geval van configuratiefouten. TLS heeft wel duidelijke voordelen wat betreft privacy en integriteit tot aan de pc van de eindgebruiker. Natuurlijk, met TLS kan je ook vergeten om je certs te vernieuwen, dit gaat inderdaad vaak fout. Maar dat is de prijs die je betaalt voor de voordelen.

[CAPSLOCK2000]

Het is waar dat het doel van beveiliging is om dingen onmogelijk te maken. Maar wat maakt DNSSEC precies onmogelijk? Als je een site bezoekt over HTTPS kan een aanvaller niks doen door DNS verkeer aan te passen.
<knip>
Klopt. Maar dan nog voegt DNSSEC praktisch niks toe terwijl het wel een nadeel heeft wbt beschikbaarheid in het geval van configuratiefouten.

In de eerste plaats maakt het het veel moeilijker om een vervalst TLS-certificaat aan te vragen.
Ten tweede zijn er nog een hoop sites die nog steeds geen HTTPS. Dat is niet goed, maar wel de realiteit.
Daarnaast zijn er nog een hoop andere protocollen waar TLS nog geen gemeengoed is en dat ook nog wel lang zo zal blijven. Denk bijvoorbeeld aan e-mail. Het is helaas heel normaal dat mailservers geen SSL/TLS gebruiken of in ieder geval niet controleren of het goed gaat.

Verder geeft DNSSEC je de mogelijkheid om DNS als "Trust Anchor" te gebruiken. Een bekend veilig beginpunt waar je andere beveiliging aan kan hangen. Het bekendste voorbeeld is misschien wel het CAA-record. Daarmee geef je aan welke CA je gebruikt voor certificaten. Andere CA's weigeren dan om certificaten uit te geven voor je domein.
Andere toepassingen van dat Trust Anchor zijn DANE (waarmee je self-signed certificaten kan gebruiken ipv ze bij een CA te moeten halen) een SSHFP (waarmee je de fingerprint van SSH-servers bekend maakt zodat je die bij de eerste verbinding al automatisch kan laten controleren).
Dit kun je niet oplossen met DoH.

Maar dan nog voegt DNSSEC praktisch niks toe terwijl het wel een nadeel heeft wbt beschikbaarheid in het geval van configuratiefouten. TLS heeft wel duidelijke voordelen wat betreft privacy en integriteit tot aan de pc van de eindgebruiker. Natuurlijk, met TLS kan je ook vergeten om je certs te vernieuwen, dit gaat inderdaad vaak fout. Maar dat is de prijs die je betaalt voor de voordelen.

Dat is een beetje meten met twee maten, als je bij TLS wel accepteert dat er een prijs aan zit maar bij DNSSEC niet.

[Eloy]

In de eerste plaats maakt het het veel moeilijker om een vervalst TLS-certificaat aan te vragen.

Dit vind ik een interessant punt. Heb je een voorbeeld van een dergelijke hack? CA's zijn lang niet altijd veilig gebleken, maar ik heb nog nooit gezien dat een rogue certificaat is uitgegeven doordat er een MITM heeft plaatsgevonden tussen de CA en de auth DNS server.

Ten tweede zijn er nog een hoop sites die nog steeds geen HTTPS. Dat is niet goed, maar wel de realiteit.

Oke, maar wat heeft DNSSEC hier mee te maken? HTTPS deployment stijgt nog steeds, dat is een goede zaak.

Daarnaast zijn er nog een hoop andere protocollen waar TLS nog geen gemeengoed is en dat ook nog wel lang zo zal blijven. Denk bijvoorbeeld aan e-mail. Het is helaas heel normaal dat mailservers geen SSL/TLS gebruiken of in ieder geval niet controleren of het goed gaat.

MTA-STS is een ding. Daarmee kunnen mailservers over HTTPS de encryptie policy van een server checken en ook onthouden voor een langere periode.

Andere toepassingen van dat Trust Anchor zijn DANE (waarmee je self-signed certificaten kan gebruiken ipv ze bij een CA te moeten halen)

DANE is problematisch, omdat je een een-op-een koppeling maakt tussen een TLD en de "CA". Stel dat een TLD zich niet aan de regels houdt omtrent certificaten, wat doe je dan? Een CA kan je nog blacklisten, maar een hele TLD?

SSHFP (waarmee je de fingerprint van SSH-servers bekend maakt zodat je die bij de eerste verbinding al automatisch kan laten controleren).
Dit kun je niet oplossen met DoH.

DoH lijkt me hier inderdaad niet de beste oplossing voor, maar DNSSEC is zeker geen vereiste om zoiets te implementeren.

Dat is een beetje meten met twee maten, als je bij TLS wel accepteert dat er een prijs aan zit maar bij DNSSEC niet.

Ik ben bereid moeite te steken in iets wat me concreet iets oplevert. Dat is me hier nog steeds niet echt duidelijk.

[CAPSLOCK2000]

Dit vind ik een interessant punt. Heb je een voorbeeld van een dergelijke hack? CA's zijn lang niet altijd veilig gebleken, maar ik heb nog nooit gezien dat een rogue certificaat is uitgegeven doordat er een MITM heeft plaatsgevonden tussen de CA en de auth DNS server.

Nee, maar dat komt omdat we momenteel vertrouwen op een andere beveiliging tegen cache poisoning, Source Port Randomization, die is alleen niet houdbaar voor de toekomst. Hoe sneller onze netwerken worden slechter die beveiliging werkt.
Lees het hele verhaal op https://duo.com/blog/the-...y-of-2008-by-dan-kaminsky

Oke, maar wat heeft DNSSEC hier mee te maken? HTTPS deployment stijgt nog steeds, dat is een goede zaak.

Zeker een goede zaak dat het stijgt, maar zolang het stijgt zijn er dus nog sites die het niet gebruiken.
Daarnaast moet je beveiliging opbouwen in lagen en niet vertrouwen op een enkel middel.
Ik ben niet tegen HTTPS ofzo, dat is ook prima en hard nodig, maar het is niet genoeg.

MTA-STS is een ding. Daarmee kunnen mailservers over HTTPS de encryptie policy van een server checken en ook onthouden voor een langere periode.

Ja, er zijn verschillende oplossing. Het nadeel van MTA-STS is dat het onze mailinfrastructuur weer afhankelijk van HTTPS, dat vind ik eigenlijk niet zo mooi. Maar het is geen probleem om allebei te doen, MTA-STS is ontworpen om niet te conflicteren met DANE/DNSSEC.

DANE is problematisch, omdat je een een-op-een koppeling maakt tussen een TLD en de "CA". Stel dat een TLD zich niet aan de regels houdt omtrent certificaten, wat doe je dan? Een CA kan je nog blacklisten, maar een hele TLD?

Wederom hoef je niet te kiezen. Je kan DANE doen met een certificaat van een CA. Je koppelt je certificaat overigens aan je eigen domein, niet aan een hele TLD. De TLD heeft geen enkele invloed op jouw DANE-records. OK, als ze het echt heel bont willen maken kan een TLD natuurlijk je hele domein registratie veranderen en iedereen naar het verkeerde IP-adres sturen en dan onderteken met een valse sleutel, maar dan hebben we groter problemen, maar dan zitten we wel op hetzelfde niveau als een CA die zich enorm misdraagt.
Daarnaast zijn er veel meer TLDs dan CA's. In praktijk zijn er maar een hand vol grote CA's en die kan je eigenlijk ook niet helemaal blokkeren. Om het lekker troebel te maken zijn een paar van de grootste TLDs, zoals .com en .net, in handen van een CA.

DoH lijkt me hier inderdaad niet de beste oplossing voor, maar DNSSEC is zeker geen vereiste om zoiets te implementeren.

Voor alles zijn alternatieven te bedenken, maar DNSSEC hebben we al.

Ik ben bereid moeite te steken in iets wat me concreet iets oplevert. Dat is me hier nog steeds niet echt duidelijk.

Beveiliging levert nooit iets concreets op anders dan veiligheid. Wat levert HTTPS nu concreet op? Wat leveren condooms nu concreet op? Beveiliging doe je om problemen te voorkomen, niet omdat het iets oplevert.

Ik vind het handig dat ik distributed database heb die ik als Trust Anchor kan gebruiken voor verschillende zaken. Ik profiteer dagelijks van SSHFPs. Ik ben blij dat ik, in sommige landen, geen last heb van de DNS-manipulatie van sommige providers.

[Dorank]

DNS over HTTP zegt niets over de correctheid van de records. De recursors die achter DoH hangen zullen DNSSEC moeten gebruiken om records te controleren.

DoH en DNSSEC hebben niets met elkaar te maken en lossen elk een ander probleem op.

[UPPERKEES]

Source? Een hoop toepassingen zijn verplaatst naar DNS als een secure source voor informatie door DNSSEC, DANE om maar een bijvoorbeeld te noemen.

[kodak]

Inmiddels een beetje te laat. DNSSEC is aardig achterhaald. DNSSEC komt uit 1997, en ik doelde op DoH als alternatief.

Het argument dat het achterhaald is door te verwijzen naar het jaar van ontwikkeling is een heel slap argument. Of iets beter is heeft te maken met of het voldoet aan de eisen, niet het moment van bedenken.

En die eisen, dat is waar het tweede argument op scheeft gaat. Dat jou eisen anders zijn dan die van een ander maakt je eisen en dus de oplossing nog niet beter.

De vraag die beter beantwoord kan worden is dus wat wel of niet acceptabel is.

[kipppertje]

Bijzondere timing, de meeste bedrijven zijn nu een beetje terughoudend met grote changes ivm thuiswerken.

[Verwijderd]

Bijzondere timing, de meeste bedrijven zijn nu een beetje terughoudend met grote changes ivm thuiswerken.

DNSSEC is niet bepaald iets nieuws; het is alleen op veel plekken nog niet actief.
De implementatie bij XS4ALL heeft bewezen dat het prima kan, en deze wijzigingen doorvoeren kan allemaal remote worden uitgevoerd; ik zie geen reden waarom deze (ongetwijfeld lang voor corona in Nederland een probleem was) geplande uitrol hierom zou moeten staken.

[kipppertje]

Oh dat het kan is het probleem niet.

Maar bij veel bedrijven zie je nu dat het management zegt "je blijft van de productie systemen af, tenzij niets doen een grotere impact heeft dan wel wat doen". Je kunt namelijk niet even je experts bij elkaar zetten om het op te lossen, dat moet allemaal op afstand en samenwerken gaat dan wat lastiger. Daarnaast zou een productieverstoring extra pijnlijk zijn nu iedereen thuis moet werken en klanten dus veel afhankelijker zijn van hun verbinding dan anders.

Ik vraag me dus af of ze DNSSEC uit laten staan als een groter risico beschouwen dan dat er een productieverstoring op zou treden.

[funxiun]

Meestal zit er een tijd tussen activeren en wereldkundig maken.
Dus het is vast niet zo dat ze vanmorgen het hebben aangezet en de woordvoerder hebben ingelicht.
Je moet ruim de tijd hebben om een evt rollback te doen.

[CAPSLOCK2000]

Bijzondere timing, de meeste bedrijven zijn nu een beetje terughoudend met grote changes ivm thuiswerken.

Het is lastig, want er zijn ook een hoop grote changes nodig om dat thuiswerken te faciliteren.
Extra lastig is dat de hele wereld weet dat veel mensen nu in een afwijkende situatie zitten en dat beveiliging meestal het eerste aspect is dat sneuvelt. Daarom vind ik het wel goed dat KPN er een schepje bovenop doet om haar gebruikers te beschermen.

Eerlijk gezegd denk ik dat deze change al maanden geleden geplanned is en dat mammoettanker KPN niet snel genoeg kan bijdraaien om echt op de actualiteit in te springen.

[Habbie]

Ze hebben deze change een paar weken geleden al gedaan, voor alle paniek.

[DeCo]

*edit

[Reactie gewijzigd door DeCo op 22 juli 2024 15:30]

[beerse]

Het activeren van dnssec heeft voor de gewone gebruikers niet zo veel impact. Je hoeft het nog steeds zelf niet te gebruiken. Maar vanaf nu kan je het dus gebruiken! (eindelijk).

Als xs4all klant had ik het al jaren in gebruik. Mijn twisted-tweaked mind zegt dat zij van kpn het moesten activeren omdat wij van xs4all anders niet bij zij van kpn op het netwerk kunnen omdat zij van kpn hebben beloofd dat alles 'als vanouds' voor xs4all gebruikers beschikbaar blijft. En ja, een beveiliging niet meer leveren is wel een heel handige stok om mee te slaan.

[Verwijderd]

Als xs4all klant had ik het al jaren in gebruik. Mijn twisted-tweaked mind zegt dat zij van kpn het moesten activeren omdat wij van xs4all anders niet bij zij van kpn op het netwerk kunnen omdat zij van kpn hebben beloofd dat alles 'als vanouds' voor xs4all gebruikers beschikbaar blijft.

Lijkt me alleen maar een gunstig argument. Als op deze manier KPN 'beter' en XS4ALL niet 'slechter' wordt dan kan ik dit alleen maar toejuichen.

[Dorank]

Als je de DNS recursors van de provider gebruikt en die valideren op basis van DNSSEC. Dan gebruik je zelf effectief DNSSEC aangezien de recursor geen resultaat op de query geeft indien het antwoord op de upstream DNS request van de recursor zelf niet voldoet aan DNSSEC. MAW je krijgt DNSSEC gefilterde resultaten.

[slaay]

Dit geldt ook voor klanten die internet hebben van bijvoorbeeld Budget, Youfone etc? Aangezien die providers gebruik maken van het KPN netwerk.

[CAPSLOCK2000]

Dit geldt ook voor klanten die internet hebben van bijvoorbeeld Budget, Youfone etc? Aangezien die providers gebruik maken van het KPN netwerk.

Nee, tenzij ze ook de DNS-servers van KPN gebruiken en dat lijkt me niet.

Volgens @slaay en @krakendmodem zit ik er naast.
Je kan het zelf controleren door de DNSSEC-resolver test te doen op https://dnssec.vs.uni-due.de/.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 15:30]

[slaay]

Zo te zien dus wel, aangezien ik gewoon een xxx.direct-adsl.nl hostname en door KPN beheerd ip-adres heb.

[krakendmodem]

Die gebruiken ze wel . Ze resellen het volledige KPN pakket.

[Reactie gewijzigd door krakendmodem op 22 juli 2024 15:30]

[Patrock]

SIDN controleert de zone en informeert actief als er validatiefouten zijn in de .nl zone.

Er zijn echter zat diensten die van subzone delegation gebruik maken dmv. NS records die voor een subzone naar een andere nameserver verwijzen. Deze zullen dan ook kapot gaan tenzij je deze keten ook gaat signen.

Denk aan nieuwsbrieftools of boekhoud-pakketten. Vaak geven deze voor het gemak aan enkel een ns record toe te voegen waarmee zij zelf dan vervolgens spf, dmarc en andere records beheren. Zonder DS records voor de signed delegation zal dit ook niet meer werken.

Benieuwd of iedereen hiervoor klaar is

[CAPSLOCK2000]

Niet iedereen, maar de grote meerderheid wel.
Ik heb het al bijna 10 jaar aan staan voor mijn gebruikers en het is jaren geleden dat ik een klacht heb gehad. Sinds Google DNSSEC gebruikt op de publieke DNS-servers worden problemen heel snel opgelost want anders kost het je veel te veel gebruikers.
Af en toe zie ik nog wel meldingen in mijn logs maar ik kan met niet herinneren wanneer de laatste gebruiker geklaagd heeft. Ik zie veel meer problemen met verlopen SSL-certificaten.

[labmuisfrl]

goeie zaak. implementatie aan de user kant ontbreekt nog vaak!

[slijkie]

Gebruik 1.1.1.1 app om op het mobiele netwerk geforceerd het te gebruiken. (ios)

T-Mobile dwingt een beetje nu DNS te gebruiken, maar met hun bewaarplicht zit ik daar niet echt op te wachten.

[Dorank]

En kan je ons even uitleggen wat de bewaardplicht is voor DNS requests? Of uberhaupt wat de bewaarplicht inhoud?

Ik heb een sterk vermoeden dat je iets roept zonder goed geinformeerd te zijn over de werkelijkheid. Maar ik kan me natuurlijk ook vergissen (en mijn interpretatie van de bewaarplicht zou natuurlijk ook foutief kunnen zijn).

[Opperpanter2]

Heb wel al de hele dag DNS problemen via KPN.

[Marctraider]

Jij kiest ervoor om op KPN's DNS servers afhankelijk te zijn?

[LocK_Out]

Man, ik gebruik dit al tijden via alternatieve DNS servers. Maar oké, handig en meer veiligheid voor de standaard gebruiker inderdaad.