Icann schiet Googles plan voor dotless .search-domein af

De Icann heeft een resolutie aangenomen die het gebruik van zogenaamde dotless-domains verbiedt. Google was juist voorstander van deze mogelijkheid en wilde dotless-domeinnamen gebruiken om een open redirectdienst te maken van de url http://search.

In een aangenomen resolutie schrijft de Icann dat zij na een uitgebreid onderzoek naar de voor- en nadelen van zogenaamde dotless-domeinen tot de conclusie is gekomen dat er te veel veiligheidsrisico's aan kleven. Google en enkele andere partijen waren voorstanders van het concept.

Met een dotless-domain was het mogelijk geweest om een top level domain te gebruiken zonder de punt. Google hoopte op die manier het tld '.search' in te zetten als redirect via de url http://search. Door aan dit domein een query-structuur te koppelen, moest een eindgebruiker eenvoudig vanuit de adresbalk van zijn browser kunnen zoeken. Ook andere bedrijven die zoekmachines exploiteren zouden van .search gebruik mogen maken. Dat idee is met de uitspraak van de Icann dus van de baan.

De Icann is momenteel druk met het behandelen van de aanvragen voor nieuwe gtld's. Instanties en bedrijven konden de afgelopen maanden verzoeken indienen voor nieuwe gtld's. Google diende aanvragen in voor onder meer .search, .app, .blog en .cloud. Onlangs werd bekend dat de aanvragen van DNS Belgium voor .brussels en .vlaanderen goedgekeurd zijn. De Nederlandse overheid was aanvankelijk van plan om .overheidnl te registreren, maar zag hiervan af omdat de omschakeling te duur en te complex zou zijn.

Reacties (54)

[Niemand_Anders]

Ik heb bij veel bedrijven intranetten gezien welke geen (g)tld extensie hadden en dus werken met http://bedrijfsnaam en vaak is dat ook de naam van de Active Directory/Workgroup.

Daarnaast zou een extensie loos domein ook problemen geven bij validaties op url's en email adressen. Want niet alleen kan http://search worden gebruik voor redirects, het is ook een mail domain waardoor info@search een geldig email adres zou zijn..

Ik ben al geen voorstander van een onbeperkt aantal generic tld's omdat het alleen maar zorgt voor fragmentatie van het internet. Je moet maar eens kijken hoeveel van je website bezoekers op je website komen, door op de bedrijfsnaam te zoeken bij een search engine. Straks is het bijna onmogelijk om te weten op welke (g)tld een website zit. Daarbij worden .name, .biz en .aero alleen eigenlijk niet gebruikt.. Zelfs de scheiding tussen .com, .net en .org is al zeer lang los gelaten.

Daarnaast zijn er nog steeds geen duidelijk regels als een 'register' misbruik maakt van zijn gtld. Stel Google start een reclame campagne op http://bing.search/engine, kan Microsoft dan een klacht indienen bij het Icann wegens inbreuk op een trademark en wat voor acties onderneemt het Icann vervolgens? Heeft Microsoft dan pech of kan het Icann Google een boete opleggen of het (g)tld ontnemen?

[boelensman1]

info@search is zowieso al een geldig e-mail adres volgens rfc5321.

Zie 2.3.5. Domain Names:
"In the case of a top-level domain used by itself in an email address, a single string is used without any dots."

Dus als iedereen z'n e-mail validatie goed schrijft, zou er niks aan de hand moeten zijn.
Helaas zal dat inderdaad wel niet het geval zijn.

[MneoreJ]

Nee, kunst. De standaard voor e-mailadressen is berucht om zijn barokheid en bijna niemand implementeert RFC 5321 volledig. Volgens RFC 5321 is "{#!$./so_crazy+\"\t\r\n\"++}"@com een geldig adres. Als er al sites zijn die dit accepteren implementeren ze waarschijnlijk niets intelligenters dan "staat er ergens een . en ergens een @ in".

Er is zelfs iets voor te zeggen om RFC 5321 expres niet volledig te implementeren: het is waarschijnlijker dat mensen met bizarre input op de proppen komen om de beveiliging te testen (SQL injection etc.) dan dat het gaat om geldige adressen.

