Advertorial

Door Tweakers Partners

Hoe dnssec de .nl-zone steeds veiliger maakt

25-08-2020 • 12:00

21

Het ondertekenen van dns-gegevens met een cryptografische key maakt websites minder kwetsbaar voor ‘man in the middle’-aanvallen. Toch maken veel domeinen geen gebruik van dnssec. SIDN, beheerder van de .nl-zone, wil hier verandering in brengen en doet er veel aan om de technologie zo aantrekkelijk mogelijk te maken.

Het domain name system (dns) is sinds jaar en dag het ‘telefoonboek’ van het internet. Elke keer wanneer je in je browser een domeinnaam invoert vertaalt het dns dit naar ip-adressen, via een hiërarchisch systeem van authorative dns-servers. Het dns is echter ook kwetsbaar voor ‘man in the middle’-aanvallen waarbij aanvallers dns-gegevens manipuleren, bijvoorbeeld om gebruikers naar een valse website te sturen. Al in de jaren negentig is daarom door verschillende partijen gestart met de ontwikkeling van dnssec, een cryptografische beveiliging voor het dns-protocol.

Bij gebruik van dnssec vindt validatie van adresinformatie plaats op meerdere niveaus, aan de hand van publieke en private beveiligingssleutels. Stel, je wil www.jebank.nl bezoeken. Om het juiste ip-adres voor je op te halen volgt een serie veiligheidschecks die begint bij een dns-resolver. Deze valideert vanaf rootniveau de keys van de onderliggende domeinen. Voor de .nl-zone gebeurt dit bij SIDN omdat hier de dns-keys voor de .nl-domeinen zijn ondergebracht. Deze (ns- en ds-)records worden vervolgens ook gematcht met de informatie die staat op de server die verantwoordelijk is voor www.jebank.nl. Zo ontstaat een keten van vertrouwen die het internet een stuk veiliger zou moeten maken. Op sidn.nl is een meer gedetailleerde beschrijving te vinden van de werking van dnssec.

Grote Nederlandse isp’s lieten de technologie lang links liggen

Dnssec is een volwassen technologie. Al in 2010 werd voor het rootdomein van dns de eerste beveiligingssleutel gesigneerd. Je zou zeggen dat domeineigenaren de technologie inmiddels overal hebben omarmd, maar niets is minder waar. Een groot deel van de domeinen maakt er geen gebruik van. Daar is een logische reden voor, zegt Niek Willems, dns system engineer bij SIDN. “De beveiligingsvoordelen van dnssec zijn er vooral voor de eindgebruikers. Voor organisaties die hun domeinen voorzien van een signature brengt het een bepaalde beheerlast met zich mee, en ook risico’s. Want als er iets verkeerd gaat bij het inrichten, wordt je domein onzichtbaar voor de wereld.” Daarnaast is er sprake van een kip-ei-situatie. “Als eindgebruiker maak je gebruik van de resolving nameserver van je provider of soms de organisatie waarvoor je werkt. Een aantal grote providers in Nederland had lang de dnssec-validatie niet aan staan. KPN ondersteunt het sinds medio maart 2020, maar VodafoneZiggo heeft het nog niet beschikbaar voor klanten. Hoewel die laatste partij positief tegenover de technologie staat en al jaren aangeeft bezig te zijn met de implementatie ervan, is het nog steeds niet duidelijk wanneer hij precies beschikbaar komt voor klanten. Het gevolg voor nu is dat veel domeinbeheerders op hun beurt de moeite (nog) niet nemen om dnssec voor hun domein in te stellen. Dit betreft ook mailservers en beschermende maatregelen tegen spam en fraude zoals spm, dmarc en dkim, die in dns zitten. Al deze technieken zijn kwetsbaar voor man-in-the-middle-aanvallen, en de eindgebruiker heeft baat bij dnssec-signing.”

Dit laatste schuurt bij SIDN, dat er veel aan gelegen is om de status van het .nl-domein als een van de allerveiligste domeinen ter wereld te behouden. Door actief dnssec te promoten, maar bijvoorbeeld ook korting te geven aan registrars die hun domeinen bij SIDN registreren, is inmiddels iets meer dan de helft van alle zes miljoen .nl-domeinnamen dnssec-signed. Dit is zelfs meer dan het aantal gesigneerde domeinen van .com, zij het met de kanttekening dat SIDN er al aanmerkelijk langer mee bezig is. Wereldwijde statistieken voor verschillende domeinen zijn te vinden via stats.dnssec-tools.org. Wil je weten of domain signatures ook voor jou gevalideerd zijn, dan kun je dit controleren op www.internet.nl, waar je verschillende handige tests uit kunt voeren, waaronder een connectiontest. Je ziet dan snel of dnssec ‘aan staat’ en jij daardoor beschermd bent tegen routing naar valse ip-adressen.

