Xs4all neemt dnssec in gebruik

Xs4all heeft aangekondigd vanaf maandag gebruik te maken van dnssec. Daarmee wil de provider zijn klanten beschermen tegen omleiding naar namaakwebsites. Momenteel ondersteunt bijna de helft van alle .nl-domeinen deze uitbreiding van het dns-protocol.

Volgens Xs4all zijn gebruikers beschermd zolang ze een website bezoeken die gebruikmaakt van een domein met dnssec. Op dit moment ondersteunt 45 procent van alle .nl-domeinen dnssec, maar de provider verwacht dat dit percentage zal stijgen. In 2014 ondersteunde een derde van de .nl-domeinen de beveiligingsmaatregel. Dnssec moet bijvoorbeeld voorkomen dat kwaadwillenden een internetgebruiker kunnen doorsturen naar een namaaksite via dns spoofing en daar vervolgens gegevens kunnen stelen door phishing.

Dnssec moet dit voorkomen door een digitale handtekening toe te voegen aan het antwoord dat een gebruiker ontvangt van een name server, die domeinnamen omzet in ip-adressen. Aan de hand daarvan is te controleren of de gebruiker inderdaad naar de juiste site wordt verwezen. Xs4all wijst erop dat dit bijvoorbeeld veel winst kan opleveren bij de websites van banken, omdat die een gewild doelwit van internetcriminelen zijn. De provider voegt daaraan toe dat banken momenteel vaak nog geen ondersteuning bieden voor dnssec.

De SIDN activeerde de beveiligingsmaatregel in 2012 voor .nl-domeinen. Destijds schreef Tweakers een achtergrond over dns. Dnssec staat eveneens op de 'pas-toe-of-leg-uitlijst' van open standaarden die overheidsorganisaties moeten toepassen. Eind 2017 moeten Nederlandse gemeenten de beveiliging toepassen op hun mailservers, zo liet minister Plasterk deze zomer weten.

Reacties (80)

[CAPSLOCK2000]

Stoomcursus DNSSEC debuggen.

DNSSEC is prachtig, mooi en geweldig maar heeft ook grote nadelen. Een van die nadelen is dat het nog onbekend is en dat DNSSEC-fouten typisch intern worden afgehandeld. Van buiten kun je niet zien wat er intern gebeurd, dat wil zeggen dat je applicatie geen duidelijk foutmelding krijgt als er iets mis gaat.
Dat is geen fundamenteel probleem, met een paar API's is dat weer op te lossen, maar meer een consequentie van de keuze om het systeem backwardscompatible te houden. Als het goed gaat dan werkt het maar als het niet goed gaat dan weet je legacy-applicatie niet waarom het mis gaat.

Het debuggen van DNSSEC-problemen kan daarom erg lastig zijn als je nog nooit van DNSSEC hebt gehoord, je weet dan domweg niet waar je moet kijken en je applicatie zal het ook niet vertellen. Je weet niet eens dát je moet kijken. In het beste geval heb je door dat DNS niet werkt maar kom je er niet achter waarom niet.

Daarom nu een stoomcursus DNSSEC-debuggen: www.dnsviz.net
Als alles groen is, dan is het goed.
Als er iets rood is dan heb je een DNSSEC-probleem.
Als er iets geel is dan moet je een expert zoeken

Zelfs als je niet begrijpt wat er precies op deze site staat dan is ie nog nuttig. Je krijgt namelijk een plaatje te zien van je DNS met in vet rood aangegeven waar het probleem zit. Ook al snap je niet wat er staat, je weet in ieder geval waar je het moet zoeken.

Het meest voorkomende probleem is dat er een mismatch onstaat tussen de sleutels die een DNS-server gebruikt om je domein te ondertekenen en de sleutels die zijn doorgegeven aan de parent. Dit gaat vaak fout bij verhuizingen. Partij X heeft DNSSEC ingeschakeld en dan wordt het domein verhuisd naar partij Y. Partij Y doet nog niet aan DNSSEC en laat de sleutels van Partij X in DNS staan zonder ook maar te beseffen dat er een probleem is.

De andere manier waarop dit fout gaat is dat iemand vol enthousiasme begint met DNSSEC te configureren maar halverwege afgeleid raakt en de klus niet afmaakt. Bij DNSSEC moet je namelijk regelmatig een nieuwe digitale handtekening zetten om te bewijzen dat de informatie nog actueel is. Dat was in het oude DNS-systeem niet nodig, dat was veel meer fire & forget.

De derde storing die ik veel zie is dat de gebruikte DNSKEYs vervangen worden maar dat men vergeet om het door te geven aan de parent. In .nl staat dan bijvoorbeeld no dat sleutel 1234 wordt gebruikt maar het domein in kwestie is al overgeschakeld op sleutel 5678.


Overigens valt het totaal aantal storingen de laatste tijd enorm mee. Sinds een paar grote partijen actief contact zoekt met organisaties die hun DNSSEC hebben verprutst is het aantal fouten enorm teruggelopen. Het begint nu ook door te dringen in de monitoringsystemen en de hoofden van de admins en helpdeskmedewerkers waardoor problemen steeds sneller worden gevonden en verholpen.
Toch is de kans nog altijd groot dat een willekeurige ITer die je spreekt over DNS-problemen nog nooit van DNSSEC heeft gehoord. Check bij twijfel altijd even met dnsviz.net, dan weet je snel waar je aan toe bent.

Bijkomend voordeel van die site is dat een groot rood kruis een heel sterk argument is. Als ik contact opneem om een DNSSEC-storing te melden weet de helpdesk vaak niet waar ik het over heb en denken dat ik onzin loop te verkopen. Een website laten zien met een groot rood kruis bij hun domeinnaam werkt vrij overtuigend, opeens geloven ze dan dat het probleem bij hun ligt in plaats van bij mij, ook al snappen ze totaal niet wat er nu eigenlijk op die website staat.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:09]

[CAPSLOCK2000]

DNSSEC is echt een Nederlands succesverhaal. Wereldwijd is het gebruik nog vrij beperkt maar in Nederland gaat het echt keihard. Dat hebben we grotendeels te danken aan een slimme marketingactie van SIDN in combinatie met hard werk van de Nederlandse DNS-community.

Bij het invoeren van dit soort nieuwe technieken is het vaak moeilijk om genoeg "kritieke massa" te krijgen om het succesvol te maken. Net zoals je niks hebt om de enige met een telefoon te zijn, het is pas nuttig als andere mensen er ook eentje hebben.

In Nederland ondersteunt bijna de helft van de domeinen het, dat zou genoeg moeten zijn om te zeggen dat we het kritieke punt voorbij zijn. Nu hebben we de andere kant van het verhaal nog nodig: de resolvers. Google runt de populairste DNS-servers ter wereld en die ondersteunen het al een paar jaar en dekken daar ruim 10% van de wereldwijde markt mee. Als een paar Nederlandse ISPs ook DNSSEC gaan ondersteunen dan is die kritieke massa voor resolvers ook binnen harndbereik.

[totaalgeenhard]

Omdat ze van nepotisme-SIDN korting hebben gekregen op hun portfolio.

De rest van de wereld weet dat meerwaarde van DNSSEC nihil is omdat er vele andere parameters zijn die je niet hiermee kunt afdekken en daarmee een valse gevoel van veiligheid geven.

Voor alle duidelijkheid keten van DNSSEC

Client pc --> DNS CACHE --> DNS RESOLVER --> ISP NAMESERVER --> SIDN NAMESERVER --> WEBHOSTER NAMESERVER en weer terug....

