Dnssec: voor het laatste onveilige protocol

Inleiding: dnssec en de SIDN

De Stichting Internet Domeinregistratie Nederland, die het topleveldomein .nl beheert, zal dit voorjaar het dnssec-protocol voor de .nl-zone invoeren. Dat zou de veiligheid van het dns-systeem flink moeten vergroten. Hoewel de veiligheid van dns niet direct in gevaar is geweest, zagen we de afgelopen jaren wel al diverse scheurtjes in het bouwwerk. Experts roepen al langer om een snelle invoering van dnssec.

Dnssec is ontwikkeld als aanvulling op het dns-protocol en moet de kwetsbaarheden in dat protocol verhelpen. Zo moeten cache poisoning en man in the middle-aanvallen worden voorkomen. Daartoe koppelt dnssec het antwoord op een dns-query aan een digitale handtekening, waardoor makkelijker kan worden gecontroleerd of de records die een dns-server teruggeeft, wel valide zijn. Dns-servers worden hiertoe voorzien van een public key cryptography-systeem: dns-informatie over een domein wordt gesigned met een private key, zodat gebruikers met een publieke sleutel kunnen verifiëren dat er niet met de informatie gerommeld is.

De werking van dns

Dns zorgt voor de vertaling van domeinnamen, zoals tweakers.net, naar ip-adressen. Elk keer als we de naam van een website intoetsen, moet eerst het internetadres van de bijbehorende server worden opgezocht. Het onderdeel van de netwerkstack dat hiervoor verantwoordelijk is, heet (stub) resolver en is onderdeel van het besturingssysteem.

Dns wordt niet alleen voor websites gebruikt, maar voor alle internetprotocollen die met domeinnamen werken. Naast voor de hand liggende protocollen als http en ftp wordt dns ook gebruikt voor DomainKeys Identified Mail en het Sender Policy Framework, twee e-mailsystemen die dns-verificatie gebruiken om spam tegen te gaan. Daarnaast wordt dns gebruikt om cryptografische sleutels en certificaten beschikbaar te maken.

Boom

Omwille van beheer, veiligheid, betrouwbaarheid en schaalbaarheid is dns opgezet in de vorm van een gedecentraliseerde boomstructuur van servers. Aan de wortel daarvan staan de rootservers, dertien systemen die voor elk topleveldomein - zoals .com of .nl - naar andere dns-servers verwijzen. Op dit moment gaat het nog om enkele honderden tld's, maar dat worden er straks veel meer.

De .nl-domeinen worden zoals gezegd beheerd door de SIDN. Deze organisatie onderhoudt daarvoor een infrastructuur van enkele tientallen servers, verspreid over drie locaties in en om Arnhem.

Eind 2006 waren er 13 root servers verspreid over 123 nodes. Inmiddels is het aantal nodes meer dan verdubbeld

Als een computer een domeinnaam in een ip-adres wil omzetten, moet die in theorie beginnen bij de rootservers. Die verwijzen naar de nameservers die aanvragen voor subdomeinen van het betreffende tld afhandelen; een verzoek om het ip-adres van tweakers.nl komt zo bij de SIDN terecht. Deze organisatie verwijst vervolgens weer naar de dns-server van het desbetreffende domein, meestal een van een commerciële provider.

Die laatste dns-servers kunnen een ip-adres voor bijvoorbeeld tweakers.nl geven, maar zijn ook verantwoordelijk voor het derde niveau - bijvoorbeeld www.tweakers.nl of tweakblogs.tweakers.nl. Het is ook mogelijk om dns-servers voor vier of meer niveaus te gebruiken. Dat gebeurt bijvoorbeeld in het Verenigd Koninkrijk, waar maar een paar second level domains als .co.uk en .org.uk gebruikt worden.

De systemen voor de root servers zijn over de hele wereld verspreid

In de praktijk wordt lang niet elke aanvraag via de rootservers afgehandeld. Internet service providers gebruiken, om het dns-verkeer binnen de perken te houden en om de tijd voor een request zo kort mogelijk te houden, namelijk ook zelf dns-servers. Die kunnen automatisch - via dhcp - of handmatig aan de aangesloten pc's worden toegewezen en verzorgen adresaanvragen voor de gebruikers. Elk adres dat ze opvragen, wordt vervolgens in een cache opgeslagen. Desondanks krijgt de SIDN overigens nog steeds twintig- tot veertigduizend query's per seconde te verwerken.

Een node van het K-rootservercluster draait bij de AMS-IX
Foto: Bas van Schaik

Beren op de weg

De twee zwakke plekken van het dns-systeem zijn de keten van query's en het gebruik van non-authoritative cache-servers. De dertien root servers - grotendeels geïmplementeerd als anycast-clusters - zijn natuurlijk een aantrekkelijk doelwit voor krakers die het internet willen platgooien. Er is echter nog nooit een succesvolle aanval uitgevoerd, hoewel er wel een paar pogingen zijn gedaan.

Wat wel is gelukt, is om computers verkeerde ip-adressen te laten gebruiken via een techniek die cache poisoning wordt genoemd. Daarbij wordt een vals adres in de lokale cache geïnjecteerd. Dat kan op een besmette machine gemakkelijk direct, bijvoorbeeld door de hosts-file aan te passen. Het is ook mogelijk om een query naar een valse dns-server te sturen - bijvoorbeeld met address spoofing - of door een vals antwoord terug te geven. Hoe dichter een valse dns-server bij de wortel van de dns-boom zit, hoe groter de reikwijdte van de hack natuurlijk is.

