Nye top-level domæner

Så har vi listen over bud på nye TLD'er.

Langt størstedelen er firmaer som vil sikre sige deres firmanavn som TLD. Skimmer jeg listen igennem finder jeg seks danske virksomheder: Lego, Lundbeck, FLSmidth, One.com, Rockwool og Saxo Bank. Der er måske enkelte der overrasker ved deres fravær - specielt Novo, men elllers ikke de store overraskelser her.

En lang række af de generiske TLD'er bliver støttet af organisationer der kun ansøger om et eller to TLD'er - foreksempel dotHot der er med i feltet om at ansøg om .hot. De helt store TLD-ejere ser ud til at blive Amazon og Google (dog under navnet Charleston Road Registry?!?).

Er I overrasket over indholdet af listen? Jeg er ikke...

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Poul-Henning Kamp Blogger

Novo skal da roses for ikke at spilde pengene på ligegyldigt flim-flam i den hellige imaterielrets navn.

Jeg kan finde 4 slags ansøgninger på listen:

  • Byrødder med jord i hovedet (Stockholm, Sydney)
  • Domænemafiosoer (gmbh etc)
  • $bigcorp der mangler proportionssans og udgiftskontrol(.fls etc)
  • Folk der har solgt venture-capitalists en god historie (.sucks)

Der er ikke nogen af deres ansøgninger der vil gøre nettet et bedre sted at være.

  • 20
  • 1
#3 Kenneth Mortensen

Nu bliver det da for alvor svært at mindske pushing angreb... Jeg synes der er ret mange TLD i forvejen, og når virksomheder nu direkte kan ansøge om et TLD vil det jo ikke blive mindre. Jeg tror vi i fremtiden vil se en større omgang pushing angreb end vi tidligere har set. Det vil for hr. og fru. Danmark nu for alvor blive svært at kende forskel "orginale" domainer og pushing domainer...

  • 2
  • 1
#5 Henning Makholm

Jeg savner stadig svar på om det er meningen at fx Lego (hvis de bliver godkendt) må forsyne "LEGO." med en A-record og derefter forvente at http://lego/ får browsere overalt i verden til at kontakte deres servere. ICANN regner med at introducere op til 1000 nye TLD'er om året -- hvordan i alverden skal en stakkels lokalnetadministrator så sørge for at hans lokale hostnavne ikke kolliderer med en TLD?

(Der er 7 ansøgninger om "MAIL.". Hvor mange systemadministratorer på verdensplan forventer mon at "ssh mail" gør noget ganske andet end de 7 ansøgere gerne vil have den til at gøre?)

  • 5
  • 0
#8 Peter Brodersen

Danske ansøgninger: FLS, FLSMIDTH, ICU, LEGO, LUNDBECK, NOW (2 fra dk), ONE, ROCKWOOL, SAXO. Jeg kan ikke lige gennemskue "icu", som One.com har søgt på.

Generelt: Kun to ansøgninger på SEX, men tre på SUCKS (og syv på LOVE). YouTube (dvs. Google) forsøger sig både med YOU, TUBE og YOUTUBE

Både REPUBLICAN og DEMOCRAT er taget af den samme.

Eneste vestlige IDN-TLD er vermögensberater og vermögensberatung. Der er ingen IDN-TLD'er med mere end 2 ansøgere (af en eller anden grund mener "uniq -c", at グーグル [google] optræder tre-fire gange, selv om det ikke er tilfældet?)

Flest ansøgninger: APP (13), INC (11), HOME (11), ART (10), SHOP (9), LLC (9), BOOK (9), BLOG (9), MUSIC (8), MOVIE (8), DESIGN (8). Ingen ansøgninger på CDN (men syv på CLOUD).

Både Google og Microsoft har ansøgning på DOCS.

Dertil kommer de (vist nok) uafklarede situationer, lidt som opfølgning på Hennings spørgsmål:

Cookies Hvordan kommer cookies til at virke? Lige nu har browsere regler for forskellige TLD'er, og tillader fx at a.foo.dk kan dele cookies med b.foo.dk, men at a.co.uk ikke kan dele cookies med b.co.uk (hvilket også er grunden til, at det er en session fixation-sikkerhedsbrist at smide noget under co.dk og bare endnu en grund til at holde sig langt væk fra dette).

