SIDN ondertekent .nl-zone met dnssec-protocol

SIDN, de organisatie die het .nl-tld beheert, heeft het dnssec-protocol op de .nl-zone ingevoerd. Binnenkort kan worden gecontroleerd of antwoorden van de dns-servers van SIDN valide zijn, mits isp's het veiligere protocol hebben geactiveerd.

In december vorig jaar bleek dat SIDN van plan was om dnssec in augustus 2010 in te voeren; maandag maakte de organisatie bekend dat dit is gelukt. Dnssec is een aanvulling op het dns-protocol en is ontwikkeld om de kwetsbaarheden in dat protocol te verhelpen. Dnssec koppelt het antwoord op een dns-query aan een digitale handtekening, waardoor kan worden gecontroleerd of de antwoorden van een dns-server valide zijn. Daarmee moeten cache poisoning en man in the middle-attacks worden voorkomen.

Met dnssec worden dns-servers voorzien van public key cryptography. Met een private key worden domeinen ondertekend en met een publieke sleutel kan worden gecontroleerd of antwoorden van dns-servers valide zijn. Over enkele weken wordt de publieke sleutel van de .nl-zone gepubliceerd in de root-zone van het internet; vanaf dan kunnen dns-resolvers met ondersteuning voor dnssec controleren of antwoorden afkomstig zijn van de dns-servers van SIDN.

Volgens SIDN gebruiken op dit moment zeer weinig dns-resolvers het dnssec-protocol, maar de organisatie werkt samen met de isp's om dit te verbeteren. De ondertekening van de .nl-zone betekent bovendien nog niet dat dns-requests voor individuele domeinnamen kunnen worden gecontroleerd. Alle vier miljoen .nl-domeinnamen moeten nog worden gesigned, wat stapsgewijs zal gebeuren. Vanaf oktober mag een beperkt aantal domeinnaamhouders zijn publieke sleutels aanleveren, totdat het mogelijk is om alle domeinnamen te beveiligen. Volgens de stichting is dat ergens in 2011.

De dns-servers in de root-zone, die verwijzen naar de dns-servers van de tld's, zijn vorige maand al op dnssec overgestapt. De .nl-zone is na .org het grootste tld dat op dnssec overstapt. Andere grote tld's, zoals .com, .edu en .net, volgen later. De dns-servers van dns.be, de organisatie die het .be-domein beheert, zijn eerder deze maand met dnssec ondertekend.

Reacties (41)

[SirBlade]

IP6, DNSsec, heel veel mensen zullen de komende jaren nieuwe netwerkapparatuur moeten gaan kopen.

[Yggdrasil]

Het zijn beide zaken die in firmware kunnen worden opgelost en zal hoogstens leiden tot wat meer CPU gebruik. Hopelijk zijn fabrikanten niet te flauw om een update uit te brengen, maar ik ben er vooral bij consumentenapparatuur bang voor.

[SirBlade]

En de kans aan hun neus voorbij laten gaan om ons allemaal een nieuw device te verkopen? Dacht het niet.

[MClaeys]

zolang een toestel in de winkelrekken te vinden is zullen ze er wel een nieuwe firmware voor uitbrengen. En voor oudere toestellen zullen de meeste bedrijven dat ook doen.

[army]

Heb je een bron voor die informatie, want bij een recente ronde langs verschillende bedrijven werd aangegeven dit niet te gaan doen. Zelfs met de confrontatie dat er nog steeds producten in de schappen liggen die al sinds 2007 volgens de vendor niet meer worden ondersteunt als extreem voorbeeld.

Je hebt gelukkig bedrijven die het wel wat serieuzer aanpakken zoals AVM, maar hier zie je ook de oorzaak. Beperkte marktpenetratie en kosten van het device zijn van invloed op de ondersteuning van de leverancier. Ik gok dat ik er niet ver naast zit als ik zeg dat van zeg de 4 miljoen huishoudens er z'n 3,9 miljoen een nieuwe router mag kopen voor juist DNSSEC en IPv6. En misschien wel twee keer, want oa Netgear is niet de meest meewerkende partij als het aankomt op nieuwe firmware.

Het meest bereikbare en complete product voor de consument thuis komt bij AVM vandaan en zit duidelijk boven de modellen bij oa Mediamarkt qua prijs. De volgende stap is Cisco voor de professionele thuiswerker. Het gat is dus redelijk groot en ik verwacht de komende zeg vijf jaar ook voldoende horte en stoten op oa de Nederlandse Internet- en telefoniemarkt.