Het vervelende is dat een eindgebruiker hier helemaal niets van hoeft te merken. Oplettende surfers kijken bijvoorbeeld eerst of een link en de onderliggende url in een mail-bericht wel overeen komen, voordat ze erop klikken. Hetzelfde geldt voor https: iedereen weet inmiddels wel dat het slotje in de browser aangeeft of een verbinding wel of niet is versleuteld. Aan een vals ip-adres waarop een goed nagemaakte website draait, kan een gebruiker echter vrijwel niets zien.

Cache injection

Tot een paar jaar terug waren dns-inbraken vooral theoretisch, maar in 2008 vond Dan Kaminsky een lek waarmee kwaadwillenden daadwerkelijk valse informatie in de caches van de meestgebruikte dns-servers konden injecteren. Daarmee werd dnssec, dat toen al meer dan tien jaar bestond, ineens heel actueel. De afgelopen jaren zijn de beheerders van de dns-infrastructuur dan ook druk bezig geweest met het uitontwikkelen en implementeren van deze beveiliging.

Met dnssec worden enkele velden aan de bestaande domeininformatie op dns-servers toegevoegd. De cryptografische ondertekening van een domeinnaam wordt aangeboden in het zogeheten RRSIG-record, en de bijbehorende publieke sleutel is opvraagbaar als het DNSKEY-veld. Hiermee kan een resolver direct controleren of de informatie die hij binnenkrijgt inderdaad van de echte dns-server afkomstig is. Bestaat een domein niet, dan levert de query een Authenticated Denial of Existence op.

De invoering bij de SIDN

Digitaal ondertekenen

"Bij de implementatie van dnssec moet je bij het begin beginnen: de root servers", aldus Marco Davids, technisch specialist van de SIDN. "Twee jaar geleden werd begonnen met de ondertekening van de berichten van de root servers. Een maand later hebben wij dat ook ingevoerd voor het .nl-domein."

Die stap was de tweede schakel in de chain of trust. De publieke sleutel waarmee SIDN zijn dns-records ondertekent, is opvraagbaar via de root servers, die de sleutel in een zogeheten ds-record aanbieden. De derde schakel is dat de publieke sleutels van individuele .nl-domeinen via de name-servers van de SIDN gecontroleerd kunnen worden. Zo wordt voorkomen dat een man-in-the-middle een gewoon dns-antwoord terugstuurt terwijl de echte nameserver wel degelijk dnssec ondersteunt.

Voor het ondertekenen van de records heeft SIDN twee Hardened Linux-systemen die van een hardware security module zijn voorzien. Deze cryptoprocessors zijn Luna SA 4-modules van Safenet. Tot nu toe werd zulke apparatuur vooral door banken gebruikt, maar te zijner tijd zullen wellicht ook hosting providers deze modules aanschaffen. Zij doen immers meestal het dns-beheer voor hun klanten. Er zijn voor hen trouwens ook goedkopere oplossingen, zoals SoftHSM.

Versleuteling zone files

De zone files waarin alle informatie voor de .nl-domeinen staat, worden elke twee uur opnieuw gegenereerd uit de gegevens van het Domeinregistratiesysteem, het administratieve systeem van de SIDN. Daarvoor wordt onder andere het opensourcepakket OpenDNSSEC gebruikt. De ondertekening van de records voor alle ruim vijf miljoen domeinen kost ongeveer een half uur. "Dat geeft ons voldoende ruimte om die batch een paar keer te herstarten als dat nodig mocht zijn", aldus Davids.

De records kunnen ook on-the-fly door de nameserver worden ondertekend. Dat wordt bijvoorbeeld ondersteund door het Nederlandse PowerDNS. "Dan moet je je geheime sleutelmateriaal naar elke slave server vervoeren, en om veiligheidsredenen doen wij dat niet."

"Failure is not an option"

"Belangrijker dan de techniek zijn de policy's en practices rond dnssec. Zo moeten er bij het genereren van nieuwe sleutels twee beheerders voor de HSM-systemen en een security officer aanwezig zijn. Die moeten elk een token presenteren en alles wordt op film vastgelegd. Het gaat ook om het gevoel dat je overbrengt: vertrouwen is ook een beetje show." Dat laatste geldt al helemaal voor de key signing ceremony van de root servers.

Daarnaast heeft men bij SIDN moeten nadenken over de problemen die kunnen opduiken. "Welke risico's zitten er aan het dnssec-proces vast? Wat gebeurt er als maar de helft van de records wordt ondertekend? Wat als er een HSM stuk gaat?" Davids' collega Miek Gieben benadrukt: "Failure is not an option. We moeten altijd in de lucht zijn." Het is in het verleden weliswaar een paar keer voorgekomen dat de registratiesystemen of de dns-servers problemen hadden, maar zou het hele .nl-domein eruit liggen, dan loopt de schade in de miljarden.

Vertraging