Klaar voor sterkere sleutels

Iets wat we overigens zeker niet moeten vergeten, is dat ook services onderling gebruikmaken van dns en daarom baat hebben bij de beveiliging, voegt Stefan Ubbink, net als zijn collega Willems dns system engineer bij SIDN, toe. “Als jouw effectenhandel-app een api heeft met een bank of beurs, dan wil je waarschijnlijk gebruikmaken van je eigen validerende resolver en niet afhankelijk zijn van een tussenliggende provider. Dnssec werkt dan gewoon honderd procent.” Om dnssec voor de .nl-zone mogelijk te maken komt er wel het nodige kijken, zoals een specifieke hardware signing module (hsm) voor het maken van de cryptografische hashes en signatures. De .nl-zone bevat al met al zo’n tien miljoen rrsig-records, die in sommige gevallen binnen vijftien minuten moeten worden gemaakt (rrsig is het type dns-record waar een signature in staat). Deze rrsig/signatures verlopen na een tijdje, maar gelukkig niet allemaal tegelijk. Daar zorgt de signing-software die de hsm aanstuurt voor, aan de hand van een uitgekiende policy die SIDN heeft opgesteld. De hsm bevat veiligheidsvoorzieningen waarmee je voorkomt dat wie dan ook sleutels van je dns-records kan manipuleren. De modules van SIDN signeren op dit moment hoofdzakelijk met het rsa-mechanisme. “Om de wapenwedloop naar steeds sterkere algoritmen bij te houden, willen we deze op termijn vervangen door nieuwe systemen die beter geschikt zijn voor de opvolger van rsa, elliptic curve. Het voordeel van ec is dat je er per seconde meer signatures mee kunt uitvoeren. Omdat de keys per bit meer security leveren, kun je namelijk met kleinere keys werken.”

Hoe werkt de toepassing van dnssec voor beheerders die een nieuw domein willen registreren? Dit begint op sidn.nl, waar de beheerder controleert of de gewenste domeinnaam nog vrij is. Is dit niet het geval, dan helpt een suggestietool op sidn.nl bij het zoeken naar een alternatieve naam. Een voorbeeld kan zijn dat bouwbedrijfjansen.nl al vergeven is, waar dit wellicht nog niet het geval is voor aannemersbedrijfjansen.nl. De tool doet daarnaast ook voorstellen op het gebied van beveiliging. Willems: “Wil je als beheerder gebruik gaan maken van dnssec, dan krijg je een lijst van registrars die dit kunnen leveren. Vaak zijn dat hostingbedrijven, maar het kunnen ook andere entiteiten zijn.” Een hostingbedrijf draagt zorg voor de dns-gegevens en het genereren van de keys, meldt het domein aan bij SIDN en levert daar ook een publieke key aan. De nameservers staan ook bij de hostingpartij, tenzij je helemaal zelf je dns wil doen op eigen nameservers, maar dan moet je wel zelf het keymateriaal aanleveren bij je registrar en ben je zelf verantwoordelijk voor het correct functioneren van de nameservers van je domein.

Let op keymanagement

Op het moment dat SIDN beschikt over het publieke deel van de sleutel (het ds-record), het domein en de bijbehorende nameservers zijn aangemeld, worden deze gegevens in het domeinregistratiesysteem (drs) gezet. De meeste organisaties zullen ervoor kiezen hun keys regelmatig te wijzigen. Dit gebeurt echter niet in de parentzone (in dit geval de .nl-zone). Deze bevat een key signing key (ksk) die alleen dient om nieuwe keys (zone signing keys) te signeren. Door het uitfaseren van oude keys kan het daardoor gebeuren dat je als gebruiker met verschillende keys tegelijk signeert. “Keymanagement is dus een belangrijk issue. Dat kan voor domeinbeheerders een reden zijn om dnssec niet met een eigen nameserver te gebruiken omdat het dan te complex wordt. Bij hostingbedrijven is dit overigens nooit een probleem. Zij hebben dit proces geautomatiseerd.”

