Nåh

Skulle lige hjælpe en kunde med at tjekke noget, så jeg tog naturligvis en terminal op og begyndte at tjekke nogle navneservers.. og de svarede godt nok forkert.. meget forkert.. sært?

Hvis jeg betaler for internet, så vil jeg gerne have.. internet, ikke sådan en løs mellemvare hvor folk hijacker mine sessions eller stjæler mine dnsopslag og gør underligt med dem.. Det gik dog hurtigt op for mig at det netop var det som skete..:

$ dig +dnssec  @thisisactuallynotannameserver.gdns.dk .

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec @thisisactuallynotannameserver.gdns.dk .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1867
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                IN    A

;; AUTHORITY SECTION:
.            10632    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2011030901 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 91.221.196.10#53(91.221.196.10)
;; WHEN: Thu Mar 10 05:23:04 2011
;; MSG SIZE  rcvd: 103

… hvordan kan man ellers få svar på en dnsforspørgelse, på en naveserver, som ikke findes…

Intercontinetal udgør dermed en sikkerhedsrisiko, og bør ikke bruges af forretningsfolk, eller andre hvor det at stole på nettet også er forbundet med at kunne stole på DNSSEC.. Det findes ikke på intercontinental hotels..

nåh, tilbage på VPN, det burde dog ikke havde været nødvendigt for et lille dnsopslag..

VI skal lege med DNSSEC, så vi skal lokke den indre nørd frem :)

Der er pt kun 71 DNSSEC domæner i .dk regi, og det kan vi simpelhen gøre bedre.

Der er ingen tvivl om, at hvis processen omkring DNSSEC havde været mere automatiseret, så havde det været en væsentlig fordel, men nu gør vi et forsøg ud af det vi har..

Du skal bruge:

1 .dk domæne (med tilhørende login til DK-Hostmaster.dk).

1 GratisDNS.dk login, med ovenstående domæne på, fuldt funktionelt.

1) Tilføj DNSSEC på domænet.

log på http://admin.gratisdns.dk, tryk på “Primær DNS”, find domænet, og tryk på “DNSSEC” ud foran det. Læs teksten, og tryk “Tilføj DNSSEC”.

2) Drik en kop kaffe, eller et glas vand..

3) Tryk “Primær DNS” igen, og tryk på “DNSSEC”.  Hvis informationerne stadig er tomme (Nøgle-ID, Algoritme osv), så vent et par minutter mere, og tryk da F5.

4) Åben et andet browservindue og log på http://www.dk-hostmaster.dk med dit registrant handle og kodeord. Tryk på “DNSSEC nøgle(r)”, og “Opret Nøgle”.

5) Overfør værdierne fra GratisDNS.dk DNSSEC siden til DK-Hostmaster.dk DNSSEC siden, brug COPY/PASTE! Husk at vælg korrekt Algoritme og Hashing­­algoritme (Det er tallet på GratisDNS.dk siden som fortæller hvilken en der er den korrekte). Husk også at VÆLGE DET KORREKTE DOMÆNENAVN! :)

6) Tryk “GEM”.. Done..

I løbet af kort tid vil dit domæne nu være på geekfaktor max! :)

Du kan teste resultatet her: http://dnssec-debugger.verisignlabs.com/ Feks: http://dnssec-debugger.verisignlabs.com/czar.dk

PS: husk hvis du fjerne DNSSEC igen fra domænet, også at fjerne det fra DK-Hostmaster’s site.. ellers kan du få problemer :)

https://addons.mozilla.org/en-US/firefox/addon/64247/
God til support og test af DNSSEC, rigtig god indikator af om det virker, direkte synligt i din firefox :)

http://www.dnssec.cz

Test om dine cache dns er klar, validating resolver check (se til højre efter “DNSSEC security test”)!

http://www.dnssectester.cz/
hardware tester af dit netværk, se om du er DNSSEC klar!

DIFO har netop sat en høringsprocess igang vedrørende DNSSEC (ud over høringen om typosquatting som har frist til 11. Maj) så har denne høring også frist til 11. Maj, og er også en revision af de generelle vilkår. Sagt med andre ord. 7 dages høringsfrist. Hurra!