De invoering van dnssec heeft dan ook diverse malen vertraging opgelopen. "Wij zijn hier paranoïde," zegt Gieben. "We willen niets veranderen zolang we niet zeker weten dat het ook werkt." Een van de vroege problemen van het nieuwe protocol was dat dns-antwoorden onderweg soms werden weggegooid. "De doorgifte van dnssec kan op elke tussenliggende firewall en resolver misgaan."

Hoewel dnssec is ontworpen als transparante aanvulling op het traditionele dns-systeem, zijn er wel degelijk verschillen. Zo konden de udp-pakketjes voor traditionele dns-berichten nooit meer dan 512 tekens bevatten. Dat is bijvoorbeeld ook de reden dat er precies dertien root servers zijn. Als de grotere dnssec-pakketten onderweg ergens geblokkeerd worden, valt het hele systeem echter in duigen.

Vandaar dat SIDN samen met het Ministerie van Economische Zaken, NLnet Labs, PowerDNS en SURFnet het platform DNSSEC.nl heeft opgericht. "Daar praten we over de implementatie-aspecten van dnssec. Gebruiken we NSEC of NSEC3? Hoeveel bits moet een sleutel bevatten? En hoelang zijn die sleutels geldig?"

Ingebruikname

De eerstvolgende stap is de uitrol van dnssec bij de registrars. Om te beginnen zorgt de SIDN dat registrars de publieke sleutels voor hun domeinen automatisch via de EPP-webservice kunnen aanleveren. Deze dienst wordt dit voorjaar in gebruik genomen.

Hosting providers, die veelal ook het dns-beheer voor hun klanten verzorgen, kunnen de implementatie van dnssec dan meteen in gang zetten. Registrars die hun klanten via een webinterface zelf de dns-instellingen laten beheren, zullen extra velden voor de publieke sleutels aan hun dashboards moeten toevoegen. Als de publieke sleutels bij de registrar bekend zijn, kan die ze weer automatisch naar de SIDN doorzetten.

"We werken op dit moment samen met de registrars en isp's aan de verdere implementatie van dnssec", aldus Davids. "Sommige providers, zoals T-Mobile en Xs4all, ondersteunen dnssec al gedeeltelijk. Daarnaast hopen we bij de introductie drie of vier registrars launching partners te hebben die dnssec direct aan hun klanten aanbieden. De software is klaar; we zitten nu in de testfase."

Friends & Fans

Wie zijn eigen domein en dns beheert en niet kan wachten tot zijn registrar dnssec aanbiedt, kan zijn publieke sleutel tot de officiële introductie zelf bij de SIDN indienen. Daarvoor is het Friends & Fans-programma opgezet. Wie mee wil doen, moet een mailtje naar de stichting sturen, die de publieke sleutel dan handmatig van de betreffende nameserver haalt en deze buiten de registrar om aan het SIDN-systeem toevoegt. Als dnssec straks officieel wordt ondersteund, zullen de sleutels bij registrars die de dienst nog niet ondersteunen, toch weer worden verwijderd. Meedoen kan dan alleen nog via de registrars.

Wil je ten slotte weten of de resolver op je eigen computer wel of geen dnssec ondersteunt, dan kun je daarvoor naar de test-pagina gaan. Volgens de statistieken van RIPE vroeg meer dan vijftig procent van alle dns-query's een half jaar geleden al om de dnssec-gegevens. Dat wil natuurlijk niet zeggen dat alle records ook daadwerkelijk gevalideerd worden, maar de penetratie van het systeem is duidelijk al vergevorderd.

Redenen te over

Hoewel we dns wel het laatste onbeveiligde protocol kunnen noemen, is er lange tijd getwijfeld aan het nut van dnssec. Het is immers nog altijd veel eenvoudiger om mensen op duidelijk onbetrouwbare links in spammailtjes te laten klikken, dan om ergens een vals dns-record te injecteren. Hoewel dnssec al veel langer bestond, kreeg het dan ook weinig aandacht.

Pas toen Kaminsky in 2008 over een bruikbare kwetsbaarheid publiceerde, kwam de beveiliging van dns in een stroomversnelling. Het DigiNotar-debacle, dat aantoonde dat voorheen onvoorstelbare veiligheidsproblemen toch echt kunnen optreden, deed daar nog een schepje bovenop - sommigen spraken zelfs van het failliet van het certificaten-systeem.

De nieuwe dnssec-infrastructuur zorgt echter niet alleen voor beveiliging van het dns-systeem - het kan ook voor nieuwe toepassingen worden gebruikt. De eerste toepassing lijkt 'DANE' te worden: DNS-based Authentication of Named Entities. Hiermee kunnen servercertificaten aan de hand van dnssec-records worden gevalideerd. Voor het opzetten van een versleutelde verbinding naar een webserver ben je dan niet langer afhankelijk van een certificaat dat door diezelfde server wordt aangeleverd, en dat alleen nog aan de hand van certificaten in je browser gevalideerd kan worden. Met DANE hadden de problemen van DigiNotar misschien kunnen worden voorkomen. Davids weet dat wel zeker: "Na DigiNotar hadden wij onze business case voor DNSSEC rond."

Reacties (61)

[CAPSLOCK2000]

