Kramshøj om DNSSEC: Der er ingen undskyldning længere

Implementering af DNSSEC burde være på toppen af to-do-listen for domæneejere, mener netværksekspert Henrik Kramshøj.

Sikkerhedssystemet DNSSEC har til formål, at verificere DNS-processen, så brugere ikke uforvarende snydes over på et falsk phishing-site. Systemet har eksisteret i årevis - men bruges på under én procent af den danske domæner, kunne Version2 i går fortælle.

Mere præcist er 10.000 .dk-domæner ud af 1,3 million sikret med DSNSEC. Og det er der ikke nogen god grund til, vurderer netværksekspert og Version2-blogger Henrik Kramshøj.

Læs også: Danske hostingudbydere forsømmer DNS-sikkerhed: Under én procent af .dk-domæner sikret med DNSSEC

»Der er ikke længere nogen undskyldning, man skal bare gøre det,« fastslår han.

»Generelt skal man tænke, at det her er ikke noget man gør for at beskytte sig selv, men for at beskytte sine brugere. Og med alle de dårlige ting, der er, så synes jeg godt, man kunne arbejde for at hjælpe brugerne lidt mere,« tilføjer Henrik Kramshøj.

Historisk besværligt

DNSSEC-systemet har tidligere lidt under diverse tekniske udfordringer, som har gjort det mere bøvlet og mindre attraktivt at implementere, fortæller Henrik Kramshøj.

»For det første var roden af internettet ikke signeret tidligere,« indleder han.

»Og det gør det bøvlet at signere et domæne, hvor roden af internettet og toplevel-domænet ikke er signeret. Men det har det efterhånden været i flere år. Og det vil sig at TLD’er, vi bruger i dagligdagen i Danmark - .com, .net, .dk osv - alle understøtter DNSSEC. Så det er på plads,« fastslår Henrik Kramshøj.

Læs også: Nu er .dk-domænet sikret med DNSSEC

Et andet problem, der muligvis har givet protokollen et dårligt ry, var, at algoritmerne tillod et såkaldt zone transfer. DNSSEC-systemet kan endegyldigt fortælle, at et domæne er validt.

Men det kan også fortælle, hvornår et hostnavn ikke findes. Det betyder, at en hacker kan ‘walk the zone’ og på den måde kortlægge hele DNS-zonen. Den viden kan i sidste ende bruges i et angreb.

Det problem er dog også blevet fikset, fordi hele DK-zonen nu er signeret med NSEC3, der blokerer for zone-walking, forklarer Kramshøj.

»Softwarepakkerne er også modne - alle vores softwareimplementeringer understøtter det. Så i det operationelle er der heller ikke længere nogen forhindringer,« fastslår han.

Falske emails og IP-adresser

DNSSEC udvider den almindelige DNS-proces med en signatur, der gør, at browseren kan verificere, at oplysninger fra for eksempel navneserveren er korrekte. Det gør det langt mere vanskeligt for it-kriminelle at lokke brugere over på et phishing-site under dække af en legitim hjemmesiden.

Det er også brugbart i lande - som f.eks. Danmark - hvor ISP’er kan udføre en såkaldt DNS intercept - en manøvre, hvor en forkert IP-adresse returneres på et DNS-opslag.

Øvelsen kendes bedst som DNS-blokering, der blandt andet har 'spærret' for fildelingstjenester som allofmp3.com og thepiratebay.org.

Læs også: Googles DNS-tjeneste hæver sikkerheden med DNSSEC

»Det forhindrer altså også man-in-the-middle-angreb fra myndighedernes side,« forklarer Henrik Kramshøj.

Hvis DNSSEC bruges sammen med DMARC-protokollen, der kan verificere afsenderen af en e-mail, kan du desuden undgå, at dine kunder modtager falske mails i dit navn, siger han.

Infrastruktur skal have overhaling

Henrik Kramshøj erkender, at der kan være flere vigtige emner på todo-listen for domæneejere som IPv6 og TLS-kryptering til domæner.

Ikke desto mindre mener netværkseksperten, at domæneejere bør sætte DNSSEC op i mod toppen af listen.

»Man burde i Danmark lave en generel overhaling af sin infrastrukturen - og det er altså ikke svært det her. Det er en relativ lille ting at gøre,« fastslår han og fortsætter:

»Hvis man synes det er besværligt, så er det nok fordi man selv kører DNS, og det skal man lade være med. Man skal overlade DNS til sin leverandør.«