Set ud fra et demokratisk synspunkt finder jeg det betænkeligt at der er to høringer i gang, begge med formål at ændre de generelle vilkår, men med forskellige dokumenter og revisioner.

Jeg vil i dette blogindlæg derfor fokusere på: http://www.difo.dk/fileadmin/user_upload/documents/generelle_Vilkaar/Generelle_vilkaar_udkast_DNSSEC.pdf og ikke http://www.difo.dk/fileadmin/user_upload/documents/generelle_Vilkaar/Generelle_vilkaar_udkast_april_2010.pdf

I forbindelse med DNSSEC har man tilføjet tilsyneladende 3 ting:

§ 2:
Ved DNSSEC forstås en teknisk sikkerhedsfacilitet, der ad kryptografisk vej og på grundlag af internationalt anerkendte standarder mindsker risikoen for, at svaret på en DNS-forespørgsel kompromitteres under afviklingen af processen.
Ved Nøgleansvarlig forstås den fysiske eller juridiske person, som registranten har bemyndi- get til at håndtere transaktioner, som indebærer ændringer i opsætning og indhold af krypte- ringsnøgler for DNSSEC.

§ 5.2:
Når ovenstående betingelser er opfyldt, registrerer DK Hostmaster, at registranten har skiftet internetudbyder. Ved redelegering af et domænenavn med tilknyttede DNSSEC-nøgler vil DNSSEC-service som hovedregel blive afbrudt, indtil registranten har angivet en ny nøglean- svarlig og nye nøgler, og DK Hostmaster har registreret den nye nøgleansvarlige og de nye nøgler.

§ 10:
DK Hostmaster påser, at de krypteringsnøgler, som DK Hostmaster genererer til brug for DNSSEC på .dk-zonen, er valide og annonceres korrekt. Ansvaret for registrantens krypte- ringsnøgler og håndteringen af disse påhviler registranten.
Det påhviler registranten selv at:
• • • •
generere sine krypteringsnøgler til brug for DNSSEC fremsende den offentlige nøgle af det genererede nøglepar til DK Hostmaster publicere nøglerne i DNS og sikre nøglerne mod kompromittering.
Brugen af DNSSEC indebærer derfor ikke en udvidelse af DK Hostmasters ansvar for rigtig- heden af DNS-oplysninger.

ad §2:
DNSSEC defineringen kan vi jo ikke rigtig sige noget til, men nøgleansvarlige bliver jeg nød til at kommentere.

En nøgleansvarlig findes i dag ikke på de godt 1000000 .dk domæner der findes, og udnævelse af en sådan, skal tilsyneladende ske ved en bemyndigelse af registranten, dvs. registranten skal personligt, eller hvertfald ved udlevering af sin adgang til dkhm hjemmeside, give nogen adgang til dette.

Resultatet bliver, uden tvivl, et af to onder. 1) DNSSEC bliver aldrig stort her i lille Danmark. 2) Kaos med support.

ad 5.2:
Redelegering udsletter så samtidigt nøgle, og nøgleansvarlig, så jeg formoder at nøgleansvarlig også kan godkendes og sættes i redelegerings fasen så vi slipper for flere unødige procedurer?

ad 10:
Det påhviler ikke registranten, men den nøgleansvarlige, at nøglerne er korrekt. i sidste ende bliver dette til registranten, men nu har man lavet rollefordeling til en nøgleansvarlig, så ville det også være smart at benytte sig af denne.

Yderlige bemærkninger til generelle vilkår:
§6
beskrivelsen af priserne bør ikke indgå i de generelle vilkår, men på et seperat prisblad.

§6.3 er ikke korrekt, fremtidligt betalinger tilfalder betalings kontakten, eller af den som registranten har markeret som betaler.

§ 8.3.5 “DIFO ́s beslutning kan ikke indbringes for Klagenævnet for Domænenavne, men kan indbrin- ges for de almindelige domstole.” Javel ja.. Hvor kom den regel fra, hvad er defineret ved sikkerheds hensyn, og hvorfor tror DIFO at loven ikke gælder for dem?