SIDN beschikt over een aantal systemen die een .nl-zone genereren. Hier begint in feite de ‘signeerstraat’. Een aantal servers in de signeerstraat kijken in de database welke domeinen er zijn, welke nameservers daarbij horen en welke ds-records, en bouwen vervolgens met deze gegevens de zone op. Deze systemen genereren grote files (ongeveer 3GB) met dns-gegevens met gesignde records. Om denial of service-aanvallen op domeinen te voorkomen is er nsec (next secure record), een mechanisme in dnssec dat ook negatieve antwoorden kan ondertekenen en verifiëren (authenticated denial of existence). Met de meest recente versie hiervan, nsec3, gaat het linken naar de volgende record in de zone met een checksum in plaats van de naam van het volgende record. Hiermee voorkom je zone walking waarbij mensen de inhoud van de totale .nl-zone in kaart proberen te brengen. Willems legt uit: “Het gaat hier om het voorkomen van het door een man-in-the-middle aanreiken van ‘dit domein bestaat niet’-antwoorden. Daardoor kan een eindgebruiker dat domein niet meer gebruiken. Als dnssec voor een domein aanstaat en de eindgebruiker maakt gebruik van een validerende resolver, dan zal de man-in-the-middle een gesigneerd ‘dit domein bestaat niet’-antwoord moeten geven, en dat kan hij niet.”

Steeds betere .nl-zone

Als alle signatures zijn opgezet, vinden verificatiestappen plaats. “Dit is in feite een file met alle dns-gegevens voor de nl-zone erin”, zegt Ubbink. “Hij wordt doorgegeven aan een publicerende nameserver die gelinkt is aan distribuerende nameservers en de ruim dertig anycastservers voor deze zone.” Omdat het telkens signen van zo’n grote zone werk is voor specialistische software, kiest SIDN ervoor te werken met OpenDnssec, waarvoor het samenwerkt met NLnet Labs. Deze opensource-software stuurt individuele records naar de hsm en verzorgt het sleutelmanagement. Verbeteringen aan deze software vinden doorlopend plaats. Willems: “We kijken met name naar het verbeteren van het key-beheer, extra tests en het stroomlijnen van de signeerstraat met nieuwe, sterkere algoritmen. Daar willen we steeds slimmer mee kunnen omgaan. En zo blijven we werken aan het steeds verder beveiligen en verbeteren van de .nl-zone, die nu al een van de allerveiligste ter wereld is. ”

Webinar SIDN: Internet of Things

Meer weten over internet security? Op donderdag 3 september organiseert SIDN van 15.00 uur tot 16.00 uur het interactieve webinar ‘Internet of Things: kansen, keerzijden en oplossingsrichtingen’. Hierin bespreken experts de context van de iot-problemen en bediscussiëren ze de verschillende mogelijke oplossingen. Lijkt dit je interessant? Lees meer en meld je gratis aan.

Dit artikel is geen redactioneel artikel, maar een advertorial in samenwerking met SIDN. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (21)

21
20
16
7
1
2
Wijzig sortering
Ik vraag me eigenlijk af hoe belangrijk het hele DNSSEC verhaal nog is. Het gros van het web gaat inmiddels over HTTPS en met de komst van DNS over HTTPS is een DNS mitm ook geen issue meer toch? In het artikel wordt "www.jebank.nl" als voorbeeld gebruikt, maar dat is toch geen issue als HTTPS dat al oplost?

Ik ben me ervan bewust dat er meer protocollen zijn naast HTTP, maar ook daar is er vaak TLS oid beschikbaar :-)

[Reactie gewijzigd door Jay-v op 24 juli 2024 00:02]

Ik vraag me eigenlijk af hoe belangrijk het hele DNSSEC verhaal nog is. Het gros van het web gaat inmiddels over HTTPS en met de komst van DNS over HTTPS is een DNS mitm ook geen issue meer toch? In het artikel wordt "www.jebank.nl" als voorbeeld gebruikt, maar dat is toch geen issue als HTTPS dat al oplost?
Hoe lost HTTPS dat op? Als DNS eenvoudig te manipuleren is dan is het tegenwoordig eenvoudig om een "vals" SSL-certificaat te verkrijgen via LetsEncrypt.

Een aspect dat HTTPS in ieder geval niet oplost is het vertrouwen dat je moet hebben in de beheerder van je DNS-resolver. Als Google je DNS-resolver is, dan is Google in staat om de resultaten te manipuleren en je valse informatie doorsturen. Nu kun je er waarschijnlijk wel op vertrouwen dat Google dat niet echt doet, maar het blijft een kwestie van vertrouwen.
Met DNSSEC kun je bewijzen dat er niet gemanipuleerd is en hoef je niet te vertrouwen.