Læs også: DNS-fejl sendte Ingeniørens hjemmeside til tælling i timevis

Det burde desuden ikke betyde noget, om man har en dyr eller en gratis leverandør - DNSSEC vil være understøttet.

»Og hvis du er hos en leverandør, der både er dyr og ikke understøtter DNSSEC, så kunne du overveje at skifte,« siger Henrik Kramshøj.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (28)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Jensen

Efter at have læst om det i går her på v2, tog det mig tre minutter at sætte det op for mit domæne. Og jeg kendte intet til det i forvejen. Ind på gratisdns.dk, læse lidt og klik, klik, klik. Dernæst ind på dk-hostmaster.dk og klik, klik, klik. Det var det.

Povl H. Pedersen

Understøtter DK TLD algorithm 13 i dag ? ECDSA ? Eller mangler de stadig opgraderingen, og derrmed er DK Hostmaster dem der forhindrer at man kører DNSSEC ?
ECDSA er kravet hos eksempelvis CloudFlare, og muligvis andre.

jeg troede at DK Hostmaster havde som en primær rolle at vedligeholde (og ikke kun drifte as-is som alm. outsourcing typisk gør) DNS infrastrukturen i DK.

Tom Sommer

> Efter at have læst om det i går her på v2, tog det mig tre minutter at sætte det op for mit domæne. Og jeg kendte intet til det i forvejen. Ind på gratisdns.dk, læse lidt og klik, klik, klik. Dernæst ind på dk-hostmaster.dk og klik, klik, klik. Det var det.

Det er super, så skal du bare gange den procedure med 1.3 millioner domæner og forklare din mor og far hvordan man gør det også.

Emil Stahl
Jørgen A Thomsen

I disse dages debat er det i høj grad teknikken om DNSSEC, der fokuseres på. DNSSEC kan relativt let sættes op for et enkelt domæne, men det er noget helt andet, når der skal administreres 1000-vis af domæner. DNSSEC introducerer et administrativt overhead (nøglehåndtering) og forøger RAM-forbruget med en faktor 10 på DNS-serveren og gør DNS-opslag langsommere.

Temmelig fraværende i debatten er værdiskabelsen.
Hvor er det lige DNSSEC skaber værdi for hr og fru Jensen ?

Hvad nytte er det til, at et domænenavn anvender DNSSEC, hvis valideringen ikke anvendes i brugen af det ?
Som IT-nørd kan man fint tilføje en DNSSEC-validator plugin til sin browser og efter en uges kursus hos Microsoft, kan man sikkert også finde ud af at bruge Windows Name Resolution Policy Table til noget, men det batter jo intet i det store billede.

DNSSEC har eksisteret i mange år, men det er mit indtryk, at værdiskabelsen i brugen af den har haltet gevaldigt bagud. Grunden kunne bl.a. være, at de DNS angreb, der var for nogle år siden, er blevet afværget med bedre DNS software. Jeg kan ikke huske noget i de senere år om større angreb, der kunne være afværget af DNSSEC.
Incitamentet for at implementere DNSSEC validering har derfor ikke været så stort.

Det er muligt, jeg ikke er helt opdateret, og at der er sket noget i det skjulte, men skulle vi ikke prøve at få værdien i praksis af DNSSEC frem i lyset, ikke blot de teoretiske fordele ?

Nogen må vide noget mere om dette.

Bent Jensen

Hvor man ikke tillade mail, fra ikke DNSSEC certificeret i sin mailboks.
Hvis tilstrækkelig mange mennesker, får en mail retur om deres mail udbyder/program/domain ikke er godkendt og overholder DNSSEC, især fra dem som folk gerne vil eller skal i kontakt med, så vil kravet til at får styr på det over for udbyder hurtigt få det på plads.
De fleste mennesker bruger jo enten google, eller på arbejde en server, hvor der er en ansvarligt, som burde have styr på de her ting. Firma som lever af at sælge ting, vil også hurtigt få styr på det, hvis de ikke kan nå i starten 1% men måske hurtigt 20-30 procent af deres kunder.

Hvordan er det med de store udbyder, det er jo dem som kan flytte noget hurtigt ?

Bent Jensen

Det er muligt, jeg ikke er helt opdateret, og at der er sket noget i det skjulte, men skulle vi ikke prøve at få værdien i praksis af DNSSEC frem i lyset, ikke blot de teoretiske fordele ?


Som jeg forstår det, du kan stole på at afsender af mail, er hvem han udgiver sig for. SPAM mail får det meget svært.