Ik mis een belangrijk voordeel van DNSSEC in dit artikel, namelijk dat eindgebruikers het niet weg kunnen klikken. Wie een melding krijgt over een ongeldig HTTPS-certificaat zal dat in 99% van de gevallen gewoon accepteren. Eindgebruikers zijn er aan gewend om zich niks aan te trekken van dat soort beveiliging, als ze het al snappen.

Met DNSSEC kan dat niet. Nog voordat de foute informatie op je computer komt wordt er al ingegrepen. Je krijgt domweg geen antwoord van je DNS-server. Er komt geen foutmelding (dat is ook een nadeel) en er is niks dat je weg kan klikken. Als DNSSEC volledig wordt doorgevoerd kun je stellen dat je of een geldig antwoord krijgt, of geen antwoord.
Op eigen houtje beslissen om je niks aan te trekken van DNSSEC gaat niet zonder zelf een DNS-server te draaien. Consumenten die de DNS-servers van hun provider gebruiken zitten altijd goed.

[smartbit]

In februari 2012 heeft Olaf Kolkman een twee daagse cursus DNSSEC gegeven.
De cursus is nu gratis en in het Nederlands online voor iedereen te volgen Op de website van de NGN vind je onderaan de links

• naar de videos (zowel voor download als op youtube),
• naar de slides en
• naar AWS instances om zelf met DNSSEC te oefenen.

[PetervdM]

dit weekend wordt het bal: anonymous gaat de root dns servers aanvallen in een poging internet plat te leggen.
http://pastebin.com/GFkQnf6e

[Reactie gewijzigd door PetervdM op 23 juli 2024 00:30]

[TDeK]

Als dat kon, dan was dat in het verleden allang eens geprobeert. Het zal ook niet werken, omdat vrijwel iedere internetgebruiker de nameservers van zijn ISP gebruikt, of OpenDNS of Google's Public DNS servers. Dit zijn meestal Tier 3 of lagere servers die hun updates van Tier 2 of Tier 1 krijgen. Als ze de Tier 1 servers eruit beuken, dan krijgen de Tier 2 en lagere DNS server geen updates meer binnen. Gevolg: ze houden hun laatste succesvolle update vast. Gevolg: het internet (ofja, DNS dan) blijft vrolijk werken. Alleen nieuwe domeinregistraties worden niet actief na een paar uur, zoals normaal wel het geval is.
Conclusie: 1 april!
PS: De landelijke TLD's worden überhaupt niet op de 13 Tier 1 servers beheerd, dus die blijven sowieso functioneren.
@PetervdM: het lijkt me stug dat de software van de DNS servers een TTL laten prevaleren, ook als de Tier n+1 update is mislukt. Volgens mij treedt dan een fail-safe functie in werking die de huidige DNS lijst vast houdt totdat er een nieuwe succesvolle update in binnengehaald.

[Reactie gewijzigd door TDeK op 23 juli 2024 00:30]

[PetervdM]

ze proberen een amplified attack. jouw dns request naar de dns server van je provider heeft een gespoofed source ip adres dat toebehoort aan een van de root dns servers.
daardoor wordt het antwoord niet naar jou, maar naar die root dns server gestuurd. die krijgt dus een unestablished packet binnen en zal dus een recovery starten.
de dns server van de provider weet van niks, dus dat gaat niet lukken, maar inmiddels zijn er weer tig pakketjes heen en weer gestuurd. en als dat genoeg gebeurt gaat die server wel door z'n hoeven.
als de ttl van de gecachede entries bij je provider verlopen is worden ze weggegooid, tenzij de dns server van je provider stale records toestaat, of je dat zelf hebt ingeschakeld als je opendns gebruikt. het kan dan zomaar zijn dat sites met een lage ttl dan niet meer bereikbaar zijn.

ik denk ook dat ze kansloos zijn, een dag is te kort. maar als ze dat langer volhouden, dan weet ik het nog niet zo net.
ik heb de ttl van de dns records van ons domain zekerheidshalve voor dit weekend op 7 dagen gezet.

@Rick2910: alleen als stale records zijn enabled. dit is zeker niet altijd standaard. als dat niet zo zou zijn, zou het heel lastig worden records te laten vervallen, en de caches zouden uit hun voegen groeien omdat eenmalig opgevraagde records "eeuwig" worden geüpdate.
standaard worden ze door het scavenging mechanisme periodiek verwijderd.

[Reactie gewijzigd door PetervdM op 23 juli 2024 00:30]

[arjankoole]

die krijgt dus een unestablished packet binnen en zal dus een recovery starten.

Jij denkt TCP. DNS verkeer is echter UDP verkeer. Dat is 'fire and forget'.

[PetervdM]

ik denk IP.
de three-way handshake ( drie pakketten ) is altijd nodig om de verbinding tot stand te brengen. pas dan komt het hoger liggende protocol tot de ontdekking dat er een fout is gemaakt ( weer tenminste twee pakketten ), en vervolgens wordt de verbinding gesloten en de poort / socket vrijgegeven ( weet ik niet precies, 2 of 3 pakketten ).
en omdat dat meer is dan wat jer er in hebt gestopt richting de dns server van je provider ( three way handshake + dns request ) wordt het een amplified attack genoemd.

[Verwijderd]

*buzzzz* U bent de zwakste schakel.

Terug naar de schoolboeken vriend.

three-way handshake is een TCP dingetje. UDP is connectionLESS (ofwel er is geen verbinding)