[boelensman1]

Hiermee ben ik het volledig oneens. Een goede bescherming tegen sql injection is niet het weigeren van volledig juiste e-mail adressen en het negeren van de standaarden.

Als je dit wel doet, betekend dit dus ook dat je het e-mail adres verder rechtstreeks de database ingooit, wat je sowieso nooit moet doen. En als je dit niet doet, en wel alles netjes via prepared statements of een dergelijke beveiliging doet, dan is er geen reden om niet gewoon de standaarden te respecteren.

Gebruik bijvoorbeeld iets als isemail wat werkt voor C#, php en java. Ongetwijfeld zijn er dergelijke dingen ook te vinden voor C++, python en alle andere talen.

De standaarden negeren wegens gemak of " veiligheid" is dus gewoon onzin. Zo'n standaard functie is minstens even makkelijk en het kleine beetje schijnveiligheid wat je opoffert lijkt het me ook niet waard.

[MneoreJ]

Agree to disagree, denk ik. Ik heb liever dat kleine beetje schijnveiligheid omdat ik weet dat we nu eenmaal niet in een wereld leven gevuld met programmeurs die überhaupt het bestaan van RFC 5321 kennen, of ooit zouden overwegen om op iets als isemail te zoeken. Je weet dat ze bestaan, je weet dat ze sites bouwen, en we kunnen wel doen alsof maar dat helpt niet.

Dan heb ik veel liever een domme check die een subset van RFC 5321 afdekt maar verder niet voor problemen kan zorgen dan dat ik me op de borst klop omdat ik alle adressen in RFC 5321 toesta maar Piet van de afdeling verderop slaagt erin om daar een exploit mee te maken omdat hij HTML niet fatsoenlijk kan escapen ("<script>alert('hi')</script>"@com is eveneens een geldig adres, bijvoorbeeld).

Uiteraard suggereer ik niet dat input strippen een methode is waaraan je de voorkeur moet geven om exploits te voorkomen. Het is wel één dingetje dat kan helpen. Dat een gebruiker dan geen + in zijn adres mag hebben is iets dat ik dan een acceptabel offer acht. Ongetwijfeld kan die gebruiker een andere mening toegedaan zijn, maar die gebruiker zal dan ook niet tante Jo op de hoek zijn maar mr. Tweaker. Sorry, mr. Tweaker. It's not personal.

[Verwijderd]

En dan nog? Als iemand het adres "{#!$./so_crazy+\"\t\r\n\"++}"@com heeft, laat hem of haar lekker!

Er is maar één manier om e-mail adressen te valideren, en dat is om er simpelweg een e-mail naar toe te sturen met een link ter verificatie. Wordt die niet gevalideerd, dan is het adres niet geldig, simpel.

Voor de rest geen domme beperkingen opleggen aan gebruikers. Zó veel sites waar je niet eens "[e-mail]" kan doen, omdat een + dan ongeldig zou zijn. Wat een onzin!

[Verwijderd]

Zó veel sites waar je niet eens "[e-mail]" kan doen, omdat een + dan ongeldig zou zijn. Wat een onzin!

het is nochtans niet mogelijk om een gmail adres te hebben met een +
erin: google aanvaardt enkel letters nummers en punten

[Ghost Dog]

Bij het aanmaken van een Google-account wel, maar een adres als [e-mail] is juist te gebruiken door [e-mail], waarbij +random voor elke website die om een e-mailadres vraagt anders kan zijn. Zo kan je altijd zien welke site jou spamt, en is het gemakkelijker om e-mail automatisch te filteren.
Je kan dus bijvoorbeeld een [e-mail] opgeven bij eBay, en [e-mail] voor willekeurige sites.

[boelensman1]

Dat klopt. Maar als je opgeeft dat je e-mail adres [e-mail] is, dan komt de mail nog steeds binnen op [e-mail]. Als ontvanger staat er echter wel [e-mail], waardoor je bijvoorbeeld kan zien wie je e-mail adres verkocht heeft, of regels kan aanmaken in je mail client in de trant van "als ontvanger is [e-mail] dan moet mail in werk map" .

[denbatte]