Bewijzen is altijd beter dan vertrouwen.

Een ander punt is dat je resolver zelf eerst aan die informatie zal moeten komen voor deze kan worden doorgegeven aan de gebruiker. HTTPS verplaatst het vertrouwens- & manipulatie-probleem maar lost het niet op.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 00:02]

Als DNS eenvoudig te manipuleren is
In de praktijk is het echter compleet niet triviaal om een DNS antwoord te manipuleren. Daarvoor zul je toch moeten kunnen MitM'en of een complete BGP hijack moeten uitvoeren. Beide zijn lastig, zeker nu bijvoorbeeld LetsEncrypt Multi-Perspective Validation heeft.
Als Google je DNS-resolver is, dan is Google in staat om de resultaten te manipuleren en je valse informatie doorsturen.
Maar dat probleem bestaat met DNSSEC nog steeds, omdat DNSSEC over het algemeen niet gebruikt wordt tussen jouw resolver en je eigen PC.

Niemand heeft mij nog duidelijk kunnen maken wat de echte toegevoegde waarde van DNSSEC is.
Daarvoor zul je toch moeten kunnen MitM'en of een complete BGP hijack moeten uitvoeren. Beide zijn lastig, zeker nu bijvoorbeeld LetsEncrypt Multi-Perspective Validation heeft.
Waarom denk je dat dat moeilijk is?
De beveiliging op BGP is flinterdun en het gaan ook regelmatig flink fout.
Een beetje geheime dienst of profesionele aanvaller draait daar z'n hand niet voorom.
Dat LE investeert in MPV is juist omdat ze zich zorgen maken over BGP hijacks.

Je kan zeggen dat het probleem daar mee is opgelost, maar dat is te veel alleen op LE gericht. Ik kijk liever naar algemene oplossingen en oplossingen die elkaar overlappen en aanvullen.
Voor de duidelijkheid: ik heb niks tegen MPV, dat is óók een goed middel en een waardevolle aanvulling.
Maar dat probleem bestaat met DNSSEC nog steeds, omdat DNSSEC over het algemeen niet gebruikt wordt tussen jouw resolver en je eigen PC.
Dan doe je het verkeerd. Moderne OS'en hebben om die reden steeds vaker een volwardige dns-resolver aan boord. Er zijn zelfs applicaties die resolven om die redenen zelf doen. (wat ik overigens geen goed model vind, maar dat is vooral een tussenoplossing).
Niemand heeft mij nog duidelijk kunnen maken wat de echte toegevoegde waarde van DNSSEC is.
DNS beschermen tegen manipulatie. Als je niet gelooft dat het mogelijk is of het niet belangrijk vind, ja dan heeft DNSSEC geen waarde, maar dat kun je over ieder beveiliging zeggen. Als je niet in de dreiging gelooft dan heeft bescherming inderdaad geen zin.
Het punt is niet dat ik niet geloof dat DNS gemanipuleerd kan worden. Het punt is vooral dat als je dat kunt doen en daarmee een SSL-certificaat kunt bemachtigen, je ook 1.) een SSL certificaat kon bemachtigen door je slachtoffer te hijacken of MitM'en, wat in veelvoorkomende gevallen makkelijker is dan de DNS server van je slachtoffer 2.) je, in het geval van overheden, waarschijnlijk ook wel op andere manieren aan een geldig SSL certificaat had kunnen komen.

Zolang er geen wijdverspreide DANE support is, zie ik gewoon niet waarom DNS veilig geacht moet worden. De grootste flaw op dit vlak is dat CA's ervan uit gaan dat DNS wel veilig zou zijn, en dat ze dat ook doen voor HTTP of email. Alle resources die in DNSSEC gestopt worden zouden wat dat betreft beter naar het fixen van de CA's kunnen gaan, want ook met een veilige DNS blijft dat probleem bestaan (of je nou poort 53 of 80/25 moet intercepten maakt het verschil ook niet).

Zodra er wel fatsoenlijke DANE support is, is het een ander verhaal. Maar ik zie bijzonder weinig beweging op dat vlak (er is wat beweging bij email, maar ook dat gaat veel te traag).