[PetervdM]

"*buzzzz* U bent de zwakste schakel.

Terug naar de schoolboeken vriend."

Uhhhhh. dacht het niet. bij berichten > 512 bytes schakelt dns over op tcp, bv ook in gebruik voor zone transfers. en google maar eens op "DNS amplification attacks". een klein query pakket kan to een 70 maal zo groot antwoord uitlokken.

[Reactie gewijzigd door PetervdM op 23 juli 2024 00:30]

[sfranken]

Het is heel erg lastig om alle 13 root servers in 1x plat te krijgen zonder dat er iemand ook maar iets in de gaten heeft. Tijdsverschil en precisie zijn 2 factoren die daarbij zeker van toepassing zijn.

Anonymous is, denk ik, niet georganiseerd genoeg om ze alle 13 in één keer plat te krijgen. En als er eenmaal 2 servers "down" zijn gaan er bij de overige 11 echt wel belletjes rinkelen en worden er door Security Officers maatregelen genomen om het down-gaan van de andere servers (koste was kost?) tegen te gaan.

Bovendien.. die servers zijn volgens mij vrij gehard, dus ik denk dat het lastig word om die neer te krijgen al zeg ik nooit nooit

[CAPSLOCK2000]

In werkelijkheid zijn het niet 13 servers, maar 13 groepen van servers. Per groep zijn er veel meer servers beschikbaar. Kijk maar eens naar het plaatje op pagina 2, er zijn werkelijk honderden root-servers.

[n4m3l355]

De details hiervan weet ik niet maar in een grijs verleden kon ik me herinneren dat hier eerder toe een poging is gedaan en dat van de 13 groepen er 11 gevallen waren. Het lijkt een onmogelijke taak maar aan de andere kant Anonymous heeft vaker zware DOSS attacks uitgevoerd.
In hoeverre dit relevant is echter tot Dnssec vraag ik me dan af. Het zou eerder aantonen hoe zwak het systeem is vanwege dat we afhankelijk zijn van de dns-servers voor eenvoudig gebruik. Mij heeft dit systeem me altijd verwondert zeker met P2P zou je toch verwachten dat dit decentraal langzaam aan uitgevoerd kan worden.

[CAPSLOCK2000]

De details hiervan weet ik niet maar in een grijs verleden kon ik me herinneren dat hier eerder toe een poging is gedaan en dat van de 13 groepen er 11 gevallen waren.

Sinds we met groepen werken is DNS noit meer down geweest. De laatste keer dat het echt fout ging waren het wel nog een paar losse servers. Dan hebben we het wel over een jaar of 10 geleden. Sindsdien is er een hoop veranderd.

5 jaar geleden was de laatste grote aanval. Toen zijn er 4 servers in de problemen gekomen maar niet zo erg dat ze helemaal onbereikbaar waren.

Het zal best wel lukken om een aantal losse DNS-servers down te krijgen maar niet zo veel dat het een probleem wordt.

Persoonlijk zou ik me niet richten op de root-servers maar op de DNS-servers van de grote providers. DNS is zo'n lichtgewicht dat de meeste providers niet meer dan twee of drie DNS-servers hebben staan. Als je die servers plat krijgt hebben miljoenen mensen daar onmiddelijk last van.

[metaal]

Als ik zo de tekst lees is het denk ik eerder een 1 aprilgrap is. In ieder geval gaat die aanval niet werken, en dat weten ze bij Anonymous vast ook wel.

[Aetje]

Het is immers nog altijd veel eenvoudiger om mensen op duidelijk onbetrouwbare links in spammailtjes te laten klikken...

Wat aangeeft dat SMTP als protocol ook nog wel enige beveiligingstekortkomingen heeft. "Het laatste onveilige protocol" vind ik ietwat te vroeg geroepen...

[Niemand_Anders]

Wat heeft het klikken van een gebruiker op een link in een email in godsnaam te maken met het SMTP protocol?

Sterker de S uit SMTP is de belangrijkste reden voor de beperkingen van het protocol. Via een aantal SMTP extensions is geprobeerd om een aantal toe te voegen. Maar juist omdat het SMTP protocol zo beperkt is is het wel zo stabiel en kan er weinig fout gaan..

SMTP, HTTP, POP3, IMAP en veel andere 'telnet' gebaseerde protocollen hebben een beperkte set aan commando's en van elk commando is goed aangegeven waaraan voldoen moet worden..

Vijftien jaar geleden werden DNS server puur gebruikt voor de omzetting van hostname naar IP adres en het teruggeven van MX records. Vandaag de dag wordt DNS ook steeds vaker gebruikt als 'security enhancement'. DKIM, Domainkeys en SPF gebruiken DNS om afzenders van email te kunnen controleren. Via Dane kun je op bais van een soort van SVR record format de fingerprint van het X.509 (SSL) certificaat terug vragen.

Zou t.net gebruik maken van dane, dan zou je met een query op '_443._tcp.www.tweakers.net' de fingerprint van het certificaat terug krijgen.

Daardoor het DNS systeem ontzettend belangrijk gemaakt. Indien je gebruik maakt van deze DNS toevoegingen en jouw DNS server ondersteund geen DNSSEC kun je dat vergelijken met het opslaan van root en administrator wachtwoorden in een plain text document..