Op elke stap zijn hacks mogelijk die ook daadwerkelijk hebben plaatsgevonden.

Bovendien als 1 element in het keten niet meer werkt of je een applicatie gebruikt die niet je DNS-cache/DNS resolver gebruikt van je OS, kun je al in de problemen zitten.

Het is een oplossing voor een probleem dat nooit bestaan heeft.

Verder als je in iemand zijn "IP stream" kunt komen, heb je een heel ander probleem..... en dan zullen specialisten zeggen maar daar heb je SSL (HTTPS) voor, klopt, maar hoe weet je dat resolver niet al reeds gefaked is...


IP is nooit bedoeld voor veiligheid en privacy, eerste gebruikers vertrouwden elkaar en hadden de beste intenties.

ps: naast korting van SIDN op portfolio is er ook een ander reden, je kunt een .NL met DNSSEC niet zomaar verhuizen naar je concurrent registrar. Als je dat niet op juiste manier doet is je site offline. En je oude webhoster zal de schuld aan de nieuwe geven.....

[Reactie gewijzigd door totaalgeenhard op 26 juli 2024 09:09]

[CAPSLOCK2000]

De rest van de wereld weet dat meerwaarde van DNSSEC nihil is omdat er vele andere parameters zijn die je niet hiermee kunt afdekken en daarmee een valse gevoel van veiligheid geven.

Noem eens een beveiligingstechniek die 100% zekerheid en veiligheid geeft? Die bestaan niet! Zo kun je alles wel "een vals gevoel van veiligheid" noemen. Beveiliging bestaat altijd uit meerde lagen en maatregelen die elkaar aanvullen en afdekken. Als je op zoek gaat naar de zilveren kogel die al je problemen in één keer oplost dan zul je nooit het antwoord vinden.

Client pc --> DNS CACHE --> DNS RESOLVER --> ISP NAMESERVER --> SIDN NAMESERVER --> WEBHOSTER NAMESERVER en weer terug....

Je beeld van hoe DNS werkt klopt niet. Die keten zit niet zo in elkaar. Je gooit twee processen door elkaar.
Ten eerste de CACHE, die heb ik nog nooit als zelfstandige dienst gezien. Die zit altijd of op je PC of op de resolver (of allebei). Daarnaast zijn er maar weinig mensen die zelf een resolver draaien en ook de resovler van hun ISP gebruiken, maar goed, dat kan.

Ten tweede worden DNS-verzoeken niet in serie doorgegeven maar parallel.
Je resolver gaat eerst naar de root, dan naar de TLD en uiteindelijk naar de dns-server van de hoster. Er wordt niks doorgegeven, dat zijn losse en onafhankelijke aanroepen.

Overigens is er aan dit deel helemaal niks veranderd ten opzichte van het oude DNS-systeem. Ik snap dus niet wat je probeert te zeggen.

Op elke stap zijn hacks mogelijk die ook daadwerkelijk hebben plaatsgevonden.

DNSSEC is een oplossing voor een deel van die problemen. Niet voor alle problemen maar dat hoeft ook niet, zolang het maar een deel van de problemen wel goed oplost. Welke alternatieve oplossing stel je voor?

Bovendien als 1 element in het keten niet meer werkt of je een applicatie gebruikt die niet je DNS-cache/DNS resolver gebruikt van je OS, kun je al in de problemen zitten.

Dat van die keten klopt niet. Nouja, als een schakel helemaal uitvalt dan werkt DNS niet meer maar dat was toch al zo. Je hebt wel een punt dat je geen fallback naar onbeveiligde DNS moet toestaan maar de meeste resolvers die ik ken doen dat ook niet. Als je DNSSEC aan zet dan accepteren ze geen antwoorden meer zonder de juiste handtekeningen.

Het is een oplossing voor een probleem dat nooit bestaan heeft.

Dan Kamynski?

Hierboven schreef je nog "Op elke stap zijn hacks mogelijk die ook daadwerkelijk hebben plaatsgevonden". Daarmee had je gelijk, er zijn daadwerkelijk allerlij aanvallen op DNS gedaan. De meest bekende, en de aanval die DNSSEC voor het voetlicht bracht, is het probleem dat Dan Kaminsky beschreef: The Great DNS Vulnerability of 2008 by Dan Kaminsky

Verder als je in iemand zijn "IP stream" kunt komen, heb je een heel ander probleem..... en dan zullen specialisten zeggen maar daar heb je SSL (HTTPS) voor, klopt, maar hoe weet je dat resolver niet al reeds gefaked is...

Door je resolver lokaal te draaien of de verbinding met je resolver op een andere manier te beveiligen. Mogelijkheden genoeg, dat probleem is jaren geleden al opgelost.
Sterker nog, als DNS niet betrouwbaar is kun je ook niet echt vertrouwen op HTTPS/SSL om je veilig te houden.

IP is nooit bedoeld voor veiligheid en privacy, eerste gebruikers vertrouwden elkaar en hadden de beste intenties.

De wereld verandert en dus moeten we onze techniek aanpassen aan de nieuwe wensen en eisen.

ps: naast korting van SIDN op portfolio is er ook een ander reden, je kunt een .NL met DNSSEC niet zomaar verhuizen naar je concurrent registrar. Als je dat niet op juiste manier doet is je site offline. En je oude webhoster zal de schuld aan de nieuwe geven.....

Dat was ooit zo en ik denk dat het inderdaad een rol heeft gespeeld bij bepaalde partijen die hier een mooie manier in zagen om het de concurrentie lastig te maken. Helaas voor hen heeft SIDN daar een stokje voor gestoken. Tegenwoordig moet je aangeven of je DNSSEC ondersteunt of niet. Bij een verhuizing wordt DNSSEC automatisch uitgeschakeld als de ontvangende partij het nog niet ondersteunt.
Ik ga er van uit dat deze maatregel tijdelijk is en vroeg of laat verwacht wordt dat alle registrars met DNSSEC om kunnen gaan. SIDN heeft ook al een mooi protocol helpen ontwerpen om verhuizingen van de ene partij met DNSSEC naar de andere partij met DNSSEC veilig te kunnen uitvoeren.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:09]

[totaalgeenhard]

Noem een OS die standaard DNSSEC ondersteund en noem een browser die zonder plugin standaard je laat zien dat keten DNSSEC gevalideerd is.

Je kunt iets onzinnig invoeren, maar het zal niets toevoegen.


Met betrekking keten, er zijn verschillende trojans waarmee je alleen al je HOSTS file kunt aanpassen, maar je kunt ook gewoon echter resolver "backdooren".

Vrijwel alle ISP's en webhosters in Nederland zijn weleens geroot. En ja ook SIDN (maar ook DNS.BE) zijn weleens geowned, op een level dat je zonefiles response kon aanpassen.


Ik wist niet dat SIDN key weggegooid zodra je domeinnaam gaat verhuizen. Maar gezien dns-propagatie zal het je nog steeds tijd kosten.

[Dorank]

Noem een OS die standaard DNSSEC ondersteund

Alles wat standaard met een default bind (post 2014) config.

noem een browser die zonder plugin standaard je laat zien dat keten DNSSEC gevalideerd is.

Doet niet terzake, immers indien de dnsresolvers aan DNSSEC doen krijg je geen response naar de client indien de keten niet voldoet. Het enige wat die plug je vertelt is waarom je geen response kregen hebt.

[totaalgeenhard]

Client OS.


Je krijgt wel response hoor. Alleen kan je standaard niet valideren of het DNSSEC keten met succes doorlopen heeft. Vandaar de plugin.