Al met al geloof ik best dat er een toegevoegde waarde kán zijn voor DNSSEC, maar dat ik met de huidige stand van zaken en voortgang op andere vlakken de toegevoegde waarde gewoon niet zie. Het kan best zijn dat ik iets in m'n threat-model mis, enlighten me. Maar het komt op mij al jaren over als een paradepaardje van de registrars (waarvan dit artikel een goed voorbeeld is), terwijl het op zichzelf geen probleem oplost.

Dan laat ik de discussie of de verantwoordelijkheden bij gebruik met DANE bij de registrars moeten liggen er nog even buiten, want dat is voor CA's in veel gevallen net zo goed te zeggen.
Dan doe je het verkeerd. Moderne OS'en hebben om die reden steeds vaker een volwardige dns-resolver aan boord.
Heb je voorbeelden? Ik zie wat dingen over DoH langskomen hier en daar, maar daarvan is het mij eigenlijk onduidelijk of die implementaties ook daadwerkelijk de gehele chain valideren. En zodra je dat niet doet heeft Google (of wie dan ook) nog steeds alle sleutels in handen.

[Reactie gewijzigd door MikeN op 24 juli 2024 00:02]

Zolang er geen wijdverspreide DANE support is, zie ik gewoon niet waarom DNS veilig geacht moet worden. De grootste flaw op dit vlak is dat CA's ervan uit gaan dat DNS wel veilig zou zijn, en dat ze dat ook doen voor HTTP of email. Alle resources die in DNSSEC gestopt worden zouden wat dat betreft beter naar het fixen van de CA's kunnen gaan, want ook met een veilige DNS blijft dat probleem bestaan (of je nou poort 53 of 80/25 moet intercepten maakt het verschil ook niet).
Hi,

Nogal toevallig las ik laatst een in dit kader zeer relevante presentatie van Daniel J Bernstein, auteur van DNSCrypt Qmail, etc, en tegenwoordig (ook) professor te Eindhoven (TUE).

Zijn presentatie (let wel, >100 pag, uit 2017) maakt idd duidelijk dat de structuur en opzet van DNSSec nog te wensen overlaat.
DNSSec biedt in de huidige opzet volgens Bernstein (zo begrijp ik althans) uiteindelijk geen bescherming tegen MitM attacks, het biedt geen end-to-end encrypted requests tussen clients en DNS-servers (zoals bij HTTPS wel het geval is) en biedt ook geen sluitende authenticatie.

DNSSec kan volgens Bernstein zelfs tot DDOS aanvallen leiden.
En ziedaar vandaag het bericht op Tweakers over problemen vanuit een Chromium functie die dns-hijacking tracht te voorkómen . En voor zware belasting root-servers zorgt.

Toeval bestaat.

*tekstcorrectie

[Reactie gewijzigd door bart.koppers op 24 juli 2024 00:02]

Zijn presentatie (let wel, >100 pag, uit 2017) maakt idd duidelijk dat de structuur en opzet van DNSSec nog te wensen overlaat.
Ik heb nu geen tijd om er op in te gaan maar DJB heeft in dat artikel fouten gemaakt, hij heeft het geschreven zonder DNSSEC echt te begrijpen en daardoor verkeerde aannames gemaakt. Zo had hij oa niet door dat DNSSEC geen vaste crypto heeft maar dat die configureerbaar is. Hij maakt een paar goede punten, maar probeerde in die tijd z'n eigen alternatief te lanceren wat hem misschien een beetje heeft verblind.
Hij maakt nog steeds goede punten waardoor die presenatie het bestuderen waard is maar wees voorzichtig met conclusies.
Ik ben me ervan bewust dat er meer protocollen zijn naast HTTP, maar ook daar is er vaak TLS oid beschikbaar :-)
HTTPS is juist TLS. :P
Het is HTTP over TLS.
Snap ik, ik bedoel andere protocollen naast mijn HTTP voorbeeld zoals IMAP die ook TLS ondersteunen
DNS over HTTPS is voor een massa beheerders, gebruikers, bedrijven een no go zone, om uiteenlopende redenen.

