Het grote DNSSEC-topic

[CAPSLOCK2000]

Domain Name System Security Extensions

DNS is het telefoonboek van internet en DNSSEC is de beveiliging die daar bij hoort. DNSSEC is een vrij nieuw systeem dat pas sinds 2009 in opmars is. DNSSEC is in Nederland explosief gegroeid maar er is nog maar vrij weinig kennis en ervaring beschikbaar. In dit topic kunnen we praten over onze ervaringen.

Achtergrond DNS

DNS is het telefoonboek van internet. Als je een website bezoekt zal je computer DNS gebruiken om te leren hoe die website bereikt kan worden. DNS moet je van rechts naar links lezen. Als je naar www.voorbeeld.com gaat dan zal je computer eerst .com opzoeken, daarna voorbeeld, en als laatste www.

Achtergrond DNSSEC

DNSSEC moet er voor zorgen dat DNS te vertrouwen is zodat je zeker weet dat je de juiste informatie krijgt. Zonder DNSSEC is het mogelijk om DNS te onderscheppen en te manipuleren wat de deur open zet voor allerlei vormen van misbruik. Zo kun je telebankiers naar een valse website sturen, e-mail onderscheppen of zoekopdrachten manipuleren.
Sinds een paar jaar wordt er daarom gewerkt aan de uitrol van DNSSEC en de resultaten beginnen nu zichtbaar te worden.

Techniek