Maar goed, ben maar sinds 1999 met IPsec en DNSSEC bezig geweest, dus ik zal het waarschijnlijk nooit begrepen hebben.

[Reactie gewijzigd door totaalgeenhard op 26 juli 2024 09:09]

[Dorank]

Client OS.

Wat is een client OS?

Je krijgt wel response hoor. Alleen kan je standaard niet valideren of het DNSSEC keten met succes doorlopen heeft. Vandaar de plugin.

Maar goed, ben maar sinds 1999 met IPsec en DNSSEC bezig geweest, dus ik zal het waarschijnlijk nooit begrepen hebben.

Ik geloof er niets van. Maar goed ik zal je mijn resultaten "tonen" met een known to be bad test record:
bind9 met dnssec-validation auto;

# host -t A -v badsign-a.test.dnssec-tools.org 127.0.0.1
Trying "badsign-a.test.dnssec-tools.org"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host badsign-a.test.dnssec-tools.org not found: 2(SERVFAIL)
Received 49 bytes from 127.0.0.1#53 in 2821 ms

bind9 zonder dnssec validtion:

# host -t A -v badsign-a.test.dnssec-tools.org 127.0.0.1
Trying "badsign-a.test.dnssec-tools.org"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39583
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN A

;; ANSWER SECTION:
badsign-a.test.dnssec-tools.org. 86397 IN A 64.90.35.104

;; AUTHORITY SECTION:
test.dnssec-tools.org. 86397 IN NS dns1.test.dnssec-tools.org.
test.dnssec-tools.org. 86397 IN NS dns2.test.dnssec-tools.org.

;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. 86397 IN A 168.150.236.43
dns2.test.dnssec-tools.org. 86397 IN A 75.101.48.145

Received 135 bytes from 127.0.0.1#53 in 0 ms

[totaalgeenhard]

Windows
IOS
Android

to name a few....

Maar goed, blijf vooral geloven dat het goed zit.

[Dorank]

Ik maak me niet druk over OSen die ik niet gebruik.

Jammer dat je niet ingaat op het ontbreken van een response bij DNSSEC fouten

[totaalgeenhard]

Je hebt hooguit Ossen die DNSSEC-ware zijn.

En aangezien Windows/Android/IOS/OSX zo een beetje 99% van de gebruikte client OSsen zijn.... is voor 99% zonder zelf technische maatregelen te (moeten) nemen, DNSSEC een leuke sprookje.

Wij trokken in 1999 al een conclusie over DNSSEC en die conclusie houd gewoon stand, het komt door mensen die gewoon geen kennis en ervaring van security hebben dat dit doorgevoerd is.

Als je weleens bij een ICANN meeting bent geweest, zul je zelf wel merken dat politiek gehalte vele malen hoger is dan technisch gehalte.
Niet dat er geen techneuten rondlopen, ben er de grootste namen uit Internet land wereldwijd tegen het lijf gelopen.

Vergeet ook niet dat in een wereld waarbij hele keten DNSSEC is je mogelijkheid tot ontkenning ook nihil is, zeker gezien het feit dat D66 rechters afgaan op wat hun verteld zal worden over onfeilbaarheid van het structureel insecurity van DNSSEC.

Met betrekking tot response bij DNSSEC fouten, Windows 7, windows 8 en Windows 10 zijn slechts DNSSEC AWARE, validatie vind geen plaatst, dus lekker relevant. En zonder plugin in je browser zal je daar nooit achter komen.....

Hoeveel mensen ken jij met een plugin of een app op zijn OSX/iPhone, android die naar DNSSEC validaties kijken? Niemand? Ik ook niet, heb het voor de lol.

[CAPSLOCK2000]

Je hebt hooguit Ossen die DNSSEC-ware zijn.

En aangezien Windows/Android/IOS/OSX zo een beetje 99% van de gebruikte client OSsen zijn.... is voor 99% zonder zelf technische maatregelen te (moeten) nemen, DNSSEC een leuke sprookje.

Wat niet is kan nog komen he. DNSSEC werkt top down, je moet bij de root van DNS beginnen en de applicaties komen pas als allerlaatste aan de beurt. De uitrol naar de root is voltooid, de uitrol naar de meeste TLDs is voltooid, en nu wordt het op domeinniveau uitgerold. Nu begint het eindelijk een beetje interessant te worden voor eindgebruikers, dusver was het een spelletje van serversbheerders onderling. Nouja, "interessant", gebruikers zijn er sowieso niet in geinteresseerd en dat hoeft ook niet. Het protocol is gemaakt om op de achtergrond te werken zonder vervelende "wilt u deze onveilige site toch bezoeken?" popups.

Goede ondersteuning op OS en applicatie niveau moet inderdaad nog komen. Het is misschien een beetje makkelijk om daar aan voorbij te gaan, maar het is ook geen fundamenteel bezwaar tegen protocol zelf.

Wij trokken in 1999 al een conclusie over DNSSEC en die conclusie houd gewoon stand, het komt door mensen die gewoon geen kennis en ervaring van security hebben dat dit doorgevoerd is.

Helaas heb ik nog geen beter voorstel gehoord. DNSSEC is geen mooi protocol, dat zal niemand beweren, maar het is ook geen makkelijk probleem. Alle alternatieven die ik heb gezien offeren belangrijke kenmerken van DNS op,

[Dorank]

Het is een oplossing voor een probleem dat nooit bestaan heeft.

Problemen als dns cache poisoning hebben nooit bestaan? De naam Kamynski is reeds gevallen, erg interessant om te lezen wat er allemaal mis kan gaan.

Maar al zou je gelijk hebben (wat je niet hebt), dan is DNSSEC de basis voor andere toekomstige oplossingen. Hoe komen we van die achterlijke SSL CA meuk af: DANE.
Hoe kunnen we nu eens eindelijk MTAs veilig met elkaar laten communiceren, wederom DANE. Uitwisseling van GPG sleutels, ssh fingerprints of enige andere te verifieeren informatie kan allemaal betrouwbaar met DNSSEC, mits de client weet dat een bepaalde domainnaam een DNSSEC sleutel heeft. MAW draai je eigen resolver.

[totaalgeenhard]

Het lost dat probleem niet op. Nogmaals als je in iemand zijn IP stream kunt komen heb je een veel groter probleem en DNS cache injectie kun je gewoon ook op de client zelf doen, bij diens ISP of waar dan ook in de keten. En aangezien mensen blind vertrouwen op DNSSEC, komen ze er doodleuk niet achter...

[Dorank]

Om de cache te poisonen moet je wel kunnen voldoen aan DNSSEC. Zie bv de unbound docu over cache poisoning:

A cache poisoning attack allows unauthorized third parties to inject data into a DNS cache, the injected data may cause rerouting of traffic.

There is no definite solution to the form of cache poisoning described to us by Kaminsky. Only DNSSEC will provide the measures to detect malicious data and prevent cache poisoning.

However in absence of DNSSEC being sufficiently deployed to benefit, methods exist to increase resilience against cache poisoning attacks, and Unbound has these implemented by design.

[totaalgeenhard]

Je praat over NAMESERVER SIDE CACHE.....
Dat probleem los je er ook niet mee op aangezien je gewoon zonefiles kunt aanpassen. Of door nameservers voor betreffende domein te pakken, of nameservers aan te passen (of bij registry of via registrar).

Wat denk je aan client side cache die veel gevoeliger is, bovendien maken criminelen gebruik van domeinen die lijken op origineel en zijn daar heel succesvol mee.