Dat klopt. Maar als je opgeeft dat je e-mail adres [e-mail] is, dan komt de mail nog steeds binnen op [e-mail]. Als ontvanger staat er echter wel [e-mail], waardoor je bijvoorbeeld kan zien wie je e-mail adres verkocht heeft, of regels kan aanmaken in je mail client in de trant van "als ontvanger is [e-mail] dan moet mail in werk map" .

Dit wist ik zelfs niet, bedankt! --> toegepast

[Verwijderd]

Daarnaast zou een extensie loos domein ook problemen geven bij validaties op url's en email adressen. Want niet alleen kan http://search worden gebruik voor redirects, het is ook een mail domain waardoor info@search een geldig email adres zou zijn..

Ik zie niet in waarom de validatie problemen zou geven, er zijn gewoon andere regels waartegen gevalideerd moet worden

Ik ben al geen voorstander van een onbeperkt aantal generic tld's omdat het alleen maar zorgt voor fragmentatie van het internet.

ik zie niet in hoe het internet meer gefragmenteerd wordt als er meer tld's zijn. Het is niet zo dat een tld een indicatie geeft over het soort site.

Je moet maar eens kijken hoeveel van je website bezoekers op je website komen, door op de bedrijfsnaam te zoeken bij een search engine. Straks is het bijna onmogelijk om te weten op welke (g)tld een website zit.

dat is toch nu ook al?
zowat alle tld's van mijn bedrijfsnaam zijn al ingenomen. Ik heb noodgedwongen een tld moeten nemen met mijn bedrijfsnaam en nog een woord erachter.

Stel Google start een reclame campagne op http://bing.search/engine, kan Microsoft dan een klacht indienen bij het Icann wegens inbreuk op een trademark en wat voor acties onderneemt het Icann vervolgens? Heeft Microsoft dan pech of kan het Icann Google een boete opleggen of het (g)tld ontnemen?

het icann is geen rechtsinstantie, het is de taak van een rechter om te beslissen of er inbreuk wordt gemaakt of niet

[--Andre--]

Volgens mij had tk dit toch al een tijdje. Nu werkt http://tk niet meer dit heeft volgens mij in het verleden wel gewerkt.

$ host tk
tk has address 217.119.57.22

tk revolved wel maar er draait geen webserver op het desbetreffende adres. Dus, tk is in principe geconfigureerd als dotless domein, enkel zonder actieve webserver.

[Tribits]

Dat klopt min of meer wel. Een TLD verschilt op zich niet fundamenteel van andere DNS records en het is op zich dus ook gewoon mogelijk om er een A record en daarmee een host/IP adres aan te koppelen. Er zijn enkele TLDs die op dit moment nog een webserver hebben draaien zoals:

