Danske .dk domæner ikke sikre for private personer

Halløjsa,

Ja, du læste rigtigt. De danske .dk domæner er ikke længere sikre for private personer.

En nyere sag afgjort af domæneklagenævnet har fastsat at en virksomhed, der har registreret et varemærke i 2009, har kunnet overtage et .dk domæne registreret af en privatperson helt tilbage i 1999. Privatpersonen havde registreret domænet, da domænenavnet var dennes nickname online i spil, chat m.m.

Det betyder basalt set, at hvis en virksomhed i dag varemærkeregistrer navnet frande, så kan de umiddelbart overtage mit domæne, frande.dk, ved blot at indsende en klage til domæneklagenævnet.

Hvad sker der lige for det klagenævn? Og hvordan kan en virksomhed overhoved varemærke-registrer sig, når der i forvejen findes et .dk-domæne på præcis samme navn (hvilket jo betyder at varemærket ikke er unik under registreringsprocessen)?

Ja, jeg undrer mig betydeligt – der er noget helt galt her!!

Der kan læses meget mere om sagen på følgende links:
http://new.czar.dk/?p=547
http://www.domæneklager.dk/uploads/2009-0099orango.dk (selve afgørelsen – i PDF-format)

Støt op om .dk-domænet

Halløj,

I den senere tid har der været udbud om det danske .dk TLD (Top Level Domain). To har budt på det, henholdsvis DIFO / DK-Hostmaster (Nuværende forvalter) og dotDK.

IT & Telestyrelsen valgte desværre dotDKs model på den betingelse, at de kan få opbakning i det danske internetsamfund. Det er ifølge min mening en forkert beslutning.
Det er dog vigtigt at nævne, at de endnu ikke officielt har fået denne opbakning. Derfor er der stadig mulighed for, at dotDK ikke bliver den fremtidige forvalter!

De to organisationer (DIFO & dotDK) har budt ind med to forskellige modeller.

DIFO har budt ind med deres nuværende model, der baserer sig på såkaldte “sole registry”. Det betyder basalt set, at der er én forvalter af TLDet og at kunden er registranten af domænet. Man er hermed uafhængig af at skulle betale fornyelser af domænet til sin webhotel-udbyder, men skal i stedet betale til DK-Hostmaster, der forvalter .dk-domænet.

dotDK har i stedet budt ind med en model, der går under navnet “shared registry”. Det betyder i menneskesprog at dotDK udbyder TLDen, men at de sælger det til grossister (i dette tilfælde webhotel-udbyderne), som så sælger det videre til slut-kunden.

Grundene til at dotDKs model ifølge min mening er det forkerte valg er:

1. Prisen på et .dk-domæne sænkes, men der kommer en grossist imellem dotDK og kunden.
dotDK har garanteret en nedsættelse af den nuværende pris for et .dk-domæne (den nuværende pris er kr. 45,- pr. år.), hvilket i sig selv er et fint initiativ. Vi har her i Danmark i forvejen et af jordens billigste domæner. Men så snart dotDK vælger at inddrage grossister, bliver det et problem.

Grossisterne driver deres egen virksomhed, og kan fuldt ud selv bestemme om prisen til deres kunder for et .dk-domæne skal være kr. 199,- pr. år, eller om det skal være kr. 50,-. Det betyder altså at prisen, som dotDK garantere kun er overfor grossisterne, men ikke overfor slut-kunden (dvs. os der køber domænerne), der kan risikere prisstigninger.

Sammenligner man med andre TLDer, der basere sig på “shared registry”-modellen (det gør bl.a. .com, .net og .org) så er priserne på disse typer domæner ret høje i både oprettelse såvel det årlige gebyr for fornyelse af domænet.

Man kan derfor også frygte, at det samme vil ske for .dk-domænet, hvis det får en “shared registry”-model.

2. Den tidligere webhotel-udbyderen skal godkende en flytning af domænet.
I dag er vi vant til, at vi hos DK-Hostmaster kan flytte (eller med DK-Hostmasters sprog redelegere) vores .dk-domæner indenfor få timer og uden at indblande andre end os selv.

Med en “shared registry”-model, så skal ens nuværende udbyder af domænet godkende, at domænet skal flyttes til ens nye udbyder. Det betyder oftest, at det tager længere tid at flytte domænet fra én udbyder til en ny. Samtidig er det et problem, hvis man flytter fra sin nuværende udbyder pga. uoverensstemmelser. De kan på sin vis nedprioritere ens flytning ved at undlade at godkende domæne-flytningen før der er gået noget tid, eller de kan helt undlade at godkende den.

Det problem har jeg personligt selv stødt i med både .com og .net domæner, der netop basere sig på en “shared registry”-model, hvor det tog bl.a. én af mine kunder over 2½ måned at flytte et .com domæne fra én udbyder til en anden. Til sammenligning tager det ikke mange timer at flytte et .dk-domæne hos DK-Hostmaster i dag.

3. dotDKs endelig løsning er pt. ret lukket.
Det tilbud dotDK afleverede til IT & Telestyrelsen beskriver en model, men fortæller ikke meget konkret om, hvordan den endelige løsning bliver. Det betyder i teorien, at man ikke 100 % ved hvad man får, når deres tilbud vælges.