DNSSEC werd verkocht als oplossing voor FQDN vervalsingen, maar zoals aangegeven werkt het juist averechts, omdat mensen valse gevoel van veiligheid hebben en niet eens weten dat vrijwel geen enkele client OS op dit moment schoon volledige DNSSEC ondersteund.

[Dorank]

Je praat over NAMESERVER SIDE CACHE.....

Ik praat over resolvers.

Dat probleem los je er ook niet mee op aangezien je gewoon zonefiles kunt aanpassen. Of door nameservers voor betreffende domein te pakken, of nameservers aan te passen (of bij registry of via registrar).

Ik heb een sterk idee dat je geen idee hebt hoe DNSSEC werkt. De hele keten van een DNSSEC enabled TLD is signed. Als je weet dat een TLD DNSSEC ondersteund moet je altijd de sigs kunnen checken. Kan je die niet checken is er iets mis. Als je locaal een DNSSEC validating resolver draait heb je ook geldige publieke sleutel voor de ROOTs om de keten te kunnen controleren.

Wat denk je aan client side cache die veel gevoeliger is, bovendien maken criminelen gebruik van domeinen die lijken op origineel en zijn daar heel succesvol mee.

Wat heeft dat met DNSSEC te maken? Typo squatting kan voorzien zijn van DNSSEC.

DNSSEC werd verkocht als oplossing voor FQDN vervalsingen, maar zoals aangegeven werkt het juist averechts, omdat mensen valse gevoel van veiligheid hebben en niet eens weten dat vrijwel geen enkele client OS op dit moment schoon volledige DNSSEC ondersteund.

De gemiddelde "client OS" gebruiker heeft daar geen weet van en interesseert het totaal niets. Blijft dat DNSSEC een oplossing is voor een probleem wat al decennia bestaat en de weg vrijmaakt voor andere oplossingen. Ik blijf dan ook bij mijn advies, wil je zeker zijn van je DNS responses, draai een eigen recursor met DNSSEC validatie.

[totaalgeenhard]

Lees eens goed wat ik geschreven heb.

Dan zal je deze schema zien.

Client OS resolver cache -> client resolver -> ISP nameserver cache -> ISP nameserver resolver -> SIDN cache -> SIDN resolver -> Webhoster cache -> webhoster resolver en weer helemaal terug.

Genoeg zwakke plekken, waarbij je ook met DNSSEC niet kunt weten of:

1!) je cache op je eigen client (windows/linux/osx/android) wel juist is
2!) je niet weet wat je resolver doet en bij wie hij het opvraagt
3) je niet weet of cache van je ISP goed is
4) je niet weet of resolver van je ISP gehacked is
5!) Je niet weet of SIDN naar juiste nameservers staat te wijzen (of via hack bij registrar nameservers zijn omgezet voor FQDN)
6!) Je niet weet of zonefile bij webhoster niet aangepast zijn


Bij elke punt waar ! achterstaat zal ook ingeval van DNSSEC je validatie gewoon correct zijn en TECHNISCH gezien je gewoon bij de website uitkomen waar je uit zou moeten komen...... ongeacht of het van rechtmatige eigenaar is of dat het een IP is van een aanvaller.....

Dus nogmaals, wat lost het op?
Als ze in je IP stream (dus van locale resolver t/m webhoster nameserver) zitten heb je een veel groter probleem en dan is dit je minste waar je je druk over gaat maken.

Typosquatting is een aanvalsvector dat met succes is ingezet en toont ook aan dat DNSSEC zinloos is. Zeker bij langere FQDN waarin één andere letter niet opvalt... of doodleuk TLD legitiem lijkt.

Maar goed, je wilt het niet inzien, omdat je er of niet over nagedacht hebt of geen affiniteit met het onderwerp hebt.

[CAPSLOCK2000]

Client OS resolver cache -> client resolver -> ISP nameserver cache -> ISP nameserver resolver -> SIDN cache -> SIDN resolver -> Webhoster cache -> webhoster resolver en weer helemaal terug.

Zo werkt DNS niet. Er is bijvoorbeeld geen SIDN cache of resolver.

Genoeg zwakke plekken, waarbij je ook met DNSSEC niet kunt weten of:

1!) je cache op je eigen client (windows/linux/osx/android) wel juist is

Als je het geheugen van je eigen computer niet kan vertrouwen dan houdt alles op, dan moet je zo'n apparaat niet gebruiken

2!) je niet weet wat je resolver doet en bij wie hij het opvraagt
3) je niet weet of cache van je ISP goed is
4) je niet weet of resolver van je ISP gehacked is

Dat weet je allemaal wel, het hele doel van DNSSEC is nu juist dat je dit soort informatie kan controleren. Je moet het dan ook zo dicht mogelijk bij de applicatie doen en bij voorkeur niet op resolver van je provider.

5!) Je niet weet of SIDN naar juiste nameservers staat te wijzen (of via hack bij registrar nameservers zijn omgezet voor FQDN)
6!) Je niet weet of zonefile bij webhoster niet aangepast zijn

Als iemand toegang heeft tot de zonefile is het inderdaad voorbij, daar beschermt DNSSEC niet tegen. Een slot op je voordeur beschermt ook niet tegen een openstaand raam.
De zonefile bij de webhost zou je overigens behoorlijk goed kunnen beveiligen met een HSM. De meeste websites zullen dat overdreven vinden maar als je echt wil kun je het zo maken dat je die file niet kan veranderen zonder fysieke toegang tot een beveiligde (niet aan internet gekoppelde) omgeving.

Bij het beveiligen van zonefiles heb je als verdediger wel het grote voordeel dat die zones altijd via publieke servers worden aangeboden. Je kan ze dus ook eenvoudig monitoren. Iemand zou wel bij SIDN kunnen inbreken en mijn sleutels veranderen maar dan slaat mijn Nagios binnen 10 minuten alarm. Ik kan zo'n hack niet voorkomen maar de aanvaller kan zijn werk ook niet meer geheim houden.

Als ze in je IP stream (dus van locale resolver t/m webhoster nameserver) zitten heb je een veel groter probleem en dan is dit je minste waar je je druk over gaat maken.

Dat is geen excuus om dan maar niks te doen. Om te beveiligen tegen dat soort aanvallen moet je ergens beginnen met iets dat je wel kan vertrouwen. DNSSEC biedt nieuwe mogelijkheden die we hiervoor niet hadden. Het is geen tovermiddel dat al je problemen oplost, het is een hulpmiddel dat nodig is om andere problemen op te lossen. Alleen DNSSEC doen is vrij zinloos, maar je hele netwerk beveiligen en DNS overslaan is ook niet goed.

Typosquatting is een aanvalsvector dat met succes is ingezet en toont ook aan dat DNSSEC zinloos is. Zeker bij langere FQDN waarin één andere letter niet opvalt... of doodleuk TLD legitiem lijkt.

DNSSEC helpt ook niet tegen een stijve nek.

Maar goed, je wilt het niet inzien, omdat je er of niet over nagedacht hebt of geen affiniteit met het onderwerp hebt.

Wie de schoen past trekke hem aan. Waar staat de resolver en de cache van SIDN?

[totaalgeenhard]

Dus keys komen niet van root nameservers van SIDN vandaan (ingeval ccTLD .NL ?).

Ik denk dat het verder zinloos is om met je te hierover van gedachten te wisselen.

[_JGC_]

Ik zie nog 1 probleem bij dnssec: de verbinding tussen client en resolver. Als je het verkeer naar 8.8.8.8 omleidt naar je eigen server staat dnssec op losse schroeven.