[MClaeys]

De overstap gebeurt natuurlijk niet van vandaag op morgen. Hier gaat een "lange" termijn over en in die termijn komen nu eenmaal nieuwe producten op de markt die wel toekomstgericht zijn en die het dus toch zullen ondersteunen. Redelijk wat mensen vervangen ook hun toestel in die termijn, puur omdat ze het te traag vinden of lelijk vinden of simpelweg omdat het stuk ging. Diegene die dat niet doen zullen ook echt niet van de ene dag op de andere uit de boot vallen.
Er zal uiteraard wel een moment komen dat ze dat wel doen, maar de personen die zo lang wachten zijn vaak onwetend, denken dat hun toestel stuk is en kopen dan een nieuw (of krijgen een nieuw van hun provider). Ze zijn dan alsnog tevreden over hun toestel want het heeft jaren goed dienst gedaan. (soms slechts maanden, maar dan hebben ze het bij een slechte winkel gekocht die hun niet op de hoogte bracht van de "niet-toekomstgerichtheid".

Zelf ben ik momenteel tevreden over mijn hardware, en aangezien mijn provider me telkens gratis een nieuwe modem opstuurt als er een nieuwer/beter model uitkomt zal ik waarschijnlijk nergens hinder van ondervinden (ze updaten de firmware ook zelf via hun netwerk). De enige "hinder" zijn telkens de "oudere" modellen, maar die verkoop ik dan of smijt ze weg.
+ van mijn routers die mijn intern dataverkeer afhandelen ben ik ook zeer tevreden over de ondersteuning

[Reactie gewijzigd door MClaeys op 23 juli 2024 00:50]

[Tomas_]

Er komen ip nummer bij ze worden niet vervangen door ip6 dus kan je oude apparatuur blijven werken

[Little Penguin]

IPv6 is een compleet ander protocol dan IPv4 en je kunt niet onderling routeren tussen deze 2 IP-standaarden. Voor iets als HTTP-verkeer zou je nog met proxies en dergelijke kunnen werken, maar voor directe TCP- of UDP-verbindingen zul je toch echt ook zelf een IPv6 adres moeten hebben.

Nu kan dit wel gecombineerd worden, zodat je zowel een IPv4 als ook een IPv6 adres hebt, maar of zoiets eenvoudig te realiseren is met de bestaande hardware... (ADSL-modem e.d.)

[mimic]

Sommige apparaten kunnen ook voorzien worden van een nieuwere firmware, die deze protocollen gaat ondersteunen.

Uiteraard zal dit niet zo gauw gebeuren, want dan verkopen ze geen nieuwe hardware meer.

[Little Penguin]

Mensen hebben ook met de overgang van analoog naar ISDN (dat is niet zo vaak gedaan door de normale consument) en van analoog naar ADSL (dat is veel vaker gedaan) nieuwe hardware moeten kopen.

Dit soort overgangen leveren weer een nieuwe investering op ja, maar je kunt dit natuurlijk ook combineren - zodat je in 1 keer een ADSL-router koopt die IPv6, DNSSec en mogelijk nog meer nieuwe protocollen ondersteunt...

Alleen als de broncode van de firmware beschikbaar is, kunnen mensen zelf gaan werken aan de implementatie - of het werk van anderen in de router flashen en als de leverancier natuurlijk gewoon nieuwe firmware levert is er ook weinig aan de hand (ook closed source dus). In beide gevallen hoef je geen nieuwe netwerkapparatuur te kopen...

[ajakkes]

Is de man in the middle attack na volledige invoering niet meer mogelijk?
Wat is het verschil in veiligheid tussen https en dnssec?

Jammer dat het nederlandse wiki artikel over dnssec niet bestaat.

[roeleboel]

met https zet je een beveiligde verbinding op met een host, maar je kan niet met zekerheid zeggen welke host, enkel dat de verbinding beveiligd is.

met dnssec krijg je zekerheid over de host waarmee je verbind.

De 2 technieken vullen elkaar dus aan.

Edit:
wat ik me afvraag:
regeringen werpen nogal eens graag blokkades op op dns-niveau om sites te blokkeren (kinderporno etc), is dat iets dat nog mogelijk is na invoering van dnssec?
mijn instinct zegt me dat dat niet mogelijk is, maar als het toch mogelijk is: hoe?

[Reactie gewijzigd door roeleboel op 23 juli 2024 00:50]

[ajakkes]

Dus als ik het goed begrijp:
Op het moment dat ik https://sidn.nl intoets vraagt de browser aan de dns van de isp welk nummer daarbij hoort. Als de isp een fout nummer doorgeeft omdat ie niet beter weet zit ik nog steeds op een foute site. Om te voorkomen dat de dns van mijn isp verkeerd is hebben ze DNSSEC bedacht.
Als ik van mijn isp het goede nummer doorkrijg zonder https gaat het later fout?

[Little Penguin]

Aangezien https://sidn.nl al gecontroleerd wordt is DNSSec daarvoor minder noodzakelijk, als je naar een verkeerde site gaat, klopt het certificaat niet - tenminste als de uitdelers van het SSL-certificaat deze alleen uitdelen aan sidn.nl. In 99.% gaat dit ook goed. En het gehele communicatie-kanaal is verder versleuteld bij HTTPS/SSL.

Echter, als jij nu naar http://tweakers.net gaat en er wordt een foutief antwoord teruggestuurd dan heb je geen extra controle, daar is DNSSec meer voor bedoeld.

[Reactie gewijzigd door Little Penguin op 23 juli 2024 00:50]

[Niemand_Anders]

Sorry? Ik kan bij elke SSL leverancier een certificaat voor sdin.nl krijgen. Officieel moet een SSL leverancier de bescheiden controleren, maar meestal is dit beperkt tot een belletje met een automatisch voice-resonse systeem.

Vervolgens heb ik dus een certificaat voor sdin.nl. Als ik dan ook nog bijvoorbeeld de DNS sever van bijvoorbeeld xs4all.nl weet te hacken, kan ik dus iedereen doorsturen. De browser ziet dat de url van de browser en het certificaat met elkaar overeenkomen en zal de website gewoon tonen.

Daarom zijn er ook de SSL certificaten met extended validation gekomen welke niet alleen de url bevatten, maar ook wie de eigenaar is van het domein. Bij verschillende browsers wil ook de adresbalk van kleur veranderen afhankelijk van welke certificaat een website heeft.

DNSSEC geeft een digitale handtekening bij elke response mee. De public key staat ook in de zone (waar ik liever had gezien dat de public key in de gegevens van sdin.nl had gestaan). De DNS server gebruikt een private key om het antwoord te ondertekenen. Middels de public key kun je controleren of de handtekening correct is.

Bind 9.3, Windows 7 en Windows Server 2008 R2 hebben support voor DNSSEC. En daar zit best wel een groot probleem. Het gros van de gebruikers heeft nog een dns client welke geen support heeft voor DNSSEC. Het zal dus nog wel een aantal jaren duren voordat DNS forgeries tot het verleden behoren.

Echter zou het mij het verbazen dat de focus van DNS forgery zal verplaatsen naar het hacken van Bind installaties. Immers als je de zone op de originele dns server weet aan te passen, heb je je doel ook bereikt. Bind wordt door meer dan 85% van de DNS servers gebruikt. Echter is Bind helaas nou niet de meest veilige DNS server..

[robvanwijk]

Bind 9.3, Windows 7 en Windows Server 2008 R2 hebben support voor DNSSEC. En daar zit best wel een groot probleem. Het gros van de gebruikers heeft nog een dns client welke geen support heeft voor DNSSEC. Het zal dus nog wel een aantal jaren duren voordat DNS forgeries tot het verleden behoren.

Even uit mijn hoofd: XP is uit zijn (extended) support, Vista zit nog wel in zijn supportfase. Oftewel, het is extreem onwaarschijnlijk dat XP-gebruikers ooit dnssec zullen kunnen gebruiken, maar het is goed mogelijk dat er binnenkort een update voor Vista uitkomt die dnssec toevoegt. Ja, er zitten nog steeds mensen op XP, maar het worden er alleen maar minder.
Een groter probleem lijkt me dat veel thuis-routers óók DNS-server spelen. Als je die niet update dan heeft het weinig zin dat de bakken op je thuisnetwerk dnssec ondersteunen; als je router het niet spreekt kunnen ze het toch niet gebruiken.

[ajakkes]

"Slechts" 55% van de gebruikers gebruikt WinXP. Dit is het afgelopen half jaar met 5% gedaald.

Windows Vista gebruik zit op 10% en is ook al dalende.
Windows 7 zit op 20%

Het poison-en van een isp dns server is denk ik veel interessanter dan het poisonen van een router van een thuisgebruiker. Als ik het protocol een beetje begrijp is het belangrijk dat hoe meer gebruikers van de dns server gebruik maken hoe belangrijker het is. Hoe interessanter het is om te poison-en. Maar ik kan het mis hebben.

Daarbij, zit de dns client in het os of in de browser?

[kluyze]

dnssec is als ik het goed om er zeker van te zijn dat de dns server waar je mee spreekt een valide server is. Je kan dan nog op de dns server de records aanpassen zodat die sites naar een ip adres van de overheid of zo geleid worden.

@CyBeR; mijn vergelijking met https was wat mis, maar ik doelde op het feit dat je net als bij https een manier hebt om de server antwoorden van de server te valideren zoals een digitale handtekening of certificaat.
Voor de rest reageerde ik op zijn vraag of overheden een beveiliging op dns niveau kunnen implementeren. Als een overheid een record aanpast en deze digitaal laat tekenen dan kan er toch gewoon een blokkade opgezet worden lijkt me.

[Reactie gewijzigd door kluyze op 23 juli 2024 00:50]

[CyBeR]

dnssec is als ik het goed om er zeker van te zijn dat de dns server waar je mee spreekt een valide server is. Zoals https, maar dan zonder het http protocol. Je kan dan nog op de dns server de records aanpassen zodat die sites naar een ip adres van de overheid of zo geleid worden.

Bijna. DNSSEC stelt je in staat te verifieren of het antwoord dat je kreeg (www.bla.com -> 1.2.3.4) klopt met wat de beheerder van bla.com wil dat jij krijgt. Dus het is dan juist niet mogelijk om op een tussenliggende DNS server het antwoord aan te passen. Nou ja je kunt 't wel aanpassen maar dan klopt de signature dus niet meer en zou de client 't antwoord moeten negeren.

@CyBeR; mijn vergelijking met https was wat mis, maar ik doelde op het feit dat je net als bij https een manier hebt om de server te valideren zoals een digitale handtekening of certificaat.
Voor de rest reageerde ik op zijn vraag of overheden een beveiliging op dns niveau kunnen implementeren.

Maar dat is nog steeds fout want je valideert niet de server, maar het antwoord. DNS werkt niet zoals https dat je meteen tegen de bronserver aanpraat (nou ja, meestal). Dat antwoord moet dus langs verschillende resolvers getransporteerd worden. Die servers zijn niet boeiend, het antwoord zelf wel.

En aangaan de overheden: natuurlijk kan op de bronserver het antwoord dat je gaat krijgen aangepast worden. Daar is immers de info bekend om de DNSSEC signature weer te laten kloppen. Maar dat is niet wat er gebeurt bij het aanpassen van DNS-antwoorden. Dat gebeurt op resolvers. Vladimir Kinderpornoboer in de Oekraïne gaat echt zijn dns server niet aanpassen omdat de Nederlandse overheid dat vraagt.

[Reactie gewijzigd door CyBeR op 23 juli 2024 00:50]

[kluyze]

Kan het niet zijn dat bv bij SIDN een record kan aangemaakt worden en dat dit op hun servers ondertekend kan worden? Is het niet mogelijk om een server te configureren dat die wel alle .net aanvragen doorgeeft maar dat bepaalde records van de eigen server komen en dan ook getekend worden?

Een dns server gaat toch eerst kijken of hij zelf het record heeft en indien nodig (niet aanwezig/vervallen) hogere servers raadplegen of ben ik daar zo mis in. De bind install op mijn netwerk doet dit anders wel.

[Reactie gewijzigd door kluyze op 23 juli 2024 00:50]

[robvanwijk]

En aangaan de overheden: natuurlijk kan op de bronserver het antwoord dat je gaat krijgen aangepast worden. Daar is immers de info bekend om de DNSSEC signature weer te laten kloppen. Maar dat is niet wat er gebeurt bij het aanpassen van DNS-antwoorden. Dat gebeurt op resolvers.

Maar dan kan SIDN toch nog wel beweren "dat domein bestaat niet"? Dat antwoord kun je moeilijk verifiëren met de key van de eigenaar, want die is er niet... Ik heb weinig kaas gegeten van dnssec, dit is vooral speculatie / interesse.

[CyBeR]

[...]

Maar dan kan SIDN toch nog wel beweren "dat domein bestaat niet"? Dat antwoord kun je moeilijk verifiëren met de key van de eigenaar, want die is er niet... Ik heb weinig kaas gegeten van dnssec, dit is vooral speculatie / interesse.

Dat is gewoon het opheffen van een domein en dat kan natuurlijk altijd. Maar dat is wat overdreven.

Maar je bovenbuurman maakt een heel goed punt, waarvan ik eigenlijk vermoed dat 't best zou kunnen werken, al ben ik er niet zeker van.

De andere optie van blokkeren als dat niet kan, is gewoon de resolvers in plaats van een ander antwoord terug geven gewoon geen antwoord te laten geven bij bepaalde queries. Dus 'www.schattigekonijntjes.com -> 1.2.3.4' (met dnssec en weetikhet) en 'www.stopkindersex.nu -> NXDOMAIN'.

[Shaflic]

Daarvoor is NSEC in het leven geroepen. SIDN signeert met NSEC3 wat een verifieerbaar "dat domein bestaat niet" respons kan geven. Voordeel van NSEC3 boven NSEC is dat de zone niet geënumereerd kan worden.

[ASS-Ware]

met https zet je een beveiligde verbinding op met een host, maar je kan niet met zekerheid zeggen welke host, enkel dat de verbinding beveiligd is.

met dnssec krijg je zekerheid over de host waarmee je verbind.

Ik denk dat het iets anders zit.
Met dnssec weet je dat het IP adres van de opgezochte DNS naam klopt en met SSL weet je met welke host je verbonden bent, omdat het SSL certificaat de DNS naam bevat.

[lenwar]

Met https kan je bevestigen dat je verbind met een host van een bepaalde organisatie. Het certificaat is immers ondertekend door een toko die jouw organisatie controleert (In het geval van Extended Validation natuurlijk).
Je kan daarmee dus bevestigen dat het bedrijf waarmee je verbind daadwerkelijk je bank is of niet via het certificaat.
En daarnaast wordt er ook nog een beveiligde verbinding opgezet.

Met dnssec wordt aan de DNS-server van je ISP bevestigd dat hij de juiste gegevens heeft gecached (omdat de handtekening wordt bevestigd bij de betreffende autoriteit, en daarmee een man-in-the-middle attack onmogelijk zou moeten maken)

[.oisyn]

Bij SSL (HTTPS) wordt de data zelf geëncrypt, zodat je die niet kunt afluisteren omdat je de privésleutel van de ontvanger niet hebt. Bij DNSSec wordt een digitale handtekening gebruikt waarbij de data zelf niet geencrypt wordt, maar de hash van de data. De ontvangende partij kan de authenticiteit controleren door de geencrypte hash te decrypten met de publieke sleutel van de verzender, en dat vervolgens te vergelijken een eigen berekende hash van het bericht. Een man in the middle kan het bericht niet forgen omdat hij niet over de privésleutel van de verzender beschikt (en dus kan hij de hash van het aangepaste bericht niet encrypten).

[Shaflic]

Een wiki artikel mag dan niet bestaan, maar zelf kan ik het één en ander van de wiki op www.dnssec.nl halen: Wiki

[Maxxi]

Https versleuteld geen DNS requests.
Daardoor weet je dus nooit zeker of de server waar je https mee spreekt ook wel echt je bank is.

[corl]

Als je daar over nadenk wordt het tijd dat we weer ip nummers gaan gebruiken ipv dns namen. Je weet namelijk nooit of je dns lookup wel door een juiste betrouwbare dns server is behandeld. Misschien heeft een virus mijn dns server instellingen wel gewijzigd naar een of andere Chinese server zodat https://www.ing.nl ook ergens in china uitkomt... Lekker veilige verbinding met je bank

[CyBeR]

Als je daar over nadenk wordt het tijd dat we weer ip nummers gaan gebruiken ipv dns namen. Je weet namelijk nooit of je dns lookup wel door een juiste betrouwbare dns server is behandeld.

En daar is DNSSEC dus tegen bedacht.

[.oisyn]

Dat kan dus niet, omdat HTTPS werkt met trusted authorities. Bij een HTTPS request wordt namelijk ook een certificaat van het domein opgevraagd, wat gekoppeld is aan het ip-nummer. Deze certificaten zijn digitaal ondertekend door bepaalde instanties (zoals Verisign) en zijn dus (in principe) niet te vervalsen. Als je DNS is gekaapt zodat www.ing.nl ergens in China uitkomt krijg je van je browser een melding dat het certificaat niet klopt, danwel omdat het domein niet overeenkomt met het ip, danwel omdat de uitgever van het certificaat niet bekend is bij de browser.

Hier een voorbeeld waarbij het certificaat niet overeenkomt met het domein, kijk maar wat je browser zegt: https://oisyn.nl/

DNSSec is juist van belang voor normale HTTP verbindingen, waarbij er niet met certificaten wordt gewerkt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:50]

