Sikkerhedssystemet DNSSEC kan i stor stil udrydde DNS-spoofing som angrebsvektor for cyberkriminelle og dermed gøre det mere sikkert at være internetbrugere og sværere at være it-kriminel.
Men systemet er implementeret på under én procent af de danske .dk-domæner, viser tal fra DK-Hostmaster. Nærmere bestemt er 10.000 danske domæner beskyttet af systemet - ud af 1,3 millioner mulige domæner.
»Når det ikke er mere udbredt, så betyder det, at DNS er et stort mål for angreb,« fortæller Erwin Lansing, der er sikkerhedschef og teknisk konsulent for DK-Hostmaster.
DNSSEC står for Domain Name System Security Extensions.DNSSEC
Systemet har til formål at autentificere kilden til DNS-data og betragtes generelt som en kritisk komponent i indsatsen for at sikre det fundamentalt usikre DNS-system.
DK-Hostmaster fik i 2010 signeret dk-domænet med DNSSEC.
Sessioner fra netbanken
DNS-hierakiet starter ved det, man kalder roden, som drives af ICANN. Når man beder en browser om at tilgå Version2.dk, starter browseren med at spørge roden, hvem der har ansvar for .dk-domænerne.
Roden henviser i dette tilfælde til DK-Hostmaster.
Herefter spørges DK-Hostmaster, hvem der har ansvar for Version2, hvor den danske internetmyndighed henviser til Version2’s navneservere, som så igen oplyser, hvilken IP-adresse webserveren kan findes på.
Men uden sikkerhedssystemet DNSSEC er der ingen sikkerhed bag de spørgsmål og svar, der sendes til og fra browseren.
»Vi har for eksempel set, at hackere overtager en router og derfra sender forkerte svar til et phishing-site eller stjæler sessioner i din kontakt med netbanken,« fortæller Erwin Lansing.
Kryptografisk signatur
DNSSEC tilføjer en kryptografisk signatur til hvert svar i DNS-processen, som hver for sig igen signeres af niveauet ovenover i hierarkiet.
Det vil sige, at det svar, man får fra Version2, kan kontrolleres hos DK-Hostmaster, og DK-Hostmasters svar kan kontrolleres hos ICANN.
I eksemplet med den inficerede router kan man få et svar, der henviser til et phishing-site.
»I det tilfælde vil signaturen ikke passe, med de oplysninger vi har, og din browser vil afvise at gå ind på phishing-sitet,« forklarer Erwin Lansing.
»Med DNSSEC beskytter du dine brugere, så de er sikre på at komme på din side, og ikke en angrebsside fra Kina eller et andet sted,« fortsætter han.
Catch 22
DK-Hostmaster arbejder sammen med tilsvarende organisationer i andre lande på at udbrede kendskabet til og brugen af DNSSEC. Udfordringen er, at de fleste almindelige brugere ikke ved, hvad DNS er, hvad DNSSEC er, og hvorfor det er vigtigt, siger Erwin Lansing.
»De køber et domæne, og så køber de noget hosting. De ved ikke, at der findes en sikkerhedsløsning, som de fleste hostingudbydere ikke tilbyder. Og hostingudbyderne tilbyder det ikke, fordi de siger, at det ikke bliver efterspurgt. Så det er lidt en catch 22-situation,« siger han og tilføjer:
»Det er den cirkel, vi gerne vil bryde.«
Den danske internetadministrator har talt med en række udbydere - uden at der er sket meget endnu, erkender Erwin Lansing. Typisk hænger velvilligheden tæt sammen med pengepungen.
»Det, vi ser fra andre lande, er, at det eneste, der virker, er en rabat på domæne-registreringen. Altså hvis de kan få rabat på de måske 50.000 domæner, de har, som slutter med .dk, så vil de lige pludselig gerne gøre det.«
Kommer i klumper
Der findes en del open-source software, der kan hentes gratis. Så det koster primært tid at få etableret DNSSEC, forklarer sikkerhedschefen, der vurderer, at det er svært at lave en prognose for udbredelsen af sikkerhedssystemet.
»Det kommer i store skridt. Man får en hostingudbyder til at signere, og så stiger tallet med x tusind. Det er ikke nogen lige kurve, som man kan forudsige,« siger Erwin Lansing.
Det er typisk internetudbyderne, der tjekker, om signaturen er til stede. Her er Danmark godt med: To af de tre største ISP’er i Danmark understøtter DNSSEC.
»Det betyder, at vi faktisk ligger i top-5 i verden over, hvor mange opslag der kontrolleres efter DNSSEC,« siger Erwin Lansing.
- DNS-systemets krypto-nøgler skiftes for første gang: Opdater eller bliv smidt af internettet
- Kramshøj om DNSSEC: Der er ingen undskyldning længere
- Denne artikel
- Efter 6 år er det tid til at skifte nøglen til internettets navneservere
- DNS-fejl sendte Ingeniørens hjemmeside til tælling i timevis
- Googles DNS-tjeneste hæver sikkerheden med DNSSEC
- Kaminsky: Nu er jeg fan af DNSSEC
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Despite the many threats that DNSSEC does not combat, the consequences of a successful cache poisoning attack are so dire that it’s worth implementing DNSSEC purely to address that risk. Adoption of DNSSEC will proceed on the Internet much more quickly than on internal, corporate networks. Internet-facing zones are generally more critical, more exposed to attackers, as well as smaller and more static than their internal counterparts. Consequently, your deployment of DNSSEC should begin by signing your Internet- facing zones and configuring validation of signed zones on the Internet. Later, as DNSSEC becomes more broadly accepted and deployed, you can implement DNSSEC on an end-to-end basis, signing and validating internal zone data. Phase 1 In Phase 1 of your implementation, you’ll enable DNSSEC on your external name servers, sign your external zones and distribute those zones’ public keys to the administrators of name servers that need to verify your zone data. You’ll also configure your forwarders with the “trust anchors” they need to validate signed data in other zones. Phase 2 In Phase 2, you’ll sign your internal zones, too, and configure trust anchors, as necessary, to enable your internal name servers to validate your internal signed data. Phase 1 is much more pressing than Phase 2, because most threats to DNS originate from the Internet, not internal networks, and because most data that a name server can validate is hosted on the Internet. Consequently, many organizations may adopt a “wait- and-see” approach toward Phase 2, and defer broader implementation until DNSSEC’s value is proven and they’re comfortable managing DNSSEC key pairs and signed zones, and have integrated DNSSEC into their internal zone-administration regimen. Se mere her https://www.infoblox.com/?s=Dnssec+
Provide privacy of DNS data. While the signatures contain encrypted data, the records they sign are still sent in the clear. • Protect DNS against DDoS attacks. There are no mechanisms in DNSSEC to guard against distributed denial of service attacks. In fact, in some ways DNSSEC actually makes DDoS attacks easier to mount, as it makes responses larger (and those responses are easy to misdirect to a target). • Protect your name server against most attacks. Many—even most—attacks that target name servers are more mundane than cache poisoning. For example, they use implementation flaws such as buffer overruns to crash a name server or execute code. DNSSEC provides no protection against these attacks, other than making it hard for a hacker who successfully breaches your name server to replace your signed data.
Hos DK Hostmaster tager vi selvfølgeligt også vores del af ansvaret for det fåtal af signerede .dk domæner indtil videre og har gjort, og er ved at lave, adskillige tiltag for at gøre det nemmere at håndtere DNSSEC-informationer hos os.
I starten af året, har vi f.eks. indført Hent DNSSEC-Nøgle funktionalitet i vores selvbetjening. Det gør det muligt at oprette DNSSEC-nøgler uden den besværlige process med at lave copy-paste af lange hashværdier. Vi har samtidig ændret vores generelle vilkår så en navneserviceudbyder som standard kan håndtere DNSSEC for de domæner de driver. Nyere eliptic-curve algoritmer, også benævnt som algoritme 13 og 14, er ved at bliver testet internt lige nu og forventes fuld understøttet inden længe.
Siden vi indførte DNSSEC tilbage i 2010, har vi haft et simpelt DS Upload (DSU) API. Den gang understøttede vi ikke den provisioneringsprotokol (EPP) som vores registratorer foretrækker. Den service tilbyder vi nu, dog med meget begrænset funktionalitet. Vores udviklingsafdeling arbejder på at udvide funktionaliteten kraftigt, og har netop i denne uge udgivet en pre-release som indeholder DNSSEC håndtering. Den forventes i en endelig release i oktober.
Der er to sider af DNSSEC, på den ene side, at signere domæner og på den anden side at kontrollere signaturene. Værdien skal ses i, at når din ISP (eller din egen server) tjekker DNSSEC for hvert opslag, så vil et svar med en forkert signatur fejle. Browseren vil derfor give en “Server blev ikke fundet” fejl, og ikke gå ind på en potentiel malware eller phishing side. Det kræver selvfølgeligt både at domænet er signeret og at svaret bliver kontrolleret. I Danmark er vi rigtig godt med på det sidste med over 50% af forespørgsler der bliver tjekket. Vi håber derfor også at kunne se flere domæner der bliver signeret og dermed få en bedre beskyttelse af os allesammen. Vi er i hvert tilfælde indstillet på at gøre det vi kan teknisk for at det kan blive nemt og enkelt.
Jeg håber, at vi med alle disse tiltag, og i samarbejde med alle interesserede parter, kan skrive en hel anden historie næste år. Hvis der er andre forslag hvordan vi kan udbrede DNSSEC, ændre vores systemer eller stille værktøjer til rådighed, hører jeg det selvfølgeligt meget gerne.
Hvis en navneserveransvarlig tilføjer eller laver ændringer til DNSSEC nøgler på et domæne, skal registranten så godkende dette, ligsom en redelegering?
Det behøver han ikke. Registranten kan dog til enhver tid deaktivere de enkelte nøgler eller slå DNSSEC helt fra for et domæne.
Og her er draftet som vi (Erwin og jeg) faktisk også snakkede om tilbage i oktober 2015 (dog version 01).https://tools.ietf.org/html/draft-latour-dnsoperator-to-rrr-protocol-03
Hvis en navneserveransvarlig tilføjer eller laver ændringer til DNSSEC nøgler på et domæne, skal registranten så godkende dette, ligsom en redelegering?Tidligere på året ændrede vi vores generelle vilkår, således at en navneserviceudbyder kan håndtere DNSSEC-nøgler for et givent domæne direkte. Den tidligere separate rolle som nøgleanvsarlig bliver dermed ikke længere brugt. Det gør det mindre kompliceret at lade DNSSEC bliver håndteret af den der allerede står for DNS for domænet.
Det er helt rigtig, som nogle af jer har bemærket, at der er en lille finurlighed i vores selvbetjening som gør det muligt at hente DNSSEC-nøgler med algoritme 13, selvom det ikke er supporteret endnu. Både algoritme 13 og 14 er ved at blive testet internt netop nu, og jeg forventer at de bliver fuld understøttet i alle vores services inden længe.
Tidligere på året ændrede vi vores generelle vilkår, således at en navneserviceudbyder kan håndtere DNSSEC-nøgler for et givent domæne direkte. Den tidligere separate rolle som nøgleanvsarlig bliver dermed ikke længere brugt. Det gør det mindre kompliceret at lade DNSSEC bliver håndteret af den der allerede står for DNS for domænet.
CloudFlare er blevet nævnt nogle gange i kommentarerne som stor fortaler for DNSSEC. For nogle måneder siden har de, sammen med bl.a. vores kollegaer hos .ca, skrevet et IETF draft som beskriver et API for hvordan en navneserviceudbyder kan indsende DNSSEC-nøgler automatisk til et registry. Deres model ligner faktisk vores nuværende DS Upload (DSU) service på mange måder, udover at være lidt mere moderne og REST-baseret. Vi er derfor i dialog med CloudFlare om at bruge DSU til at signere alle deres .dk domæner automatisk og jeg håber snart at kunne se mange flere signerede .dk domæner.
Derudover er der de mere bagudskuende spørgsmål som:</p>
<ul><li>Hvorfor skal det tage så lang tid?</li>
</ul><p>Men måske vi kan lægge pres på, så de også understøtter et standard API. Så ville Internationale spillere som Cloudflare nok også gerne lege med - ud over spillerne i vores egen lille andedam.
Mig d. 25 oktober 2015:
Do you plan to support Algorithm 13? CloudFlare only supports algorithm 13.
Erwin Lansing (DK Hostmaster) d. 28 oktober 2015:
Link: https://liste.dk-hostmaster.dk/archive/dnssec-discuss/0004.htmlWe do indeed plan to add support for ECDSA P-256 and P-384, but I’m afraid I don’t have a timeline for it as yet. We also discussed with Cloudflare ways in which they can send DS records directly to us on behalf of their customer, rather than having each customer having to contact us individually, so Cloudlfare can automatically sign all their customer domains at once. I do hope to have news early next year, but at this moment I can’t make any promises.
Cloudflare og DK Hostmaster har i øvrigt været i dialog af flere omgang (sidst i denne måned). Så Cloudflare vil rigtigt gerne lege med.
Det er komplet surrealistisk læsning at læse en udmeldelse fra DK-hostmaster om det er udbydernes skyld
Yderst spændende info du bringer på banen. Jeg har med stor interesse læst det, og hvad Peter Makholm har skrevet.
I virker dog begge som nogen der har været i kampen længe, og er blevet godt trætte af det. Det er menneskeligt forståeligt og jeg har fuld sympati for det. Især efter at skulle læse sådan en overskrift. Men der er en hårfin grænse før det bliver polemisk.
Skulle jeg koge det ned til mere konstruktive spørgsmål man kunne stille ville det være:
- Hvorfor har DK Hostmaster valgt at skrive deres eget API istedet for at benytte standard API'et X?
- Burde DK Hostmaster ikke have en strategi for at DNSSEC skal være lige så nemt som hos .SE, .NU og .EU?
- Hvad er DK hostmasters argument for at nøgleadministrator skal være seperat fra teknisk kontakt?
- Og hvorfor kan reselleren ikke som udgangspunkt være nøgleadministrator?
- Hvad er DK Hostmasters tidslinie for ovenstående?
Derudover er der de mere bagudskuende spørgsmål som:
- Hvorfor skal det tage så lang tid?
- Hvem har ansvaret?
- Er det håndteret godt nok?
Men disse får os ikke rigtig videre. Det bringer os kun ned på samme lave niveau som var udgangspunktet for denne artikel. Jeg håber vi kan få Version2 til at følge op! En Post Mortem kunne være ganske interessant, men det virker som om skuden ikke helt er roet i land endnu.
Løbet er jo nok kørt med, at de allerede har skrevet deres eget API. Men måske vi kan lægge pres på, så de også understøtter et standard API. Så ville Internationale spillere som Cloudflare nok også gerne lege med - ud over spillerne i vores egen lille andedam. Men hvilke er der at vælge imellem, og hvilken ville du foretrække? Har der været kvalificeret modstand fra DK Hostmaster imod nogle af disse? Har DK Hostmaster været villige til at åbne deres forhåbenligt meget bedre løsning, så den så kan vinde udbredelse?
Lad mig først gøre det klart hvad jeg ikke mener gavner: Mere mudderkastning mellem DK-Hostmaster og deres resellers (fra begge sider).
Så giver det mere mening. Det kan nemlig være svært at gennemskue, da det er et emne der kan være meget støj omkring.
Den første udmelding fra dig kan nemlig nemt læses som faktisk modstand imod DNSSEC. Og med Peter Larsens krølle - så tydeliggør det jo, at resellerne er mere ambitiøse end DK Hostmaster - selvom det er dem der får lov til at løbe med overskriften.
Men istedet er det jo de positive budskaber der skal ud:
Med signede roots og DK Hostmaster på banen er vi nu ved at være klar til DNSSEC for alvor.
De danske udbydere står på spring til at integrere det fuldt og simpelt for brugerne når DK Hostmaster stiller et API til rådighed i lighed med andre progressive TLD'er.
Så efter 5-6 år har vi nu overstået den hårde/træge del af implementeringen. Hurra for det - vi kan noget med "click next".
Så når den kære journalist er gået i brechen med med den lettere negative click-bait vinkel - kunne man så håbe på en opfølgende artikel? Hvornår har DK Hostmaster tænkte sig at stille et automatiseret API til rådighed for resellers?
Jeg prøvede lige at se om "de store drenge" bruger dnssec:
Bruger tilsyneladende ikke dnssec: kernel.org krebsonsecurity.com schneier.com eff.org akamai.com bahnhof.se hosteurope.de one.com oracle.com microsoft.com sap.de suse.de ubuntu.org gnu.org ipvanish.com purevpn.com
Har dnssec records i DNS: wikileaks.org
click click click... på 1,3 millioner domæner tager 451 dage
Hvis der ER slået DNSSEC til i DNS
451 dage i mandetimer og i forbrugt tid, det er en udgift på ca 2,1 millioner DKK i dummeklik på en hjemmeside.
Ja, det kan lade sig gøre, det er direkte stupidt i henhold til spild af resourcer modsat ordentlig automatik
Lad mig først gøre det klart hvad jeg ikke mener gavner: Mere mudderkastning mellem DK-Hostmaster og deres resellers (fra begge sider).Hvad er det du mener der skal ske?
Til dem der pointerer at det bare er klik, klik, klik (eller som Corydon ville have formuleret det: "Vi trykker enter og så kører det") så har man med en enkelt script kunne gøre det samme siden 16. oktober 2010: https://www.version2.dk/comment/164033#comment-164033
Jeg er af den holdning at for 6 år siden var DNSSEC for besværligt, der var ingen værdi i det fordi det ikke blev valideret og der var for stor risiko for at et nogen lavede et fuck-up med dk-zonen (eventuelt i forbindelse med et nøgleskifte).
Så hvad skal der ske? Jeg mener allerede at jeg har skrevet det: DK-Hostmaster skal fortælle den positive historie om at nu er DNSSEC moden nok til at normale brugere får værdi af DNSSEC. Det kunne blandt andet være en historie om at flertallet af danskere nu vil opleve at DNSSEC rent faktisk virker (hvilket det muligvis tyder på).
En anden mulighed er at DK-Hostmaster tager en snak med de mest interessante brugere af DNSSEC (for eksempel fra Kristian Sørensen liste) og skubber på historien om hvordan DNSSEC rent faktisk sikrer finanssektoren (fremfor historier om en hypotetisk router).
Det jeg forventer af DK-Hostmaster er at de tager domænelovens §24 alvorligt og tager ansvar for at skabe efterspørgslen frem for bare at pege fingre af andre aktører.
Det er komplet surrealistisk læsning at læse en udmeldelse fra DK-hostmaster om det er udbydernes skyld
Nu har flere valgt at linke til vores wiki https://larsendata.wiki/gratisdns:dnssec, jeg skal i den forbindelse gøre super meget opmærksom på hvor nemt det er med .se, .nu og .eu domæner..
Du skal nemlig ikke klikke på noget, du skal ikke vide hvad DNSSEC er og du skal ikke tænke over det, for vi kan hjælpe dig, og hjælper også gerne med DNSSEC, når vi har et tidssvarende automatisk system vi kan interface imod.
Men det HAR VI IKKE!
Jeg har valgt at svare på dk-hostmaster's yderligere beskyldninger om udbydernes forsømmelser ved at linke til et 7 ÅR gammelt blogindlæg, som i den grad udpensler problematikken.
http://new.czar.dk/2016/09/29/dnssec-for-dummies/
Vi vil som udbydere ikke stå model til at VI ikke har gjort noget, det er DK-Hostmaster som med deres forstokket ikke-samarbejde og mistillid til deres forhandlerled IKKE har ville samarbejde med os.
Vi vil ikke sponsorer udvikler tid til dk-hostmaster når vi gang på gang skal skydes ned , og når vi på denne måde skal udhænges i pressen.
Nuværende fejl: Siden den nye selvbetjening kom online har vi ikke kunne administrerer vores DNSSEC kunder på selvbetjeningen, fejlmeldt flere gange for OP TIL OVER 1,5 ÅR SIDEN. Nøgleadministrator skal væk, sagt og gentaget i OVER 7 år!
Dette passer ikke, det eneste du ikke kan gøre er at overdrage domænet til en anden - og det er rimeligt nok - det er jo kundens ejendom og ikke dinfordi DK Hostmaster insisterer på ikke at give udbyderne adgang til at administrere alle delene af et domæne på vegne af en kunde uanset om begge parter måtte ønske dette.
Du følger vist ikke helt med, det er ren "next->next->next" at sætte DNSSEC op på dkdomæner hos Cloudflare. Tager max 30 sekunderCloudflare er verdens største DNS hoster. Måske skulle DK-Hostmaster skelne til hvilke algoritmer de og andre udbydere, tilbyder brugerne at benytte på deres zoner.
Det er vel ikke domæneejerne der ikke interesserer sig for sikkerhed? Og deres rådgivere? Selve hostingprovidererne kan sa sagtens håndtere DNSSEC - eller er der stadig nogle der kan ikke???
Min forventning er, at min resolver skal fejle hvis DNSSEC er sat op for domænet og fejler. Bevares - browseren kan ikke se hvorfor opslaget ikke virker. Men værdien er der vel?</p>
<p>På denne side <a href="http://dnssec.vs.uni-due.de/">http://dnssec.vs.uni-due.de/</a> får jeg at vide, at min resolver validerer DNSSEC signaturer.
Det er lige netop det den side gør. Forsørger at hente noget på en side hvor der er fejl på dnssec-opslag. Og nej - det er ikke browsweren der gør det, men dns-resolveren ;-)
Så hvad er der sket på de 5-6 år?
Hvad er det du mener der skal ske?
Min forventning er, at min resolver skal fejle hvis DNSSEC er sat op for domænet og fejler. Bevares - browseren kan ikke se hvorfor opslaget ikke virker. Men værdien er der vel?
På denne side http://dnssec.vs.uni-due.de/ får jeg at vide, at min resolver validerer DNSSEC signaturer. Dette på en almindelig Windows 10 på Chrome.
Skal ærligt indrømme, at jeg ikke selv har testet yderligere.
Opsætningen af domæne syntes jeg også er nem. Jeg har lige gjort det for et domæne hvor min DNS kører på Cloudflare:
- Hos Cloudflare klikker jeg "Enable DNSSEC"
- Hos DK Hostmaster klikker jeg "Hent nøgler"
Så bliver det vist ikke ret meget nemmere. Jo - man kunne argumenterer for, at det skulle være default.
Jeg kan være lige så mavesur som den næste - men jeg ser ikke din pointe. Hvad er det du mener der skal til for at det har reel værdi?
Dengang DK-Hostmaster meget tøvende indførte DNSSEC bloggede jeg en del om det. Det var besværligt (især processen der involverede DK-Hostmaster) og gav ingen egentlig værdi.
Så hvad er der sket på de 5-6 år?
Ptjaaa, hvis man kun skal håndtere en håndfuld domæner ser det ud til at processen med DK-Hostmaster er blevet marginalt lettere. Det ser i hvert fald ud til at de nu tilbyder at oprette DS-records mere direkte gennem selvbetjeningen (har dog ikke prøvet det).
Men giver det nogen værdi endnu?
Mig bekendt er der sket absolut ingenting på klient-siden og de tiltag der dengang var til at bruge DNS som sikker infrastruktur (bla. DANE) er stendøde fra browserfabrikanternes side.
Så i stedet for at læse at DK-Hostmaster og hostingudbyderne (og registrarene) peger fingre af hinanden, så ville jeg meget heller læse hvorfor Erwin Lansing mener at nu er vi i mål med alt det værdiskabende og så er det bare at høste den forbedrede sikkerhed.
Nu kan DK-HM selv "fiske" DNSSEC-nøgler, så man slipper for copy/paste. Det virker for gratisdns.dk, og kan næsten ikke være nemmere. Har lige gjort det for ni domains, og det tog sammenlagt ca. 15 minutter.
. Man kan sagtens registrere flere samtidige DNSSEC-nøgler så både din gamle og nye DNS-udbyders nøgle er valide samtidig i overgangsperioden, så ingen grund til bekymring hvis man ikke er natteravnDet lyder som en god måde at holde på kunderne på :-D
Men er et skift ikke bare et spørgsmål om at sætte TTL ned til få minutter, og lave det hele forfra en nat.
Synes det er lettere skræmmende at ikke flere har DNSSEC - Specielt når jeg tænker på at jeg med mine 2 private domæner udgør 2 af de 10.000 domæner som har DNSSEC
Det er jo ellers nemt og tager under 5 min at oprette.
Ja det er en anelse bøvlet at kopierer DNSSEC ind i DK-Hostmaster, men så er det altså heller ikke mere end det!
Forstår ikke kritikken. Der er fire roller: Ejer, Administrator, DNSSEC-Administrator og betaler. Hvis du som udbyder er adminstrator, kan du gøre alt, undtagen at overdrage domænet (og betale:) Så hvad er det du savner? Har kigget på interfacet til DNSSEC, det er en webservice, som forholdsvis enkelt kan integreres i egne systemer. Jeg kender ikke alderen på deres systemer, men synes det var mere relevant med en præcis kritik af hvad det er du mener man ikke kan gøre uagtet alderen.
Det lyder som en god måde at holde på kunderne på :-D Men er et skift ikke bare et spørgsmål om at sætte TTL ned til få minutter, og lave det hele forfra en nat.Det vil formentlig gå hen og blive lidt finurligt hvis man flytter sin DNS til en anden udbyder (så skal der sikkert dannes nye nøgler, og så er det lige at få synkroniseret opdateringen af dem), men det har jeg ikke prøvet.
Jeg kender ikke omkostningerne på DNS server siden (altså hos udbyderen), men for den enkelte DK-domæne ejer er der ikke nogen omkostning - ud over den tid, det tager at sætte op.
Hos gratisdns.dk er det ret enkelt, beskrevet her: https://larsendata.wiki/gratisdns:dnssec . Du klikker på en knap, venter lidt på at der genereres en nøgle, og den kopierer du så ind i din DNS registrering på DK Hostmaster's hjemmeside via deres selvbetjening.
Sidste trin er noget bøvl - det kunne godt gøres smartere.
Det vil formentlig gå hen og blive lidt finurligt hvis man flytter sin DNS til en anden udbyder (så skal der sikkert dannes nye nøgler, og så er det lige at få synkroniseret opdateringen af dem), men det har jeg ikke prøvet.
1 hvad koster det for udbyderen at stille til rådighed, altså at inkorporere i deres systemer ? 2 hvad vil prisen være for domænerne, anskaffelse og implementering ? 3 er der tale om rasende dyrt ekstra udstyr, eller bagstræberiskhed ?
Please make some relevant links available, pt har jeg ikke overskuddet til at forsøge at søge på det selv, men vil hjertens gerne modtage relevante links her, og være med til at udbrede kendskabet !
Man ser tit at et site har et SSL certifikat som er udløbet. Hvad med DNSSEC, løber de også ud, og er konsekvensen så at domænet helt er væk?
DK Hostmasters tekniske systemer og forretningsmodel er forældet og utidssvarende.
Det er i dag ikke muligt for en udbyder at signere alle deres zoner automatisk på en god måde.
Derudover er det ikke muligt for udbyderne at give kunderne ordentlig kundeservice fordi DK Hostmaster insisterer på ikke at give udbyderne adgang til at administrere alle delene af et domæne på vegne af en kunde uanset om begge parter måtte ønske dette.
.se .no .nl og andre giver registrarer økonomisk tilskud hvis der aktiveres DNSSEC og på den måde er de med til at understøtte at der signeres så mange zoner som muligt. .dk giver intet økonomisk tilskud.
Pt. understøtter DK-Hostmaster kun et snævert sæt af de ældre algoritmer og derfor er muligheden for at beskytte zonerne også afgrænset. Og så ville det også hjælpe med en række let forståelige guides, bakket godt op af billeder eller video.</p>
<p>En side note er at Cloudflare også tilbyder https uden eget certifikat via proxy.
DK Hostmaster understøtter endnu ikke algorithm 13 (som er den CloudFlare bruger), hvis du bruger funktionen "tilføj nøgle", men hvis du bruger "Hent DNSSEC" nøgle (fra navneserveren) så virker det. Det kan Erwin måske uddybe?
Se evt. http://dnsviz.net/d/sb-group.dk/dnssec/ (CloudFlare) og http://dnsviz.net/d/srv1.dk (PowerDNS)
DK Hostmsater har ikke svaret her https://liste.dk-hostmaster.dk/archive/dnssec-discuss/0009.html
De kunne passende starte med at implementere det ordenligt, inden de brokker sig.
Cloudflare er verdens største DNS hoster. Måske skulle DK-Hostmaster skelne til hvilke algoritmer de og andre udbydere, tilbyder brugerne at benytte på deres zoner.
Pt. understøtter DK-Hostmaster kun et snævert sæt af de ældre algoritmer og derfor er muligheden for at beskytte zonerne også afgrænset. Og så ville det også hjælpe med en række let forståelige guides, bakket godt op af billeder eller video.
En side note er at Cloudflare også tilbyder https uden eget certifikat via proxy.
DNSSEC har intet med Let's Encrypt at gøre og tager 2 minutter at aktivere.
Jeg ville rigtig gerne køre DNSSEC og https på mine domæner. De ligger på gratisdns.dk (som understøtter DNSSEC) og jeg har egen (virtuel) server, men ungerne kommer i første række, så jeg er ikke kommet ret langt i projektet.
Men mulighederne har aldrig været bedre efter letsencrypt.org kom til Verden. Det gælder om at få det gjort.
Det kunne være spændende at få at vide hvem de 10.000 "kvikke drenge i klassen" er.
Jeg prøvede lige at køre whois på en række *.dk domæner hvor man skulle tro DNSSEC er særligt relevant (kig efter linjen Dnssec: under "Domain") ("dig dnskey" er en anden måde at se det samme på):
Har dnssec records i DNS: danskebank.dk dk-hostmaster.dk gratisdns.dk itu.dk
Bruger tilsyneladende ikke dnssec ? e-boks.dk nets.dk sydbank.dk jyskebank.dk nordea.dk nykredit.dk kmd.dk pbs.dk ft.dk politi.dk domstol.dk version2.dk