[johnkeates]

Wat je bedoelt is dat je DNSSEC kan 'uitzetten', een beetje als SSLStrip voor HTPS. Dat zou in theorie inderdaad kunnen, maar als iets eerst DNSSEC had, en daarna opeens niet meer weet je sowieso al dat er iets niet klopt.

[CAPSLOCK2000]

Wat je bedoelt is dat je DNSSEC kan 'uitzetten', een beetje als SSLStrip voor HTPS. Dat zou in theorie inderdaad kunnen, maar als iets eerst DNSSEC had, en daarna opeens niet meer weet je sowieso al dat er iets niet klopt.

Beter nog, het DNSSEC-systeem is daar tegen beveiligd. Het detecteren van gestript materiaal zit ingebouwd en het werkt altijd, niet alleen als je computer al weet dat een domein vroeger wel DNSSEC heeft gebruikt (zoals TOFU-systemen als HSTS doen).

Kort gezegd bevat iedere "laag" van DNS (., .nl, voorbeeld.nl, www.voorbeeld.nl) informatie over de volgende laag. In de root-zone (.) staat dat .nl gebruik maakt van DNSSEC. In .nl staat weer dat voorbeeld.nl gebruik maakt van DNSSEC. De zone voorbeeld.nl bevat dan weer bewijs dat www.voorbeeld.nl gebruik maakt van DNSSEC (óf juist bewijs dat er géén gebruik wordt gemaakt van DNSSEC, dat kan ook).
Je kan een deel van die informatie wel tegenhouden maar de computer heeft dat onmiddelijk door en kan dan proberen om de juiste informatie via een andere route te verkrijgen. In het slechtste geval werkt DNS helemaal niet maar je krijgt in ieder geval nooit vervalste of beschadigde informatie door.

[johnkeates]

Het idee is natuurlijk om een lokale rewriting DNS server te gebruiken waarbij je alle signatures gewoon dropt. Het is net alsof de DNS server dan geen DNSSEC ondersteunt. Ik heb dat (volgens mij met Unbound en een simpel stukje python) gedemonstreerd bij een college over te weinig weten van wat er buiten je scope plaatsvindt. Dat ging vooral over de generatie 'app' developers die eigenlijk niet weten waar ze mee bezig zijn en bijvoorbeeld self-signed certs zonder pinning accepteren om dat ze niet beter weten.

[CAPSLOCK2000]

Het idee is natuurlijk om een lokale rewriting DNS server te gebruiken waarbij je alle signatures gewoon dropt. Het is net alsof de DNS server dan geen DNSSEC ondersteunt. Ik heb dat (volgens mij met Unbound en een simpel stukje python) gedemonstreerd bij een college over te weinig weten van wat er buiten je scope plaatsvindt. Dat ging vooral over de generatie 'app' developers die eigenlijk niet weten waar ze mee bezig zijn en bijvoorbeeld self-signed certs zonder pinning accepteren om dat ze niet beter weten.

Mijn resolver (ook Unbound) weet dat de root voorzien is van DNSSEC en weet welke handtekening daar aan hoort te hangen. Als er antwoorden van de (vervalste) root komen die niet zijn ondertekend dan worden die gewoon compleet genegeerd. Er zijn wel resolvers te vinden die een fallback doen naar DNS zonder DNSSEC maar dat zijn er niet veel, ik ken alleen dnssec-trigger en dat is nu juist in het speciaal ontworpen om op een goede manier met die situatie om te gaan.

Een normaal ingerichte DNS-resolver met DNSSEC is zo niet te bedriegen. Ze kunnen je wel afsnijden van de buitenwereld door nooit de goede informatie door te laten maar ze kunnen me niet verleiden om vervalste informatie te accepteren.

[johnkeates]

Uiteraard, maar het gaat hier om een aanval, niet een goed geconfigureerde situatie ;-) En wat dacht je van de resolvers, proxies en caches die je in DSL en kabel modems hebt, vaak dnsmasq uit het jaar 0 Je kan trouwens ook een root, tld enz. doorlaten, maar een losse zone gewoon filteren zodat je intern een lookup doet en alleen gefabriceerde NS en A records teruggeeft.

[Reactie gewijzigd door johnkeates op 26 juli 2024 09:09]

[CAPSLOCK2000]

Ik denk dat de beste oplossing is om je resolver lokaal te draaien. Als dat niet gaat kun je naar tsig of ipsec kijken om de communicatie met je resolver te beveiligen. Als je het echt wil kun je DNS zelfs via HTTPS tunnelen

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:09]

[Dorank]

Offtopic: maar de beste oplossing die ik gevonden heb voor penetratie van (pay|fire)walls is een tunnel over DNS, kan ik daar vervolgens weer DNS over tunnelen op een veilige manier

[lenwar]

Hier haakt DNSCrypt dan ook op in. https://dnscrypt.org/ OpenDNS ondersteunt dit standaard.

OpenDNS heeft ook DNSCurve ontwikkeld. Dit kan je zien als een tegenhanger van DNSSEC, alleen ben je niet afhankelijk van een derde partij, en gedoe met certificaten, en heeft ook minder transacties per request nodig.

Voor meer info (niet geheel objectief natuurlijk, maar het geeft wel een beeld:)

http://dnscurve.org/
https://blog.opendns.com/2010/02/23/opendns-dnscurve/

[CAPSLOCK2000]

Hier haakt DNSCrypt dan ook op in. https://dnscrypt.org/ OpenDNS ondersteunt dit standaard.

OpenDNS heeft ook DNSCurve ontwikkeld. Dit kan je zien als een tegenhanger van DNSSEC, alleen ben je niet afhankelijk van een derde partij, en gedoe met certificaten, en heeft ook minder transacties per request nodig.

Voor zover ik het begrijp (en ik ben geen expert) hebben DNSCrypt en DNSCurve hetzelfde doel: de communicatie tussen authorative server en resolver beveiligen. Wat het niet doet is de authenticiteit van de communicatie vaststellen. Dit systeem is als HTTPs met self-signed certificaten. Dat is heel redelijk beveiligd tegen afluisteren onderscheppen van een verbinding, maar je weet niet zeker wie er aan de andere kant van de lijn zit. Je kan niet controleren of dat echt de juiste partner is of een aanvaller. Het enige dat je weet is dat de communicatie met die partner niet onderschept kan worden.

DNSSEC is dan meer als de handtekening die een mens onder een contract zet. De inhoud van het contract is niet geheim, iedereen kan het lezen en iedereen kan controleren dat het contract is voorzien van een handtekening en dus geldig is. (Hoe mensen controleren of een handtekening echt is laat ik even in het midden, zoals iedereen doet die met handtekening werkt, legacy enzo )
DNSSEC doet hetzelfde. DNSSEC verbergt niet dat of wat je communiceert, het garandeert dat je communicatie niet wordt gemanipuleerd of vervalst.

Aanvulling:
1. DNSSEC en DNSCurve zijn compatible met elkaar. Je kan best beide technieken tegelijk toepassen.
2. ICANN heeft aangegeven dat ze niet van plan zijn om DNSCurve te gebruiken. Het probleem is dat alle DNS-servers die een bepaalde zone serveren dezelfde sleutels moeten hebben. De root-zone maakt gebruik van honderden servers die door tientallen verschillende partijen worden beheerd. Al die servers en beheerders toegang geven tot dezelfde sleutelbos is organisatorisch niet veilig te krijgen.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:09]

[Dorank]