[ASS-Ware]

Dat kan dus niet, omdat HTTPS werkt met trusted authorities. Bij een HTTPS request wordt namelijk ook een certificaat van het domein opgevraagd, wat gekoppeld is aan het ip-nummer.

Sorry, maar dat klopt helaas niet.
Het certificaar bevat de DNS naam, niet het IP adres.

[.oisyn]

Ik zeg toch ook helemaal niet dat het ip adres in het certificaat staat? Ik zeg dat het gekoppeld is aan het ip adres. Oftewel, de browser vraagt het certificaat op aan de hand van het ip, en kan vervolgens kijken of de hostname in het certificaat overeenkomt met de daadwerkelijke hostname.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:50]

[Yggdrasil]

Het hele DNSSEC verhaal speelt zich af vóórdat de HTTPS verbinding wordt opgezet. Het zijn twee verschillende zaken.

Om überhaupt contact te kunnen maken met www.ing.nl moet de browser eerst weten welk IP-adres er bij die naam hoort. Daartoe wordt een DNS resolver gebruikt, en tijdens dat proces kan DNSSEC gebruikt worden om te verifiëren dat het DNS antwoord van een legitieme DNS server komt. Niet meer en niet minder. DNSSEC zegt niks over wie de eigenaar van een domein of IP-adres is, maar alleen dat de juiste DNS servers hebben geantwoord, en dus dat de je het IP adres te zien krijgt dat de eigenaar van het domein je wilt laten zien.