Der undres også en del over over i Kødbyen, at der tilsyneladende er så meget brug for ansvarsfraskrivelsen OG typosquatting reglerne… Men det kan vi komme ind på senere.. Offentlighedsfasen og information om DNSSEC finde der intet af på DK-Hostmaster.dk (prøv selv at søge efter “DNSSEC” her: https://www.dk-hostmaster.dk/soegning)

Tid til at flytte bits og bytes, tid til at få erfaring og tid til at komme i gear og få r*ven ud af vandskorpen. Vi har kørt med DNSSEC i nu snart mange år, som en eksperimental feature.

Vi har signed alle vores .se zoner som vi har i DNS med DNSSEC i en ren demonstration for at vise at det her ikke er en umulig opgave, alle DS nøglepar er vidresendt, automatisk, til det svenske registry via EPP, og alt er klar.

Det gør os med et til Sveriges største udbyder af DNSSEC, med lidt over 65% af de samlede antale DNSSEC signed zoner.

.. og hvad er så problemet, for der må da være problemer?

Ja, problemer er der masser af, feks har jeg ca 147444 .dk problemer. Disse zoner kan jeg ikke DNSSEC signere, da vi pr default ikke får adgang til at gøre dette i dk-hostmaster‘s nye fine system som frigives 1/7, da vi “ikke har nogle nøgleansvarlig på de ca 1 million .dk domæner der ligenu findes, da registranten manuelt skal gå ind og tilføje en nøgleansvarlig” – citat, mere eller mindre ordret, Per Kølle – DK-Hostmaster A/S (att Per: jeg modtager gerne korrigeringer hvis min opfattelse fra registrator møderne og DNSSEC mødet er opfattet forkert).

I forvejen findes der en DNS zone kontakt, hvis du ikke stoler på din DNS operatør, hvem fanden skal du så stole på?

DK-Hostmaster har en vision om at du som registrant, selv, eller giver en tredjepart adgang til at lave signeringen af zonen, dvs

1) du opretter en dns opsætning et sted

2) du laver en KSK og ZSK

3) du laver diverse smarte ting med værktøjer og zonen.. og volia, zonen er signed.

4) du uploader zonen igen til DNS udbyder

5) du uploader DS nøglen til DK-Hostmaster.dk

6) punkt 4 og 5 skal være nogenlunde timet, ellers ender du i problemer.

… Personligt tror jeg at løsningen er udtænkt af en teknikker i samarbejde med en jurist, vores kunder har enddog svært nok i forvejen ved at forstå de skal lave orderbekræftelse efter de HAR købt domænerne. At bede kunderne om ovenstående øvelse, eller bare det at gå ind og udvælge en nøgle kontakt (som i princippet kan være en anden end zonekontakten) og adgang til opdatering af en DS nøgle (hvem tror at kunder kunne finde på at indtaste tilfældige tal og bogstaver her?) er utopi.

.. i gratisdns.dk‘s tilfaelde, og for .se zonen, skal du lave .. absolut.. ingenting.. du skal bare blive ved med at sidde og lave din hjemmeside.. besvare dine mails fra dine kunder og gør dine kone glad med blomster. Det hedder shared registry, EPP, og god kundeservice.

Dét er visionen i fuld galop. Er det da ikke smart?

Hmm

Ja, vi var jo til et møde hos DIFO/DK-Hostmaster i den forgangende uge, det kan jeg have svært ved at fornægte.

Et superkort punktopstilling af emner fra mødet vil være:

Ting der er fast besluttet:

DNSSEC

Ting som man ikke rigtig ved/snakker om/blev taget op på mødet:

Webinterface, eller ej.

Email form eller ej.

Pris?

NSEC eller NSEC3, dog er der en vis lykke forbundet med NSEC3, da man ikke kan lave en DNSWALK, men man kan jo bare downloade listen af domæner fra dkhm hver søndag?

EPP systemet kommer til at være hovednøglen til oprettelse af domæner med DNSSEC (det er tilladt at sige, “Hva??” her)

Testsystem, måske, hvis der er en egentlig grund til at lave et.

Måske bliver DNSSEC bundlet med VID, måske ikke, måske kommer der en pris på ved siden af.

Registrars er egentlig meget besværlige kunder, de spørger for meget, men så igen er de jo ikke slutkunden.. Sååh..