Verklaar je nader, ik zie het probleem namelijk niet. Of je controleert lokaal de signatures en dan werkt DNSSEC nog altijd, of je controleert lokaal geen signatures en dan veranderd er niets voor je aangezien DNS altijd al last van een MitM had.

[Mafra]

Hmmm. Ze zijn echt niet de eerste in Nederland.

https://www.onsbrabantnet...eilig-op-de-achtergrond-/

Onsbrabantnet ondersteunt het blijkbaar al 5 jaar.

[acehighness]

brabantnet is alleen geen LANDELIJKE provider ...
maar ze liegen alsnog, want T-Mobile heft ook al 4+ jaar dnssec geimplementeerd. En ik weet het niet zeker maar ik neem aan de ISP 'Online' ook, dat is immers ook TMNL.

[Verwijderd]

Add on voor firefox die dnssec info in adresbalk plaatst

https://addons.mozilla.or.../user/cznic-labs/?src=api

[Maurits van Baerle]

Dank. Ik heb dit vanochtend geinstalleerd maar moet zeggen dat het tegenvalt hoe weinig sites DNSSEC ondersteunen. Ik ben er vandaag pas twee tegengekomen, Xs4all.nl (omdat ik dacht dat die het wel aan zouden hebben staan) en Freebsd.org (omdat ik daar toevallig moest zijn).

Het houdt dus nog niet over...

[CAPSLOCK2000]

Wereldwijd stelt het in percentages nog vrij weinig voor.
De meeste TLD's gebruiken* het inmiddels maar de meeste domeinen van eindgebruikers niet.

In Nederland ligt het anders. Bijna de helft van .NL maakt er gebruik van.
Daar moet ik wel bijzeggen dat het meer de kleine dan de grote sites zijn.
Een aantal grote hostingboeren hebben het in een keer voor al hun klanten aangezet. Dit zijn dan typisch kleine websites die geen eigen infrastructuur hebben en alles door hun host laten regelen. Dat geeft de ironische situatie dat de website van de bakker om de hoek wel beveiligd is maar die van de grote banken niet.

* DNSSEC is verplicht voor nieuwe TLD's. Die regel bestaat al langer maar was een tijd lang onzichtbaar omdat er nooit TLDs bij kwamen. Een tijdje geleden zijn honderden nieuwe TLDs goedgekeurd en die gebruiken allemaal DNSSEC. Alleen al via die route zijn er honderden TLDs met DNSSEC bij gekomen. Het geeft wel een beetje vertekendbeeld, want die TLDs zijn lang niet zo belangrijk als .com of .nl . Gelukkkig hebben vrijwel alle TLDs die er toe doen inmiddels ondersteuning voor DNSSEC.

Van de 1515 TLDs in de root zone hebben er 1366 ondersteuning voor DNSSEC.
Je kan een landkaart vinden met ondersteuning van de land-TLDs op http://www.dnssec-deploym...y/dnssec-deployment-maps/ . Daarop kun je zien dat de hele westerse wereld inmiddels ondersteuning heeft voor DNSSEC. Eigenlijk alleen midden afrika doet nog niet goed mee.

Recent snapshot van dat plaatje: https://elists.isoc.org/p...c6e05/attachment-0012.png

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:09]

[LiquiD-AciD]

Awesome, bij mijn website krijg ik trouwens zowel een secured als een non secured logotje

[CAPSLOCK2000]

DNSSEC is meer dan een extra beveiliginsmaatregel voor DNS, het voegt een heel nieuwe dimensie aan DNS toe en maakt van DNS een platform voor nieuwe ontwikkelingen.

DNS is vrij bijzondere software. Net netwerk van DNS-servers vormt samen een wereldwijde gedistribueerde database. Iedereen kan z'n eigen takje aan de boom hangen en z'n eigen informatie toevoegen aan deze database.

Dusver hebben wie die database niet echt ten volle benut. Iedereen wist namelijk dat DNS niet echt betrouwbaar is (was). Voor de oorspronkelijke functie (het telefoonboek van internet) was dat eigenlijk al niet meer acceptabel. Vaak gebruiken we daarom nog maar extra informatie om te controleren of een verbinding wel veilig is.

DNSSEC verandert dat, door DNSSEC kunnen we het DNS-systeem nu wel vertrouwen. Dat zet de deur open voor nieuwe en innovatieve toepassingen. Via DNS hebben we een beveiligd communicatiekanaal gemaakt naar de beheerders van iedere website en ieder e-mail domein dat meedoet.

DNSSEC is niet het eerste systeem dat vertrouwen toevoegt. Het Certificate Authority systeem met "trusted third parties" voor SSL-certificaten doet hetzelfde, net als het Web of Trust van PGP. Het verschil is dat DNSSEC meelift op het bestaande DNS-systeem. Dat is wijd verbreid en onafhankelijk. Je hoeft nieman te betalen voor een commercieel certificaat (zoals bij traditionele SSL) en je hoeft geen sleutelmateriaal uit te wisselen met je partners (zoals bij PGP).

Een handig aspect van DNSSEC is dat het compatible is met het bestaande DNS-systeem. Je apparaten/applicaties hoeven het niet te ondersteunen om toch van (een deel van) de voordelen te profiteren. Als een DNSSEC-resolver ziet dat er geknoeid wordt dan geeft hij gewoon geen antwoord, in plaats van blind een vervalst antwoord door te geven. Je aplicatie snapt dan wel niet wat er aan de hand is en zal een foutmelding geven ("domain not found!") maar dat is beter dan de verkeerde site bezoeken.

[badkuipzeiler]

Jammer dat Tweakers dnssec niet gebruikt. Een gemiste kans.

[XSlicer]

DNSSEC is geen heilige graal, er zitten een hoop problemen nog in.
Google, Facebook, Yahoo, Akamai, Amazon, eBay gebruiken het bijvoorbeeld allemaal niet. Waarom zouden dat soort bedrijven achterliggen? Wat is het nut dat Tweakers dat doet?

https://sockpuppet.org/blog/2015/01/15/against-dnssec/ geeft nog een aantal argumenten tegen DNSSEC, waaronder dat cryptografische sleutels bij overheden gaan liggen, ipv nu bij commerciële bedrijven.

[CAPSLOCK2000]

https://sockpuppet.org/blog/2015/01/15/against-dnssec/ geeft nog een aantal argumenten tegen DNSSEC, waaronder dat cryptografische sleutels bij overheden gaan liggen, ipv nu bij commerciële bedrijven.

Niet deze weer, op al die punten is wat aan te merken.

All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure.

Al die systemen hebben dus nog een aanvulling nodig om daar mee om te gaan. Dat die systemen nu allemaal een gat laten is geen reden om dat gat niet op te lossen.

But domain-validated certificates remain insecure, because SMTP is itself insecure.

De manier om SMTP wel secure te maken is DNSSEC en DANE gebruiken. De auteur van dit artikel ziet dat blijkbaar niet en denkt dat het onoplosbaar is.

Whichever system replaces CAs needs to make TLS more resilient to government attacks.

Iedere regering van de wereld heeft wel een eigen CA waarmee ze certificaten voor ieder TLD in de wereld kunnen afgeven. Via DNSSEC/DANE kunnen ze dat ook, als ze de rootservers weten de manipuleren en dat is niet zo waarschijnlijk, zonder medewerking van de rest van de wereld lukt het je in ieder geval niet. Als je het toch doet dan heeft iedere DNS(SEC)-client het onmiddelijk door.
DNSSEC/DANE ís betere bestand tegen manipulatie dan het huidige CA systeem. Het probleem is niet opgelost maar het wordt kleiner, niet groter.
Sterker nog, zowel in de CA-wereld als in de DANE/DNSSEC wereld staat het je altijd vrij om je eigen CA op te zetten of je eigen DNS-trust-anchor en die te delen met iedereen die het wil.