Men skal foo.sony kunne dele cookies med bar.sony? Nogle steder er det én organisation, som har alt, mens det andre steder ligger op til, at indehaveren vil videre-udstede domænenavne, fx AMSTERDAM, AFRICA, BAYERN, etc. (typisk dem, som er markeret "Geographic") - og så vil foo.bayern måske helst ikke kunne dele cookies med bar.bayern

Måske browserudviklerne kan bruge "Community"- eller "Geographic"-flaget for at definere regler for dette som en tommelfingerregel. Men der kan måske stadigvæk dukke nye tld's op med tiden, uden at browseren når at blive opdateret til at have regler for denne.

Der er også andre individuelle regler og "best practice" for forskellige tld'er ud over cookies, fx om browseren bør vise/tillade specialtegn i adresselinjen, eller om den punycode-encodede adresse bør vises i stedet. At udvide denne domæne-tjek-liste fra nogle hundrede stykker til nogle tusinde stykker burde næppe have nogen betydning rent performancemæssigt.

SSL Kan alle SSL-udstedere nu også udstede certifikater under disse tld's?

MX og mail Er der noget i vejen for at smide en MX-record på direkte på tld'et? Efter sigende var IANA ikke tilfredse, da de for mange år siden opdagede, at der var en mx-record for dk. Men hvis der stadigvæk er en A-record, så...

Det ville kunne føre til kortere adresser i stil med brodersen@gmail - omend der sikkert er en million websites og applikationer med dumme regulære udtryk, som vil brokke sig over manglende punktum, når man skal indtaste en mailadresse.

Omvendt set er mange af de regler i forvejen defekte - fx de håbløse eksempler, hvor folk har taget en RFC for at tjekke, hvordan en "gyldig mail-adresse" ser ud og ender med et monster-udtryk, uden at de er klar over, at de regler altså også definerer, hvordan man angiver navn, så RFC'ens opfattelse af en adresse er fx snarere "Peter Brodersen" <brodersen@gmail> end blot brodersen@gmail

Vi kan også håbe på, at det dræber de par sidste scripts derude, der arbejder med en lokal, statisk whitelist over tld's, i stedet for bare at forsøge at lave et opslag på hostnavnet.

  • 10
  • 0
#10 Peter Mogensen

Ang. publicsuffix.org... Hvor stort er bureaukratiet for at få et suffix, der er forkert listet på den liste taget af?

Suk... de er virkelig på vej til at ødelægge DNS. Når jeg bliver gammel vil jeg nok sidde med vemod og kigge tilbage på dengang DNS virkede, en digital signatur faktisk var en digital signatur og man ikke skulle have en Facebook konto for at kommunikere med sit barns folkeskole. :(

Jeg begynder at få en smule respekt for gamle sure mænd.

  • 16
  • 2
#12 Jan Ferré Jensen

Du er ikke den eneste, der undrer sig, Palle :)

Men at dømme efter eksemplerne i nogle af svarene, må det dreje sig om at lave navne, der matcher 'almindelige' stavefejl, samt som let kan fejlfortolkes. Altså i retning af at lokke dig til at logge på nordrea.dk, når du opfordres til at kontakte nordea. Eller måske at have domænerne legi.dk, legp.dk, leg9.dk til produkter, der konkurrerer med lego.

Eller også er pushing bare et forsøg på at miskreditere phishing :)

  • 0
  • 0
#13 Bjarke Walling

Hvordan kommer cookies til at virke? Lige nu har browsere regler for forskellige TLD'er, og tillader fx at a.foo.dk kan dele cookies med b.foo.dk, men at a.co.uk ikke kan dele cookies med b.co.uk