Helaas heeft dane nog steeds de draft status en hebben weinig browser hier support voor. Echter dane kan een belangrijke drempel worden voor DNS poisoning. Als ING (en andere banken) Dane + DNSSEC zou gaan gebruiken dan moet een hackers niet alleen meerdere DNS records voor ing.nl aanpassen, ook moeten ze dan de public DNSSEC key aanwezig bij SIDN zien te wijzigen. Het upstream key principe bij DNSSEC is een van de belangrijkste peilers van het protocol.

De upstream keys voorkomen ook dat DNS servers worden overspoeld met DNS queries om de antwoorden van caching DNS servers te controleren. De resolver kan daardoor gewoon het antwoord van de xs4all cache server accepteren en via de key op de SIDN server het antwoord valideren..

[Reactie gewijzigd door Niemand_Anders op 23 juli 2024 00:30]

[CAPSLOCK2000]

Helaas heeft dane nog steeds de draft status en hebben weinig browser hier support voor. Echter dane kan een belangrijke drempel worden voor DNS poisoning. Als ING (en andere banken) Dane + DNSSEC zou gaan gebruiken dan moet een hackers niet alleen meerdere DNS records voor ing.nl aanpassen, ook moeten ze dan de public DNSSEC key aanwezig bij SIDN zien te wijzigen. Het upstream key principe bij DNSSEC is een van de belangrijkste peilers van het protocol.

Het nadeel van DANE is dat in de meeste gevallen alle verantwoordelijkheden bij 1 partij komen te liggen. De meeste mensen registreren een website bij een hosting-boer die ook zorgt voor een SSL-certificaat en een DNS-server. In de toekomst zal DNSSEC daar ook bij komen. Als diezelfde toko nu ook voor DANE gaat zorgen is de meerwaarde weer een stuk kleiner.
Als een aanvaller er in slaagt om zo'n hoster te kraken of te social engineeren (heb ik deze week nog moeten doen) heeft hij alle touwtjes in handen.
Bij de traditionele manier van SSL heb je altijd nog een tweede controler door de leverancier van het SSL-certificaat (al geef ik gelijk toe dat dit systeem in praktijk nauwelijks werkt).

[Niemand_Anders]

Dat is niet helemaal correct. Immers vrijwel iedereen gebruikt de DNS server van hun provider. DNS Poisoning gebeurt in de regel dan ook bij caching servers en niet bij authoritive DNS servers.

Ook het injecteren van foutieve certificaat gegevens is een stuk lastiger met DANE + DNSSEC (het gaat uiteraard om de combinatie) omdat het zeer complex is om de vervalste data te voorzien van een geldige checksum. De nameserver van xs4all kan de public key van ing.nl ophalen bij de SIDN servers. Daarmee kan de xs4all server valideren of de ontvangen data ook daadwerkelijk van de authoritive server lijkt af te komen.

Aan de andere kant kan DANE + DNSSEC ook weer tegen je werken. We kennen allemaal inmiddels de driemaal kloppen regel welke de banken via een aantal stopjes goed onder de aandacht heeft gebracht.

Maar het is niet lastig om een phising site op IN9.NL (juist met hoofdletters zodat de 9 minder opvalt) te draaien en daarvoor DANE, DNSSEC en EV-SSL certificaten voor te gebruiken. Je browser heeft dan niets in de gaten omdat die niet weet dat je ing ipv IN9 wou bezoeken. Gelukkig heeft ING inmiddels SPF records opgenomen in al zijn domeinen, waaronder ook postbank.nl. Echter ABN Amro heeft nog steeds geen SPF record opgenomen in hun DNS. Persoonlijk vind ik dat grove nalatigheid vooral omdat het zo'n simpele aanpassing is.

Maar er ligt hier ook een grote rol voor Govcert. Zij zouden eigenlijk elke 6 maanden een lijst van best practices moeten uitbrengen. De overheid zou daarnaast deze lijst verplichte kost maken voor onder andere financiele instellingen en boetes moeten opleggen als de maatregelen niet binnen 6 maanden zijn doorgevoerd, tenzij een goede reden aangedragen kan worden.

Govcert zou deze lijst hun website moeten publiceren zodat iedereen kan zien welke instellingen wel en niet up to date zijn met de laatste technieken. Dat zou dan ook weer inhouden dat browser/mail client fabrikanten deze lijst kan gebruiken om te waarschuwen voor mogelijk onveilige domeinen.

[TDeK]

Het verschil is ook dat je SMTP, POP, IMAP, FTP, HTTP enz. best als basisprotocol kunt gebruiken, waarna je de sessie over TLS of SSL laat lopen. Dan ben je alsnog secure, hoewel het beter direct in het protocol kan zitten, zoals ze bij DNSSEC doen.

[MPAnnihilator]

Key rollovers zijn als administrator toch echt wel een ramp. Door iedereen zijn eigen manier van key rollovers te laten implementeren( lees scripten) , gaan er volgens mij nog lijken uit de kast vallen binnenkort. 1 logische denkfout in je rollover systeem en je hele DNS server om zeep.