Daarna maakt je browser verbinding met het IP-adres wat in de vorige stap is verkregen en begint te onderhandelen over een HTTPS verbinding. Het SSL certificaat van de server is gekoppeld aan de domeinnaam, dus weet je dat de site die je op je scherm ziet ook echt hoort bij de domeinnaam in je adresbalk. Met de 'luxere' EV-SSL certificaten wordt er zelfs gecontroleerd welke organisatie het certificaat aanvraagt.

Het zijn dus meerdere beveiligingslagen, maar ze hebben niet direct met elkaar te maken.

[Verwijderd]

Mooi nu nog wachten op de rest van de wereld.

[Verwijderd]

Fipo? de rootservers zijn al over.

[Hadron]

De root-servers wel ja, maar als de servers voor .com en .net nog niet over zijn, schiet je daar weinig mee op.

Edit: Desalniettemin, het is mooi dat het SIDN en dns.be al over zijn. Het is altijd fijn om het goede voorbeeld te kunnen geven. Ik vraag me overigens wel af wat de impact is qua bandbreedte en server-load bij sidn.

[Reactie gewijzigd door Hadron op 23 juli 2024 00:50]

[Shaflic]

Afhankelijk van hoeveel domeinen er gesigned zijn binnen de .nl zone zal de impact op de bandbreedte flink op kunnen lopen. Op dit moment is de .nl zone gesigned, maar nog geen domeinen, dan valt de impact nog mee.

Het gaat ook impact hebben op resolvers, want de NSEC3 techniek die gebruikt wordt om "domein-bestaat-niet" antwoorden te geven gebruikt hashing. Dit betekent dat de resolvers ook moeten hashen om antwoorden te vergelijken. Hier heeft SIDN echter rekening mee gehouden door de hashing niet absurd zwaar te configureren.

[Lord Anubis]

Hoe zit het met load balancing van een site?
Wat als ik drie servers heb draaien voor het zelfde domein?

Wat als je van adres veranderd als je b.v een IP6 krijg?
Of wat als je bv. een IPv4 en een IPv6 heb?

[CyBeR]

Hoe zit het met load balancing van een site?
Wat als ik drie servers heb draaien voor het zelfde domein?

Wat als je van adres veranderd als je b.v een IP6 krijg?
Of wat als je bv. een IPv4 en een IPv6 heb?

Dat alles heeft niets met dnssec te maken.