DNS over HTTPS zorgt er alleen voor dat de informatie die van de DoH server van b.v. cloudflare, ongewijzigd tot bij jou geraakt. Uiteindelijk moet cloudflare de informatie ook ergens vandaan halen, en doet dat door de DNS info van de respectievelijke NS servers, die de DNS info van het specifieke domain bevatten, te raadplegen. Als op die NS server wat mis is, krijg jij via cloudflare de foute info over een HTTPS verbinding doorgespeeld.
DNSSEC beveiligt de authenticiteit van de DNS records op de NS server zelf (waar de DNS records in eerste instantie worden aangemaakt.

DNSSEC: veilig van de NS server tot bij de gebruiker.
DoH: veilig van bij de provider (b.v. cloudflare) tot bij de gebruiker.

Ik twijfel er niet aan dat cloudflare de DNSSEC info, die van de NS server wordt aangeleverd, verifieerd en geen info aan de client doorgeeft als er wat mis is. Dat impliceerd nog steeds dat de DNSSEC info wel beschikbaar moet zijn.

Als jezelf wil testen of je DNSSEC ready bent, run een test, hier of hier.

Zelf draai ik lokaal pihole + unbound, unbound valideert de DNSSEC info, foute DNSSEC info -> geen antwoord naar de client.
Als je geen locale (recursieve) DNS server hebt, kan je DNSSEC info valideren op je client, door een plugin in je browser te instaleren, die je dan attent maakt op een DNSSEC problem. Er is een veelheid van plugins beschikbaar voor verschillende browsers.
Het enige wat ik kan verzinnen is als een soort backup voor als/wanneer HTTPS ook niet meer veilig genoeg is.
Het is amper belangrijk. Maar dat is met vrijwel alle security maatregelen zo. Samen vormen ze dan een belangrijk geheel.

Stel dat een gehackte CA (is gebeurt) bv. een certificaat uitgeeft voor Gmail.com (is ook gebeurt!) dan is DNSSEC weer handig, want dat voorkomt dan DNS spoofing (gebeurt in Iran).
TLS is toch vooral een web dingetje. Bij e-mail, vooral SMTP zie je vaak self-signed certificates, of helemaal geen TLS, en veel servers controleren daar dus niet op.

Daarnaast zijn er natuurlijk nog talloze andere protocollen die het niet zo nauw nemen met SSL. Een hoop VoIP clients bijvoorbeeld controleren helemaal niet waar ze het wachtwoord naartoe sturen.

Nu is DNSSEC daar niet per se de aangewezen oplossing voor, maar het is vrij eenvoudige toevoeging die een hoop gaten minder gevaarlijk maakt.
Ongeveer twee jaar geleden heb ik over DNSSEC een vraag gesteld aan de minister van Digitale Agende (België , toen Alexander De Croo). Uiteraard antwoordt hij niet zelf (denkt waarschijnlijk dat DNSSEC een of andere ziekte is). Na verloop van tijd kreeg ik volgend antwoord van de Directeur Beleidscel Digitale agenda:

quote
De veiligheid van onze websites is een belangrijk aandachtspunt. DNSSEC biedt echtheidsgaranties voor de geraadpleegde sites en kan een verbetering betekenen voor de veilgheid van onze overheidswebsites.

Om de websites van de Federale Overheid te beschermen, hebben we op dit ogenblik een aanpak die gebaseerd is op het tot stand brengen van veilige verbindingen zonder evenwel DNSSCEC te gebruiken. DNSSEC als protocol is gebaseerd enerzijds op een asymmetrisch sleutelbeheer waarvan het onderhoud niet eenvoudig is] (beveiliging en vernieuwing) en anderzijds op vaardigheidsniveaus van belanghebbenden in de vertrouwensketen die vrij uiteenlopend kunnen zijn. DNSSEC impliceert ook een toename van de grootte van de pakketten die over de netwerken gaan. De complexiteit van het implementeren van het proces is relatief hoog en kan de kans op problemen of fouten vergroten, vooral bij het configuratiebeheer en bij het levenscyclusbeheer van de gebruikte sleutels.
/quote

Omdat de beheerders dus onvoldoende DNSSEC kennis hebben, word het dus niet gebruikt.

[Reactie gewijzigd door jpgview op 24 juli 2024 00:02]

Eerlijk gezegd moet ik bekennen dat ik onder de indruk ben omdat je een echt inhoudelijk antwoord hebt gekregen dat nog redelijk goed beargumenteerd is ook, ook al is het niet het antwoord dat ik zou willen.

Tegelijkertijd is het ook wel een pijnlijk erkennen van incompetentie.
Het klopt dat het beheren van DNSSEC sleutels extra complexiteit en afhankelijkheden met zich mee brengt. Tegelijkertijd is het ook weer niet super complex. De meeste aspecten van DNSSEC zijn prima te automatiseren en te monitoren. Een beetje IT-afdeling doet dingen die veel ingewikkelder zijn.

