Aantal met dnssec ondertekende .nl-domeinen groeit tot boven 600.000
Het aantal met dnssec ondertekende .nl-domeinen is in de afgelopen twee weken verdubbeld en bedraagt nu meer dan 600.000. Nederland loopt daarmee ver vooruit op andere landen. De groei komt vooral door een kortingsactie van de SIDN.
De SIDN noemt het doorbreken van de 600.000 met dnssec ondertekende .nl-domeinnamen een mijlpaal. Pas sinds mei van dit jaar is het voor beheerders van een .nl-domein mogelijk om het dnssec-protocol te activeren, maar de groei verloopt sindsdien exponentieel. Eerder deze maand werd het aantal van 355.000 ondertekende domeinnamen bereikt en daarmee nam Nederland de koppositie over van Tsjechië.
Sinds die tijd is het aantal dus nog eens enorm toegenomen, vooral omdat grote partijen als TransIP en MijnDomein druk bezig zijn met het ondertekenen van domeinnamen. Met name voor grote registrars heeft de SIDN het ondertekenen met dnssec interessant gemaakt door tot juli 2014 een korting te bieden van 7 cent per domein per kwartaal. De stimulans heeft er al voor gezorgd dat zo’n 130 bij de SIDN aangesloten registrars de overstap naar dnssec hebben gemaakt. In juni werd dnssec daarnaast verplicht voor domeinnamen van overheidsorganisaties.
Dnssec is ontwikkeld als aanvulling op het dns-protocol en moet cache poisoning en man in the middle-aanvallen onmogelijk maken. Dnssec koppelt het antwoord op een dns-query aan een digitale handtekening, om de authenticiteit te controleren. Dns-servers worden hiertoe voorzien van een public key cryptography-systeem: dns-informatie over een domein wordt ondertekend met een private key, zodat gebruikers met een publieke sleutel kunnen verifiëren dat er niet met de informatie gerommeld is.
Reacties (24)
Nu heb ik al het een en het ander hierover gelezen , maar blijkt dat als men wat veranderd op de geinfecteerde computer dat het hele DNSSEC helemaal geen zin heeft. Immers leuk en al dat een query aan een handtekening gekoppeld word , maar als noobs nog steeds op www.hottemail.com ipv www.hotmail.com inloggen heeft DNSSEC niets te bieden.
DNSSEC laat immers niet gebruikers hun computer updaten / hun flash / java / internet explorer etc.
Geef het een paar maanden en ik denk dat hackers hier wel weer wat omheen vinden.
DNSSEC laat immers niet gebruikers hun computer updaten / hun flash / java / internet explorer etc.
Geef het een paar maanden en ik denk dat hackers hier wel weer wat omheen vinden.
DNSSEC is dan ook een bescherming tegen een "man-in-the-middle", iemand die op de route tussen jou en DNS zit.
Net zoals dat https je http-verkeer versleutelt, zodat niemand tussen jou en de doelserver de pakketjes kan lezen, doet DNSSEC dat voor DNS.
Maar inderdaad ook aan https heb je natuurlijk niet zo heel veel als het je _eindstation_ is dat is besmet. Zodra je aan jouw kant de gegevens decrypt zijn er weer mogelijkheden tot manipulatie.
Beveiliging is dan ook niet iets dat je op 1 punt ,moet/kan doen, het gaat erom dat je de beveiliging op alle mogelijke lagen die aangevallen kunnen worden doet.
Dus, encrypteer je disk tegen fysieke diefstal. Draai virusscanners en hou je OS/browser/software up-to-date voor bescherming tegen aanvallen op je computer. Versleutel al je verkeer (https, dnssec) tegen afluisteren. Gebruik overal sterke (en van elkaar verschillende) wachtwoorden, om je accounts te beschermen.
(Etc. etc. etc.)
[edit vanwege typo: DNSSEX is iets heel anders dan DNSSEC]
Net zoals dat https je http-verkeer versleutelt, zodat niemand tussen jou en de doelserver de pakketjes kan lezen, doet DNSSEC dat voor DNS.
Maar inderdaad ook aan https heb je natuurlijk niet zo heel veel als het je _eindstation_ is dat is besmet. Zodra je aan jouw kant de gegevens decrypt zijn er weer mogelijkheden tot manipulatie.
Beveiliging is dan ook niet iets dat je op 1 punt ,moet/kan doen, het gaat erom dat je de beveiliging op alle mogelijke lagen die aangevallen kunnen worden doet.
Dus, encrypteer je disk tegen fysieke diefstal. Draai virusscanners en hou je OS/browser/software up-to-date voor bescherming tegen aanvallen op je computer. Versleutel al je verkeer (https, dnssec) tegen afluisteren. Gebruik overal sterke (en van elkaar verschillende) wachtwoorden, om je accounts te beschermen.
(Etc. etc. etc.)
[edit vanwege typo: DNSSEX is iets heel anders dan DNSSEC]
[Reactie gewijzigd door Keypunchie op zaterdag 18 augustus 2012 11:23]
Als aanvulling kun je als gebruiker op je systeem ook de progjes van OpenDNS install
DNSCrypt --> http://www.opendns.com/technology/dnscrypt/
OpenDNS Updater --> http://www.opendns.com/support/dynamic_ip_downloads/
plus er staan nog wat fijne tools die je kunt gebruiken
DNSCrypt --> http://www.opendns.com/technology/dnscrypt/
OpenDNS Updater --> http://www.opendns.com/support/dynamic_ip_downloads/
plus er staan nog wat fijne tools die je kunt gebruiken
DNSSEC versleutelt de DNS reply's niet, maar de reply's worden gesignd. Ondertekend met de private key, waarbij de signature is te controleren via de public key. De public key van de nameservers is bekend bij SIDN, en dus is de hele chain te controleren.
Dit is nog niet 100% veilig, het moet natuurlijk ook zo zijn dat de root nameservers en .nl zone net zo beveiligd zijn, en de client moet al weten welke servers de root servers zijn en wat hun public key is. Dat is natuurlijk ook het geval als een client DNSSEC ondersteunt.
Er wordt dus gebruik gemaakt van de mogelijkheid om signatures te controleren, zoals mogelijk is met asynchrone encryptie, of public key cryptography. Er wordt géén gebruik gemaakt van versleutelde requests/replies. Dat zou wel kunnen met dezelfde methode, maar is niet de achterliggende gedachte.
De enige reden voor DNSSEC is -op dit moment- het kunnen controleren van die signatures en dus of de DNS replies wel naar de juiste servers verwijzen. Dat maakt het lastiger om MITM aanvallen uit te voeren omdat je naast bijvoorbeeld een vals SSL certificaat of onterecht verkregen certificaat, ook de DNS infrastructuur moet vervalsen. Dit zou het Diginotar-verhaal veel sneller onder de aandacht hebben gebracht.
Dit is nog niet 100% veilig, het moet natuurlijk ook zo zijn dat de root nameservers en .nl zone net zo beveiligd zijn, en de client moet al weten welke servers de root servers zijn en wat hun public key is. Dat is natuurlijk ook het geval als een client DNSSEC ondersteunt.
Er wordt dus gebruik gemaakt van de mogelijkheid om signatures te controleren, zoals mogelijk is met asynchrone encryptie, of public key cryptography. Er wordt géén gebruik gemaakt van versleutelde requests/replies. Dat zou wel kunnen met dezelfde methode, maar is niet de achterliggende gedachte.
De enige reden voor DNSSEC is -op dit moment- het kunnen controleren van die signatures en dus of de DNS replies wel naar de juiste servers verwijzen. Dat maakt het lastiger om MITM aanvallen uit te voeren omdat je naast bijvoorbeeld een vals SSL certificaat of onterecht verkregen certificaat, ook de DNS infrastructuur moet vervalsen. Dit zou het Diginotar-verhaal veel sneller onder de aandacht hebben gebracht.
Het enige wat DNSSEC doet is zorgen (mits lokale resolver daarin voorziet) dat DOMEIN+IP adres combinatie niet vervalst kan worden.DNSSEC is dan ook een bescherming tegen een "man-in-the-middle", iemand die op de route tussen jou en DNS zit.
Maar het beschermd je helemaal NIET tegen een "man-in-the-middle" aanvalsvector.
Bij een "man-in-the-middle" aanvalsvector heeft iemand toegang tot verkeer tussen jou en een bepaalde server.
Wat jij terug krijgt hoeft dus helemaal niet van de server af te komen omdat in inhoud van de packets nog steeds onderschept en aangepast kunnen worden.
Alleen in combinatie met SSL verbinding verklein je de kans.
Eind punten (server of client) blijven altijd kwetsbaar.
Verder is DNSSEC iets uit de vorige eeuw en er is een reden waarom het zolang op de plank is blijven liggen.... noodzaak, kosten, resources.
Bovendien als "man-in-the-middle" mogelijk is, heb je hele andere problemen, die veel verder gaan dan dat iemand je verkeer naar een IP wil omleiden.
Verder is het naast de kortingen die SIDN verstrekt ook een andere reden dat grote partijen hun klanten (ongevraagd?) van DNSSEC voorzien.
Je kunt niet zomaar een dergelijke domein verhuizen namelijk het is een sneaky vorm van vendor lockin. Er komt bij verhuizing veel meer bij kijken. (tenminste als site niet offline mag gaan)
[Reactie gewijzigd door totaalgeenhard op zondag 19 augustus 2012 03:44]
DNSSEC is natuurlijk geen totaal oplossing voor alle internet ellende in deze wereld, maar gewoon een klein onderdeel van een totaal pakket aan veiligheids maatregelen die men kan nemen.
Erg mooie ontwikkeling dat Nederland niet alleen de koppositie behoudt, maar deze ook nog verder vergroot.
En wellicht kan DNSSEC ook de noodzaak voor commerciele SSL certificaten onnodig maken, omdat domeinen al een certificaat hebben?
Geen goede ontwikkeling voor Verisign, Komodo en consorten.
https://grepular.com/DNSSEC_Will_Kill_Commercial_CAs
Wellicht dat over een paar jaarcertificaten ondergebracht kunnen worden in het domein.
http://tools.ietf.org/html/rfc4398
En wellicht kan DNSSEC ook de noodzaak voor commerciele SSL certificaten onnodig maken, omdat domeinen al een certificaat hebben?
Geen goede ontwikkeling voor Verisign, Komodo en consorten.
https://grepular.com/DNSSEC_Will_Kill_Commercial_CAs
Wellicht dat over een paar jaarcertificaten ondergebracht kunnen worden in het domein.
http://tools.ietf.org/html/rfc4398
Ik denk het niet, aangezien dat DNSSEC alleen voor DNS is... niet voor het veilig versturen van informatie, Keypunchie geeft meer duidelijkheid
Mooi voor gevoelens van nationale trots, misschien. Maar ik bezoek toch meer .com en .net en andere websites, dan .nl-websites. Ik zou het het prettigst vinden als _alle_ DNS-boeren hun beste beentje voor zouden zetten.Erg mooie ontwikkeling dat Nederland niet alleen de koppositie behoudt, maar deze ook nog verder vergroot.
Leuk dat wij het beste jongetje van de klas zijn, maar als internetgebruiker zie ik veel liever een hele klas vol met slimme jongetjes.
Als er een schaap over de dam is, dan volgen er anderen.
Het is een kwestie van tijd voordat het geimplementeerd wordt. Ik kan me voorstellen dat dit over een jaar wellicht binnen de hele EU verplicht wordt voor banken en andere financiele instellingen, al is het maar 1 druppel op de gloeiende plaat.
Daarnaast wordt er steeds meer gestimuleerd om over te gaan.
"In juni werd dnssec daarnaast verplicht voor domeinnamen van overheidsorganisaties.", het is een kwestie van tijd dat meer landen dit gaan doen.
Het is een kwestie van tijd voordat het geimplementeerd wordt. Ik kan me voorstellen dat dit over een jaar wellicht binnen de hele EU verplicht wordt voor banken en andere financiele instellingen, al is het maar 1 druppel op de gloeiende plaat.
Daarnaast wordt er steeds meer gestimuleerd om over te gaan.
"In juni werd dnssec daarnaast verplicht voor domeinnamen van overheidsorganisaties.", het is een kwestie van tijd dat meer landen dit gaan doen.
In de VS doen ze het ook al, het Witte Huis is bijvoorbeeld al om.
Als je toch DNSSEC moet inrichten voor .NL dan is het maar een kleine moeite om andere TLDs te doen, het moeilijkste stuk heb je al gehad. Bij TransIP kun je dus ook andere TLDs van DNSSEC voorzien, ik heb al .com, .net. .org en .eu domeinen gedaan.
SIDN richt zich natuurlijk alleen op .nl maar alle andere TLDs profiteren mee van de infrastructuur die wordt ontwikkeld.
SIDN richt zich natuurlijk alleen op .nl maar alle andere TLDs profiteren mee van de infrastructuur die wordt ontwikkeld.
TransIP mijn DNS domein boer.. geeft standaard DNSSEC mee met alle TLD die dat ondersteunen...
Aangezien TransIP 1 van de grotere is in nederland kan dat best wel een impact hebben.
Aangezien TransIP 1 van de grotere is in nederland kan dat best wel een impact hebben.
dnsseq is ECHT is heel anders dan SSL...
waar je bij dnssec alleen maar praat over welke ip er bij naam x.y.z hoort, weet je verder nog niet zo heel veel, je zou na een geldige dnssec request namelijk nog steeds met de routing van een pc kunnen knutselen om het ip ergens anders heen te sturen je bent dan enkel maar 1 laag dieper, dus voor jan met de pet zou je kunnen zeggen dat dnssec genoeg is, omdat je er vanuit kunt gaan dat netwerken op ip level voldoende zijn beschermt...
maar nu komt het, dat is natuurlijk niet zo... dus zonder verdere check ben je nog steeds zo kwetsbaar zij het iets dieper in de network stack,
men kan dnssec dus zien als één van een paartje.. met dnssec zorg je voor een verbinding naar de juiste server, en met sert valideer je dat het idd de juiste server is. in het ideale geval zou het zelfs zo zijn dat je op dns niveau zelfs al kon vaststellen met welke sleutel je later te maken krijgt - zodat zelfs vals uitgeven certificaten veel moeilijker te gebruiken zijn.. maar zover ik weet hebben ze dat niet gedaan - en dat is best heel jammer..
zowiso moet ik eerlijk vaststellen dat ik de huidige trusted cert eigenlijk niet meer vertrouw ... daar zou een beter en transparanter systeem voor moeten komen.
waar je bij dnssec alleen maar praat over welke ip er bij naam x.y.z hoort, weet je verder nog niet zo heel veel, je zou na een geldige dnssec request namelijk nog steeds met de routing van een pc kunnen knutselen om het ip ergens anders heen te sturen je bent dan enkel maar 1 laag dieper, dus voor jan met de pet zou je kunnen zeggen dat dnssec genoeg is, omdat je er vanuit kunt gaan dat netwerken op ip level voldoende zijn beschermt...
maar nu komt het, dat is natuurlijk niet zo... dus zonder verdere check ben je nog steeds zo kwetsbaar zij het iets dieper in de network stack,
men kan dnssec dus zien als één van een paartje.. met dnssec zorg je voor een verbinding naar de juiste server, en met sert valideer je dat het idd de juiste server is. in het ideale geval zou het zelfs zo zijn dat je op dns niveau zelfs al kon vaststellen met welke sleutel je later te maken krijgt - zodat zelfs vals uitgeven certificaten veel moeilijker te gebruiken zijn.. maar zover ik weet hebben ze dat niet gedaan - en dat is best heel jammer..
zowiso moet ik eerlijk vaststellen dat ik de huidige trusted cert eigenlijk niet meer vertrouw ... daar zou een beter en transparanter systeem voor moeten komen.
DNSSEC gebruikt GEEN certificaten. DNSSEC gebruik een private/pub keypair. De public key plaats je in je DNS zone en geef je ook door aan je upstream DNS provider (meestal de register). Upstream DNS providers houden dus niet meer alleen de authoritive DNS records bij, maar bewaren ook de DNSSEC records. En de upstream gaat nu helemaal door tot de root DNS servers.
De public key van SIDN is bekend bij de root servers, de public key van je register is bekend bij SIDN en jouw key is dus bekend bij jouw DNS provider.
Echter Duitsland geeft officieel nog geen DNSSEC support. De register kan het eventueel wel aanbieden. Maar de public key van die register is onbekend voor het .DE domein. Jouw DNS is alleen beschermd door je DNS register, maar de register zelf is niet beschermd. Dat betekend dat als iemand de DNS van de register weet te hacken, deze ook de public keys van de domeinen van de klanten kan aanpassen. Hiermee is dan een denial of service mogelijk. Immers het is bekend dat het domein DNSSEC support heeft en DNS resolvers met support voor DNSSEC, zullen dan de antwoorden van jouw authoritive DNS servers niet accepteren omdat het antwoord van jouw server 'verkeerd' is ondertekend.. Callback naar classis DNS (DNSSEC records negeren) is verboden. Anders is het namelijk voldoende door slechts de public keys van de 13 root servers (clusters) te veranderen om de ondertekening uit te schakelen.
Maar omdat het antwoord dus onjuist 'lijkt' zal de resolver terug geven dat de query niet uitgevoerd kan worden, zeg maar een 'host not found'.
Echter TLD's met volledig DNSSEC support zijn hiertegen beschermd omdat de public key niet alleen bekend is bij jouw provider, maar ook bij de TLD beheerder welke ook deze public key publiceert.
DNSSEC is dus geen vervanging van SSL/TLS. Het is een aanvulling op het bestaande DNS systeem zoals HTTPS dat is voor HTTP.
De public key van SIDN is bekend bij de root servers, de public key van je register is bekend bij SIDN en jouw key is dus bekend bij jouw DNS provider.
Echter Duitsland geeft officieel nog geen DNSSEC support. De register kan het eventueel wel aanbieden. Maar de public key van die register is onbekend voor het .DE domein. Jouw DNS is alleen beschermd door je DNS register, maar de register zelf is niet beschermd. Dat betekend dat als iemand de DNS van de register weet te hacken, deze ook de public keys van de domeinen van de klanten kan aanpassen. Hiermee is dan een denial of service mogelijk. Immers het is bekend dat het domein DNSSEC support heeft en DNS resolvers met support voor DNSSEC, zullen dan de antwoorden van jouw authoritive DNS servers niet accepteren omdat het antwoord van jouw server 'verkeerd' is ondertekend.. Callback naar classis DNS (DNSSEC records negeren) is verboden. Anders is het namelijk voldoende door slechts de public keys van de 13 root servers (clusters) te veranderen om de ondertekening uit te schakelen.
Maar omdat het antwoord dus onjuist 'lijkt' zal de resolver terug geven dat de query niet uitgevoerd kan worden, zeg maar een 'host not found'.
Echter TLD's met volledig DNSSEC support zijn hiertegen beschermd omdat de public key niet alleen bekend is bij jouw provider, maar ook bij de TLD beheerder welke ook deze public key publiceert.
DNSSEC is dus geen vervanging van SSL/TLS. Het is een aanvulling op het bestaande DNS systeem zoals HTTPS dat is voor HTTP.
Het ging over de overbodigheid commerciële certificaten, niet SSL/TLS.DNSSEC is dus geen vervanging van SSL/TLS. Het is een aanvulling op het bestaande DNS systeem zoals HTTPS dat is voor HTTP.
Als DNS veilig is dan kan je bijvoorbeeld:
SSH host key informatie aanbieden (is al een RFC voor)
Certificaten aanbieden
Op dit moment moet je dat nog allemaal laten certificeren door een CA. Als DNS veilig is, zou dat allemaal verandert kunnen worden. Dan ben je wel afhankelijk van DNSSEC, maar niet meer van een CA.
ik heb net het stuk nog eens opnieuw gelezen, maar wat ze daar eigenlijk voorstellen is om een dns reccord oid toe te voegen waarin de hashes van jouw certs staan. zodat self-signed keys, toch enigszins te vertouwen zijn...
als ik dan nog eens naar de reacties (waaronder die van mij) kijk heb je deels misschien toch wel gelijk... voor een goedkoop email validated cert (de goedkoopste soort) zou deze manier een prima vervanger zijn zo'n aanbieding als starttls of peer review is dan niet meer nodig.
en het zou een prima manier kunnen zijn om standaard data voortaan versleuteld te versturen... bijv voor privé websites met joomla of wordpress de website van je sportclub of voor sites met gratis accounts. iets waar certificaten en ssl nog vrij duur zijn hoefd dat strax natuurlijk niet meer.
MAAR aangzien het internet nog steeds voornamelijk ip4 draait, en je voor ssl certs nog steeds een eigen IP nodig hebt (er is wel een namebased ssl mogelijkheid maar die wordt door te weinig servers en browsers ondersteund). word het uitrollen hiervan nog steeds een probleem.
om dit op te lossen kun je wachten op ip6 zodat elke website zijn eigen IP (of zelfs ip-reeks) kan krijgen.
maar voor het zover is zou je nog wel eens 10 jaar kunnen wachten, het is maar de vraag of dat snel genoeg is...
als ik dan nog eens naar de reacties (waaronder die van mij) kijk heb je deels misschien toch wel gelijk... voor een goedkoop email validated cert (de goedkoopste soort) zou deze manier een prima vervanger zijn zo'n aanbieding als starttls of peer review is dan niet meer nodig.
en het zou een prima manier kunnen zijn om standaard data voortaan versleuteld te versturen... bijv voor privé websites met joomla of wordpress de website van je sportclub of voor sites met gratis accounts. iets waar certificaten en ssl nog vrij duur zijn hoefd dat strax natuurlijk niet meer.
MAAR aangzien het internet nog steeds voornamelijk ip4 draait, en je voor ssl certs nog steeds een eigen IP nodig hebt (er is wel een namebased ssl mogelijkheid maar die wordt door te weinig servers en browsers ondersteund). word het uitrollen hiervan nog steeds een probleem.
om dit op te lossen kun je wachten op ip6 zodat elke website zijn eigen IP (of zelfs ip-reeks) kan krijgen.
maar voor het zover is zou je nog wel eens 10 jaar kunnen wachten, het is maar de vraag of dat snel genoeg is...
Heb zojuist op basis van dit artikel even een DNSSEC validator addon geinstalleerd. Ik was ervan overtuigd dat Tweakers.net deze methode wel zou ondersteunen, maar dit blijkt niet het geval. Iemand van HQ geinteresseerd om aan te geven waarom Tweakers hier nog geen gebruik van maakt?
Misschien omdat Tweakers.net gebruikt maakt van een .NET extentie i.p.v. .NL ?
Geen excuus dus.. Tenzij tweakers.net natuurlijk niet bij TransIP is geregistreerd, maar ik neem aan dat andere registars hetzelfde zullen doen, en dus niet alleen .NL domeinen zullen beveiligen. Ik kan me voorstellen dat ze hier mss pas mee beginnen met tweakers 7.0?1 augustus 2012
Goed nieuws voor alle klanten van TransIP: reeds 200.000 domeinnamen (110.000 .NL-domeinnamen) op nameservers van TransIP zijn DNSSEC beveiligd! In de komende dagen zullen er meer domeinen worden ondertekend tot een totaal van 400.000. Hiermee is TransIP direct de grootste aanbieder van DNSSEC domeinnamen ter wereld.
U hoeft voor deze beveiliging op uw domeinnamen niets te doen: de ondersteunde extensies zullen automatisch voor u worden gesigned. U zult hierna in uw controlepaneel te zien krijgen dat uw domeinnaam is beveiligd. DNSSEC wordt gratis aangeboden, de werking van uw domeinen wordt op geen enkele wijze belemmerd door DNSSEC. De extensies die zullen worden beveiligd met DNSSEC zijn .NL, .COM, .NET, .BE, .DE, .ORG, .EU en .INFO.
Voor meer uitleg en informatie over DNSSEC kunt u terecht op onze DNSSEC-pagina. Indien u gebruik maakt van domeinnamen met eigen nameservers, dan kunt u deze zelf beveiligen met DNSSEC via het controlepaneel van TransIP.
[Reactie gewijzigd door ExtendedCaesar op zaterdag 18 augustus 2012 12:24]
Tweakers.net is wel degelijk bij transip geregistreerd zo blijkt uit de whois:
DOMAIN: TWEAKERS.NET
RSP: TransIP BV
created date: 1999-02-04 05:00:00
updated date: 2012-04-19 08:41:58
expiration date: 2021-08-05 12:11:20
DOMAIN: TWEAKERS.NET
RSP: TransIP BV
created date: 1999-02-04 05:00:00
updated date: 2012-04-19 08:41:58
expiration date: 2021-08-05 12:11:20
[Reactie gewijzigd door jGS op zaterdag 18 augustus 2012 13:18]
Raar genoeg loopt Tweakers.net altijd achter, ze zijn bijvoorbeeld ook nog steeds niet bereikbaar over IPv6.
Complimenten aan SIDN. Hier zou de Nederlands regering voorbeeld aan kunnen nemen.
Met een relatief kleine investering (een paar ton? een paar miljoen?) is Nederland opeens wereldwijd koploper voor deze nieuwe technologie. Reken er maar op dat we goed gaan verdienen aan de kennis en ervaring die wij nu opdoen.
Ik durf te wedden dat het nog jaren duurt voor dat andere landen hier bij in de buurt komen.
Met een relatief kleine investering (een paar ton? een paar miljoen?) is Nederland opeens wereldwijd koploper voor deze nieuwe technologie. Reken er maar op dat we goed gaan verdienen aan de kennis en ervaring die wij nu opdoen.
Ik durf te wedden dat het nog jaren duurt voor dat andere landen hier bij in de buurt komen.
Leuk allemaal, maar ik beheer een aantal SBS2003 bakkies, kan ik dan het beste om de DNSSEC uitbreiding/security toe te voegen gebruik maken van http://technet.microsoft....c779943%28v=ws.10%29.aspx en dan waarde 0x1 toevoegen?
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 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