Voor organizaties als SIDN of dns.be is het hun core business en deze zijn al sterk geautomatiseerd , hebben toegang tot up to date info , genoeg contacten binnen de DNS wereld , maar je moet bijna het wiel heruitvinden en genoeg tijd en budget voor krijgen om dat wiel mooi rond te krijgen.

Komt daar nog eens bij dat alle zones totaal onleesbaar worden op je servers met die NSEC3 en je moet al uit de Matrix komen om al het Chinees op je scherm te snappen. Zeker bij troubleshooting.

M.a.w. , ik stap van bind/Windows af en zal vertrouwen op een kant en klare oplossing van bijv. Infoblox of Men & Mice

[merlijn85]

Dat valt redelijk mee hoor, je moet die key rollovers uiteraard scripten - maar OpenDNSSEC heeft daar al redelijk wat kant en klare zaken voor. Je kunt ook bij SURFnet gaan kijken die ook DNSSEC al hebben geimplementeerd, en alles openbaar hebben gemaakt over hoe ze dat precies hebben gedaan.

Key rollovers zijn uiteraard een gevoelig onderwerp, maar de meeste keys hebben een lange expire time van bijvoorbeeld een week - en worden dan na 4 dagen al ververst. Logischerwijs moet je dan extern iets bouwen die ook continue je keys valideerd, maar als er iets mis gaat kan je altijd nog terug vallen op je 'oude' keys. Dan heb je nog 3 dagen om het probleem te verhelpen voordat je zone wegvalt van het internet.

[totaalgeenhard]

Voor organizaties als SIDN of dns.be is het hun core business en deze zijn al sterk geautomatiseerd

Uhm, SIDN had tot voor kort een COBOL achtig systeem. Het huidig systeem werkt een stuk beter maar handmatig iets doen bij SIDN (via webinterface) is een hel.

Om maar te zwijgen over DNS.BE bij elke update ben je uren aan het ploeteren omdat ze amper hun changes communiceren, laat staan zelf (vanuit registrar perspectief) testen.

Overigens is het wel vreemd, immers de grootste TLD's maken gebruik van een uniform systeem, terwijl Europese landen elk het wiel zelf trachten uit te vinden.

Zowel SIDN als DNS.BE luisteren niet naar hun primaire doelgroep, te weten hun registrars, laat staan dat ze die om advies vragen.

Zo achtte SIDN het onlangs nodig om een APP voor particulieren uit te brengen met functionaliteit waarover hun eigen registrars al niet over beschikken.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 00:30]

[arjankoole]

Zo achtte SIDN het onlangs nodig om een APP voor particulieren uit te brengen met functionaliteit waarover hun eigen registrars al niet over beschikken.

Bedoel je die app die een notificatie geeft als een domein weer vrij is? Dat is gewoon een app die puur checked op de expire date, en op die datum een in-app-notification laat uitvoeren.

Dat is functionaliteit die iedere deelnemer van SIDN heeft. (het heet outlook, ical, of zit ingebakken in hun eigen provisioning software)

SIDN luistert best aardig. Maar ze hebben meer belangen dan alleen de deelnemers, de commercieele belangen van de deelnemers. En dat botst nog wel eens.

[totaalgeenhard]

Zie nieuwsbrief van Verenging van registrars mbt APP.

Als SIDN zou luisteren hadden deze nieuwe vereniging er niet geweest en was alle commotie omtrent korting die ze aan de grootste partijen gegeven overbodig geweest.

Concurrentie vervalsing is niet iets wat je beoogd indien je eerlijke marktwerking nastreeft.

Wat dat aangaat is SIDN haar legitimiteit verloren en is het hoog tijd om rededelegatie verzoek bij ICANN in te dienen zodat belanghebbende (de registrars) het over gaan nemen.

[CAPSLOCK2000]

Die nsec3 dingen kun je 90% van de tijd volledig negeren. Overigens valt er aan al die lange strings niks te snappen. Het zijn digitale sleutels, meer hoef je niet van te weten. Dat het lange en lelijke strings zijn zou een ITer niet moeten afschrikken.

Je opmerking over rollovers klopt wel, dat gaat nog een probleem worden. Er is een hoop software om je te helpen, maar ook met die software er bij blijft het erg foutgevoelig.

[MPAnnihilator]

Nsec3 is als provider toch wel een must , tenzij je wil dat iedereen zomaar in 1 keer je volledig zones kan zien.

[CAPSLOCK2000]

Ach, een must zou ik het niet willen noemen. We doen het al 20 jaar zonder. Overigens is zelfs met nsec3 nog wel het een en ander mogelijk.

Ik wilde eigenlijk zeggen dat je in het dagelijks gebruik van DNSSEC niks met NSEC3 te maken hebt. Het wordt wel heel specialistisch als je daar echt iets mee doet. Zelfs bij het debuggen heb ik nog niet meegemaakt dat er meer nodig dan "is deze lange random string gelijk aan die andere of niet?"
Nu is dat al vervelend genoeg maar gelukkig zijn er tools die je er bij helpen.

[D11]

DNS hacking zal met DNSSEC dus neerkomen met het omleiden van de queries naar de root servers bijvoorbeeld door ip-spoofing. Dat is uiteraard niet makkelijk. Maar ook niet onmogelijk.

[CAPSLOCK2000]