Als je het beheer van DNSSEC te ingewikkeld vind zeg je in mijn oren dat je geen echte controle hebt over je systemen en dat de organisatie nog niet erg volwassen is en vertrouwt op handwerk en geluk in plaats van automatisering en redundantie.

Het wrange is natuurlijk dat dit helemaal klopt. De meeste (IT-)organisaties zijn heel amateuristisch en ongestructureerd. Dat heeft natuurlijk ook iets met de opdrachtgevers en gebruikers te maken. Die zijn niet bezig met veiligheid en organisatie, die willen alleen dat hun applicatie/feature snel wordt geinstalleerd.
Gelukkig begint er wel verandering in te komen, ook al wordt dat gedreven door de AVG en ransomwareaanvallen. Langzaam begint de zakelijke kant te begrijpen dat IT-beveiliging belangrijk is en niet altijd het sluitstuk kan zijn.
Ik deel die mening niet. SSL certificaten zijn als je het mij vraagt ook een pain in the ass.

Tuurlijk, op een LAMP servertje werkt het allemaal prachtig. Lets Encrypt Certbot of eventueel wat API-calls naar Sectigo en dat gaat als een tierelier. Zo beheren wij honderden zo niet duizenden certificaten.

Maar certificaten op loadbalancers, Cisco ASAs, Juniper appliances.. Het is 1 grote nachtmerrie. Die dingen zijn al vaak obsolete voordat je ze koopt, ze moeten rommel vaak in specifieke formaten hebben, het is slecht te automatiseren, etc, etc.

DNSSEC is niet anders. Voor DNSSEC moet je sleutelmateriaal naar de registry uploaden. Bijvoorbeeld bij .NL naar de SIDN. Dat impliceert dat er logingegevens van de SIDN bij de partij bekend moet zijn die DNSSEC beheert.

Kijk naar rivm.nl. Domein is geregistreerd bij SURFnet, ook een aan de overheid gelieerde partij. Dan zou de IT beheerder van RIVM een mail moeten sturen naar SURFnet met 'Hey wil je deze keys toevoegen?', want RIVM krijgt echt de EPP gegevens van SURFnet niet.

DNSSEC toevoegen is heel simpel binnen een kleine onderneming met een eenvoudige setup. DNSSEC toevoegen bij een overheid of een multinational is een absoluut drama. Er is fragmentatie van registrars, fragmentatie van DNS software, er zijn veel subdomeinen met eigen nameservers, er is onderscheid tussen de afdeling die DNS beheer doet en de afdeling die domeinbeheer doet, etc, etc. Mag je dan van een administratieve afdeling 'domein beheer' verwachten dat ze weten hoe ze op de juiste manier DNSSEC sleutelmateriaal moeten invoeren? En mag je van een administratieve afdeling verwachten dat die ook tijdens een probleem diep in de nacht met DNSSEC beschikbaar zijn om keymateriaal te wijzigen?

Binnen zo'n organisatie vergt het nogal wat om DNSSEC te implementeren.

Dit allemaal heeft 0,0 te maken met IT maar allemaal met organisatorische uitdagingen.
Het heeft naar mijn mening zeker te maken met IT. Zoiets wil je ook automatiseren, net als Let's Encrypt.

Om op je voorbeeld van SURFnet verder te gaan, waarom zou RIVM de EPP gegevens van SURFnet nodig hebben? Daar zijn toch juist API's voor, die je juist gebruikt om zo'n zaken te automatiseren. Ik heb zelf geen ervaring met SURFnet, maar de provider waar ik bij zit (Openprovider) heeft gewoon een API waarmee je zo'n beetje alles kan wat ook via de web interface kan, waaronder DNSSEC beheren (https://doc.openprovider.eu/API_Module_Domain_modifyDomainRequest).