The original DNSSEC design is two decades old; the first drafts I can find are from 1994. Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. The deployed system is littered with 1024-bit keys.

Suggestieve onzin van iemand die het niet wil begrip. De cryptografie in DNSSEC is modulair en vervangbaar. De gebruikte techniek wordt aangepast aan het doel en de stand van de techniek. Ooit gebruikte DNSSEC inderdaad een 1024 bit RSA key voor de root maar die is al vervangen. Zo is het systeem ontworpen. Precies hetzelfde argument kun je tegen het CA-systeem gebruiken, daar waren 1024 bits keys tot een jaar geleden ook heel normaal.
Met 1024 bit keys is op zich niks mis. Iedere keylengte is te kraken als je maar genoeg tijd neemt. De kunst is de lengte zo kiezen dat de sleutel niet te kraken is binnen de verwachte levensduur. Sleutels die heel lang veilig moeten zijn moeten daarom een hoge sleutellengte hebben. Sleutels die maar kort gebruikt worden en/of snel vervangen worden kunnen met een kortere sleuttellengte toe. 1024 bits keys zoals ze nu door DNSSEC gebruikt worden zijn typisch maar een paar dagen of weken geldig. Het is nog niemand gelukt om een 1024 bit key te bruteforcen, laat staan in een paar dagen tijd. Als we over een jaar of 10 zo ver zijn dat we dat wel kunnen dan hebben we die sleutels al lang weer vervangen.

Trouble is, software must handle those cases. End-users excoriate browser vendors for making it harder to “click through” certificate warnings, which are common. So frustrating were these warnings that the authors of curl egregiously broke their own API to appease programmers. So there’s no reason to believe that hard failures for DNS lookups will be acceptable to users.

Eindgebruikers vinden beveiliging nooit leuk, dat is waar, daar valt niet veel aan te doen. Ondanks de verzekering van deze auteur dat niemand het zou accepteren zijn browsers tegenwoordig wel degelijk bezig met het steeds moeilijker te maken om ongeldige SSL-certificaten toch te accepteren. Als het voor HTTPS met CA's kan, dan kan het ook voor HTTPS zonder CA's.

DNSSEC is Expensive To Deploy

Dat is waar maar ook dat geldt tot op zekere hoogte voor iedere vorm van beveiliging. Je geeft geld uit om zaken complexer te maken en je hoopt dat je er nooit gebruik van hoeft te maken.
Misschien dat DNSSEC duurder is dan het huidige CA systeem, misschien niet. Technieken als DANE bieden namelijk weer de mogelijkheid om dingen zelf (gratis) te doen waar je voorheen voor moest betalen, zoals het aanvragen van een certificaat. Niet alleen kost zo'n certificaat geld, het kost ook tijd. Mensen en systemen die met elkaar moeten communiceren zijn altijd relatief duur. DANE/DNSSEC geeft de mogelijkheid om alles zelf en lokaal te doen, dat spaart weer overhead. Met DNSSEC/DANE kun je 1000 certificaten per seconde aanmaken, gebruiken en weer afdanken zonder ooit een cent aan een CA te betalen. Technisch gezien kan dat nu al maar bijna niemand (behalve cloudflare) doet het omdat de overhead gigantisch is.

DNSSEC is Incomplete (...). In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.

Nog meer misleidende en onwillende informatie. De term "server" betekent niet dat je een 25.000 euro kostend apparaat in je kelder moet zetten. Iedere PC draait tegenwoordig "server" applicaties. SMTP is ook een "server to server" protocol, en toch gebruikt iedereen het dagelijks om z'n mail mee te versturen. Het is waar dat betere integratie tussen resolver en applicatie wenselijk is, maar dat staat helemaal los van het DNSSEC protocol. De bestaande DNS-api's bieden weinige ruimte aan applicaties maar dat is helemaal op te lossen met een nieuwe API. Het is de gewoonste zaak van de wereld dat oude software geen ondersteuning heeft voor nieuwe protocollen. Het is niet meer dan een kwestie van tijd voor applicaties wel gebruik gaan maken van de nieuwe mogelijkheden.

Als je daar niet op wil wachten dan is het nu ook al prima mogelijk om het systeem veilig te draaien. Je moet alleen zorgen dat je veilig met je DNS-resolver kan praten en dat probleem is al jaren geleden opgelost. Het is niet nodig dat DNSSEC daar ook nog iets voor gaat verzinnen.

But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly.

DNSESC is ontworpen om daar compatible mee te zijn maar online signeren is ook mogelijk. Bind en PowerDNS doen het, dat bewijst dat het mogelijk is.
Dat is inderdaad niet compatible met NSEC3 maar als je dat wil dan is dat ook geen probleem. Dat is zoiets als klagen dat gebakken klei niet meer kneedbaar is.

For everyone who accepts the default, every hostname in their DNS zones are public information.

Wederom toont de auteur een enorm kennisgat. Welke systemen hebben dat dan als default?
Kijk ook even naar wat we nu in praktijk gebruiken:

• .com -> nsec3
• .org >- nsec3
• .net -> nsec3
• .nl -> nsec3
• .be -> nsec3
• .uk -> nsec3

Nu geen onzin meer verkopen over onveilige of onwerkbare defaults.

A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.

Dat klopt maar de auteur heeft oogkleppen op waardoor hij weigert te zien dat DNSSEC ook prima end-to-end werkt. Alle informatie is beschikbaar aan de end-points om te verwerken. Je kan wel zeggen dat DNS getrapt is, maar dat is het huidige CA systeem ook. Daar moet je ook intermediate certificaten controleren om tussenliggende stappen te controleren. (Het is daar iets makkelijker omdat we een mechanisme hebben om die intermediates mee te geven met je certificaat, maar een vergelijkbaar mechanisme kun je ook bij DNSSEC toe passen).
Daarbij moet je die tussenliggende stappen toch nemen om DNS te laten werken, of je ze nu controleert of niet.

[XSlicer]

Bedankt voor je antwoord. Ik zag deze bron niet worden bediscussieerd in het DNSSEC-topic en ook op locaties van Cloudflare werd het altijd genegeerd dus de diepere details en kritiek hierop misten mij.
Zelf ontbreekt me de DNSSEC-kennis nogal dus kon ook niet echt op elk punt een antwoord vinden, bedankt dat je dat wilde doen.

[Blokker_1999]

Het blijft mij ook verbazen dat Tweakers in zijn Eigen infrastructuur zelf niet zo flexible is met de uitrol van nieuwe technieken zoals IPv6, HTTPS of DNSSEC. Vaak een gemiste kans voor een technologiesite. Dat men het niet te snel wil doen kan ik inkomen, maar men mag er toch wel een beetje werk van maken imho.

[CAPSLOCK2000]

Als ik me goed herinner hadden ze het al een tijdje aan staan op één van hun resolvers. Goed dat ze het nu ook op de anderen hebben aangezet. Het systeem heeft zich nu wel bewezen.

[ringlord_oc]

Zou dit ook een oplossing kunnen bieden tegen SPAM?
Of zijn het daar de DNS registrars die nog te laks omgaan met het verwijderen van spammende domeinen? bvb belgiumhotelinvest.be of eigenaarvanaf30000.be

[CAPSLOCK2000]