Det er vel af meget værdi for alle modtager. Som da nummerviser kom til telefonen.
Med DNSSEC kan du ikke "ringe" fra et falsk eller hemmeligt nummer.

Kristian Sørensen

Det er også brugbart i lande - som f.eks. Danmark - hvor ISP’er kan udføre en såkaldt DNS intercept - en manøvre, hvor en forkert IP-adresse returneres på et DNS-opslag.

Øvelsen kendes bedst som DNS-blokering, der blandt andet har 'spærret' for fildelingstjenester som allofmp3.com og thepiratebay.org.

Gælder det ikke kun hvis ens klient konsekvent afviser svar på DNS opslag uden DNSSEC?

Og det er vel ikke en realistisk politik at føre, når kun få procent af verdens domæner bruger DNSSEC?

Hvis jeg laver opslaget: "giv mig ip-nummeret for www.test1234.com " og domænet bruger DNSSEC:

Så vil den rigtige dnsserver svare: "DNSKEY: Q1W2E3R4T5Y6; ip-nummer: 1.2.3.4"

Mens censur-dnsserver eller censur-man-in-the-middle der opsnapper og omskriver svaret fra den rigtige dnsserver, kan vel godt svare: "DNSSEC: unsigned; ip-nummer: 6.6.6.6"

Så er vi ikke i en situation hvor DNSSEC først rigtigt giver udbytte når det er blevet så udbredt at klienterne kan indøfres om standard policy at afvise eller stærkt advare mod dnsopslag der ikke bruger DNSSEC?

Christian Nobel

Efter at have læst om det i går her på v2, tog det mig tre minutter at sætte det op for mit domæne. Og jeg kendte intet til det i forvejen. Ind på gratisdns.dk, læse lidt og klik, klik, klik. Dernæst ind på dk-hostmaster.dk og klik, klik, klik. Det var det.

Er der noget yderligere der skal tages in mente (konfiguration serverside?), og er der nogen faldgrupper, for umiddelbart ser klik, klik, klik jo alt for let ud?

Dernæst, hvis det vitterligt er så enkelt, hvorfor sætter eksempelvis GratisDNS det så ikke automatisk op for alle domæner - er der en bagside af medaljen, ud over der kommer mere load på deres servere?

Jørgen A Thomsen

DMARC og ethvert andet system, der baserer sig på SPF, som pr design forhindrer forwarding af emails, er i praksis uanvendeligt mod SPAM mail, når ikke samtlige mailservere i verden anvender det.

Citat fra openspf.org

Does SPF break forwarding?

Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. If receivers are going to check SPF, they should whitelist forwarders that do not rewrite the sender address from SPF checks.

Whitelist all forwarders ? Come on !

Henrik Schack
Jørgen A Thomsen

Sæt et flueben, afvent mail fra dk-hostmaster og følg instrukser.

99 % af registranterne fatter ikke hvad DNSSEC er.
Ca. samme procentdel vil derfor ignorere en email om, at de skal foretage sig noget med DNSSEC.
Det er derfor essentielt, at det er DNS-operatørerne, der kan administrere DNSSEC uden involvering af brugerne.
TDC involverer jo heller ikke brugerne, når de moderniserer teknikken på centralerne.

Hos DK Hostmaster har man desværre stadig den opfattelse, at alle kunder er IT-nørder, som kender til og skal involveres i alle aspekter. Det besværliggør livet for både kunder og udbydere.

Christian Schmidt

Hvor er det lige DNSSEC skaber værdi for hr og fru Jensen ?

DNSSEC har først værdi, når der er nogle DNSSEC-records at tjekke, og nogen så rent faktisk tjekker dem. Sidstnævnte bør selvfølgelig ske automatisk uden brug af browserplugins.

DNSSEC kan forhindre man-in-the-middle-angreb, hvor folk opsnapper trafikken fx mellem dig og din bank og aflurer din adgangskode. Det burde SSL også kunne afhjælpe, men det sker ikke sjældent, at certifikatudstedere har udstedt SSL-certifikater til uvedkommende. Man er fx et let offer for man-in-the-middle-angreb, når man benytter et offentligt wifi.

Det er super, så skal du bare gange den procedure med 1.3 millioner domæner og forklare din mor og far hvordan man gør det også.

Hovedparten af de 1,3 mio. domæner er næppe i farezonen for man-in-the-middle-angreb.

Derimod er domæner for store virksomheder mere udsatte. Hvis blot Skat, Borger.dk og alle landets banker får styr på DNSSEC, er vi kommet langt.