Dat het niet altijd eenvoudig zal zijn met een uitgebreide (sub)domein structuur geloof ik direct. Maar door het zoveel mogelijk te automatiseren voorkom je dat afdelingen die hier niets van weten ermee bezig moeten zijn, en voorkom je zoveel mogelijk fouten.
Ik deel die mening niet. SSL certificaten zijn als je het mij vraagt ook een pain in the ass.
Welke stuk van de mening?
Ik ben het met je eens dat SSL ook een hoop gedoe oplevert.
Maar certificaten op loadbalancers, Cisco ASAs, Juniper appliances.. Het is 1 grote nachtmerrie. Die dingen zijn al vaak obsolete voordat je ze koopt, ze moeten rommel vaak in specifieke formaten hebben, het is slecht te automatiseren, etc, etc.
Helemaal mee eens, daarom wil ik dat soort dozen ook niet in mijn netwerk. Het is overigens niet zo dat die dozen per definitie kansloos zijn, het is meer dat ze zo behandelt worden. Het beeld bestaat dat je een doos koopt en dan een beheerder kan afschaffen, terwijl je in praktijk juist een extra beheerder zou moeten hebben om die doos te beheren.
Hoe je zo'n kist beheerd, bv via een api of scripts, zou een grote rol moeten spelen bij het aanschaffen en configureren.
Kijk naar rivm.nl. Domein is geregistreerd bij SURFnet, ook een aan de overheid gelieerde partij. Dan zou de IT beheerder van RIVM een mail moeten sturen naar SURFnet met 'Hey wil je deze keys toevoegen?', want RIVM krijgt echt de EPP gegevens van SURFnet niet.
Nee, RIVM moet contact opnemen met SURFnet en via die route de aanpassing laten doen. Als het goed is heeft SURFnet daar een interface voor.
DNSSEC toevoegen is heel simpel binnen een kleine onderneming met een eenvoudige setup. DNSSEC toevoegen bij een overheid of een multinational is een absoluut drama. Er is fragmentatie van registrars, fragmentatie van DNS software, er zijn veel subdomeinen met eigen nameservers, er is onderscheid tussen de afdeling die DNS beheer doet en de afdeling die domeinbeheer doet, etc, etc. Mag je dan van een administratieve afdeling 'domein beheer' verwachten dat ze weten hoe ze op de juiste manier DNSSEC sleutelmateriaal moeten invoeren?
Je moet techniek natuurlijk niet bij een administratieve afdeling onderbrengen.

Ik heb 10 jaar lang DNSSEC beheerd voor een organisatie die honderden domeinen heeft verdeeld over verschillende registrars, beheerd door verschillende afdelingen en op verschillende DNS-resolvers. Ik heb een vrij aardig beeld van wat er bij komt kijken.
Je zal er werk en tijd in moeten steken, maar ja, dat heb je wel vaker met werk ;)
Als je dat doet dan is het prima te automatiseren en beheren.

Ik zal niet ontkennen dat het voor veel IT'ers te moeilijk is, maar het is helaas de realiteit dat de meeste IT'ers nogal nauw gevormd zijn en weinig begrijpen buiten hun eigen vakgebied. Vandaar dat ik begon over het erkennen van incompetentie.

Als je de techiek goed hebt opgzet kun je daarna overwegen om het door een administratieve afdeling te laten beheren. Het invoeren van DNSSEC sleutels zouden ze nooit met de hand moeten doen. Ik weet overigens best dat het in praktijk soms nog nodig is omdat sommige hosters en TLD's het nog niet geautomatisseerd hebben, maar dat zou een tijdelijke situatie moeten zijn. Dat soort partijen kun je beter vermijden want die zullen wel meer niet op orde hebben.
Maar goed, als die afdeling toch sleutels moet gaan invoeren dan hoeft dat ook geen probleem te zijn. Als het rekeningnummer en wachtwoord goed kunnen invoeren moet zo'n sleutel ook wel lukken.
En mag je van een administratieve afdeling verwachten dat die ook tijdens een probleem diep in de nacht met DNSSEC beschikbaar zijn om keymateriaal te wijzigen?
Er is geen enkele IT-uitdaging die zou moeten betekenen dat een adminstratieve afdeling diep in de nacht bezig is. Dan heb je het niet goed geautomatiseerd.
Dit allemaal heeft 0,0 te maken met IT maar allemaal met organisatorische uitdagingen.
Zodra die organisatorische uitdagingen invloed hebben op IT zie ik ze als deel van IT.
De rest van de organisatie informeren en adviseren hoort ook bij het werk van IT.
Dit betreft ook mailservers en beschermende maatregelen tegen spam en fraude zoals spm, dmarc en dkim, die in dns zitten.
Ik denk dat er SPF bedoeld wordt ipv SPM?
Een nuttige aanvulling kan hier de website van het Forum Standaardisatie zijn. Daar is het volgende te lezen:
"DNSSEC moet worden toegepast op alle overheidsdomeinnamen én op DNS-resolvers die clients van overheidsorganisaties direct of indirect van DNS-antwoorden voorzien." https://www.forumstandaardisatie.nl/open-standaarden/dnssec
De Nederlandse overheid is dus beter bezig dan de Belgische op dit moment.

Op dit item kan niet meer gereageerd worden.