Som de fleste nok kan regne ud, så støtter jeg den nuværende model, som DIFO / DK-Hostmaster kører med. Den fungerer fint for mig, og har gjort det i en årrække. Det betyder dog ikke, at der ikke er plads til forbedringer. Det er der helt bestemt. Jeg er dog ikke i tvivl om, at DK-Hostmaster vil kunne løfte opgaven.

Jeg har tilmeldt mig en Facebook-gruppe, der støtter den nuværende model (den støtter dog ikke direkte DIFO / DK-Hostmaster). Hvis du derfor er på Facebook og meget gerne vil beholde den nuværende danske .dk-domæne model, så synes jeg, at du skal tilmelde dig gruppen og vise din støtte.

Du finder gruppen her: Bevar .dk domænet uafhængigt!

Subdomæner med PHP

Subdomæner bruges i stor stil i dag til at brugere nemmere kan finde delindhold på websites.

Der er flere former for subdomæner. Der er dem, hvor:

  • subdomænet er oprettet på et seperat webhotel.
  • subdomænet er et “spejl” af en mappe (test.frande.dk har samme indhold som frande.dk/test/)
  • subdomænet viderestiller til et placering (test.frande.dk viderestiller til frande.dk/test/)

Jeg vil nu vise hvordan man med simpel PHP-kode, og en smule DNS-opsætning (bliver man ikke guidet igennem), kan lave subdomæner, der viderestiller til en given placering.

Jeg tager udgangspunkt i mit eget domæne (frande.dk), men vil gerne notere, at det ikke er sat op på mit domæne – det er ren eksempel!

Opsætning af domænets DNS

Opsætningen af domænets DNS er i dette eksempel meget vigtigt, at have på plads.

For at kunne opsætte viderestillingen via PHP, skal det ønskede subdomænenavn pege på selve “hoveddomænet”. Oftest vil man gøre det med et såkaldt stjerne-alias, hvor man siger, at *.frande.dk peger ind på samme webserver som frande.dk.

Dertil skal man sætte op på web-serveren at *.frande.dk skal pege ind på frande.dk.

I de fleste tilfælde vil man selv kunne sætte DNSen op, mens web-serveren oftest skal sættes op af ens udbyder.

Nu til det spændende

For at starte udvælger vi nogle subdomæner, som vi vil oprette, samt nogle placeringer.

jubii.frande.dk viderestiller til jubii.dk
galleri.frande.dk viderestiller til frande.dk/galleri/
links.frande.dk viderestiller til frande.dk/links.php

Herefter skriver vi følgende PHP-kode:

  1. <?php
  2. $redirect_to = "";
  3. if ($_SERVER[‘HTTP_HOST’] == "jubii.frande.dk")
  4.     $redirect_to = "http://www.jubii.dk/";
  5. else if ($_SERVER[‘HTTP_HOST’] == "galleri.frande.dk")
  6.     $redirect_to = "http://www.frande.dk/galleri/";
  7. else if ($_SERVER[‘HTTP_HOST’] == "links.frande.dk")
  8.     $redirect_to = "http://www.frande.dk/links.php";
  9.  
  10. if (!empty($redirect_to))
  11. {
  12.     header("Location: " + $redirect_to);
  13.     exit;
  14. }
  15. ?>

Det er vigtigt at koden ligger i index.php-filen i roden af webhotellet. Det er den fil, som man skal ramme som standard, når man indtaster f.eks. frande.dk i browseren.
Koden skal ligge allerøverst i filen og være det allerførste, der udføres. På den måde sikrer man, at der ikke udføres noget andet PHP-kode inden man viderestiller.

Nu til forklaringen af koden – det er jo vigtigt for forståelsen af, hvad der sker.

Jeg vælger, da der kan indtastet flere forskellige subdomæner, at gemme den adresse, der skal viderestilles til, i en variabel ($redirect_to).
Til at starte med sætter jeg derfor variablen $redirect_to til ikke at indeholde noget.

Derefter tjekker jeg om adressen, brugeren har indtastet i browseren, er en af de ønskede subdomæneadresser. Det sker vha. en såkaldt if-then-else sætning, hvor jeg spørger om variablen $_SERVER['HTTP_HOST'] er lig de forskellige subdomæneadresser. $_SERVER['HTTP_HOST'] indeholder den adresse, som brugeren indtaster i browseren. Såfremt $_SERVER['HTTP_HOST'] er lig én af de ønskde subdomæneadresser, tildeles variablen $redirect_to den adresse, der skal viderestilles til.

Til sidst tjekker jeg på om variablen $redirect_to er tom. Er den ikke tom, skal den sende data ud til brugerens browser om, at den i stedet skal efterspørge den side, som, der ønskes viderestillet til. Til sidst bruges metoden exit for at sikre, at der ikke udføres mere kode efter denne linje.

Alt i alt et meget simpelt script, der kan hjælpe til at forenkle mange ting. At bruge PHP til dette er blot én af mange måder, hvorpå man kan udføre ovenstående. Det vil jeg dog ikke kigge nærmere på.