Jeg håber egentligt at de nye domæner ikke tillader deling af cookies på tværs af sub-domæner. Det er IMHO en bedre og simplere sikkerhedsmodel. I HTML5 localStorage er det heller ikke tilladt at dele data på tværs af sub-domæner, med god grund. Der er kun få use-cases for deling af cookies, som ikke kan løses på andre måder. Du kan enten bruge cross-domain messaging (IE8+) eller køre dit single-sign on API på ét subdomain (med understøttelse af Cross Origin Resource Sharing).

  • 1
  • 0
#14 Peter Brodersen

Ang. publicsuffix.org... Hvor stort er bureaukratiet for at få et suffix, der er forkert listet på den liste taget af?

Suk... de er virkelig på vej til at ødelægge DNS.

Bum, "problemstillingen" med at browseren skulle kende til forskellige tld's hierarkier er over 15 år gammel. Det er også fint, at en browser ved, at den ikke bør acceptere et SSL-certifikat for *.co.uk, men godt for *.foo.dk og for *.foo.co.uk

I forvejen er hostnavne for længst røget op på applikationsniveau, fx Host-headeren i HTTP-requests, som første gang set i RFC 2068 fra 1997 (senere RFC 2616). Jeg ved ikke, om vi virkelig ønsker os tilbage til den tid, før det var en del af virkeligheden, selv om det i og for sig er lidt af et hack. Vi ser stort set ikke dette trick i nogen andre protokoller end HTTP.

  • 0
  • 0
#15 Peter Makholm Blogger

På en eller anden måde overrasker det mig meget, men jeg kan simpelthen ikke påstage mig en mening om hele dette projekt. Jeg synes hverken at argumenterne for eller imod er specielt overbevisende.

For en stor del at ansøgningerne ser jeg mest af alt en mulighed for at profiterer ved at kunne sælge flere domæner. Det giver selvfølgelig mening for sælger, men jeg synes ikke det er et godt argument.