Nee, dat klopt niet. Iedere client kent de key van de root. Die heb je gewoon in een file staan. Sommige moderne OS'en (zoals Debian) leveren die gewoon mee. Je client zal het dus onmiddelijk door hebben als je naar een andere root-server wordt omgeleid.

[sniek]

Ik vind in dat opzicht SMTP en HTTP ook niet bepaald veilig.

[The Zep Man]

Ik vind in dat opzicht SMTP en HTTP ook niet bepaald veilig.

HTTP wordt veel gecombineerd met SSL (HTTPS). SMTP tussen client en server kan ook via SSL (SMTPS). Echter, tussen mail servers wordt SMTP nog steeds onbeveiligd gebruikt. Een gebruiker kan de inhoud van mails beveiligen, maar niet de headers.

Hierdoor blijft het veelgebruikte protocol SMTP ook erg onveilig. Het is niet alleen DNS, hoewel DNS natuurlijk nog veel meer gebruikt wordt.

[Gert]

SMTP servers onderling kunnen ook gewoon tls gebruiken.

[webkiller71]

Helaas gebeurt dat weinig en je kunt ook nergens afdwingen dat het end-to-end secure getransporteerd wordt.

[arjankoole]

Helaas gebeurt dat weinig en je kunt ook nergens afdwingen dat het end-to-end secure getransporteerd wordt.

Competente mailservers kunnen dat wel degelijk afdwingen. En de meeste mailservers doen ook automatisch STARTTLS als ze zien dat het bij de capaciteiten staat.

[Supermario16]

Voor HTTP te beveiliging zijn certificaten (HTTPS) geïntroduceerd, ook SMTP kun je prima beveiligen door verkeer te encrypten met TLS of SSL. Voor DNS was er nog geen mogelijkheid tot beveiliging tot DNSSEC. M.a.w., als je HTTP of SNMP onbeveiligd kies je (of je ISP / provider) hiervoor

[mcboss1]

"Wie zijn eigen domein en dns beheert en niet kan wachten tot zijn registrar dnssec aanbiedt, kan zijn publieke sleutel tot de officiële introductie zelf bij de SIDN indienen."
Als ik een sleutel indien bij SIDN voor een bepaald domein, hoe verifieerd SIDN dat ik de eigenaar ben van dat betreffende domein? Moet ik bij SIDN langs en mij legitimeren?

[Precision]

Ik heb geen idee hoe ze te werk gaan maar een mogelijke oplossing is bijvoorbeeld:
Je geeft je domeinnaam op, het contact e-mailadres wordt opgezocht en er wordt een link verstuurt naar dat e-mailadres, via die link zet je je sleutel online.
Edit:
SIDN accepteert alleen verzoeken afkomstig van het bij de domeinnaam geregistreerde e-mailadres van een van de volgende personen:

• De registrant (houder) van de domeinnaam, of
• De registrar van de domeinnaam, of
• Een administratief contactpersoon (admin-c), of
• Een technisch contactpersoon (tech-c).

[Reactie gewijzigd door Precision op 23 juli 2024 00:30]

[jvo]

SIDN accepteert alleen verzoeken afkomstig van het bij de domeinnaam geregistreerde e-mailadres van een van de volgende personen:

Ik hoop het niet, gezien een afzenderadres vrij eenvoudig is te "spoofen". Daarbij komt dat de genoemde e-mailadressen vrij eenvoudig te achterhalen zijn via de registratieinformatie van het domein in kwestie.

[CAPSLOCK2000]

Ik heb het een paar keer gedaan.

1. je stuurt ze een mail met hun gegevens
2. zij bellen je op om de gegevens te controleren
3. zij sturen de eigenaar en de beheerders van het domein een e-mail. Die adressen hebben ze immers al in hun whois-database staan.
4. als alle partijen hun goedkeuring geven wordt je key geupload

[tikkietrugjaap]

Beetje misleidende titel als je het mij vraagt. Dacht namelijk eerst dat dnssec ook al niet meer goed was.

Wel een interessant artikel. Al moest ik wel vaak op de diverse links klikken om te even te zien wat het allemaal betekende.
Grappig dat er straks zo'n gefilmde ceremonie gehouden gaat worden bij het genereren van nieuwe sleutels. We gaan weer terug naar dagen dat de wacht heel plechtig wordt afgelost

[Wilbert de Vries]

Ik heb het woordje 'voor' in de titel toegevoegd in de hoop dat het meer duidelijkheid biedt.

[David Mulder]

Wow... o.O ik dacht dus hetzelfde als tikkietrugjaap zelfs nadat je 'voor' had toegevoegd (ook al vond ik het sowieso een te vreemde titel )

[mdavids]

mcboss1:

Zie: https://www.sidn.nl/over-nl/dnssec/friends-fans-fase/

En dan onderdaan doorklikken naar de details.

Overigens zal dit programma niet zo heel lang meer lopen.

[mcboss1]

dit is wat ik heb gevonden;
"Er wordt daarna telefonisch contact opgenomen met de aanvrager (via de in de Whois geregistreerde telefoonnummers) om de DNSKEY te verifiëren."

Ik vind dit een niet erg sterke methode van verificatie.

[CAPSLOCK2000]

Dat is niet de enige controle. Dat telefoontje is voornamelijk om te controleren of er geen fouten in de mail staan en of je wel weet waar je mee bezig bent.