Claus Andersen

Det er muligt, jeg ikke er helt opdateret, og at der er sket noget i det skjulte, men skulle vi ikke prøve at få værdien i praksis af DNSSEC frem i lyset, ikke blot de teoretiske fordele ?

NRPT mv. er interessant i dit eget "domæne" (AD) - men der er også en verden udenfor.

Den vigtige forskel er, at både root og DK nu er signede. Dvs. du kan nu vælge at stole på din egen resolver.

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. Dette uden nogen særlige plugins.

Spørgsmålet er naturligvis så stadig om du stoler på din resolver - men nu har du mulighed for at verificere dette.

Erwin Lansing

DNSSEC har først værdi, når der er nogle DNSSEC-records at tjekke, og nogen så rent faktisk tjekker dem. Sidstnævnte bør selvfølgelig ske automatisk uden brug af browserplugins.

Her er lidt statistik fra APNIC, som måler diverse ting omkring DNSSEC-udbredelsen ved hjælp af Google ads, det vil sige helt ude i applikationen hos rigtige brugere. Med over 50% af forespørgsler der bliver kontrolleret er vi faktisk godt med i verden, selvom vi stadig halter efter vores nordiske naboer.

Claus Bruun

Så prøvede jeg også lige at sætte det op for et par .dk domæner, og det var jo piece-of-cake. Men da jeg dig'ede lidt rundt kunne jeg ikke finde et eneste domæne, som havde det sat op. Man burde forvente at statslige institutioner, større firmaer og sikkerhedsfolk havde sådant noget på plads. Men ingen af

132 dig ibm.com any any
133 dig schneier.com any any
134 dig krebs.com any any
135 dig tv2.com any any
136 dig tv2.dk any any
137 dig dr.dk any any
138 dig ing.dk any any
139 dig pol.dk any any
140 dig b.dk any any
141 dig berlingske.dk any any
142 dig jp.dk any any
143 dig i.dk any any
144 dig politi.dk any any
145 dig skat.dk any any
146 dig ft.dk any any
147 dig im.dk any any
148 dig microsoft.com any any
149 dig stm.dk any any
150 dig secunia.dk any any
151 dig kviknet.dk any any
152 dig topdanmark.dk any any
153 dig ddb.dk any any
154 dig unibank.dk any any
155 dig svt.se any any
156 dig tv4.se any any
157 dig polis.se any any
158 dig ibm.se any any
159 dig ibm.dk any any
160 dig lsb.dk any any
161 dig tveast.dk any any
162 dig pfsense.com any any
163 dig pfsense.org any any
164 dig cisco.com any any
165 dig dannet.com any any
166 dig gigabit.dk any any
167 dig www.gigabit.dk any any
168 dig gigabit.dk any any
169 dig mail.gigabit.dk any any
170 dig fm.dk any any
171 dig uu.net any any
172 dig ini.dk any any
173 dig uni.dk any any
174 dig dtu.dk any any
175 dig dth.dk any any
176 dig polyteknisk.dk any any
177 dig diku.dk any any
178 dig id.dk any any
179 dig id.dtu.dk any any
180 dig xfm.dtu.dk any any
181 dig kampsax.dtu.dk any any
182 dig k-net.dk any any
183 dig skat.dk any any
184 dig nets.dk any any
185 dig danid.dk any any
186 dig nemid.nu any any
187 dig csc.dk any any
188 dig hp.dk any any
189 dig i.dk any any
190 dig information.dk any any
191 dig skejby.dk any any
192 dig azure.com any any
193 dig google.com any any
194 dig gmail.com any any
195 dig netapp.com any any
196 dig larsen.dk any any
197 dig larsendata.dk any any
198 dig he.net any any

synes at finde det nødvendig at sætte DNSSEC op!

Tilgengæld har de fleste adopteret spf records, og dertil ser man meget ofte DNS TXT records af typen

TXT "MS=msxxxxx"
TXT "<base64 token>"
TXT "google-site-verification=<base64 token>"
:

Jeg har på fornemmelsen, at de mange "MS=" skyldes, at diverse institutioner og firmaer bruger MS's tjenester til at route mailen igennem for at scanne for virus og malware.

Er der nogen som kan uddybe, hvad de andre TXT bruges til og om DNSSEC giver mening "the last mile", når ingen øjensynlig bruger det og følgelig ingen kan regne med at kunne checke DNSSEC ?!

Log ind eller Opret konto for at kommentere