[url=http://ac/]http://ac/[/url] [url=http://ac./]http://ac./[/url]
[url=http://io/]http://io/[/url] [url=http://io./]http://io./[/url]
[url=http://tm/]http://tm/[/url] [url=http://tm./]http://tm./[/url]

Tot zover het 'goede' nieuws. Het slecht nieuws is dat het allesbehalve zeker is dat je ook daadwerkelijk op de server uitkomt die aan het TLD gekoppeld is als je een TLD op deze manier gebruikt. Omdat een reeks tekens zonder punt geen FQDN is zal de resolver er zelf een FQDN van moeten maken. Dat gebeurt doorgaans door het default domain er aan vast te plakken waarmee je in het geval van io dus uitkomt op 'io.mydomain.tld.' en niet op 'io.' zoals je zou verwachten. Bij het ontbreken van een default domain of bij gebruik van een resolver die er een punt achter plakt kom je wel goed uit maar het probleem is dat je dus afhankelijk bent van de lokale situatie/configuratie voor de juiste werking. Als je dat probleem de wereld uit wilt helpen zal je dus ieder stuk software dat name resolution uitvoert aan moeten passen (browsers, applicaties, besturingssystemen etc.)

De beslissing waar dit artikel over bericht is gemaakt op basis van een eerder onderzoek waarbij de huidige situatie en de gevolgen voor het accepteren van dotless domains onderzocht werden. (zie: http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf). Daarin waren ze eigenlijk al tot de conclusie gekomen dat het geen haalbare kaart is. Icann raadt het gebruik van TLDs op deze manier dan ook af en verbiedt het waar mogelijk.

edit: URLs naar TLDs aangepast, tweede is nu de FQDN versie, dus met puntje.

[Reactie gewijzigd door Tribits op 26 juli 2024 10:24]

[Eloy]

En tercht. Dit zou erg verwarrend worden met de namen van lokale devices.

Door ergens bij een wifi hotspot aan te melden en je eigen apparaat 'search' te noemen, kan je alle query's afluisteren die via dat netwerk worden verzonden.

[Reactie gewijzigd door Eloy op 26 juli 2024 10:24]

[Verwijderd]

Volgens mij kan je indien je toegang hebt, dat geintje ook wel met een sniffer, tenzij via https wordt gezocht. Of mis ik iets?

[Eloy]

Klopt inderdaad. Maar je kan nu ook mensen een compleet andere webpagina serveren

http://search/?q=mijn.ing.nl > phis.ing.ru

[Rex]

Dat kan ook uberhaupt met een man-in-the-middle attack (ARP poisoning). Daar hoef je de naam van je apparaat niet voor te veranderen naar 'search'.
Verwarrend met lokale devices zie ik niet snel gebeuren, alhoewel ik ook niet zag gebeuren dat veel namen geregistreerd zouden worden, maar toch zijn er al zo'n 1930 aanvragen in behandeling.

[Loller1]

Verwarring niet snel gebeuren? Je browser zoekt normaal gezien eerst lokaal om dan pas online te gaan. Mocht iemand bijvoorbeeld het gTLD .localhost hebben gekocht, dan krijg je wat rommel

[dasiro]

daarom dat aanvragen eerst worden onderzocht voordat ze worden goedgekeurd en in dit geval heeft google dus pech dat hun spelletje niet op gaat

[Verwijderd]

dat is ook weer waar

[Verwijderd]

Door aan dit domein een query-structuur te koppelen, moest een eindgebruiker eenvoudig vanuit de adresbalk van zijn browser kunnen zoeken.

Ik search al jaren via de adresbalk...

[Tok Tok]

Ik idd ook, lijkt mij in die zin niks nieuws...

[Verwijderd]

Ja, maar dat komt zeker omdat je Chrome hebt en daardoor automatisch de search gebruikt van Google.

[aadje93]

Je hoeft niet perse chrome te hebben om dat te kunnen. Als je het invoert komt safari (naar mijn weten) ook gewoon op je "default search engine" uit om het op te zoeken.

Firefox heeft volgens mij eenzelfde systeem.

[Blokker_1999]

En zelfs IE doet het, daar is de aparte zoekbalk naast de adresbalk ondertussen ook verdwenen.

[Loller1]

Sterker nog, als je gewoon een zoekopdracht in de URL balk van IE6 typte, werd je ook gewoon doorgestuurd naar het resultaat dat je zoekmachine zou geven.

[Huismus]

Daar moest je geloof ik wel Google Toolbar voor hebben.

[nlvmark]

Nee hoor, je kon alleen niet instellen welke zoekmachine dus je kwam altijd bij msn/bing uit.

[badboyqxy]

bij ie moet je zoek opdrachten starten met ? en dan de opdracht

[jayjay1990]

Niet helemaal waar. Zolang je zoekopdracht een spatie bevat wordt het eigenlijk altijd als zodanig uitgevoerd. Is volgens mij al zo sinds IE8.

[madcow22]

Jep alleen voor searches met . erin moet je vaak ? gebruiken.

[MrQuincle]

OT: ja, ik had in Firefox ook altijd ?? als "keyword" ingesteld voor scholar.google.com, maar in Google Chrome kan dat helaas niet.

[Proxy]

Bij Opera werkt het ook

[Eloy]

Ik heb 't ook in Firefox hoor. (Alleen dan wel DuckDuckGo en geen. Google )

Maar ik betwijfel of zo'n http://search zin heeft, volgensmij hebben de meeste browsers nu wel een zoek mogelijkheid via de adresbalk, en als je dan iets extentieloos invult dan gaat 'ie zoeken op 'search'

Maar het is voor browsermakers makkelijker om gewoon zoeken in de adresbalk te implementeren dan een extentieloos domein, wat nogal raar is. (Want het lijkt me wel dat browsers een soort van 'syntax check' doen: iets punt paar letters)

[ep667]

Want het lijkt me wel dat browsers een soort van 'syntax check' doen: iets punt paar letters

Ik heb nog geen browser gezien die dat doet. Wel browsers die automatisch aanvullen als je iets intikt wat niet af lijkt en dat vervolgens ook niet bereikbaar is.

Is ook logisch dat dit niet zo werkt. Dan zou je bijvoorbeeld geen websites meer op basis van IP-adres kunnen bezoeken. In een lokale netwerkomgeving, waar in zeer veel gevallen lang niet altijd alles een FQDN heeft, zou het ook niet meer werken. Ik ken genoeg bedrijven waar lokale systemen te bereiken zijn via, ik noem maar wat, http://app29/topdesk/. Dat zou dan ook niet kunnen.

In de browser hoeft er dus niets veranderd te worden. Daar niet.

[Reflian]

Maarja, als jij in je browser slechts app29 intypt, gaat ie echt niet naar http://app29/ maar zoeken naar app29, type je daarentegen app29.com gaat hij wel naar http://app29.com, dat is volgens mij wat ik.ben.iemand. bedoelde.


Ik vind het ook nog steeds maar een raar voorstel, het klinkt natuurlijk wel spannend die nieuwe toplevel domains maar inderdaad zie ik niet helemaal de toegevoegde waarde voor een .search
Andere TLDs kunnen wel leuk zijn, zoals .blog, lekker makkelijk en duidelijk, maar de vraag wordt dan natuurlijk wie dat uitbaat en welke diensten daar dan onder terecht mogen komen.

[RubenTheys]

Om het rijtje hierboven te vervolledigen; Safari op OSX heeft het ook

[Verwijderd]

En in Safari in iOS7 zit het ook.

[knirfie244]

Elke browser kan dit ondertussen. Van Opera kan ik me niet eens herinneren wanneer deze functionaliteit geïntroduceerd is, het was in ieder geval lang voordat Chrome bestond. Dus het zit er al minimaal een jaartje of 6/7 in...

[Reactie gewijzigd door knirfie244 op 26 juli 2024 10:24]

[mae-t.net]

Opera en Firefox kennen dat systeem ook. Bovendien kan je zowel in Opera als in IE een aparte zoekbalk naast je adresbalk plaatsen en volledig customiseren welke zoekmachine(s) je daarin wilt gebruiken.

[Twazerty]

Dat werkt ook vanuit Firefox en Internet Explorer hoor.

[Caelorum]

vanuit ie9 is er wel een plugin voor nodig om de juste search engine te gebruiken [...]

Juiste? Daarnaast zoekt IE9 prima het web zonder plug-in.

[Blokker_1999]

nee ok, maar of je nu naar google.com gaat of je moet via http://search parametrering alsnog je search engine aangeven, wat is dan nog het verschil? Stel ik wil gebruik maken van bijvoorbeeld Yahoo dan zou ik al naar http://search/e=Yahoo moeten gaan om yahoo te verkrijgen bijvoorbeeld, is dat vooruitgang? Help je daar iemand mee?

[CAPSLOCK2000]

Ik heb een beetje dubbele gevoelens bij dit nieuws, maar met al die nieuwe TLDs is dit wel een erg practische keuze. Ik vrees alleen dat het niet gaat helpen. ICANN kan dit wel zeggen, maar het zijn de browsers en DNS-servers die het moeten gaan afdwingen. Als Google (of Microsoft, of Firefox) toch FQDNs zonder punt willen kunnen ze dat gewoon doen, ze hebben controle over de hele stack.
Ik hoop dat de techneuten hun poot stijf houden en de afspraken volgen, maar ik vrees dat er wel een paar directeuren zijn die hun plannetje toch doordrukken.

[stamp]

Ik zat ook al, wat let google om deze functionaliteit toe te voegen aan hun dns servers.

Kan ICANN je boetes geven of ze verder iets maken

volgens mij heeft opendns ook een search redirect ingebouwd zitten

[yannickzz]

Leek me eerlijk gezegd ook vrij nutteloos, omdat de meest gebruikte browsers zowat allemaal de mogeiljkheid hebben om gewoon in je adresbalk te zoeken.

PS: 'Toplevenldomain

[Verwijderd]

"...eenvoudig vanuit de adresbalk van zijn browser kunnen zoeken". Alsof de modale gebruiker nog weet wat een adresbalk is. Mensen starten gewoon "het internet" op door op het blauwe icoontje te klikken en typen alles in het zoekveld van Google, zelfs urls. Dat ze in een browser bezig zijn, dat die browser een adresbalk heeft en dat "de google" alleen maar een startpagina is ontgaat ze meestal volledig. Met zo'n dotless search-domein erbij zou het voor de modale gebruiker al helemaal te moeilijk worden omdat ze dan verplicht zouden zijn het verschil te leren kennen tussen de adresbalk en het zoekveld van Google.

[We Are Borg]

Kan iedereen dan straks een .app of .cloud domein registreren of alleen de aanvrager

[verzenden]

Als Google .app of .cloud krijgt toegewezen als TLD kan je bij Google wellicht een domein kopen zoals: mijnbedrijf.app

Zodra Google .app beter gaat positioneren in de search index gaat menig bedrijf massaal over op een mijnbedrijf.app domein om maar beter in de resultaten naar voren te komen.

Al met al ben ik tegen deze generieke TLD's. Dacht ook dat de inzet van ICANN was om enkel merknamen toe te staan. mijnbedrijf.google is prima toch?

Ik hoop dat ICANN zijn poot stijf houd en alle generieke TLD's afwijst.

[_Thanatos_]

Je moest eens weten hoeveel mensen "w w w punt g o o g l e punt n l" intypen voordat ze gaan zoeken. en na het typen van de zoekterm natuurlijk de handen van het toetsenbord af, en dan met de muis naar de zoekknop

Maar ipv http://search lijkt het me beter om die mensen op te voeden in hoe je een browser wat efficienter kunt gebruiken. Want alle browsers kunnen zoeken via de adresbalk,en bij alle browsers is de zoekmachine daarachter instelbaar.

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 10:24]

[Laloeka]

Opvoeden kan ook zonder search TLD. Daarnaast is het eerder zaak aan het browser om de input in de adresbalk/awesomebar goed te interpreteren. Als ik typ "Zoek nieuwe auto" dan moet mijn browser snappen dat ik naar mijn favoriete zoekmachine wil en wil zoeken naar "nieuwe auto". Niet naar http://Zoek nieuwe auto.com/ om er vervolgens achter te komen dat dat niet bestaat en me door te verwijzen naar de zoekmachine met de zoekopdracht "http://Zoek nieuwe auto.com/' ". *IE6*

Gebruiksvriendelijkheid brengt één groot nadeel met zich mee: mensen worden naïef. Ze denken niet meer na bij wat er achter de schermen gebeurt, en als er dan iets geks gebeurt 'werkt het niet meer' of 'snappen ze het niet'.

[Reactie gewijzigd door Laloeka op 26 juli 2024 10:24]

[_Thanatos_]

Alle browsers snappen dat een spatie in de adresbalk sowieso naar de zoekmachine gaat. IE6 bestaat al heel lang niet meer. IE7 eigenlijk ook al niet meer. Windows XP is intussen 11 jaar oud, en de nieuwste IE die daarop draait is IE8. Er is dus geen enkele reden meer om IE6 of IE7 te draaien, tenzij je willens en wetens een oud barrel hebt met Windows 2000 of nog ouder.

[Woutske]

Ik vind die nieuwe aanvragen echt totaal onnodig en een slechte manier om extra geld te vangen. Straks zijn er zo veel tld's dat er helemaal geen waarde meer aan zit. Erger is nog dat de meeste bedrijven nieteens meer logisch denken en het enkel voor prestige lijken te doen..

Voorbeeld:
iphone.apple.nl -> iphone.apple/nl
digid.overheid.nl -> digid.overheidnl

Totaal overbodig dus..

(Denk ook aan al die wildcard-certificaten die je nu moet kopen )