Zou dit ook een oplossing kunnen bieden tegen SPAM?
Of zijn het daar de DNS registrars die nog te laks omgaan met het verwijderen van spammende domeinen? bvb belgiumhotelinvest.be of eigenaarvanaf30000.be

Ja en nee. DNSSEC biedt zelf geen oplossing, het is meer een gereedschapskist om DNS-gebaseerde oplossingen mee te bouwen. Nu wil het toeval (nouja) dat een paar van onze belangrijkste anti-spam maatregelen zijn gebaseerd op DNS.

Technieken als RBL, DKIM, SPF en DMARC zijn volledig op DNS gebaseerd en zijn daar ook van afhankelijk. Als je DNS niet te vertrouwen is dan zijn voornoemde technieken eigenlijk ook niet te vertrouwen. DNSSEC maakt het mogelijk om die technieken wel te vertrouwen. Dat is een enorme vooruitgang ten opzichte van voorheen.

Voor e-mail is er nog een ander groot voordeel. Dusver heeft e-mail altijd verplicht een fallback naar clear-text-communicatie gehad. Als een mailserver niet bereikbaar is via een beveiligde verbinding dan zal zo'n beetje iedere mailserver in de wereld het opnieuw proberen via een onbeveiligde verbinding want zo is het ooit in een ver verleden afgesproken. Die afspraak is verouderd maar we komen er niet meer vanaf. We hebben namelijk geen manier om aan te geven dat je alleen via veilige verbindingen wil communiceren. Als dat niet lukt moet je het wel opnieuw proberen via een onbeveiligde verbinding of er gaat zo veel mail verloren dat niemand het accepteert. Zo maak je het aanvallers wel heel erg makkelijk, die hoeven alleen maar de beveiligde verbindingen te blokkeren.

Via een nieuwe techniek die DANE heet hebben we eindelijk een uitweg. DANE maakt gebruik van het betrouwbare communicatiekanaal dat DNSSEC biedt om de intenties van de mailserverbeheerder door te geven. In een DNSSEC-record publiceer je dat je TLS ondersteunt en dat ook altijd wil gebruiken. Nu kunnen verzendende mailservers eindelijk weigeren om een fallback naar cleartext te doen, ze weten zeker dat de ontvangende server TLS ondersteunt. Als de verbinding niet doorkomt is er dus sprake van een storing en dat is geen reden om de beveiliging maar uit te schakelen.

[hackerhater]

Helaas niet
Wat wel goed werkt om spam te identificeren is SPF.
Kort gezegd : een whitelist die namens jouw domein mail mag sturen.

[CAPSLOCK2000]

Om echt op SPF te kunnen vertrouwen heb je eigenlijk wel DNSSEC nodig. Zonder DNSSEC kun je DNS immers niet vertrouwen en is het mogelijk om die SPF-records te vervalsen of te blokkeren.

[hackerhater]

Klopt, het gaat hand-in-hand.
Helaas is de beste oplossing tegen spam direct ook de moeilijkste : alle ISP's bij consumenten poort 25 laten blokkeren en besmette clients afsluiten.

[i-chat]

Klopt, het gaat hand-in-hand.
Helaas is de beste oplossing tegen spam direct ook de moeilijkste : alle ISP's bij consumenten poort 25 laten blokkeren en besmette clients afsluiten.

er is een betere oplossing, elke eigenaar van een pc verantwoordelijk stellen voor zijn pc...

net zoals een vader geen bal door mijn ruit heeft getrapt en toch moet betalen, omdat zijn kind dat wel deed.. net zals de buurman moet betalen omdat zijn boom op mijn dak waaide... terwijl hij wist dat het ding rottende wortels had...
allebei soorten gevolgschade die niet direct aan de ander te wijten zijn ... maar wel voor zijn rekening worden geacht...

dus als je je pc niet afdoende beveiligd.... ben je net zo 'verantwoordelijk' als wanneer je onvoorzichtig rijdt in de auto, brand veroorzaakt, of je kinderen niet in de gaten houdt

[Ed Vertijsment]

Dat je verantwoordelijk bent betekent nog niet dat de spam niet verstuurd wordt, daar kom je vaak achteraf ook pas achter.

Ik heb altijd geleerd dat voorkomen beter is dan genezen en dus kan het mijn inziens dan ook geen kwaad om standaard poort 25 dicht te timmeren en slechts op verzoek te openen.

Tuurlijk zou ik graag zien dat iedereen fatsoenlijk met computers om kon gaan maar in de praktijk vinden veel mensen dat moeilijk, en om nou de meerderheid van Nederland toegang tot een computer te gaan ontzeggen.

Bij de provider alles afdwingen is ook geen goed idee maar naar mijn mening is er niets mis met "sane defaults". Ik ken namelijk niet heel veel mensen die thuis een mailserver hebben draaien.

[Blokker_1999]

Er bestaan vandaag meerdere oplossingen, maar geen enkele werkt perfect.

[Noppie1991]

Dit zou ik ook erg graag willen weten. 1 van mijn collega's heeft hier vrij veel last van en omdat de mail zo legitiem eruit ziet is er nauwlijks wat aan te doen (het is ook steeds van een ander afzenderadres).

[hackerhater]

Niet echt. De domeinen die vervalst worden moeten dingen als SPF aan zetten en de ontvangende server moet erop controleren.
Voor de rest : spamfilter.

[Heidistein]

Goede zet. Wat mij wel opviel toen we het op kantoor hadden aangezet, dat een aantal sites het behoorlijk stuk geconfigureerd hadden. Ik ben alweer vergeten hoe het precies zat, maar ik dacht dan wel het domein.nl gesigned was, en dan een redirect naar een ongetekend www.domein.nl. Of zoiets.
En dan kunnen mensen niet meer op je site komen. In een kantoorsituatie maak je weinig verschil, maar als een beetje ISP dit gaat doen, gaan mensen misschien een keer hun rommel repareren.

[CAPSLOCK2000]

Google ondersteunt het nu al een paar jaar en dat heeft flink geholpen.

Ik monitor het gebruik van DNSSEC al een paar jaar in een vrij groot netwerk dat ik beheer (>10.000 gebruikers) en het gaat nog maar zelde fout. Ik heb afgelopen jaar maar twee keer een storing meegemaakt die groot genoeg was dat iemand er over kwam klagen (en dan bedoel ik dat 1 website of e-mail-adres niet bereikbaar is, niet meer). Dat is niet erger dan alle andere storingen waar we toch al mee te maken hebben. Een website of e-mail die er een paar uur uitligt merken de meeste gebruikers niet eens.

[TheCricketer25]

Hoe zou het zitten bij KPN, per slot van rekening is XS4All een volle dochter van hen

[hottestbrain]

Die hebben het niet. XS4ALL heeft ook een eigen netwerk, hoewel het gebruik maakt van de backbone van KPN.

[jurri@n]

Mooi dat ze dit standaard gaan controleren. Ik hoop dat andere ISP's snel volgen, dan kunnen we ook door naar de volgende stap: DANE (kort samengevat: hash van je SSL-certificaat opnemen in DNS, zodat je kunt controleren of het certificaat niet vervalst is).

[cruysen]

Misschien hier een beter uitleg wat DNSSEC is: https://www.dnssec.nl/home.html
Alleen wel jammer dat er alleen een inventarisatielijst is van augustus 2014

Software die aanbevolen wordt op deze site: De Valibox: beveilig je netwerk met DNSSEC-validatie
En de link naar internet.nl (Tip )

[Reactie gewijzigd door cruysen op 26 juli 2024 09:09]