Prisen på et .dk domæne kunne “nemt sættes et par kroner ned” for et par år siden, under den store “valgkamp”, nu skal vi betale ekstra.. måske, måske ikke, hvis vi skal have DNSSEC.

.dk zonen er pivåben for phising angreb på 10. år, og ingen ønsker at diskutere dette.

Ingen forklaring på forretningsmodel omkring DNSSEC.

Intet budget blev fremvist.

En forventning om at blive indenfor det tekniske personal’s rådige timetal.

En forventning om at virksomheder og andre med interesse i DNSSEC skal tilføje de ekstra resourcer til testing af DNSSEC.

Mangel på kommunikation ved ændring af praksis.

… De fleste af de ting der reelt blev diskuteret, var og er igen og igen, den manglende fornemmelse for verden som DIFO og DK-Hostmaster til tider udviser.

Koster DNSSEC på et .dk domæne noget?

ja, nej.. Måske.. testperioden er gratis!

Peter Makholm bragt dette spørgsmål op, og pludselig befandt forsamlingen sig i et limbo af nja, njow og narj.. For det viste sig at ingen havde reelt et svar på dette ellers meget kritiske spørgsmål. Vi har set det i .SE regi, da prisen på DNSSEC var over 0,-, var der mildt sagt ringe interesse for det hos hostingvirksomhederne, da det er tvivlsomt at man kan sige man vil bruge resourcer på at udvikle noget til DNSSEC hvis kundernes pris for et domæne pr år bliver fordoblet.. i så fald vil de fleste kunder nemlig så vælge det fra, og vores resourcer på udvikling er dermed tabt. Nobody wins!

Hvem skal holde nøglerne?

Her er svaret jo klart.. hvertfald set med DK-Hostmasters øjne, det skal registranten!

.. men hvordan helvede skal vi så signe zonen? Skal vi mødes i en hemmelig baggård, med dårligt lys, og registranten med nøglen, zonekontakten med en kopi af zonefilen og så stå og kryptere det på den medbragte laptop?

.. og naturligvis skal registranten så bagefter fortælle dk-hostmaster hvornår zonekontakten sætter zonen i drift med nøglen.. ?

.. og så når registranten ringer til DK-Hostmaster, så sendes de bare videre til zonekontakten, for det er jo os der ved svaret, men det er DK-Hostmasters kunde.. Dvs, DK-Hostmaster tjener pengene på domænet og DNSSEC, og vi skal levere varen og servicen.. god arbejdsfordeling.. hvis man tror på havenisser og loch ness uhyret altså..

VÅGN DOG OP! Successraten på ovenstående er lige så stor som sandsynligheden for at møde fritlevende pingviner i Sibirien!

Svaret er simpelt, din primære zonekontakt skal kunne opdatere DK-Hostmaster med den korrekte nøgleinformation, og i mange tilfælde vil det også betyde at zonekontakten laver nøglen og holder nøglen, stoler du ikke på din primære zonekontakt, så bør du nok overveje om han skal holde din zonefil!

Budget/forretningsplan for DNSSEC?

.. Der blev som sagt ikke fremlagt nogen egentlig forretningsplan for DNSSEC i .dk zonen, om det så betyder at man mener det ingen betydning har for DK-Hostmaster økonomisk, eller om man bare ikke ved hvor meget andre registries i den forbindelse har brugt af resourcer på DNSSEC, det er mig en gåde. Jeg har flere gange spurgt andre registries om deres fremgang med DNSSEC, og de svare typisk med en teknisk “manpower” tal på 10-20 mennesker fuldtil i op til 1,5 år, og policy arbejde ved siden af. Vi har til 1/7-2010, og der er en håndfuld teknikkere (som også varetager den daglige drift), og et ekspertpanel (som består af 3 eksterne og 3 interne) personer…

Jeg har ikke set noget endnu jeg vil betegne som policy work, og heller ikke endnu nogen løsninger på de tekniske spørgsmål. Måske derfor man har svært ved at lave et regnestykke?

Og uanset hvordan DIFO og DK-Hostmaster så end vender og drejer det, nøglen til succes ER igennem udbyderne, og med DNSSEC set fra en internationalt synspunkt, ligger igennem samarbejde med registrars/zonekontakten og registryet, og jeg ser ikke historisk set at samarbejdet virker, det er noget ensrettet og uden tilsætning af smagsoplevelser.