Resten er firmer der mener at det har en værdi at have et privat TLD. Men her tror jeg at domæner (og URL'er generelt) bliver mere og mere ligegyldige til markedsføring. Mailadresser bliver den sidste bastion, men ellers går jeg ikke rundt og husker på domænenavne. Skal jeg finde et firma jeg har set noget ikke-online reklame for, så søger jeg efter firmanavnet, eventuelt i kombination med branche eller et produktnavn. Jeg vil da i hvert fald ikke prøve at gætte mig frem til http://mindstorm.lego/

Det ødelægger den hierarkiske struktur, siger modstanderne. Det passer måske til dels i forhold til firmaernes private TLD'er, men i forhold til resten så finder jeg at den nuværende hierarkiske struktur er så skæv at det kun kan blive bedre. I øvrigt er det kun bibliotekarer og visse IT-folk der bvliver indoktrineret til at en streng hierarkisk struktur er tilstrækkelig. Der er ingen andre der tænker såden.

Men det ødelægger vores kludge der løser dette eller hint problem, får vi også at vide. For eksempel hele problematikken om hvor bredt cookies kan deles. Det ser jeg mest af alt netop som et argument for at tilføje TLD'er i en så stor bunke at det er indlysende klart at de eksisterende løsninger ikke virker.

Øger de nye TLD'er risikoen for phishing? Nu tror jeg ikke at domænenavne er en specielt god beskyttelse mod phishing - selv ikke hvis jeg generelt tager fejl i at domænenavne bliver ligegyldige. For nogle firmaer er det måske endda en beskyttelse, hvis de har råd til at kaste en million i kassen.

Verden var meget bedre da RFC920 var authoritativ. Beklageligvis tog den bare ikke hensyn til småting som at jeg godt vil have et personligt, ikke-nationalt domænenavn. Men så fik vi .name - som så bare krævede små ændringer i forhold til alle ovenstående betragtnigner. Måske skulle man have indset problemerne med betragtningerne allerede den gang.

  • 3
  • 0
#17 Henning Makholm

I forvejen er hostnavne for længst røget op på applikationsniveau, fx Host-headeren i HTTP-requests, som første gang set i RFC 2068 fra 1997 (senere RFC 2616). Jeg ved ikke, om vi virkelig ønsker os tilbage til den tid, før det var en del af virkeligheden, selv om det i og for sig er lidt af et hack. Vi ser stort set ikke dette trick i nogen andre protokoller end HTTP.

Tæller SMTP?

For mig at se er det eneste problem med HTTP's løsning sammenlignet med SMTP at serveren ikke [i]fra starten[/i] fik den fulde URL at vide -- og så blev man bagefter nødt til tilføje den til protokollen på en måde der ad hensyn til bagudkompatibilitet ser lidt klodset ud.

I en ideel verden ville HTTP bruge en analog til MX, så man kunne modularisere sin konfiguration uden at brænde alle broerne med en CNAME -- men SRV var jo ikke opfundet dengang.

  • 0
  • 0
#20 Peter Mogensen

Måske skulle jeg uddybe at grunden til at det skurer i ørene for mig med det her ikke er phising eller at cookies til subdomæner (som jeg er enig i er en dårlig måde at styre hvem der får hvad på). Næe.. det var såmænd en reaktion på at det nok kan blive nødvendigt at eksplicit skrive det sidste punktum altid i DNS og at vi ka får lappeløsninger som publicsuffix.org. (som for mig også lyder som en dårlig ide).

Man kan måske have en pointe i at måden at skelne om noget var et relativt eller absolut ostnavn ved at antage at absolutte hostnavne skulle have mindst 1 punktum nok også var en dårlig ide.

  • 0
  • 1
#21 Jacob Pind

Kigger man på de dokument og økonomiske prognoser som icann har lagt ud, er det jo tydlige at det var tiltænkt som værende nye offenlige tlds, men ting som lego, saxo og flsmidth tyder ikke på de har tænkt sig at bruge det som sådan.

Men derfor bliver de vel stadigvæk afkrævet at etablere strukture til at håndere ansøgninger, havde tekniker, og infrastruktur til det.

  • 0
  • 0
#24 Peter Makholm Blogger

Næe.. det var såmænd en reaktion på at det nok kan blive nødvendigt at eksplicit skrive det sidste punktum altid i DNS og at vi ka får lappeløsninger som publicsuffix.org. (som for mig også lyder som en dårlig ide).

Pseudobehovet for publicsuffix.org har intet med de nye gTLD'er at gøre.

I bedste fald kan det måske få publicsuffix.org til at bryde sammen under sin egen kompleksitet, men jeg tvivler. 1000 nye tld'er vil næppe gøre fra eller til når vedligeholdelsen af den liste allerede kræver at man ved hvordan der bliver tildelt domæner til grundskolerne i Massachusetts. Men jeg forventer at reglerne for de fleste af de nye domæner vil være temmelig meget simplere end for .us

  • 0
  • 0
#25 Poul-Henning Kamp Blogger

Jeg synes egnetlig ikke det er publicsuffix.org der er problemet: Problemet er at HTTP ikke har et brugbart session-begreb og at cookies er et hjernedødt kludge for at tilføje det.

Den rigtige løsning er at indføre et ordenligt session-begreb i HTTP/2.0 så vi kan slippe for cookies.

  • 0
  • 0
#26 Peter Makholm Blogger

Comon har tal med Legos kommunikationschef:

"Vi mener hverken, at det her bringer innovation, medfører lavere priser eller gør tingene nemmere for den almindelige forbruger," siger Roar Rude Trangbæk.

Kommunikationschefen mener, at netbrugerne i højere grad end domæne-navne bruger apps og søgemaskiner for at finde indhold på nettet, og i LEGOs tilfælde har forbrugerne lært, at Lego.com er stedet at finde information.

Men Lego vurderer altså alligevel at det er mindre besværligt bare at registrerer her og nu end at overvåge registreringssystemet og indgive indsigelser hvis nogen skulle finde på at registrere noget der ligger for nært.

Hvis den risikovurdering holder bliver hele spillet om nye domæner et kæmpe spil prisoners dilemma, hvor flertallet måske vurderer at vi vinder ved kollektivt ikke at gå amok, men hvis bare nogle få går amok så bliver man nødt til at følge efter.

Og dét er i grunden trist...

  • 0
  • 0
Log ind eller Opret konto for at kommentere