DNSSEC werkt door een digitale handtekening toe te voegen aan ieder stuk informatie dat in DNS staat. (Zo'n stuk informatie heet een "resource record"). Er wordt een Public Key Infrastructure gebouwd bovenop het bestaande DNS. Een digitale handtekening is een bewijs dat informatie niet is veranderd. Met behulp van digitale sleutels kun je handtekeningen zetten en controleren.

Voor ieder domein wordt er een digitale sleutel aangemaakt waarmee een handtekening wordt gezet onder alle DNS-records in dat domein. De digitale sleutel bewijst de echtheid van die handtekeningen. Je moet dan wel de digitale sleutel hebben en de echtheid daar van controleren. Daartoe worden die sleutels zelf ook in DNS gezet.

Om de echtheid te bewijzen laat je jouw sleutels ondertekenen door een betrouwbare partij. Gelukkig is er voor ieder domein een betrouwbare partij, namelijk het bovenliggende domein. Als je naar voorbeeld.com gaat zoekt je computer immers eerst '.com' op. Als dat al niet te vertrouwen is, dan heeft het ook geen zin om verder te gaan. Je kan dus prima informatie over 'voorbeeld.com' opslaan in '.com' . Informatie over 'www.voorbeeld.com' kun je dan weer mooi kwijt in 'voorbeeld.com'.

Zo schuift het probleem dus steeds een stukje op tot alles op één punt samen komt:

• 'www.afdeling.voorbeeld.com' controleer je met 'afdeling.voorbeeld.com'.
• 'afdeling.voorbeeld.com' controleer je met 'voorbeeld.com'.
• 'voorbeeld.com' controleer je met '.com'.
• '.com' controleer je met '.' .

Dat laatste punt heeft ook weer een digitale handtekening. Om die te controleren heb je de bijhoorende digitale sleutel nodig. Als je een moderne DNS-resolver download krijg je die key er bij. In de toekomst zal die sleutel in je OS worden opgenomen net zoals we dat ook met SSL-certificaten doen.

Servers

Er zijn twee soorten DNS-servers. 'Authorative' servers bieden informatie aan. 'Resolvers' zoeken deze informatie op en geven het antwoord door aan de opvrager. DNSSEC moet je aan beide kanten implementeren. De handtekeningen die je maakt worden door de authorative servers gepubliceerd. De resolvers moeten op hun beurt die informatie weer controleren. Dat noemen we valideren.

DNSSEC vorderingen

Ondanks dat DNSSEC pas sinds 2010 actief is doet een flink deel van Internet al mee:

• 30% van de top-level-domains gebruikt DNSSEC (.com, .net, .nl, .edu, .gov, ...).
• 1% van de second-level-domains gebruikt DNSSEC (sidn.nl, whitehouse.gov, google.com, etc...).
• 30%(!) van .NL gebruikt DNSSEC.
• 10% van de eindgebruikers is beveiligd met DNSSEC.

DNSSEC is nogal top-down. Je kan er niet veel mee tot het domein boven je ook meewerkt. Het is dus logisch dat de uitrol bij de TLDs verder is dan bij de onderliggende domeinen. Alle belangrijke TLDs ondersteunen het nu maar daaronder begint het pas net op gang te komen, met een paar uitzonderingen.

De grote uitzondering daarop is Nederland. Dankzij slimme stimulering van SIDN hebben de grootste aanbieders van Nederland DNSSEC massaal aangezet. Waar .com zo'n kwart miljoen ondertekende domeinen heeft is het in .nl al meer dan anderhalfmiljoen. NL is daarin groter dan de rest van de wereld samen. Vergelijk:


Verschillende nationale overheden (waaronder NL en de VS) hebben DNSSEC min-of-meer verplicht gesteld voor overheidsdomeinen.

Aan de kant van de resolvers is het beeld vergelijkbaar. Wereldwijd heeft een klein percentage van de resolvers DNSSEC aan staan met één grote uitzondering die het hele wereldbeeld bepaald: Google. Google heeft een publieke DNS-resolver die door bijna 10% van de wereld gebruikt wordt. Deze DNS-resolver heeft DNSSEC aan staan waarmee in één klap zo'n 10% van de wereld beveiligd is.

Vergelijkingen

DNSSEC vs HTTPS/SSL

DNSSEC wordt wel eens vergelijken met HTTPS en/of SSL. Eigenlijk is dat appels met peren vergelijken. Deze systemen lossen verschillende problemen op en vullen elkaar aan maar het zijn geen alternatieven, je hebt allebei nodig.

• DNSSEC heeft aan één handtekening genoeg hebt om het hele systeem te controleren. SSL heeft honderden CA's met eigen handtekeningen.
• Iedere SSL-CA kan een certificaat maken voor voorbeeld.com . In DNSSEC kan alléén .com zorgen voor de beveiligingen van voorbeeld.com .
• Een SSL(EV) certificaat garandeert iets over de eigenaar. Er wordt (in theorie) gecontroleerd of jij wel legitieme eigenaar van een domein bent (in praktijk valt die controle nogal tegen). DNSSEC doet hier geen beloftes over en kijkt alleen naar de techniek.
• SSL beveiligt tegen afluisteren, DNSSEC niet, alles gaat in cleartext over het netwerk.
• DNSSEC-informatie kan gecachte en gedeeld worden tussen verschillende gebuikers. SSL sessies kun je niet delen.
• SSL wordt door de applicatie gedaan, DNSSEC door de resolver. Applicaties kunnen SSL slecht implementeren of fouten negeren. We klikken dus massaal HTTPS-waarschuwingen weg. DNSSEC wordt door je DNS-resolver gedaan. Op applicatieniveau hoef (en kan) je niks doen.

DNSSEC vs DNS

Ook dit is een beetje een valse vergelijking, DNSSEC verandert namelijk niks aan het bestaande DNS-systeem maar voegt er alleen maar aan toe, maar er is één fundamentele verandering. Vroeger was DNS een onveranderlijk en simpel systeem. Eenmaal geinstalleerd had je er geen omkijken meer naar. DNSSEC handtekeningen zijn echter maar beperkt geldig. Je hebt een stuk software nodig dat die handtekeningen regelmatig ververst. Die software kan zelfstandig zijn (zonesigner, OpenDNSSEC) of deel van je DNS-server (Bind, PowerDNS). Daarnaast is het gebruikelijk om regelmatig de digitale sleutels te vernieuwen en die door te geven aan je registrar.

Verhuizen

Het (veilig) verhuizen van DNSSEC-domeinen is een kunst op zich. Vroeger was het genoeg om een transfer-code door te geven. Tegenwoordig moet je elkaars sleutels tekenen. Doe je dat niet dan gaan dingen afschuwelijk fout. Vergelijk het met de verkoop van een auto. Als je de sleutel hebt kun je met een auto weg rijden, maar als je de papieren niet laat omzetten anders heb je een probleem bij de eerste de beste verkeerscontrole.
SIDN werkt aan een systeem om dit te vereenvoudigen.

• DNS: fire & forget, DNSSEC: regelmatig onderhoud nodig
• DNS: alleen contact met registrar bij verhuizingen, DNSSEC: jaarlijks sleutel vervangen
• DNS: verhuizen domeinen simpel, DNSSEC: verhuizen enorm ingewikkeld.
• DNS: makkelijk te manipuleren
• DNSSEC: "het gevraagde antwoord bestaat niet". DNS: "ik weet het niet, maar misschien het ander wel"

Misverstanden

DNSSEC kun je veilig negeren

Voor aanbieders van DNS is DNSSEC niet te negeren. Als je niks doet kom je in de problemen zodra je domeinen gaat verhuizen. Je hoeft niet mee te doen, maar dan moet je het uitschakelen. Je kan het niet negeren. Als je dat wel doet dan kan 10% van de wereld je domein niet meer bezoeken, waaronder Google. Niet in Google staan is voor de meeste websites funest.

DNSSEC is in de eerste plaats een technisch probleem

De techniek is niet het probleem, die werkt wel. Voor DNSSEC heb je echter procedures nodig om digitale sleutels aan te maken, op te slaan en uit te wisselen. Dat is meer een kwestie van beleid dan van techniek. Een digitale handtekening maken is makkelijk maar er ook aan denken om 13 keer per jaar een sleutel te wisselen past niet in de huidige DNS-workflow.

DNSSEC beschermt tegen afluisteren / internetblokkades

DNSSEC is net zo makkelijk af te luisteren en te blokkeren als gewone DNS, daar helpt het niet tegen. Tegen afluisteren wordt dnscrypt ontwikkeld.
Blokkades en manipulatie van DNS-pakketjes kun je niet voorkomen maar je kan wel detecteren dat de informatie die je krijgt niet klopt of niet compleet is. Je kan het dan opnieuw proberen bij een andere DNS-server.

Goodies

DNSSEC is op zichzelf al heel nuttig maar er zijn meer applicaties die kunnen profiteren van een vertrouwbare gedistribueerde database.

IPSEC

IPSEC is een systeem om ip-verbindingen te beveiligen. Net als DNSSEC werkt het met digitale sleutels. Die sleutels moet je dan wel veilig kunnen uitwisselen, en dat kan nu via DNS.

SSHFP

SSHFP publiceert de fingerprints van een SSH-server via DNS. Zo kun je bij de eerste verbinding al controleren of je met de juiste server van doen hebt. Dat kan al langer, maar nu kan het ook veilig. OpenSSH kan zelf controleren of je DNSSEC-ondersteuning hebt en daar dan gebruik van maken.

DANE

De meest spraakmakende toepassing van DNSSEC is wel DANE (DNS-based Authentication of Named Entities). DANE is een alternatief voor de CA's die SSL gebruikt. SSL maakt gebruik van "trusted third parties". Een partij die instaat voor de echtheid van een stel SSL-certificaten. Er zijn zo'n 600 CA's in de wereld die je blind moet vertrouwen. Één rotte appel brengt het hele systeem aan het wankelen. In Nederland hebben we Diginotar gehad. Ik vrees dat in andere delen van de wereld de situatie nog veel slechter is. CA's vragen geld voor hun diensten. Je kan wel je eigen certificaat uitgeven (een zgn. "self signed certificate") maar dan krijgen je bezoekers zo'n HTTPS-waarschuwing.
DANE maakt het mogelijk om SSL-certificaten te controleren via DNS. Je neemt het hele proces zelf in handen en bent alleen nog afhankelijk van je registrar, maar daar was je toch al van afhankelijk. Het nadeel van dit systeem is wel dat je helemaal afhankelijk wordt van DNS en er zijn veel meer slechte registrars dan er CA's zijn.

Mail

Bij DANE denken de meeste mensen in de eerste plaats aan HTTPS. Er kan misschien nog wel meer winst worden gemaakt als het om e-mail gaat. E-mail wordt van server naar server doorgestuurd. Daarbij wordt er vaak wel gebruik gemaakt van SSL maar eigenlijk niemand controleert die certificaten ooit. Bij een webbrowser kun je nog een pop-up maken en het aan de gebruiker vragen, maar een mailserver kan dat niet (die hangt immers in een datacenter zonder dat er een mens in de buurt is). Mailservers accepteren dus maar alle SSL-certificaten, hoe rot ze ook zijn. DANE zou dat kunnen verbeteren.

Gouden tip

Als er één ding is wat je onthoudt over DNSSEC, laat het dan de website http://dnsviz.net zijn. Deze website helpt je bij het analyseren en debuggen van DNSSEC.

[CAPSLOCK2000]

DNSSEC bestaat uit twee delen, enerzijds het publiceren van DNSSEC-sleutels en handtekeningen en anderszijds en het opvragen en controleren daarvan. Dat laatste noemen we valideren.

DNSSEC voor luilakken

Valideren

De makkelijkste manier om DNSSEC te testen is het niet zelf te doen maar kant en klare servers te gebruiken. Google biedt publieke DNS-resolvers aan met DNSSEC ondersteuning. Gebruik daarvoor 2001:4860:4860::8888 en/of 8.8.8.8 als enige DNS-server(s). Ga dan naar http://dnssectest.sidn.nl/ en doe de test om te kijken of het werkt.

Publiceren

Er zijn flink aantal commerciele DNS-aanbieders die DNSSEC ondersteunen. Met name in Nederland zijn er al veel die het kunnen. Er zijn al een paar grote webhosters die het standaard aanzetten, met een beetje zoeken kun je ze zo vinden.

DNSSEC voor tweakers

Valideren

Om je eigen resolver te laten valideren heb je een kopie van de root-key nodig, ook wel 'anchor' genoemd. Dat anchor is te downloaden bij IANA maar als je een recente DNS-resolver hebt dan zit er waarschijnlijk al een anchor bij. Debian/Ubuntu-gebruikers, installeer het pakket 'unbound-anchor'.

code:

auto-trust-anchor-file: "/etc/unbound/root.key"

code:

options {
     dnssec-enable yes;
     dnssec-validation yes;
};

DNS-server herstarten en klaar is Henk. Simpel toch?

Publiceren

Om je eigen domein te publiceren moet je een paar dingen doen.

1. Keys aanmaken
2. Handtekeningen maken voor alle records je domein
3. (Hash van) je publiek sleutel uploaden naar je registrar
4. Zorgen dat die handtekeningen regelmatig ververst worden.

Die laatste stap is de allerbelangrijkste. Zo belangrijk dat ik hier geen kant en klare configuraties ga geven, want dat geeft alleen maar brokken. Maar ik kan wel wat scenarios bespreken.

dnssec-tools

De meest eenvoudige optie is dat je met dnssec-keygen sleutels aanaakt en dan dnssec-signzone gebruikt om alle records in je zonefile te ondertekenen. Deze ondertekende zonefile laat je dan door je DNS-server publiceren in plaats van de oude zonefile. Vervolgens maak je een cronjobje om de handtekeningen regelmatig op nieuwe te maken en dan je DNS-server te herladen.

OpenDNSSEC

OpenDNSSEC is een manager voor DNSSEC. ODS maakt keys voor je aan, ondertekent je zones en communiceert met je DNS-server. Het houdt ook bij wanneer het tijd is om opnieuw te ondertekenen en kan je berichten als er menselijk ingrijpen vereist is. Het is wat meer werk om het te installeren dan dnssec-tools maar daarna krijg je er vele gemak voor terug.

Autosigning

Sommige DNS-servers zoals Bind en PowerDNS kunnen zelf DNSSEC-handtekeningen maken wanneer dat nodig is. Dat is bv handig als je geen statische zonefile hebt, maar ook een dyanmische database als backend gebruikt.

Sleutel uploaden

Nu moet je nog (een hash van) de sleutel laten publiceren door je registrar. Hoe dat gaat verschilt van leverancier tot leverancier. Een veel gebruikte standaard hiervoor is EPP.

Diversen

Controleren

Ga naar http://dnsviz.net en laat je eigen site analyseren.

Monitoren

Als laatste is het belangrijk dat je in de gaten houdt of alles blijft werken. Denk er aan dan DNSSEC-handtekeningen verlopen. Ook al werkt het nu goed, over twee weken kan het zijn verlopen. Zorg dus dat je domeinen automatisch worden gemonitored.

Hoeveel sleutels heb ik nodig? aka KSK en ZSK

In bovenstaande verhaal heb ik gedaan als of er 1 digitale sleutel is. Dat klopt niet, in praktijk zijn het er minstens twee maar meestal vier. Soms worden er dan ook nog wat reservesleutels gepubliceerd voor toekomstig gebruikig.
PKI
Digitale sleutels komen altijd in setjes van twee, een prive-sleutel en een publieke-sleutel. De prive-sleutel hou je geheim en gebruik je zelf om handtekeningen mee te maken, de publieke sleutel publiceer je en wordt gebruikt om jouw handtekeningen te controleren. Zie het hoofdstuk PKI in een handboek over cryptografie voor meer informatie.
ZSK & KSK
Cryptografie is een trade-off tussen gemak en veiligheid. Om die twee beter af te stemmen wordt er gebruik gemaakt van twee setjes sleutels. De Zone Signing Keys en de Key Signing Keys. De ZSK gebruik je om handtekeningen te zetten, maar je upload deze sleutel niet naar je registrar. In plaats daarvan upload je de KSK, en gebruikt de KSK om de ZSK te beveiligen. Nu kun je de ZSK zo vaak vervangen als je wil zonder een nieuwe key naar je registrar te uploaden. (Dat geeft alleen maar risico op fouten).
Het voordeel van vaak een key wisselen is dat je niet zo'n zware cryptografie nodig hebt en dat houdt de boel snel.

Verhuizen

Let op bij het verhuizen van domeinen. Een domein verhuizen zonder de DNSSEC-beveiliging te doorbreken is best pittig. In praktijk wordt DNSSEC meestal uitgeschakeld tijdens het verhuizen. Veruit het meest voorkomende DNSSEC-probleem is dat domeinen worden verhuisd zonder dat de DNSSEC-informatie wordt geupdate. In een cynische bui noem ik het wel eens 'vendor lock-in' voor DNS-boeren.

[ Voor 122% gewijzigd door CAPSLOCK2000 op 28-07-2013 21:31 ]

[Osiris]

Leuke post!

Alleen ben ik ook heel erg benieuwd naar je "ik heb een domein en wil DNSSEC!"-stukje

[webfreakz.nl]

DNSSEC is interessant, tot op zekere hoogte. Maar hoe weet je DNS client dat je Resolving server wel een legitiem antwoordt geeft? Voor zover ik DNSSEC ken, kan je client dat niet controleren. De controles vinden plaats tussen de Authoritative / Resolving nameservers en niet je client (PC / tablet / etc). Tuurlijk moet je een DNS server instellen die je vertrouwt, maar wie zegt dat de Google DNS niet ooit gekaapt wordt met een MITM attack? Als we het toch over security hebben: BGP Path / Origin validiation is ook (nog) niet breed geimplementeerd.. Daarnaast mis ik SSHFP checking in PuTTY, en helaas zijn ze daar zelf ook nog niet over uit: http://www.chiark.greenen...y/wishlist/sshfp-dns.html .

[Kompaan]

Ik moet zeggen dat ik DNSSEC ook wel interessant/belangrijk vindt, maar zelf gebruik ik gewoon TransIP, die regelt dit allemaal voor mij, voor een paar euro per jaar.

Ligt het aan mij of zou elke "DNS boer" dit moeten bieden?

[Midas.e]

Moeten ja, maar het is niet zo makkelijk om even op te zetten zoals ook in bovenstaande post staat..

[CAPSLOCK2000]

webfreakz.nl schreef op zondag 28 juli 2013 @ 19:46:
DNSSEC is interessant, tot op zekere hoogte. Maar hoe weet je DNS client dat je Resolving server wel een legitiem antwoordt geeft? Voor zover ik DNSSEC ken, kan je client dat niet controleren. De controles vinden plaats tussen de Authoritative / Resolving nameservers en niet je client (PC / tablet / etc). Tuurlijk moet je een DNS server instellen die je vertrouwt, maar wie zegt dat de Google DNS niet ooit gekaapt wordt met een MITM attack? Als we het toch over security hebben: BGP Path / Origin validiation is ook (nog) niet breed geimplementeerd.. Daarnaast mis ik SSHFP checking in PuTTY, en helaas zijn ze daar zelf ook nog niet over uit: http://www.chiark.greenen...y/wishlist/sshfp-dns.html .

Je hebt helemaal gelijk, zolang de communicatie tussen de client en de resolver niet veilig is schiet je er niet heel veel mee op. Als je de resolver niet vertrouwt heeft het natuurlijk helemaal geen zin. Persoonlijk gebruik ik de Google-resolver dan ook niet, behalve om te testen*.
Er zijn grofweg twee oplossingen. De ene is om een resolver op de client te draaien. Zo zwaar is dat niet, op een moderne pc kan het er prima bij.
De andere oplossing is om de communicatie tussen client en resolver te beveiligen, bv met TSIG. Dat is behoorlijk ongebruikelijk maar wel mogelijk.
Een vervelend gevolg van de huidige situatie is dat applicaties niet weten of ze nu echt op DNSSEC kunnen vertrouwen of niet. Daarom zijn sommige applicaties begonnen om zelf maar te valideren.

Ik verwacht dat DNSSEC op termijn wordt opgenomen in je OS net zoals DNS dat ook al is.

* Een ander voordeel is dat mensen eerder naar je luisteren als je zegt iets niet werkt op een Google server dan wanneer je zegt dat het op je prive-servertje niet werkt.

[CAPSLOCK2000]

Wat doe je als een domein het vertikt om z'n DNSSEC te repareren?

Spotify.nl is nu al weken stuk. Ze hebben DNSSEC wel geregistreerd maar niet geactiveerd. Daardoor is spotify.nl dus onbereikbaar vanaf netwerken die DNSSEC controleren.

Op zich is dat (helaas) dagelijkse praktijk. Normaal gesproken mail of bel ik dan even met de beheerder en wordt het vrij snel opgelost. Spotify lijkt echter een gesloten vesting; er wordt niet gereageerd op welke vorm van communicatie dan ook. Ondertussen moet ik aan mijn gebruikers uitleggen waarom Spotify elders wel werkt maar niet op ons netwerk. Normaal vinden ze het niet zo erg als een website er een paar dagen uit ligt, maar Spotify is blijkbaar onmisbaar.

Na verschilllende pogingen om Spotify te bereiken heb ik het maar opgegeven en ze toegevoegd aan m'n whitelist. Mijn gebruikers kunnen weer muziek luisteren, maar zo komen we er niet. Als beveiliging wordt uitgezet zodra er iets wordt tegengehouden heeft het geen zin. Van de andere kant, als belangrijke diensten het niet doen dan hebben mijn klanten als snel genoeg van mijn diensten.

Je zou hetzelfde kunnen stellen over HTTPS, maar het verschil is dat de eindgebruiker dan zelf kan beslissen om een ongeldig certificaat te accepteren of niet. Als ze dat toch doen dan is het hun eigen verantwoordelijkheid. DNSSEC kunnen ze niet zo eenvoudig omzeilen, en ze krijgen ook (nog) geen popup met een foutmelding of uitleg. Alles komt dus op de beheerder aan.

Wat denken jullie er van?
A. Veiligheid voor alles, wie niet horen wil moet maar voelen, dan leren ze hun lesje. Dat Spotify dan niet werkt is niet mijn probleem.
B. Service voor alles. Als Spotify het niet belangrijk vindt en mijn gebruikers het ook niet belangrijk vinden dan is het niet mijn probleem.

De waarheid ligt natuurlijk ergens in het midden, maar waar? Wat doen jullie als een belangrijke site niet valideert? Valideren jullie uberhaupt DNSSEC?

PS. AUB geen discussie over het nut van Spotify op de werkvloer, dat is hier niet van toepassing.
PS2. Dit is geen aanval op Spotify. Spotify is een toevallig voorbeeld van een "onmisbare" website met DNSSEC-problemen die er niks aan doet

.

[webfreakz.nl]

CAPSLOCK2000 schreef op donderdag 08 augustus 2013 @ 15:32:
Valideren jullie uberhaupt DNSSEC?

Ik heb een Firefox plugin die de validatie doet, maar hecht niet veel waarde aan de resultaten.

Mijn webhost heeft nog(steeds) geen DNSSEC. Zat dit jaar al te denken om volledig over te gaan op een VPS omgeving en mijn domein bij een grote DNS boer te stallen die wel DNSSEC en IPV6 ondersteunt.

[Osiris]

CAPSLOCK2000 schreef op donderdag 08 augustus 2013 @ 15:32:
PS2. Dit is geen aanval op Spotify. Spotify is een toevallig voorbeeld van een "onmisbare" website met DNSSEC-problemen die er niks aan doet

Waarom niet? Je mag Spotify, of althans, de beheerders, er zeker wel over aanvallen natuurlijk Alleen niet over één kam scheren

[CAPSLOCK2000]

Spotify is zo'n bedrijf dat een hoop haat en liefde oproept. Ik wil het hier over DNSSEC hebben, niet over Spotify. Geen probleem om te zeggen dat beheerders van Spotify hun DNSSEC hebben verprutst en bijkbaar ook niet zo professioneel zijn dat ze het monitoren.

Daarmee komen we weer bij een belangrijk verschil tussen DNS en DNSSEC. Naar DNS heb je geen omkijken. Als het eenmaal werkt dat blijft het ook werken. DNSSEC is veel complexer en de zones moeten voortdurend worden ververst. Daarbij komt dat het onderwerp nog vrij nieuw is en de software vrij jong.
Het is dus essentieel dat je monitoring hebt om in de gaten te houden of alles nog werkt. Let er daarbij op dat je monitoringssysteem niet afhankelijk is van DNSSEC.

Zo ontdekte ik een paar weken geleden wat DNSSEC-problemen bij ISOC. Ik nam contact op met de beheerder en die melde mij verbaasd dat hij een mail zou moeten krijgen als z'n DNSSEC uitviel. Helaas had hij er niet aan gedacht dat de mailserver ook DNS gebruikt. Als het bij ISOC al fout gaat dan maak ik me zorgen om de rest van de wereld.
(We communiceerden overigens via Twitter, want z'n mail werkte dus niet.)

[Osiris]

Nog een belangrijker verschil:

DNS is simpel.

DNSSEC snap ik werkelijk geen ene moer van. Ja, iets met keys.. Maar dan houdt 't ook wel op

Ik heb al meerdere keren gegoogled en howto's gezocht et cetera, maar snap het nog steeds niet.

Geen wonder dat 't mis gaat als 't eenmaal ergens fout gaat. Al die MBO-niveau cursusjes waar je bijv. leert qua subnetmaskers en IP-adresjes e.d., tja, dat kan ik ook wel autodidactisch m.b.v. Google, maar for some reason lijkt het alsof je voor DNSSEC een bachelor+master's degree DNSSEC nodig hebt voordat je 't doorhebt. Dus dan vind ik 't ook niet raar als een beheerder denkt, jezus, ik ga me d'r ook niet mee bemoeien/bezig houden

[ Voor 49% gewijzigd door Osiris op 09-08-2013 15:26 ]

[webfreakz.nl]

@Osiris: Dat heb ik dus ook als ik encryptie-source code zie. Ik kan wel redelijk programmeren, ben geen expert danwel applicatie architect.... , maar dan zit ik echt van: "Wut?? "

Las ook dit artikel:
http://dnssec.nl/cases/dn...ransfers-het-kan-wel.html

Hij heeft het over een 14 stappenplan, en dacht al dat hij cross-signing ging doen en terug importeren met die zones / keys. Als je dan zijn uitgebreide versie leest klopt dat wel aardig maar dan nog heb ik een "pffff wat een gedoe...". Onderaan staat dus ook dat die schrijver aan de TUE heeft gezeten.. bevestigt jouw vermoeden ja dat je een M.Sc nodig hebt

[CAPSLOCK2000]

Osiris schreef op vrijdag 09 augustus 2013 @ 15:24:
Nog een belangrijker verschil:

DNS is simpel.

DNSSEC snap ik werkelijk geen ene moer van. Ja, iets met keys.. Maar dan houdt 't ook wel op

Het helpt ook niet dat alle voorbeelden direct beginnen met complexe configuraties met dubbele keys. Ik heb in mijn uitleg gekozen om het niet over ZSKs en KSKs te hebben, dat maakt het alleen maar verwarend.

doorhebt. Dus dan vind ik 't ook niet raar als een beheerder denkt, jezus, ik ga me d'r ook niet mee bemoeien/bezig houden

Ik begrijp je reactie. je bent niet de enige. Het vervelende is alleen dat je hostingbedrijven eigenlijk gedwongen worden om iets met DNSSEC te doen, of ze het nu willen of niet.

Een probleem dat ik letterlijk dagelijks tegenkom is dat een domein verhuisd wordt van een host met DNSSEC naar een host zonder DNSSEC. De nieuw host beseft dan vaak niet dat DNSSEC is geactiveerd. In plaats van DNSSEC weer uit te schakelen bij SIDN doen ze helemaal niks. Iedereen die wel DNSSEC gebruikt kan dat domein vervolgens niet meer bereiken.Een paar maanden geleden was dat nog niet zo'n probleem omdat minder dan 1% van de wereld DNSSEC valideerde, maar sinds Google mee doet ben je opeens 5% van je bezoekers kwijt.

Ik noem DNSSEC wel eens vendor lock-in voor DNS-boeren.

[CAPSLOCK2000]

webfreakz.nl schreef op vrijdag 09 augustus 2013 @ 16:32:Las ook dit artikel:
http://dnssec.nl/cases/dn...ransfers-het-kan-wel.html

Dit is echt het summum van moeilijk. Ik heb het drie keer iemand bereid gevonden om deze procedure met mij uit te voeren, en alle drie de keren is het mis gegaan

Gelukkig is er een oplossing. SIDN heeft het hele proces geautomatiseerd. Ik heb het zelf nog niet geprobeerd maar het zou nu wel eenvoudig moeten zijn.
http://www.youtube.com/wa...rI_LSggk&feature=youtu.be

edit: oeps, dubbelpost

[johnkeates]

Osiris schreef op vrijdag 09 augustus 2013 @ 15:24:
Nog een belangrijker verschil:

DNS is simpel.

DNSSEC snap ik werkelijk geen ene moer van. Ja, iets met keys.. Maar dan houdt 't ook wel op

Ik heb al meerdere keren gegoogled en howto's gezocht et cetera, maar snap het nog steeds niet.

Geen wonder dat 't mis gaat als 't eenmaal ergens fout gaat. Al die MBO-niveau cursusjes waar je bijv. leert qua subnetmaskers en IP-adresjes e.d., tja, dat kan ik ook wel autodidactisch m.b.v. Google, maar for some reason lijkt het alsof je voor DNSSEC een bachelor+master's degree DNSSEC nodig hebt voordat je 't doorhebt. Dus dan vind ik 't ook niet raar als een beheerder denkt, jezus, ik ga me d'r ook niet mee bemoeien/bezig houden

Ik denk dat het juist daar ligt, het is een encryptie methode, en dat is niet even 1+1=2. MBO-cursusjes zijn daar niet geschikt voor, want die vragen je niet zelf te denken. Die geven je een stappenplan, en als je dat kan onthouden kan je voor een paar variabelen wel een uitkomst verzinnen. Dat is een beetje het pijnpuntje van de hele ICT industrie. Mensen snappen het niet, want het lijkt een soort van 'magie', terwijl het gewoon systemen zijn die op andere systemen gebouwd zijn. Als je wil weten hoe en waarom iets werkt hoef je alleen maar de systemen te vereenvoudigen tot op een niveau waarop je het snapt. Meestal kom je ergens bij wiskunde uit, maar ook dat zou je als IT'er moeten snappen.

Ga bijvoorbeeld eens kijken hoe RSA werkt. Geen complexe materie, dat heb ik op de HAVO ooit een keer uitgezocht, en het valt wel mee met hoe moeilijk dat is

DNSSEC is net zo iets, het is niet moeilijk, maar je moet wel zelf willen denken, en dat is iets wat dan volgens mij weer niet van een 'beheerder' gevraagd wordt. Dat is op zich best gek, want je zou van een beheerder verwachten dat die alles wel weet. Als het uiteindelijk iemand met een of ander lullig certificaatje is die stappenplannen volgt, dan zou je daar net zo goed iemand neer kunnen zetten die kan lezen en schrijven, want dat zijn eigelijk de enige vaardigheden die je dan nodig hebt.

Je zou ook gewoon een RFC'tje erbij kunnen pakken voor de zelfstudie. Check bijvoorbeeld RFC 2898, erg interessant. Wordt o.a. voor WPA gebruikt. Volgens mij is tweakers.net dat een tijd geleden ook gaan gebruiken voor wachtwoorden.

Nu hoef je natuurlijk niet bij elke DNSSEC operatie zelf die algoritmes uitvoeren, daar heb je gereedschap voor, zoals bijv. http://linux.die.net/man/8/dnssec-keygen waar je geowon je parameters in duwt, en dan krijg je de key die je wil hebben, die je dan weer in je BIND zone stopt.

Edit: om wat minder 'snob' over te komen; je kan veel dingen die BIND doet ook gewoon met PowerDNS doen, en die is qua configuratie net wat overzichtelijker in te richten en bij te houden.

Kijk bijv op http://doc.powerdns.com/h...tml#dnssec-presigned-mode en http://doc.powerdns.com/html/pdnssec.html

genoeg docs om zonder zelf constant keys heen en weer te schuiven je zone bij te werken
Er staat zelfs gewoon een 'boodschappenlijstje' met RFC's bij waar je kan controleren waar welk algoritme voor gesuggeerd wordt, en met de pdnssec tool kan je zelfs lekker lui een basis config voor een zone uitpoepen (secure-zone) om daarna rectify-zone doen om het ook nog eens meteen DNSSEC-compatible (qua spec) te maken. Je hoeft bijna niks meer te weten van DNSSEC om het toch nog goed te doen wat ons waarschijnlijk weer bij een ander probleem brengt: mensen die niet weten wat ze doen, maar die wel achter de knoppen zitten, en waarvan verwacht wordt dat ze het goed doen. (En daar dan ook verantwoordelijk voor zijn) Maar ik denk dat dat een veel grotere discussie is...

Edit2: Ik zie net dat er helemaal niet van uit gegaan wordt dat mensen zelf hun DNS servers beheren, en dan ben je natuurlijk afhankelijk van je DNS hosting provider.. en dat er toch wel vooral van BIND uitgegaan wordt, en de dnssec-tools... ik zit me af te vragen of mijn post zo wel iets met dit topic te maken heeft

[ Voor 20% gewijzigd door johnkeates op 09-08-2013 17:02 ]

[Freeaqingme]

Goede TS!

Heeft iemand ervaring met het zelf draaien van een nameserver welke dnssec doet? In mijn geval heb ik net alle nameservers ingericht, klaar om in gebruik te nemen; kom ik dit ticket tegen. En ja, ik was DNSSEC vergeten...

Zijn er mensen die hier ervaring mee hebben in combinatie met Transip? Ik kan nergens in hun interface een mogelijkheid vinden om een DS record te uploaden (ook niet in hun API)
Edit: Als je een nameserver verandert in iets anders dan dat van Transip, dan krijg je een menu'tje waar je een ZSK en KSK kan instellen. Waarom zou je hier ook een ZSK kunnen uploaden? Naar ik begreep gaat het eigenlijk alleen maar om een KSK die je registrar nodig heeft?

[ Voor 29% gewijzigd door Freeaqingme op 09-08-2013 21:34 ]

[CAPSLOCK2000]

johnkeates schreef op vrijdag 09 augustus 2013 @ 16:50:

Ik denk dat het juist daar ligt, het is een encryptie methode, en dat is niet even 1+1=2. MBO-cursusjes zijn daar niet geschikt voor, want die vragen je niet zelf te denken. Die geven je een stappenplan, en als je dat kan onthouden kan je voor een paar variabelen wel een uitkomst verzinnen. Dat is een beetje het pijnpuntje van de
<knip>
Edit: om wat minder 'snob' over te komen; je kan veel dingen die BIND doet ook gewoon met PowerDNS doen, en die is qua configuratie net wat overzichtelijker in te richten en bij te houden.

Bind kan ook al het een en ander zelf doen. Ik verwacht dat DNSSEC binnenkort niet meer is dan een vinkje aanzetten. In principe is het hele proces te automatiseren. In mijn eigen omgeving moet ik de DS nog met de hand uploaden naar de registrars, maar dat is bij sommige registrars ook al te automatiseren. Verder werkt mijn omgeving helemaal automatisch. Ik maak een "gewone" DNS-zone aan en de software plakt alle DNSSEC-tjoep er om heen.

Edit2: Ik zie net dat er helemaal niet van uit gegaan wordt dat mensen zelf hun DNS servers beheren, en dan ben je natuurlijk afhankelijk van je DNS hosting provider.. en dat er toch wel vooral van BIND uitgegaan wordt,
en de dnssec-tools... ik zit me af te vragen of mijn post zo wel iets met dit topic te maken heeft

Alle DNSSEC-gerelateerde onderwerpen zijn bespreekbaar, of je het nu zelf host of niet.

Freeaqingme schreef op vrijdag 09 augustus 2013 @ 21:20:
Goede TS!

tnx

Edit: Als je een nameserver verandert in iets anders dan dat van Transip, dan krijg je een menu'tje waar je een ZSK en KSK kan instellen. Waarom zou je hier ook een ZSK kunnen uploaden? Naar ik begreep gaat het eigenlijk alleen maar om een KSK die je registrar nodig heeft?

Dat is inderdaad een beetje ongebruikelijk, maar wel correct. Je hoeft helemaal geen KSK te gebruiken. Alleen een ZSK is ook goed. Die ZSKs en KSKs maken DNSSEC moeilijk te begrijpen.
Op zich wordt al het werk door de ZSK gedaan. De KSK is er zodat je zelf de ZSK kan veranderen zonder te communiceren met je registrar. Als je dat toch niet van plan bent kun je het ook simpel houden en geen KSK gebruiken.
Vul altijd maar een van de twee in. Als je een KSK hebt moet je die gebruiken en geen ZSK invullen. Alleen als je geen KSK hebt gebruik je de ZSK. Dat is zo ongebruikelijk dat je het wel weet als het nodig is.

[ Voor 4% gewijzigd door CAPSLOCK2000 op 10-08-2013 01:01 ]

[CAPSLOCK2000]

Zojuist heeft .gov z'n DNSSEC verprutst. Alle .gov sites zijn daardoor onbereikbaar geworden.

[chickpoint]

CAPSLOCK2000 schreef op zaterdag 10 augustus 2013 @ 00:58:
[...]
Ik verwacht dat DNSSEC binnenkort niet meer is dan een vinkje aanzetten. In principe is het hele proces te automatiseren.
[...]

Bij mijn host is inderdaad alles geautomatiseerd. Ik hoef alleen de DNS records aan te passen en de rest regelen hun, het enige wat je extra kunt doen is DNSSEC uitzetten.

[ Voor 9% gewijzigd door chickpoint op 20-05-2015 14:04 ]

[CAPSLOCK2000]

Interessant, mag ik vragen welke host dat is?

[DutchNutcase]

Als ik de screenshot zo zie is dat mijndomein.nl.

[Osiris]

`dig +trace www.box4ehv.nl` resulteert in een laatste lookup vanaf de DNS-server achter 't IP 2a00:4e40:1:1::2:1 wat resulteert in:

inet6num:       2a00:4e40::/32
netname:        NL-MIJNDOMEIN-20111202
descr:          mijndomein.nl BV

Dus idd

[ Voor 5% gewijzigd door Osiris op 14-08-2013 18:19 ]

[ppl]

webfreakz.nl schreef op zondag 28 juli 2013 @ 19:46:
Maar hoe weet je DNS client dat je Resolving server wel een legitiem antwoordt geeft?

Dat is nou het hele idee achter DNSSEC. Er wordt in de DNS structuur op diverse niveaus gesigned (zonefile is daar eentje van maar ook een record in de zonefile). Wat je client dan doet is het antwoord wat ie krijgt van de DNS server controleren door die signature te controleren. Klopt dat dan is het ok, klopt het niet dan is er iets aangepast. Je moet het dan ook meer vergelijken met een identiteitscontrole op een vliegveld: men kan alleen controleren of jij degene bent op het paspoort. Ze kunnen niet zien of jij kwade bedoelingen hebt, of jij een oogje hebt op die ene collega, enz. Of zoals RIPE NCC het zo mooi verwoord:

It is a set of extensions to DNS, which provide:

- origin authentication of DNS data
- data integrity
- authenticated denial of existence

DNSSEC does not provide availability or confidentiality.

Dat is ook het probleem met DNSCrypt (of liever gezegd DNSCurve): het versleuteld de communicatie waardoor je het onderweg niet af kunt luisteren of daar iets mee kunt doen. Je kunt echter wel de server hacken en de records gaan lopen wijzigen. Dat kan met DNSSEC weer niet omdat je bij iedere aanpassingen aan de zonefile de boel weer opnieuw moet signen. Je zult daarvoor dus ook die key e.d. moeten weten. Als je, net zoals laatst, achter een DRS login van een ISP kunt komen kun je natuurlijk diverse domeinnamen naar je eigen DNS server laten verwijzen. Als je die inricht met DNSSEC ziet de client ook niet dat er iets mis is. DNSCurve/DNSCrypt zal ook dit niet oplossen. Ik denk dat DNSSEC de grootste problemen met DNS wel aanpakt. In hoeverre je dan nog iets als DNSCrypt/DNSCurve nodig hebt vraag ik me af.

Dat signen is ook hetgeen wat DNSSEC zo ontzettend lastig maakt waardoor het weinig geimplementeerd wordt en het vaak misgaat. Administratief is het lastig en als je het echt goed wil doen moet eigenlijk alles DNSSEC doen. Denk hierbij niet alleen aan het steeds moeten signen van allerlei zaken maar ook aan key roll-overs. DNSSEC is alleen secure als je regelmatig de keys preventief vervangt. Het is net als met basketbal: het is moeilijk aanvallen als iedereen in beweging is en de bal snel rondgespeeld wordt. Bij het RIPE NCC kun je een document vinden met daarin hun key management: http://www.ripe.net/ripe/...key-maintenance-procedure

De DNSSEC pagina op Engelstalige Wikipedia is ook wel een aanrader als startpunt: Domain Name System Security Extensions.

[webfreakz.nl]

www.opendns.com/technology/dnscrypt/

Mooie lezing: http://pilif.github.io/2011/04/dnssec-to-clean-the-ssl-mess/

En er wordt verwezen naar DANE in de comments. Heb de introduction in de RFC gelezen, en klinkt als een prima alternatief op CA's.

[CAPSLOCK2000]

Persoonlijk vind ik DNSCrypt minder dringend als DNSSEC. Begrijp me niet verkeerd, DNSCrypt is ook nodig, maar er is niet zo veel om te beschermen. Als jouw client verbinding maakt met de DNS-server van youtube heb ik weinig fantasie nodig om te bedenken dat je YouTube: YouTube gaat opzoeken.


DANE vind ik erg leuk maar ik twijfel of het wel echt een goed idee is. Je legt namelijk alle risico's op dezelfde plek neer. Om DNSSEC (en dus DANE) te gebruiken moet je wel je DNS-leverancier kunnen vertrouwen. De meeste DNS-leveranciers zijn kleine jongens die de middelen niet hebben om echt veilig te werken.


Ik wil binnenkort mijn mailserver voorzien van DANE, die kan het hard gebruiken.

[blaataaps]

CAPSLOCK2000 schreef op zaterdag 17 augustus 2013 @ 09:48:
DANE vind ik erg leuk maar ik twijfel of het wel echt een goed idee is. Je legt namelijk alle risico's op dezelfde plek neer. Om DNSSEC (en dus DANE) te gebruiken moet je wel je DNS-leverancier kunnen vertrouwen. De meeste DNS-leveranciers zijn kleine jongens die de middelen niet hebben om echt veilig te werken.

Hoe leg je risico's op dezelfde plek neer? In plaats van een miljoen CA's die door duizend browserbouwers vertrouwd worden, waaronder Honest Achmed CA, vertrouw je 1 DNS-boer die je zelf uitzoekt (als je die niet vertrouwt heb je een verkeerde gekozen). Daarbij moet je nog het DNS-pad naar je DNS-boer vertrouwen, dat zijn ook maar een stuk of 2-3 partijen (die je toch al wel moet vertrouwen, wil je een beetje kunnen internetten).

[CAPSLOCK2000]

Allereest, ik ben geen fan van het CA systeem. Met name dat iedere CA zomaar voor ieder domein een certificaat kan uitgeven is enorm vervelend. Gelukkig sluiten deze systemen elkaar niet uit. Je kan een "echt" certificaat afnemen bij een CA en dat ook publiceren via DANE.

Ten tweede, mijn bezwaar is een beetje gebaseerd op theorie vs praktijk. In theorie kies ik liever zelf een betrouwbare DNS-leverancier. In praktijk is het bij 90% van de DNS-leveranciers zeer treurig gesteld met de veiligheid. (Ik heb hier een apart topic over gestart, zie Social Engineer je eigen webhost ). Ik zie dat ook niet veranderen zolang je domeinen kan kopen voor een euro. Daarbij denken de meeste klanten ook niet aan veiligheid, die kijken alleen naar de prijs.
Zelf kan ik misschien wel een betrouwbare hoster uitzoeken maar ik heb geen invloed op de rest van internet. Als we de CA's er nu uit zouden gooien en alleen nog maar DANE gebruiken denk ik dat we er netto op achteruit gaan.

[webfreakz.nl]

DANE vind ik erg leuk maar ik twijfel of het wel echt een goed idee is. Je legt namelijk alle risico's op dezelfde plek neer. Om DNSSEC (en dus DANE) te gebruiken moet je wel je DNS-leverancier kunnen vertrouwen. De meeste DNS-leveranciers zijn kleine jongens die de middelen niet hebben om echt veilig te werken.

Dan maar stoppen met DNSSEC? Lijkt me juist een goed plan om die SSL certs te signen met DNSSEC data. Gare CA's als Diginotar kan je dan lekker vermijden! Ook hoeven ze dan geen geld te kosten. Hoe dat dan verder zal gaan met SSL EV certificaten weet ik niet DNS heb je toch nodig om de meeste domeinen te benaderen aangezien Apache die verwacht. Domweg op IP browsen werkt zelfs naar servers met één website vaak niet eens. Of je moet even tijdelijk een entry in je hosts.conf knallen

[ Voor 20% gewijzigd door webfreakz.nl op 17-08-2013 14:37 ]

[CAPSLOCK2000]

Ook zonder DANE is DNSSEC een goed idee. SSL-certificaten ook met DNSSEC beveiligen vind ik een uitstekend idee. Op dit moment denk ik dat we nog niet zonder de CA's kunnen. Ik heb geen fundamentele bezwaren tegen DANE, maar wel praktische. De praktijk is namelijk dat de meeste DNS-leveranciers nog minder beveiliging hebben dan de CA's.

Een ander nadeel van DANE is dat je voor sommige domeinen helemaal niet kan kiezen tussen verschillende registrars. Dat geldt met name voor veel van de nieuwe TLDs die momenteel worden gelanceerd. Dat kun je natuurlijk voorkomen door geen domeinen te kopen in dat soort TLDs, maar leg dat maar aan je baas uit.
Als ik bv Versign niet zou vertrouwen dan vallen er honderden domeinen af.

Ik zie overigens nog wel mogelijkheden om DANE-certificaten te gebruiken in combinatie met een andere controle-mechanisme dan de CA's, bv Convergence. Zodra er zo'n ander mechanisme is kunnen we de macht van de CA's gaan afbreken.

Het algemene principe dat ik wil uitdragen is dat je beveiliging niet te veel moet centraliseren. Als alles bij één partij ligt dan ben je kwetsbaar voor fouten van die ene partij. Hoe meer onafhankelijke beveiligingsmaatregelen je treft hoe beter. Er is nog steeds een plek voor CA's in de wereld, maar niet meer als enige bron van de absolute waarheid.

[ppl]

Je moet dingen ook niet overbeveiligen. DNSSEC dekt de meest voorkomende problemen wel af. Het enige wat je met ssl verbindingen tussen server en client opschiet is dat je dat verkeer versleuteld en een buitenstaander daar niks mee kan. Het nut is klein omdat je na die DNS lookup vaak ook contact zoekt met hetgeen je opgezocht hebt. Dat hoeft niet per definitie over een beveiligde verbinding te gaan. Daarnaast is er ook nog iets als de bewaarplicht. Wat vooral belangrijk is, is dat de lookups die je doet wel antwoorden opleveren die enigszins te vertrouwen zijn (daar is DNSSEC voor).

[webfreakz.nl]

Ik hoef met de meeste sites waar ik een HTTPS verbinding mee opbouw ook helemaal geen encryptie, wel authenticatie. Tuurlijk, bij mijn bank wil ik wel encryptie. Maar ik wil gewoon van de mogelijke MITM attacks af.

[Out.of.Control]

Heb sinds een paar weken een paar domeinen met DNSSEC uitgerust. Als je het eenmaal door hebt valt het (zoals met zoveel dingen) best mee.
In het kort mijn setup: hidden master met Bind 9.9.2 en met inline-signing, twee publieke authoritative servers als slave met NSD. Alle drie onder OpenBSD.

Wat nog niet lekker werkt: als je met "rndc signing -list <zone>" de status controleert, dan zie je meestal bij bijna alles zones "No signing records found". Meestal zie je maar bij 1 van de zones de keys waarmee gesigneerd wordt. Het verversen van de RRSIG records lijkt dan ook te stoppen en dat wil je natuurlijk niet.
Als je Bind stopt, de gesigneerde zones verwijdert en Bind weer start (zodat alles opnieuw wordt gesigneerd) dan gaat het een tijdje goed, maar als je dan een keer een zone hebt aangepast (of wellicht ook spontaan), dan krijg je bij 9 van de 10 zones weer "No signing records found". Die andere ene van de 10 blijft werken, maar het is niet altijd dezelfde die het blijft doen. De logfile geeft geen aanknopingspunten. Iemand een idee?
Ik moet nog controleren of dit in Bind 9.9.4 is opgelost. Net getest met 9.9.4: geen verschil.

En nog een vraag waar iemand hopelijk een antwoord op weet:
Bij 1 van de zones gebruikt ik NSEC3, om zone-walking te voorkomen. Je leest her en der dat het verstandig is om na enige tijd (bv bij een ZSK rollover) de salt aan te passen. Mijn vraag is: kan dat zomaar of is daar ook een rollover procedure voor nodig?

[ Voor 1% gewijzigd door Out.of.Control op 06-10-2013 22:31 . Reden: geen verschil in 9.9.4 ]

[CAPSLOCK2000]

FreeBSD heeft Unbound opgenomen in het base systeem en DNSSEC staat aan. Daarmee is het volgens mij het eerste OS dat by default DNSSEC gebruikt. Een mooie stap vooruit.

[EnsconcE]

DNSSEC is voor mij wel te configureren op een openwrt, of vergelijkbare geflashte, router. Maar ik lees nergens nog dat routers het vanuit huis ondersteunen. Op de websites van netgear, linksys of tp-link staat DNSSEC nergens aangeduid. Is er ergens een overzicht met routers die DNSSEC ondersteunen?

[CAPSLOCK2000]

Ik weet dat F5 het kan, maar dat is een beetje te duur voor thuis. Er is sowieso nog een discussie gaande waar je DNSSEC precies wil controleren. Het mooiste is natuurlijk als iedere resolver het controleert, maar eigenlijk wil je dat je eigen computer het doet, zodat het verkeer tussen je router/resolver en je PC niet gemanipuleerd kan worden.

[Equator]

Dergelijke beveiliging heeft weinig nut als het niet door het endpoint gecontroleerd wordt vind ik. Ik kan me echter wel weer voorstellen dat een cliënt het zo erg druk gaat krijgen. Dus offloaden naar een trusted DNS server (ergo: de DNS server in je eigen LAN)

[EnsconcE]

Het is ook meer bedoelt voor de devices die het standaard niet ondersteunen. Ik heb bv een aantal devices in huis staan die het internet op kunnen, maar die nooit een DNSSEC implementatie gaan krijgen. ios ondersteund het nu ook nog niet, dus voor de tablets is het nu ook wel van toegevoegde waarde.

[CAPSLOCK2000]

Er zit ook een voordeel aan DNSSEC centraal doen in plaats van op het device: eindgebruikers kunnen het niet uitschakelen. In de HTTPS wereld is heel gewoon om foutmeldingen over een ongeldig certificaat te negeren en toch naar de website te gaan. In DNSSEC lukt je dat niet, daar bepaalt je resolver alles en krijg je helemaal geen pop-up waarschuwing. Het nadeel is weer dat het debuggen moeilijker maakt.

[CAPSLOCK2000]

Er worden mooie grafiekjes gemaakt van het gebruik van DNSSEC-validatie:

wereldwijd: http://gronggrong.rand.ap...page?c=XA&x=1&g=0&r=1&w=7
West-Europa: http://gronggrong.rand.ap...page?c=QO&x=1&g=1&r=1&w=1
Nederland: http://gronggrong.rand.ap...?c=NL&x=1&g=1&r=1&w=7&g=0

Jammer om te zien dat Nederland zo'n achterblijver is terwijl we wel de absolute topper zijn als het gaat om het aanbieden van domeinen met DNSSEC.

[ThinkPad]

-- post verplaatst naar ThinkPadd in "Het grote OpenWRT topic" --

Ik gebruik sinds een tijdje OpenNIC, maar de 3 servers die ik gebruik ondersteunen helaas geen DNSSEC lijkt het

95.85.9.86
31.220.43.191
151.236.29.92

Er zijn wel andere OpenNIC servers die het wel ondersteunen, maar die zijn dan weer gevestigd in DE of AT bijv., waardoor de resolvetijd weer een stuk hoger ligt (getest met 'namebench').

8.8.8.8 (Google DNS) doet wel DNSSEC en zijn bloedsnel, maarja ik heb er niet zo'n fijn gevoel bij om alles naar Google te sturen.

Welke DNS-servers gebruiken jullie?

[ Voor 200% gewijzigd door ThinkPad op 23-08-2015 16:59 ]

[CAPSLOCK2000]

Ik draai m'n eigen DNS-resolver. Meestal Unbound of Bind. Bij een DNS-resolver op afstand weet ik niet of het verkeer tussen mij en de resolver niet onderschept wordt. Als ik geen keuze heb is een resolver op afstand met DNSSEC natuurlijk beter dan eentje zonder. Bij voorkeur draai ik de resolver echter zo dicht mogelijk bij me, het liefst op de computer zelf. Op een moderne PC zijn de kosten daarvan verwaarloosbaar.

[ThinkPad]

Even een kick van dit topic

Gisteren ook gezorgd dat ik zelf de resolver ben ipv dat ik alle DNS-requests door m'n ISP of 8.8.8.8 (Google) laat oplossen. Bij m'n router (pfSense) was dat maar twee vinkje aanpassen en het werkte. DNSSEC werkt nu ook Had veel meer werk verwacht.

Zelf resolven is altijd trager dan 8.8.8.8 of 1.1.1.1 o.i.d. gebruiken, maar ik moet zeggen, het valt best mee.
De eerste keer duurt het eventjes (langste wat ik heb gezien was 394ms) maar dat is nog steeds snel eigenlijk. Ik testte het met dig dus dat was op enter drukken en in een oogwenk stond er. De volgende keer kon hij verzoek in 0ms beantwoorden doordat hij het inmiddels gecached had.

Ik snap eigenlijk niet waarom niet meer mensen zelf gaan resolven. Ik hoef niet zo nodig elk DNS-request door Google te laten oplossen eigenlijk.

[Osiris]

't Is makkelijker als een grote partij de caching server speelt dan jij in je Remy. Relatief meer cache hits, minder DNS-verkeer en daardoor minder load richting de authoritative DNS servers van de diverse sites et cetera. En de n00b weet toch niet hoe het anders kan, hóeft het ook niet anders én 't is nog sneller ook.

De gemiddelde internetter heeft geen behoefte om al zijn DNS-verkeer en DNSSEC-controles in eigen beheer te hebben.

[ppl]

Al helemaal niet met dingen als Bonjour waardoor devices op het netwerk elkaar kunnen vinden middels een naam ipv een ip-adres.

Overigens kun je ook gewoon een andere DNS server instellen dan die van Google als je niet zo nodig iedere DNS-request via hun wilt laten gaan. Hoef je geen eigen DNS server voor op te zetten.

[ThinkPad]

ppl schreef op zondag 13 mei 2018 @ 17:46:
Al helemaal niet met dingen als Bonjour waardoor devices op het netwerk elkaar kunnen vinden middels een naam ipv een ip-adres.

Overigens kun je ook gewoon een andere DNS server instellen dan die van Google als je niet zo nodig iedere DNS-request via hun wilt laten gaan. Hoef je geen eigen DNS server voor op te zetten.

Je eerste stukje snap ik niet helemaal, dat staat los van een eigen DNS resolver draaien en DNSSEC

Het tweede klopt, Google en Cloudflare doen bijv. allebei DNSSEC. Maar dan weet je nog steeds niet helemaal zeker of het antwoord wat je krijgt wel klopt, tenminste dat is wat ik begrijp uit onderstaande quote:

CAPSLOCK2000 schreef op vrijdag 9 oktober 2015 @ 22:49:
Ik draai m'n eigen DNS-resolver. Meestal Unbound of Bind. Bij een DNS-resolver op afstand weet ik niet of het verkeer tussen mij en de resolver niet onderschept wordt. Als ik geen keuze heb is een resolver op afstand met DNSSEC natuurlijk beter dan eentje zonder. Bij voorkeur draai ik de resolver echter zo dicht mogelijk bij me, het liefst op de computer zelf. Op een moderne PC zijn de kosten daarvan verwaarloosbaar.

Ik heb tot nu toe nog geen nadelen gevonden in het draaien van een eigen resolver die het voor mij oninteressant maken. Het is ietsje langer bij domeinnamen die hij nog niet gecached heeft, aan de andere kant krijg ik er wel veiligheid voor terug

[ Voor 18% gewijzigd door ThinkPad op 13-05-2018 18:43 ]

[Osiris]

ThinkPadd schreef op zondag 13 mei 2018 @ 18:41:
[...]

Het tweede klopt, Google en Cloudflare doen bijv. allebei DNSSEC. Maar dan weet je nog steeds niet helemaal zeker of het antwoord wat je krijgt wel klopt, tenminste dat is wat ik begrijp uit onderstaande quote:

[...]

Als de zone/DNS-servers van 't opgevraagde record aan DNSSEC doet, dan maakt 't niet uit welke klootviool de resolver draait, dan weet je i.p. (tenzij DNSSEC gekraakt wordt) dat 't correct is. Je hebt immers lokaal uiteraaaaaard een DNSSEC-enabled client draaien

Nadeel is natuurlijk dat je resolver misschien wel DNSSEC ondersteunt, maar dat een complete TLD geen DNSSEC doet of de authoritative DNS-servers van de hostname in kwestie niet. Maargoed, dan is een eigen resolver draaien net zo kwetsbaar.

[ThinkPad]

Heb m'n eigen resolver weer draaien (tijdje niet actief gehad omdat ik van pfSense was overgestapt naar een EdgeRouter). Heb Pi-hole in een VM draaien, in die VM draait ook Unbound per instructies van Pi-hole. Werkt prima en netjes DNSSEC in alle tests
Was eigenlijk ook zo klaar, dus waarom alle DNS-requests weggeven aan 8.8.8.8 als ik ook zelf resolvertje kan spelen

Klopt het trouwens dat wanneer je je eigen resolver draait, je op https://dnsleaktest.com/ je eigen hostname ziet?

[ Voor 13% gewijzigd door ThinkPad op 14-01-2019 23:28 ]

[CyBeR]

ThinkPadd schreef op maandag 14 januari 2019 @ 23:26:
Was eigenlijk ook zo klaar, dus waarom alle DNS-requests weggeven aan 8.8.8.8 als ik ook zelf resolvertje kan spelen

Omdat dat op zich beter is. Google houdt een grotere cache bij dan jij vanwege hun enorme user base, en je hoeft je geen zorgen te maken over security flaws in je eigen nameserver of bijvoorbeeld de DNSSEC-validatie ervan zoals bij een rollover van de root key.

Klopt het trouwens dat wanneer je je eigen resolver draait, je op https://dnsleaktest.com/ je eigen hostname ziet?

Ja, aangezien die reqs nu bij jou direct vandaan komen ipv bij Google, CloudFlare (1.1.1.1), Quad9 (9.9.9.9), OpenDNS of je ISP.

[CAPSLOCK2000]

Het is natuurlijk maar de vraag met wie je dat wil delen. Zelf deel ik het liever met m'n ISP dan met Google. Maar daarmee komen we eigenlijk op het gebied van DNS Privacy, wat ook een heel mooi onderwerp is.

[CyBeR]

Daarvoor is het gebruik van je ISP nameservers idd het beste; zeker niet je eigen resolver draaien. Ik heb daar eens een hele presentatie over gezien maar ik kan me niet direct herinneren waar dat was…

Overigens voorziet Google niet in hun Public DNS dienst om er aan te verdienen (althans, niet direct; alleen in zoverre dat ze graag willen dat hun andere diensten beter, sneller en veiliger bereikbaar zijn) dus daarvoor hoef je niet heel bang te zijn privacy-wise.

[ Voor 39% gewijzigd door CyBeR op 15-01-2019 17:39 ]