Testsetup af .dk?

.. blev officielt efterspurgt på dette møde, omend jeg sad tilbage med fornemmelsen for at forståelse for dette ønske ikke var til stede.. Bla hørte jeg med begrundelse med at “følge sverige på dette punkt” blive afvist med “ja, men de gør også så meget andet som vi heller ikke har planer om/ønsker at gøre”.

.. Antallet af fejl i en overgang til DNSSEC ville nu engang blive mindsket hvis man ikke skal lege med de officielle systemer, ellers gør man sgu nok som svenskerne en eller anden dag, og vælter hele pisset.

.. og alligevel vil man gerne lave et mini testsetup af DNSSEC, for vi kan hvertfald tilmelde os på tilmelding@dk-hostmaster.dk til at være forsøgsrotter med DNSSEC i .dk regi. Problemet er bare, hvis man ikke laver et komplet setup med et EPP system, og en email formular, og et webinterface med registrant adgang, hvad er det så vi tester? tester vi et udsnit af det tekniske setup, eller fodre vi bare systemet med testdata?

Far er ikke sur, far er skuffet, og far gidder faktisk ikke mere pis.

DU overvejer om hvornår rodzonen bliver signed, svaret er simpelt.

Det bliver den i år

Kommer .dk til at være klar til det? Er registratorerne klar til det, har de nogen interesse i at lave arbejdet? Hvad er vores (registratorens) mål med det, hvordan kan vi opnå det, når vi end ikke har adgang til .dk domænernes data eller har lov til at tage medansvar for dem, men at vi sættes udenfor indflydelse og bare kan rette ind via ikkestandardiseret værktøjer? Så stort et land er Danmark heller ikke..

Er det i virkeligheden her at diskutionen om shared registry/sole registry står.. Hvis man fratager folk andel i ansvaret, betyder det så også de ikke gider tage ansvar for udviklingen?

Vi kan lige så godt indse det, det her bliver Danmarks mest orange blog.. Hvis det ikke er :)

Som sagt, ICANN Cairo mødet har virkelig jumpstartet en del DNSSEC omtale, især hos nogle af de store spillere, feks kan man læse en kort FUD buster om DNSSEC af Ram Mohan (kan du genkende navnet?) fra Afilias og ikke mindst se en kort lettere teknisk forklaring af dns og dnssec her: http://www.circleid.com/posts/20081106_dnssec_fud_buster_necessary/

Det jeg ikke kan se, og som jeg ikke har fået noget billed af i lang tid efter at vi fik en afgørelse (well, formelt set er det endnu op til IT & telestyrelsen at vurdere om DIFO får .dk), er en tidsplan og hvordan vi arbejder os hen i mod DNSSEC på .dk domænet.

Vi skal have erfaringen direkte, og kun DK-Hostmaster kan hjælpe os med det, og i det her tilfælde er det jo ikke en advokat der kan svare på spørgsmålet, så vi må rette blikket mod den, efter min mening, alt for lille stab af teknikkere hos DK-Hostmaster.

Drenge, hvornår skal vi lege med DNSSEC ?

Er det overhovedet muligt at påbegynde arbejdet med DNSSEC uden at udvide teknikstaben hos DK-Hostmaster?

Ikke fordi jeg kan finde en fejl, eller mangel på iver hos teknik afdelingen, men jeg kunne godt frygte der ikke var nok af jer..

Især når jeg læser at DIFO søger forretningsfører, som “Forretningsføreren må have uddannelse som jurist eller på anden måde kunne dokumentere fortrolighed med retlig regulering.” så vil jeg være meget mere tryg ved at der kom mere “modvægt”, mere fornuft.. Flere teknikkere til at opveje for nogle af de “juridiske tosserier” som der hurtigt kan opstå når advokater keder sig..

Jeg vælger også at læse comon artiklen som en accept af at DIFO/DK-Hostmaster ikke er nok synlig i det internationale samarbejde. Her ikke begrænset til DNSSEC, men burde vi ikke havde søgt om afholdelse af det næste ICANN møde i europa her i lille Danmark, kunne det ikke være en fin start?

Orange, for altid :)