SIDN activeert dnssec voor .nl-domeinnamen
SIDN heeft de implementatie van het dnssec-protocol op .nl-domeinnamen afgerond. Vanaf dinsdag kunnen domeinnaamhouders het nieuwe protocol gebruiken, wat de veiligheid van het dns-systeem flink moet vergroten.
De invoering van dnssec heeft al diverse malen vertraging opgelopen, onder meer doordat het protocol nog te kampen had met enkele vroege problemen. Omdat SIDN niets wilde veranderen aan de werking van het systeem zolang niet zeker was dat het ook zou werken, is gewacht met de invoer.
Dinsdag is dnssec ingevoerd, wat betekent dat het is geïmplementeerd in het domeinnaamsysteem DRS van SIDN. Hierdoor is het voor registrars mogelijk om dnssec geautomatiseerd aan te bieden aan hun klanten. Dit heeft volgens SIDN tot gevolg dat de acceptatie van dnssec sneller kan groeien.
Er zijn inmiddels negen registrars die vanaf dinsdag ook direct dnssec als mogelijkheid aanbieden aan hun klanten. Roelof Meijer, directeur van SIDN, stelt dat zijn bedrijf een 'onmisbare schakel in de dns-hiërarchie' is om dnssec beschikbaar te maken. Ook de registrars, dns-operators en internetproviders spelen echter een belangrijke rol. "En zij zijn nu aan zet", aldus Meijer.
De directeur erkent dat het uitrollen van dnssec in de infrastructuur van een registrar geen sinecure is. "Desondanks verwachten wij dat het aantal aanbieders snel zal groeien, omdat Nederland traditioneel vooroploopt met nieuwe internetontwikkelingen", aldus Meijer.
De invoering van dnssec moet een antwoord bieden op de toenemende roep om betere beveiliging van het dns-protocol. Hoewel de veiligheid van dns niet direct in gevaar is geweest, zagen we in de afgelopen jaren wel al diverse scheurtjes in het bouwwerk. 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.
Meer informatie over het dnssec-protocol is te vinden in ons artikel 'Dnssec: voor het laatste onveilige protocol'.
Reacties (35)
Het heeft even geduurd, maar dan heb je ook wat 
Is er ergens een overzicht te vinden met welke registrars dit ook al daadwerkelijk aanbieden aan hun klanten? Ik ben eigenlijk wel benieuwd wie dit zijn..Er zijn inmiddels negen registrars die vanaf dinsdag ook direct dnssec als mogelijkheid aanbieden aan hun klanten.
Die lijst is niet helemaal actueel, want mijn registrar (Intention) biedt het inmiddels ook al aan sinds vanmorgen..
Waarschijnlijk wordt de lijst nog wel geupdate. Langzamerhand zullen verschillende providers dit gaan implementeren.
Ik denk dat de bedrijven in die lijst mee hebben gewerkt aan een pilot van het project. Zodoende kon SIDN zelf kijken of hun systemen conform de standaard waren.
Ik denk dat de bedrijven in die lijst mee hebben gewerkt aan een pilot van het project. Zodoende kon SIDN zelf kijken of hun systemen conform de standaard waren.
Inderdaad, dat lijstje is verre van compleet, want Prolocation B.V. biedt al sinds september 2009 DNSSEC voor surfnet. Prolocation wil al haar domains 
laten signen en er gaan geruchten dat de HSM infrastructuur van sidn niet de capaciteit heeft 
om het grote aantal domeins van Proclocation te signen.
laten signen en er gaan geruchten dat de HSM infrastructuur van sidn niet de capaciteit heeft om het grote aantal domeins van Proclocation te signen.Dat gerucht kan ik gegrond als onwaar bestempelen.
Je linkt overigens naar een artikel over de vervanging van routers, firewalls en switches. Wat heeft de HSM daar mee te maken? Ik kan uit eerste hand vertellen dat de HSM's van een andere leverancier komen. SafeNet. Dat zijn monsterlijke machines. Even uit het blote hoofd zo'n 7000 signs/sec.
SIDN kan als ze willen de gehele .nl zone signen.
Je linkt overigens naar een artikel over de vervanging van routers, firewalls en switches. Wat heeft de HSM daar mee te maken? Ik kan uit eerste hand vertellen dat de HSM's van een andere leverancier komen. SafeNet. Dat zijn monsterlijke machines. Even uit het blote hoofd zo'n 7000 signs/sec.
SIDN kan als ze willen de gehele .nl zone signen.
Iedereen die toegang heeft tot DRS kan er bij. Ik heb dan ook maar direct een extra domein voor mijn werkgever voorzien. Als je eerst mee deed met het Friends & Fans programma dan zijn je keys als het goed is gewoon overgenomen.
https://www.sidn.nl/over-nl/dnssec/
BIT
HCC
Mijndomein
MijnDomeinReseller
Monshouwer Internet Diensten
Nederhost
SinnerG
SysTech Media
TransIP
BIT
HCC
Mijndomein
MijnDomeinReseller
Monshouwer Internet Diensten
Nederhost
SinnerG
SysTech Media
TransIP
Je kan sowieso al controleren of jij zelf dnssec kan gebruiken:
http://dnssectest.sidn.nl/index_nl.php
Hiermee wordt aangegeven of je browser/client het dnssec protocol ondersteund.
Waarschijnlijk komen er binnenkort meer ondersteuning voor dit protocol nu dit uitgerold is.
https://www.sidn.nl/nieuw...u-klaar-bent-voor-dnssec/
http://dnssectest.sidn.nl/index_nl.php
Hiermee wordt aangegeven of je browser/client het dnssec protocol ondersteund.
Waarschijnlijk komen er binnenkort meer ondersteuning voor dit protocol nu dit uitgerold is.
https://www.sidn.nl/nieuw...u-klaar-bent-voor-dnssec/
IE9 en Chrome 18 dus niet. Ook ergens staan welke het wel ondersteunen?
[edit]
ik zie dat het via Add-Ins mogelijk is om die functionaliteit iig toe te voegen aan Firefox en Chrome:
http://www.internetsociet...support-to-google-chrome/
http://www.internetsociet...pport-to-mozilla-firefox/
[edit2]
Zie Moartn en mijn reply hier onder voor een nuancering; IE9 en Chrome 18 ondersteunen het dus wel, maar afhankelijk van welke DNS Server er in je chain er tussen zit, kan dat de DNSSEC functie tegenhouden.
[edit]
ik zie dat het via Add-Ins mogelijk is om die functionaliteit iig toe te voegen aan Firefox en Chrome:
http://www.internetsociet...support-to-google-chrome/
http://www.internetsociet...pport-to-mozilla-firefox/
[edit2]
Zie Moartn en mijn reply hier onder voor een nuancering; IE9 en Chrome 18 ondersteunen het dus wel, maar afhankelijk van welke DNS Server er in je chain er tussen zit, kan dat de DNSSEC functie tegenhouden.
[Reactie gewijzigd door CMG op dinsdag 15 mei 2012 11:02]
IE9, Chome en Firefox ondersteunen het bij mij wel aldus die SIDN-tool, dus is vermoed dat het aan de DNS-server van je provider ligt, en niet aan de browser.
Dat is dan wel een groot probleem als dit niet doorgegeven wordt... onze Microsoft SBS 2008 R2 zit hier als default DNS Server en daarmee gaat dus de DNSSEC informatie verloren als jij met de zelfde browser zonder addons wel kunt valideren... Welke DNS Server gebruik jij?
[update]
Na reactie van Lisadr hier beneden lijkt het er meer op dat het aan de Ziggo (Zakelijk in ons geval) DNS servers ligt die de SBS server weer gebruikt. Volgens http://technet.microsoft....ry/cc728328(v=ws.10).aspx zou die SBS het niet tegen moeten houden iig.
[update]
Na reactie van Lisadr hier beneden lijkt het er meer op dat het aan de Ziggo (Zakelijk in ons geval) DNS servers ligt die de SBS server weer gebruikt. Volgens http://technet.microsoft....ry/cc728328(v=ws.10).aspx zou die SBS het niet tegen moeten houden iig.
[Reactie gewijzigd door CMG op dinsdag 15 mei 2012 11:07]
Hier op kantoor gebruiken we Windows Server 2008 R2 (geen SBS), en daarmee werkt het wel blijkbaar. Dus het ligt aan het feit dat jullie SBS gebruiken, of een instelling ergens.
[edit] Of de upstream DNS-server inderdaad. Wij hebben zijn onze eigen provider (gewoon fibertje naar het datacentrum), dus dan heb je dat probleem niet
[edit] Of de upstream DNS-server inderdaad. Wij hebben zijn onze eigen provider (gewoon fibertje naar het datacentrum), dus dan heb je dat probleem niet
[Reactie gewijzigd door Moartn op dinsdag 15 mei 2012 11:17]
Ziggo Klant
Geen ondersteuning voor
IE8
IE9
Opera 11.6x
Firefox 12
Safari
Kortom, geen enkele browser. Denk dat het met de DNS van Ziggo te maken heeft.
Geen ondersteuning voor
IE8
IE9
Opera 11.6x
Firefox 12
Safari
Kortom, geen enkele browser. Denk dat het met de DNS van Ziggo te maken heeft.
Browsers en andere programma's dienen de DNS resolver van het besturingssysteem te gebruiken. Al vanaf Internet Explorer 4 maakt IE niet meer gebruik van een eigen resolver, maar die van het OS. Dit had ermee te maken dat IE ook de intranets in NT4 netwerken moest kunnen benaderen.
Als de browser de standaard DNS resolver (nslookup is de commandline frontend onder Windows) negeert, dan mist deze de interne DNS zones.
Toen in Windows 2000 Active Directory werd geintroduceerd werd het gebruik van de systeem resolver nog belangrijker. Bedrijven die gebruik maken van DHCP voor het uitdelen van IP adressen geven in de regel de DNS server IP's door.
De addins voor Chrome en Firefox gebruiken niet hun eigen resolver implementatie, maar de addin doet een losse query naar de DNS server en controleerd of deze vervolgens DNSSEC informatie terug krijgt.
Echter die methode is niet water dicht. Stel ik heb twee DNS servers en om te testen installeerd ik DNSSEC op slechts 1 server. Als de systeem resolver gebruik maakt van de DNSSEC server en de addin net de andere server pakt, dan zal de addin aangeven dat het domein niet is beschermd middels DNSSEC. De systeem resolver zal normaal deze informatie niet doorgeven. Dat is ook niet nodig omdat als de DNSSEC informatie niet klopt, de resolver het antwoord negeert. Veel mailserver spam filters controleren of het domain ook een zogenaamd SPF (txt) record heeft. Als de mail afkomt van een server welke vermeld is in het SPF record, dan wordt de mail geaccepteerd. Al de mail is verstuurd vanaf een mailserver welke niet in het SPF record staat dan wordt de mail mogelijk gedropped (afhankelijk van instellingen van het filter). Is er geen SPF record dan wordt de controle niet uitgevoerd.
DNSSEC-compatible resolvers werken op een soortgelijke manier. Indien er geen DNSSEC informatie is wordt er ook niet gecontroleerd en wordt het antwoord als 'correct' beschouwd. Als DNSSEC geimplementeerd is dan wordt ook dat antwoord gecontroleerd en als de infomatie foutief is wordt het gehele antwoord op de DNS query gedropped.
DNSSEC is heel erg simpel gezegd niet meer dan een checksum berekend over een aantal velden in het antwoord van de DNS server. DomainsKeys werkt op dezelfde manier alleen gebruikt voor de checksum een aantal header velden. DomainsKeys leunt sterk op van DNS records, dus is het belangrijk dat die gegevens zou betrouwbaar mogelijk zijn.
Ik heb voor mijn domeinen al bijna twee jaar DNSSEC en DomainKeys geconfigureerd, alleen wat er tot iets meer dan een jaar geleden geen mogelijkheid om MIJN public key te controleren.
Sinds een jaar staat mijn public key ook op de VeriSign DNS servers via mijn DNS intermediair. VeriSign (welke de DNS voor onder andere .com, .net en .org beheerd) koppelt vervolgens de public key aan de authoritive DNS gegevens. De public key van Verisign en ook SDIN staan weer op de DNS servers van ICANN samen met de 'root' key van ICANN zelf. Meer info: http://www.root-dnssec.org/
Nu moet ik alleen nog wachten tot directnic eindelijk de mogelijkheid om DNSSEC keys voor .NL domeinen te plaatsen op de SIDN servers. Tot die tijd geeft mijn server wel DNSEC informatie voor mijn .NL domein terug, maar is er nog geen mogelijkheid om de authenticiteit van de key welke gebruikt is te controleren. Daardoor is er geen volledige chain of trust.
Houd er wel rekening mee dat als je je DNSSEC public key publiceert, als je DNS server DNSSEC correct geimplementeerd moeten hebben. Anders loopt je de kans dat resolvers antwoorden weggooien omdat er geen of een incorrecte checksum wordt meegegeven.
Als de browser de standaard DNS resolver (nslookup is de commandline frontend onder Windows) negeert, dan mist deze de interne DNS zones.
Toen in Windows 2000 Active Directory werd geintroduceerd werd het gebruik van de systeem resolver nog belangrijker. Bedrijven die gebruik maken van DHCP voor het uitdelen van IP adressen geven in de regel de DNS server IP's door.
De addins voor Chrome en Firefox gebruiken niet hun eigen resolver implementatie, maar de addin doet een losse query naar de DNS server en controleerd of deze vervolgens DNSSEC informatie terug krijgt.
Echter die methode is niet water dicht. Stel ik heb twee DNS servers en om te testen installeerd ik DNSSEC op slechts 1 server. Als de systeem resolver gebruik maakt van de DNSSEC server en de addin net de andere server pakt, dan zal de addin aangeven dat het domein niet is beschermd middels DNSSEC. De systeem resolver zal normaal deze informatie niet doorgeven. Dat is ook niet nodig omdat als de DNSSEC informatie niet klopt, de resolver het antwoord negeert. Veel mailserver spam filters controleren of het domain ook een zogenaamd SPF (txt) record heeft. Als de mail afkomt van een server welke vermeld is in het SPF record, dan wordt de mail geaccepteerd. Al de mail is verstuurd vanaf een mailserver welke niet in het SPF record staat dan wordt de mail mogelijk gedropped (afhankelijk van instellingen van het filter). Is er geen SPF record dan wordt de controle niet uitgevoerd.
DNSSEC-compatible resolvers werken op een soortgelijke manier. Indien er geen DNSSEC informatie is wordt er ook niet gecontroleerd en wordt het antwoord als 'correct' beschouwd. Als DNSSEC geimplementeerd is dan wordt ook dat antwoord gecontroleerd en als de infomatie foutief is wordt het gehele antwoord op de DNS query gedropped.
DNSSEC is heel erg simpel gezegd niet meer dan een checksum berekend over een aantal velden in het antwoord van de DNS server. DomainsKeys werkt op dezelfde manier alleen gebruikt voor de checksum een aantal header velden. DomainsKeys leunt sterk op van DNS records, dus is het belangrijk dat die gegevens zou betrouwbaar mogelijk zijn.
Ik heb voor mijn domeinen al bijna twee jaar DNSSEC en DomainKeys geconfigureerd, alleen wat er tot iets meer dan een jaar geleden geen mogelijkheid om MIJN public key te controleren.
Sinds een jaar staat mijn public key ook op de VeriSign DNS servers via mijn DNS intermediair. VeriSign (welke de DNS voor onder andere .com, .net en .org beheerd) koppelt vervolgens de public key aan de authoritive DNS gegevens. De public key van Verisign en ook SDIN staan weer op de DNS servers van ICANN samen met de 'root' key van ICANN zelf. Meer info: http://www.root-dnssec.org/
Nu moet ik alleen nog wachten tot directnic eindelijk de mogelijkheid om DNSSEC keys voor .NL domeinen te plaatsen op de SIDN servers. Tot die tijd geeft mijn server wel DNSEC informatie voor mijn .NL domein terug, maar is er nog geen mogelijkheid om de authenticiteit van de key welke gebruikt is te controleren. Daardoor is er geen volledige chain of trust.
Houd er wel rekening mee dat als je je DNSSEC public key publiceert, als je DNS server DNSSEC correct geimplementeerd moeten hebben. Anders loopt je de kans dat resolvers antwoorden weggooien omdat er geen of een incorrecte checksum wordt meegegeven.
Wat kan ik doen als ik wil profiteren van de extra beveiliging die DNSSEC heeft te bieden?
Dat is afhankelijk van de manier waarop nu gebruik maakt van het DNS. Vaak verzorgt uw internet service provider (ISP) de DNS-dienst waar u nu gebruik van maakt. Uw ISP is in dat geval de aangewezen partij om DNSSEC te activeren. U kunt daarvoor contact met hen opnemen. Het is ook mogelijk dat zich tussen uw computer en de DNS-server(s) een modem of router (firmware) bevindt dat/die geen DNSSEC begrijpt. De firmware moet dan, indien mogelijk, worden bijgewerkt. Gevorderde gebruikers kunnen ook zelf een name server instellen die DNSSEC-ondersteuning heeft, of eventueel zelf een lokale name server installeren met DNSSEC-ondersteuning. Doet u deze test in een bedrijfsmatige omgeving, dan is uw afdeling systeembeheer, of uw ICT-dienstverlener het aangewezen aanspreekpunt. Houd er rekening mee dat u in eerste instantie niet meteen wordt begrepen. DNSSEC kennis is nog geen gemeengoed.
bron: http://dnssectest.sidn.nl/faq_nl.php
Ik zelf gebruik de Google DNS servers, blijkbaar nog geen DNSSEC ondersteuning daar? Of mijn Draytek-router doet moeilijk, maar dat lijkt me niet. Ik ga het even uitzoeken
Dat is afhankelijk van de manier waarop nu gebruik maakt van het DNS. Vaak verzorgt uw internet service provider (ISP) de DNS-dienst waar u nu gebruik van maakt. Uw ISP is in dat geval de aangewezen partij om DNSSEC te activeren. U kunt daarvoor contact met hen opnemen. Het is ook mogelijk dat zich tussen uw computer en de DNS-server(s) een modem of router (firmware) bevindt dat/die geen DNSSEC begrijpt. De firmware moet dan, indien mogelijk, worden bijgewerkt. Gevorderde gebruikers kunnen ook zelf een name server instellen die DNSSEC-ondersteuning heeft, of eventueel zelf een lokale name server installeren met DNSSEC-ondersteuning. Doet u deze test in een bedrijfsmatige omgeving, dan is uw afdeling systeembeheer, of uw ICT-dienstverlener het aangewezen aanspreekpunt. Houd er rekening mee dat u in eerste instantie niet meteen wordt begrepen. DNSSEC kennis is nog geen gemeengoed.
bron: http://dnssectest.sidn.nl/faq_nl.php
Ik zelf gebruik de Google DNS servers, blijkbaar nog geen DNSSEC ondersteuning daar? Of mijn Draytek-router doet moeilijk, maar dat lijkt me niet. Ik ga het even uitzoeken
Jammer maar bij mij doet IE9 het wel.
Goede zet!
Ik denk dat binnenkort de grote hostingproviders (bijv. Leaseweb en Transip) over zullen gaan op dnssec. Zodra dat gebeurt is het overgrote deel van het Nederlandse internet over op dnssec en is het dus grotendeels veilig
-edit-
TransIP is dus een van de registrars die overgaan
Ik denk dat binnenkort de grote hostingproviders (bijv. Leaseweb en Transip) over zullen gaan op dnssec. Zodra dat gebeurt is het overgrote deel van het Nederlandse internet over op dnssec en is het dus grotendeels veilig
-edit-
TransIP is dus een van de registrars die overgaan
[Reactie gewijzigd door TvdW op dinsdag 15 mei 2012 10:37]
Ik kan bij TransIP DNSSEC nu al activeren voor mijn .nl domeinen.
En vergeet Mijndomein niet; samen met TransIP die al bevestigd was, heb je dan de grootste twee al zo'n beetje te pakken.
eindelijk dnssec, mocht ook eens tijd worden :-)
Gelukkig komt Microsoft server 2012 nu eindelijk ook eens met goede dnssec ondersteunen.
zou dit het einde betekenen van dns mitm aanvallen?
Gelukkig komt Microsoft server 2012 nu eindelijk ook eens met goede dnssec ondersteunen.
zou dit het einde betekenen van dns mitm aanvallen?
Met Zonesigner kun je het signeren wat makkelijker uitvoeren. Op Youtube staat een handig filmpje dat uitlegt hoe je DNSSEC kunt instellen: http://www.youtube.com/watch?v=7ksgTFxAg6U
Jammer dat onze servers tinydns / djbdns gebruiken, deze ondersteunen geen DNSSEC.
dit omdat de maker dat onzin vind....
http://cr.yp.to/djbdns/forgery.html
dit omdat de maker dat onzin vind....
http://cr.yp.to/djbdns/forgery.html
Hij vind het geen onzin, hij geeft enkel aan dat het al 15 jaar duurt en nog steeds niet tot een oplossing heeft geleid. Op het moment dat DNS Servers & Browsers het ondersteunen, dan zal hij zijn mening heus wel bijstellen. Neemt niet weg dat hij denkt aan een betere oplossing te werken.
ja, excuus verkeerd gezegt. maar helaas ben ik daar niet meegeholpen.
Ik zal eens vragen hoe hij er nu overdenkt.
Ik zal eens vragen hoe hij er nu overdenkt.
Tja, als meneer Bernstein het zelf niet uitgevonden heeft is het inderdaad niet goed
Dan J. Bernstein is een geniale maar ongelofelijk arrogante vent met een vreselijk slechte codeerstijl. Hij is altijd 1 van de eersten om een probleem te herkennen en een oplossing aan te dragen maar zijn oplossing houdt altijd in om zelf een programmaatje in elkaar te knutselen en vervolgens aan iets anders te beginnen.
Ik heb mij eind jaren 90 laten verleiden om qmail te installeren "omdat het zo veilig was" en omdat de ene na de andere root exploit voor sendmail uitkwam.
Ik heb in die tijd regelmatig e-mail contact gehad met hem met vragen en verzoeken over qmail. Hij weigerde alles, Toen qmail zwaar uit de tijd begon te raken heeft hij de zaak in public domain gemikt en vervolgens er niets meer aan gedaan. Dit alleen maar omdat hij niet zijn ongelijk wil toegeven.
Voorbeeld: DJB vond in mail delivery dat problemen opgelost moesten worden met een bouncemail. Als bijvoorbeeld een mail binnenkwam voor een niet-bestaande gebruiker werd de mail geaccepteerd en vervolgens een bounce mailtje gestuurd naar de afzender met "Your mail could not be delivered". Dit was natuurlijk een spamgoudmijn, stuur gewoon een mail naar reutelblaat@eenqmailserver.com met een gespoofde afzender en jouw qmail begon vrolijk de spam terug te sturen. Maar wel volledig RFC-822 compliant.
Hij weigerde ook maar een letter code te wijzigen zelfs niet toen de hele wereld erachter kwam dat bounce mailtjes zoveel mogelijk vermeden moesten worden. Uiteindelijk heb ik qmail zelf maar aangepast, authenticatie, blocklists, userverificatie etc. Ik gebruik vandaag de dag nog steeds qmail maar ik heb 't inmiddels zo zwaar verbouwd dat het bijna niet meer als zodanig te herkennen is.
Mijn tip: Als die man met iets nieuws komt luister er dan goed naar en kijk langs de arrogantie. Ga alleen niet zomaar zijn software gebruiken en helemaal niet in een zakelijke omgeving. Support zal je van hem niet krijgen.
Dan J. Bernstein is een geniale maar ongelofelijk arrogante vent met een vreselijk slechte codeerstijl. Hij is altijd 1 van de eersten om een probleem te herkennen en een oplossing aan te dragen maar zijn oplossing houdt altijd in om zelf een programmaatje in elkaar te knutselen en vervolgens aan iets anders te beginnen.
Ik heb mij eind jaren 90 laten verleiden om qmail te installeren "omdat het zo veilig was" en omdat de ene na de andere root exploit voor sendmail uitkwam.
Ik heb in die tijd regelmatig e-mail contact gehad met hem met vragen en verzoeken over qmail. Hij weigerde alles, Toen qmail zwaar uit de tijd begon te raken heeft hij de zaak in public domain gemikt en vervolgens er niets meer aan gedaan. Dit alleen maar omdat hij niet zijn ongelijk wil toegeven.
Voorbeeld: DJB vond in mail delivery dat problemen opgelost moesten worden met een bouncemail. Als bijvoorbeeld een mail binnenkwam voor een niet-bestaande gebruiker werd de mail geaccepteerd en vervolgens een bounce mailtje gestuurd naar de afzender met "Your mail could not be delivered". Dit was natuurlijk een spamgoudmijn, stuur gewoon een mail naar reutelblaat@eenqmailserver.com met een gespoofde afzender en jouw qmail begon vrolijk de spam terug te sturen. Maar wel volledig RFC-822 compliant.
Hij weigerde ook maar een letter code te wijzigen zelfs niet toen de hele wereld erachter kwam dat bounce mailtjes zoveel mogelijk vermeden moesten worden. Uiteindelijk heb ik qmail zelf maar aangepast, authenticatie, blocklists, userverificatie etc. Ik gebruik vandaag de dag nog steeds qmail maar ik heb 't inmiddels zo zwaar verbouwd dat het bijna niet meer als zodanig te herkennen is.
Mijn tip: Als die man met iets nieuws komt luister er dan goed naar en kijk langs de arrogantie. Ga alleen niet zomaar zijn software gebruiken en helemaal niet in een zakelijke omgeving. Support zal je van hem niet krijgen.
Je kunt vinden van Bernstein wat je wilt, maar wat betreft DNSSEC heeft hij gewoon hele sterke punten. De eeuwig durende ontwikkeling daargelaten, DNSSEC vult gewoon niet alle gaten en brengt daarentegen nieuwe vulnerabilities met zich mee: http://cr.yp.to/talks/2012.03.08-1/slides.pdf
Ik heb er in mijn master thesis ook nog enkele hoofdstukken aan besteed: http://curvedns.on2it.net..._security_with_curves.pdf
Ik heb er in mijn master thesis ook nog enkele hoofdstukken aan besteed: http://curvedns.on2it.net..._security_with_curves.pdf
Zoals ik al zei: Als die man iets zegt moet je naar hem luisteren, dus ik ben het helemaal met je eens.
Maar als hij nou in plaats van te roepen "het is allemaal troep" zich wat constructiever zou opstellen en zou gaan samenwerken met de community in plaats van alleen maar alles af te kraken zou het internet een stuk beter en veiliger worden.
De slides over DNSSEC zijn typerend voor hem. Bijzonder aanmatigend. Met name dit stukje:
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Dat geeft bij mij toch het idee dat die man vreselijk aan een "not-invented-here" syndroom lijdt - 108 slides aanklachten, vooral tegen DNSSEC en geen enkele suggestie hoe het beter zou kunnen. Daarnaast maakt hij denk ik de zaak in mijn ogen erger dan het is. In zijn tirade staan diverse argumenten vermeld die niets met DNSSEC an sich te maken hebben. (Example 5 op slide 108, Conficker heeft niets met cryptografie/DNSSEC te maken e.d.)
Als hij daadwerkelijk constructief bezig wil zijn zou hij aan oplossingen moeten denken - hij is er per slot van rekening al zo'n 10 jaar mee bezig! Tot op de dag van vandaag is er nog niet 1 RFC van zijn hand verschenen en hij heeft er toch wel de kennis voor. In het bedrijfsleven is het simpel, geen standaard, geen ondersteuning van ons..
Nogmaals: ik vind DJB een geniaal man die vrijwel alle aspecten van (inter)netwerken beter snapt dan vrijwel iedereen maar ik vind hem ook een ontzettend arrogante en megalomane eikel die enkel door zijn houding al zijn mogelijkheden tot verbetering van het internet laat liggen.
Maar als hij nou in plaats van te roepen "het is allemaal troep" zich wat constructiever zou opstellen en zou gaan samenwerken met de community in plaats van alleen maar alles af te kraken zou het internet een stuk beter en veiliger worden.
De slides over DNSSEC zijn typerend voor hem. Bijzonder aanmatigend. Met name dit stukje:
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Dat geeft bij mij toch het idee dat die man vreselijk aan een "not-invented-here" syndroom lijdt - 108 slides aanklachten, vooral tegen DNSSEC en geen enkele suggestie hoe het beter zou kunnen. Daarnaast maakt hij denk ik de zaak in mijn ogen erger dan het is. In zijn tirade staan diverse argumenten vermeld die niets met DNSSEC an sich te maken hebben. (Example 5 op slide 108, Conficker heeft niets met cryptografie/DNSSEC te maken e.d.)
Als hij daadwerkelijk constructief bezig wil zijn zou hij aan oplossingen moeten denken - hij is er per slot van rekening al zo'n 10 jaar mee bezig! Tot op de dag van vandaag is er nog niet 1 RFC van zijn hand verschenen en hij heeft er toch wel de kennis voor. In het bedrijfsleven is het simpel, geen standaard, geen ondersteuning van ons..
Nogmaals: ik vind DJB een geniaal man die vrijwel alle aspecten van (inter)netwerken beter snapt dan vrijwel iedereen maar ik vind hem ook een ontzettend arrogante en megalomane eikel die enkel door zijn houding al zijn mogelijkheden tot verbetering van het internet laat liggen.
Dit creeërt dan wel weer een beetje het gevoel van schijnveiligheid. Naar mijn mening zijn er in het verleden maar relatief weinig aanvallen op DNS geweest, en zullen er ook maar weinig aanvallen op DNS uitgevoerd worden omdat er veel lucratievere manieren zijn voor "hackers" om gebruikers uit te buiten. Dit maakt het internet niet heel veel veiliger
Ja, maar als je dit open laat, en in de loop van de tijd worden de andere manieren voor hackers minder interessant (betere voorlichting en beveiliging bij gebruikers), dan zouden ze misschien juist hun aandacht hierop kunnen richten.
'T is een beetje als je huis beveiligen: niet dat ene bovenlicht vergeten, anders is dat de zwakste schakel
'T is een beetje als je huis beveiligen: niet dat ene bovenlicht vergeten, anders is dat de zwakste schakel
Helemaal geen schijnveiligheid, aangezien het een techniek is die werkt. Het internet wordt er een beetje veiliger van, hoewel er genoeg aanvalsvectoren overblijven. De gemiddelde gebruiker zal hier niks van merken, maar dat maakt het nog geen zinloze techniek.
Ik geloof ook wel dat de techniek prima zal werken, echter doet dit op de argeloze gebruiker overkomen als: "oh, dan hoef ik niet meer op te letten wat ik intyp/aanklik.", wat natuurlijk grote onzin is. Verder zeg ik ook nergens dat ik het zinloze techniek vind, echter zal de toegevoegde waarde voor 99% van de internetgebruikers nihil zijn.
Dit is op zich een goeie zaak. Het is alleen wel zo dat DNSSEC gebruik maakt van Public Key Cryptography om de DNS verzoeken te valideren. Op zich wel een goed idee alleen heeft mijn vertrouwen in het PKI een deuk opgelopen door incidenten in het recente verleden.
Het gaat er allemaal om wie jij (of je provider) vertrouwt en daar zou het wel eens mis kunnen gaan. Als ik op 1 of andere manier iets zou kunnen doen met de Key Signing Key (DS Record in DNS) of de Zone Signing Key (opgeslagen in de eigen DNS zone) kan ik valide lijkende DNS verzoeken sturen en bijvoorbeeld spoofing aanvallen uitvoeren.
Al met al ben ik hier wel blij mee, maar het moet mijn inziens niet worden gezien als een soort heilige graal voor het verhogen van de veiligheid van DNS.
Het gaat er allemaal om wie jij (of je provider) vertrouwt en daar zou het wel eens mis kunnen gaan. Als ik op 1 of andere manier iets zou kunnen doen met de Key Signing Key (DS Record in DNS) of de Zone Signing Key (opgeslagen in de eigen DNS zone) kan ik valide lijkende DNS verzoeken sturen en bijvoorbeeld spoofing aanvallen uitvoeren.
Al met al ben ik hier wel blij mee, maar het moet mijn inziens niet worden gezien als een soort heilige graal voor het verhogen van de veiligheid van DNS.
Gratis 2 daagse cursus met oefeningen bij de NGN
Stichting NLNetlabs is 1 van de belangrijkste organisaties voor DNSSEC en wordt sinds begin 2012 voor een groot percentage gesubsidieerd door SIDN.
Stichting NLNetlabs is 1 van de belangrijkste organisaties voor DNSSEC en wordt sinds begin 2012 voor een groot percentage gesubsidieerd door SIDN.
[Reactie gewijzigd door smartbit op dinsdag 15 mei 2012 13:09]
Of juist niet.Zo moeten cache poisoning en man in the middle-aanvallen worden voorkomen.
De kans is veel groter dat iemand toegang heeft tot zonefile dan dat hij je internet verkeer kan aftappen/rerouten.
Het lost niets op brengt alleen extra aanvalsvectoren met zich mee....
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
