Ostatecznie, za styczeń 2009 roku poziom przedłużeń domen .pl wygasających w minionym miesiącu ukształtował się na poziomie 53,7%. Wartość ta pokazuje tylko styczeń, a nie poziom odnowień rok do roku, jak to zwykle podajemy.
Ta informacja powinna natomiast zaspokoić potrzeby informacyjne wielu osób, chociaż dla analityków rynku wartość cząstkowa odnowień nie ma zupełnie sensu i nie da się na jej podstawie dokonywać jakichkolwiek prognoz.
Dodam jeszcze, że wartość ta nie uwzględnia „odnowień” przez opcje.
Monday, 16 February 2009
Tuesday, 10 February 2009
DNSSEC: Komisja Europejska bardziej rozsądna niż rząd USA
Kilka dni temu odbyło się w Brukseli spotkanie przedstawicieli Komisji Europejskiej, rzadów i zaproszonych ekspertów. Spotkanie to poświęcone było rozwiązaniom DNSSEC, a więc „bezpiecznej” wersji protokołu DNS. Osoby zainteresowane tym, co to jest DNSSEC, odsyłam do bogatych źródeł w Internecie. Wystarczy wpisać w Google frazę „DNSSEC”.
Ale wracając do spotkania w Brukseli, w przeciwieństwie do ICANN-u i przedstawicieli (byłej) administracji amerykańskiej (byłej, bo co do obecnej to nikt nie wie, jakie ma stanowisko w tym zakresie), Komisja Europejska chce faktycznie temat poznać, i dopiero mając odpowiednią wiedzę, zająć stanowisko.
Bardzo rozsądne podejście. Spotkanie miało na celu właśnie edukację i poznanie poglądów zarówno zwolenników, jak i przeciwników DNSSEC. Zaproszeni przez KE eksperci to przedstawiciele rejestrów UK, CZ, SE, AT, DE oraz moja skromna osoba z PL. Na spotkaniu byli też przedstawiciele ICANN-u oraz firm zajmujących się bezpieczeństwem DNS, m.in. CommunityDNS oraz Autonomica.
Spotkanie nie zakończyło się konkretnymi wnioskami – to zadanie samej Komisji, aby podjąć własną decyzję w tej sprawie i wziąć za to odpowiedzialność. Jednak główne argumenty, które na spotkaniu padły, a które na chwilę obecną nie pozwalają na wdrożenie DNSSEC w praktyce, to:
* NSEC3 (implementacja DNSSEC) jest produktem świeżym, nie został wystarczająco przetestowany; w rezultacie nie może zostać zastosowany tam, gdzie jest wymagana niezawodność np. w domenach narodowych.
* Brak ustandaryzowanej w IETF procedury zarządzania kluczami i podpisywania plików stref na poziomie root – obecnie próbuje się na siłę znaleźć rozwiązanie tego problemu w postaci bazy Trust Anchor Repository oraz koncepcji kluczy współdzielonych pomiędzy różne instytucje itd.Warto dodać, że proces standaryzacji DNSSEC trwał 15 lat, a mimo to procesy obsługi kluczy na poziomie root nie zostały zdefiniowane – amatorstwo jakich mało.
* Jeśli baza centralna (Trust Anchory Repository) będzie w pewnym momencie nieosiągalna, to użytkownicy Internetu otrzymaja dla domen podpisanych cyfrowo komunikat, że dane domeny są nieprawidłowe i strona nie może zostać załadowana mimo tego, że sama domena i DNS będą funkcjonowały bez zarzutu.
* Brakuje określonych (wystandaryzowanych) sposobów zachowania aplikacji w sytuacji kiedy: nie można dokonać weryfikacji podpisu bądź weryfikacja zakończyła się negatywnie.
* Na chwilę obecną DNSSEC nie zapewnia bezpiecznej drogi pomiędzy drzewem DNS a użytkownikiem końcowym – nadal brakuje np. systemów operacyjnych wspierających DNSSEC; Windows 7 będzie wspierał DNSSEC, ale tylko w wersji Server, o desktopach na razie nikt nie myśli, bo i tak nie ma na to klientów.
* DNSSEC to niestety porażka biznesowa w krajach, które zdecydowały się wdrożyć tą technologię – pytanie czy w Polsce ktoś odważyłby się wydać pieniądze na coś co zadowoli kilkustet użytkowników? Może największe firmy jak Home czy NetArt, ale i tak w to wątpię.
* Skomplikowany proces generowania kluczy i obsługi podpisywania stref spowoduje, że zamiast użytkownika (abonenta domeny) będzie to realizowane przez Registrara (Partnera). Opisane podejście mija się z celem, bo poziom zaufania do takich domen automatycznie maleje.
* Konkurencja w postaci SSL dobija DNSSEC. SSL pozwala nie tylko zabezpieczyć stronę, ale również poprzez np. extended validation, zapewnić wysoki poziom autentykacji kto jest właścicielem serwisu. Niestety DNSSEC nigdy nie zapewni autentykacji. Przykładowo jeśli ktoś nieuprawniony zarejestruje powiedzmy citibank.XX to na podstawie certyfikatów SSL będzie można sprawdzić czy taka strona faktycznie należy do Citibank. Ale w przypadku DNSSEC otrzymamy niestety np. odpowiedź potwierdzającą, że dane skojarzone z domeną należą do firmy która domenę zarejestrowała – ale czy to jest Citibank czy nie, tego się nie dowiemy, a nieświadomy użytkownik uzna, że strona jest autentyczna i... phishing gotowy.
Ale wracając do spotkania w Brukseli, w przeciwieństwie do ICANN-u i przedstawicieli (byłej) administracji amerykańskiej (byłej, bo co do obecnej to nikt nie wie, jakie ma stanowisko w tym zakresie), Komisja Europejska chce faktycznie temat poznać, i dopiero mając odpowiednią wiedzę, zająć stanowisko.
Bardzo rozsądne podejście. Spotkanie miało na celu właśnie edukację i poznanie poglądów zarówno zwolenników, jak i przeciwników DNSSEC. Zaproszeni przez KE eksperci to przedstawiciele rejestrów UK, CZ, SE, AT, DE oraz moja skromna osoba z PL. Na spotkaniu byli też przedstawiciele ICANN-u oraz firm zajmujących się bezpieczeństwem DNS, m.in. CommunityDNS oraz Autonomica.
Spotkanie nie zakończyło się konkretnymi wnioskami – to zadanie samej Komisji, aby podjąć własną decyzję w tej sprawie i wziąć za to odpowiedzialność. Jednak główne argumenty, które na spotkaniu padły, a które na chwilę obecną nie pozwalają na wdrożenie DNSSEC w praktyce, to:
* NSEC3 (implementacja DNSSEC) jest produktem świeżym, nie został wystarczająco przetestowany; w rezultacie nie może zostać zastosowany tam, gdzie jest wymagana niezawodność np. w domenach narodowych.
* Brak ustandaryzowanej w IETF procedury zarządzania kluczami i podpisywania plików stref na poziomie root – obecnie próbuje się na siłę znaleźć rozwiązanie tego problemu w postaci bazy Trust Anchor Repository oraz koncepcji kluczy współdzielonych pomiędzy różne instytucje itd.Warto dodać, że proces standaryzacji DNSSEC trwał 15 lat, a mimo to procesy obsługi kluczy na poziomie root nie zostały zdefiniowane – amatorstwo jakich mało.
* Jeśli baza centralna (Trust Anchory Repository) będzie w pewnym momencie nieosiągalna, to użytkownicy Internetu otrzymaja dla domen podpisanych cyfrowo komunikat, że dane domeny są nieprawidłowe i strona nie może zostać załadowana mimo tego, że sama domena i DNS będą funkcjonowały bez zarzutu.
* Brakuje określonych (wystandaryzowanych) sposobów zachowania aplikacji w sytuacji kiedy: nie można dokonać weryfikacji podpisu bądź weryfikacja zakończyła się negatywnie.
* Na chwilę obecną DNSSEC nie zapewnia bezpiecznej drogi pomiędzy drzewem DNS a użytkownikiem końcowym – nadal brakuje np. systemów operacyjnych wspierających DNSSEC; Windows 7 będzie wspierał DNSSEC, ale tylko w wersji Server, o desktopach na razie nikt nie myśli, bo i tak nie ma na to klientów.
* DNSSEC to niestety porażka biznesowa w krajach, które zdecydowały się wdrożyć tą technologię – pytanie czy w Polsce ktoś odważyłby się wydać pieniądze na coś co zadowoli kilkustet użytkowników? Może największe firmy jak Home czy NetArt, ale i tak w to wątpię.
* Skomplikowany proces generowania kluczy i obsługi podpisywania stref spowoduje, że zamiast użytkownika (abonenta domeny) będzie to realizowane przez Registrara (Partnera). Opisane podejście mija się z celem, bo poziom zaufania do takich domen automatycznie maleje.
* Konkurencja w postaci SSL dobija DNSSEC. SSL pozwala nie tylko zabezpieczyć stronę, ale również poprzez np. extended validation, zapewnić wysoki poziom autentykacji kto jest właścicielem serwisu. Niestety DNSSEC nigdy nie zapewni autentykacji. Przykładowo jeśli ktoś nieuprawniony zarejestruje powiedzmy citibank.XX to na podstawie certyfikatów SSL będzie można sprawdzić czy taka strona faktycznie należy do Citibank. Ale w przypadku DNSSEC otrzymamy niestety np. odpowiedź potwierdzającą, że dane skojarzone z domeną należą do firmy która domenę zarejestrowała – ale czy to jest Citibank czy nie, tego się nie dowiemy, a nieświadomy użytkownik uzna, że strona jest autentyczna i... phishing gotowy.
Thursday, 5 February 2009
A few arguments why DNSSEC is a very bad idea.
A short list of arguments why DNSSEC shouldn't be implemented in DNS.
1. NSEC3 hasn't been tested enough, it's fresh product from 2008. It requires more real life tests of the software supporting NSEC3 before we say, it can go to production.
2. There is no standardized procedure for key management at root level and signing the root. Explanations from IETF why root signing is not standardized are not satisfactory. Signing the root is technical solution, not political, and that's why should be subject to the RFC process but it isn't and it's not going to be in the future at all.
It's like having all standards for the plane manufacturing but there are no standards for engines... Or having standards for a car manufacturing... except air bags.
3. Trust Anchor Repository is just fixing a problem in not the proper way - can you imagine that standardization process took 15+ years, but everybody "forgot" to think about the root?
4. If the central repository (Trust Anchor Repository) is not accessible, than validation cannot be executed, even if the signed zone is signed properly. Results: you can't use the Web for signed domains.
5. DNSSEC doesn't secure all the way from DNS to end-user- no Operating Systems support DNSSEC as of now (Jan.2009)
6. No interest from the end-users.
7. Business failure in the countries that implemented it.
8. Complicated process of signing and key management which will lead into the situation where Registrar or Name Server operator is managing all the signing process for end-user - this is a big break in the security. You can't hire somebody to sign documents for you with your personal signature.
9. In case of European Commission, EC must be technically neutral - supporting DNSSEC breaks this rule.
and many more to go...
1. NSEC3 hasn't been tested enough, it's fresh product from 2008. It requires more real life tests of the software supporting NSEC3 before we say, it can go to production.
2. There is no standardized procedure for key management at root level and signing the root. Explanations from IETF why root signing is not standardized are not satisfactory. Signing the root is technical solution, not political, and that's why should be subject to the RFC process but it isn't and it's not going to be in the future at all.
It's like having all standards for the plane manufacturing but there are no standards for engines... Or having standards for a car manufacturing... except air bags.
3. Trust Anchor Repository is just fixing a problem in not the proper way - can you imagine that standardization process took 15+ years, but everybody "forgot" to think about the root?
4. If the central repository (Trust Anchor Repository) is not accessible, than validation cannot be executed, even if the signed zone is signed properly. Results: you can't use the Web for signed domains.
5. DNSSEC doesn't secure all the way from DNS to end-user- no Operating Systems support DNSSEC as of now (Jan.2009)
6. No interest from the end-users.
7. Business failure in the countries that implemented it.
8. Complicated process of signing and key management which will lead into the situation where Registrar or Name Server operator is managing all the signing process for end-user - this is a big break in the security. You can't hire somebody to sign documents for you with your personal signature.
9. In case of European Commission, EC must be technically neutral - supporting DNSSEC breaks this rule.
and many more to go...
Wednesday, 4 February 2009
Chcesz zadzwonić do premiera? Wybierz premier.tel
Chcesz zadzwonić do premiera – wybierasz premier.tel. Chcesz zadzwonić do Obamy – wybierasz obama.tel. To nie mrzonka. Taki ma być właśnie .tel – uniwersalny identyfikator, dzięki któremu można umieścić dane swojej firmy w Internecie, a później dzwonić bezpośrednio z telefonu na adres domenowy.
Dotychczas były różne próby stworzenia uniwersalnego ID, którym można posługiwać się jednocześnie w Internecie i tradycyjnej telefonii. Nadal klasyczny numer telefonu był niezastąpiony ze względu na kilka cech, które go wyróżniają:
* jest unikatowy, nie ma dwóch takich samych numerów,
* urządzenia komunikacyjne potrafią go obsłużyć (a więc zarówno telefony, jak i różnego rodzaju komunikatory, np. Skype),
* jest porządek – nad całością czuwa jedna organizacja i to czuwa od ponad 100 lat, bez żadnych wpadek (czego nie można powiedzieć o ICANN).
Numer ma też fantastyczną cechę: nikt nie „podrejestrowuje” sobie numerów telefonów, żeby je później odsprzedawać – kwestia ochrony znaków towarowych nie istnieje bowiem w zakresie numeracji telefonicznej.
Prekursor – ENUM
Była próba bezpośredniego przeniesienia numerów telefonu do Internetu – jako projekt ENUM. Niestety, rynek generalnie odrzucił to rozwiązanie w roku 2008 i pozostaje pytanie, czy pojawi się usługa lub produkt reaktywujący ENUM (ale już w skali masowej), jest wciąż otwarte.
Teraz widzimy kolejne podejście – tym razem w postaci wprowadzenia domeny .tel. Ma ona być uniwersalną nazwą, dzięki której każdy może odnaleźć kontakt do drugiej osoby czy firmy, posługując się tylko nazwą domenową. Z punktu widzenia technicznego .tel to ENUM, tylko zamiast numeru telefonu jako identyfikatora mamy „klasyczną domenę”. Dalej, tak jak w przypadku ENUM, bezpośrednio pod nazwą nie kryje się serwis, ale zbiór kontaktów i adresów.
Zalety .tel
Znając nazwę domenową firmy, możemy bezpośrednio do takiej firmy zadzwonić, wysłać fax, e-mail czy otworzyć ich stronę WWW. Nie trzeba mozolnie odnajdywać kontaktu telefonicznego (tudzież kontaktu via Skype) na stronie – wystarczy automatycznie pobrać to, co jest skojarzone z domeną.
Wady .tel
Jedną z wad domen .tel jest znowu kwestia ochrony znaków towarowych i innych praw. Nadal będzie ktoś chciał zarejestrować znaki towarowe jako domeny i później je odsprzedawać. Nadal nie będzie pewności, czy domena przykładowo coca-cola.tel należy do Coca-Cola Company czy nie, a jak nie, to do kogo itd.
Drugą wadą .tel w porówaniu z ENUM jest brak kompatybilności w dwie strony. Z numeru telefonu można korzystać bezposrednio w telefonii, jak również w Internecie (większość komunikatorów to potrafi). Ale z domeny już nie można korzystać w telefonii, bo nie ma jak wstukać nazwy domenowej na klasycznym telefonie.
Porażka na starcie? Raczej nie
Pytanie więc, czy skoro ENUM okazał się ostatecznie porażką na rynku end-userów (bo na rynku B2B w VoIP ma nadal dużą szansę), to czy .tel przetrwa? A raczej czy się rozwinie, bo przetrwać to nie będzie problemu – z samych „defensive registrations” zarobią na utrzymanie rejestru i opłaty dla ICANN.
W Polsce na razie tylko AZ.pl ma umowę z Telnic, chociaż samo AZ.pl nie oferuje możliwości rejestracji domen .tel dla swoich klientów. Po co więc akredytacja, skoro nie sprzedaje się takiej usługi?
Wsparcie w komórkach
Domena .tel ma natomiast dużą szansę zaistnieć w świecie, jeśli któryś z producentów oprogramowania dla komórek zdecyduje się wprowadzić to usprawnienie. Czyli w prosty sposób – bez konieczności pobierania dodatkowej aplikacji – pod jednym przyciskiem umożliwi wprowadzanie nazwy domeny z rozszerzeniem .tel i pozwoli bezpośrednio inicjować połączenie. Jeśli tego nie będzie – na duży sukces szans nie ma.
„Landrush” kontra „Go Live”
Obecnie jesteśmy w fazie Landrush dla domen .tel, czyli każdy może zarejestrować taką domenę między 3 lutego a 23 marca 2009, oczywiście, za wyższą cenę (około 350 USD za trzy lata wraz z opłatami dodatkowymi). Do 24 marca 2009 też każdy, ale za cenę niższą. Takie usprawnienie ;).
Domena .tel w Polsce
Z przedstawicielem Telnic, Jimem Reidem, Szkotem z krwi, kości i zamiłowania do single malt whiskey, można będzie się spotkać w Warszawie, 16 kwietnia na konferencji Future Business Trends. Polecam szczególnie tym, którzy planuja w jakiś sposób zarabiać na .tel – czyli potencjalnych partnerów biznesowych Telnica.
Dotychczas były różne próby stworzenia uniwersalnego ID, którym można posługiwać się jednocześnie w Internecie i tradycyjnej telefonii. Nadal klasyczny numer telefonu był niezastąpiony ze względu na kilka cech, które go wyróżniają:
* jest unikatowy, nie ma dwóch takich samych numerów,
* urządzenia komunikacyjne potrafią go obsłużyć (a więc zarówno telefony, jak i różnego rodzaju komunikatory, np. Skype),
* jest porządek – nad całością czuwa jedna organizacja i to czuwa od ponad 100 lat, bez żadnych wpadek (czego nie można powiedzieć o ICANN).
Numer ma też fantastyczną cechę: nikt nie „podrejestrowuje” sobie numerów telefonów, żeby je później odsprzedawać – kwestia ochrony znaków towarowych nie istnieje bowiem w zakresie numeracji telefonicznej.
Prekursor – ENUM
Była próba bezpośredniego przeniesienia numerów telefonu do Internetu – jako projekt ENUM. Niestety, rynek generalnie odrzucił to rozwiązanie w roku 2008 i pozostaje pytanie, czy pojawi się usługa lub produkt reaktywujący ENUM (ale już w skali masowej), jest wciąż otwarte.
Teraz widzimy kolejne podejście – tym razem w postaci wprowadzenia domeny .tel. Ma ona być uniwersalną nazwą, dzięki której każdy może odnaleźć kontakt do drugiej osoby czy firmy, posługując się tylko nazwą domenową. Z punktu widzenia technicznego .tel to ENUM, tylko zamiast numeru telefonu jako identyfikatora mamy „klasyczną domenę”. Dalej, tak jak w przypadku ENUM, bezpośrednio pod nazwą nie kryje się serwis, ale zbiór kontaktów i adresów.
Zalety .tel
Znając nazwę domenową firmy, możemy bezpośrednio do takiej firmy zadzwonić, wysłać fax, e-mail czy otworzyć ich stronę WWW. Nie trzeba mozolnie odnajdywać kontaktu telefonicznego (tudzież kontaktu via Skype) na stronie – wystarczy automatycznie pobrać to, co jest skojarzone z domeną.
Wady .tel
Jedną z wad domen .tel jest znowu kwestia ochrony znaków towarowych i innych praw. Nadal będzie ktoś chciał zarejestrować znaki towarowe jako domeny i później je odsprzedawać. Nadal nie będzie pewności, czy domena przykładowo coca-cola.tel należy do Coca-Cola Company czy nie, a jak nie, to do kogo itd.
Drugą wadą .tel w porówaniu z ENUM jest brak kompatybilności w dwie strony. Z numeru telefonu można korzystać bezposrednio w telefonii, jak również w Internecie (większość komunikatorów to potrafi). Ale z domeny już nie można korzystać w telefonii, bo nie ma jak wstukać nazwy domenowej na klasycznym telefonie.
Porażka na starcie? Raczej nie
Pytanie więc, czy skoro ENUM okazał się ostatecznie porażką na rynku end-userów (bo na rynku B2B w VoIP ma nadal dużą szansę), to czy .tel przetrwa? A raczej czy się rozwinie, bo przetrwać to nie będzie problemu – z samych „defensive registrations” zarobią na utrzymanie rejestru i opłaty dla ICANN.
W Polsce na razie tylko AZ.pl ma umowę z Telnic, chociaż samo AZ.pl nie oferuje możliwości rejestracji domen .tel dla swoich klientów. Po co więc akredytacja, skoro nie sprzedaje się takiej usługi?
Wsparcie w komórkach
Domena .tel ma natomiast dużą szansę zaistnieć w świecie, jeśli któryś z producentów oprogramowania dla komórek zdecyduje się wprowadzić to usprawnienie. Czyli w prosty sposób – bez konieczności pobierania dodatkowej aplikacji – pod jednym przyciskiem umożliwi wprowadzanie nazwy domeny z rozszerzeniem .tel i pozwoli bezpośrednio inicjować połączenie. Jeśli tego nie będzie – na duży sukces szans nie ma.
„Landrush” kontra „Go Live”
Obecnie jesteśmy w fazie Landrush dla domen .tel, czyli każdy może zarejestrować taką domenę między 3 lutego a 23 marca 2009, oczywiście, za wyższą cenę (około 350 USD za trzy lata wraz z opłatami dodatkowymi). Do 24 marca 2009 też każdy, ale za cenę niższą. Takie usprawnienie ;).
Domena .tel w Polsce
Z przedstawicielem Telnic, Jimem Reidem, Szkotem z krwi, kości i zamiłowania do single malt whiskey, można będzie się spotkać w Warszawie, 16 kwietnia na konferencji Future Business Trends. Polecam szczególnie tym, którzy planuja w jakiś sposób zarabiać na .tel – czyli potencjalnych partnerów biznesowych Telnica.
Tuesday, 3 February 2009
Antyefekt stycznia
W domenach zamykamy styczeń 2009 z mieszanymi uczuciami, tak na słodko-kwaśno. Z jednej strony mamy spadek liczby domen w DNS o 4000 przy jednoczesnym spadku odnowień (rok do roku, za styczeń 2009) do poziomu 69,37%. Z drugiej strony odnotowaliśmy duży przyrost nowych domen – aż o 67 741.
Dla osób mających stały kontakt z rynkiem domen dane z mijającego miesiąca nie powinny być zaskoczeniem. Z jednej strony w styczniu 2008 r. mieliśmy bardzo dużo tanich rejestracji (z dopłatami od Partnerów NASK) w cenie poniżej 1 złotego, z drugiej styczeń zeszłego roku był miesiącem wyczekiwanym przez wiele osób, które wstrzymywały się z rejestracjami w związku z obniżką cen obowiązującą od 01.01.2008 r. W efekcie, po roku, wiele osób nie odnowiło części swoich domen.
To, co niepokoi, to brak znaczących obniżek cen odnowień u Partnerów NASK. Mimo że cena hurtowa odnowienia domeny .pl to 40 zł, a domeny .com.pl to 30 zł – u Partnerów ceny netto nadal są bardzo wysokie, po 90-100 złotych za domenę.
Obniżka cen w NASK nie przełożyła się, lub przełożyła się w minimalnym stopniu na ceny detaliczne – Partnerzy zatrzymali obniżkę, aby zwiększyć swoje marże. Bo jak inaczej określić sytuację, kiedy Partner dopłaca klientowi do rejestracji domeny 10 zł, a następnie pobiera za odnowienie 100 zł, czyli 60 zł marży, w sytuacji gdy bez obniżki cen w NASK, cena odnowienia była taka sama? Są jednak Partnerzy z niskimi cenami, jak np. dropped.pl, który za odnowienie domeny .pl pobiera kwotę 50 złotych brutto, co oczywiście jest bardzo pozytywnym krokiem na rynku.
Na koniec tego bloga, aktualizacja wykresu średniej liczby domen przypadających na jednego abonenta w poszczególnych rejestrach ccTLD:
Dla osób mających stały kontakt z rynkiem domen dane z mijającego miesiąca nie powinny być zaskoczeniem. Z jednej strony w styczniu 2008 r. mieliśmy bardzo dużo tanich rejestracji (z dopłatami od Partnerów NASK) w cenie poniżej 1 złotego, z drugiej styczeń zeszłego roku był miesiącem wyczekiwanym przez wiele osób, które wstrzymywały się z rejestracjami w związku z obniżką cen obowiązującą od 01.01.2008 r. W efekcie, po roku, wiele osób nie odnowiło części swoich domen.
To, co niepokoi, to brak znaczących obniżek cen odnowień u Partnerów NASK. Mimo że cena hurtowa odnowienia domeny .pl to 40 zł, a domeny .com.pl to 30 zł – u Partnerów ceny netto nadal są bardzo wysokie, po 90-100 złotych za domenę.
Obniżka cen w NASK nie przełożyła się, lub przełożyła się w minimalnym stopniu na ceny detaliczne – Partnerzy zatrzymali obniżkę, aby zwiększyć swoje marże. Bo jak inaczej określić sytuację, kiedy Partner dopłaca klientowi do rejestracji domeny 10 zł, a następnie pobiera za odnowienie 100 zł, czyli 60 zł marży, w sytuacji gdy bez obniżki cen w NASK, cena odnowienia była taka sama? Są jednak Partnerzy z niskimi cenami, jak np. dropped.pl, który za odnowienie domeny .pl pobiera kwotę 50 złotych brutto, co oczywiście jest bardzo pozytywnym krokiem na rynku.
Na koniec tego bloga, aktualizacja wykresu średniej liczby domen przypadających na jednego abonenta w poszczególnych rejestrach ccTLD:
Concentration factor in domain names worldwide
I conducted analysis on the Subscribers' concentration factor in ccTLDs. I was interested to find out the average value of domain names registered by one, single Subscriber.
In Poland we have 2.6, but it looks, some TLDs have even higer values. Generally higher value, more domains are concentrated around smaller number of subscribers.
I expected that TLDs which are popular among domainers will be high in the chart, but it was not true. For example NL is quite low, but this is domainers friendly TLD... Another example are PL and ES - I would expect that ES is placed much lower than PL, but in reality PL and ES are one the same level... Of course this subject requires more advanced statistical tools to make proper analysis, at least to find the distibuton, variation etc. but unfortunately it is almost impossible to gather very detailed data from differnet ccTLD and conduct full analysis... But now, you have to live with this chart only ;)
In Poland we have 2.6, but it looks, some TLDs have even higer values. Generally higher value, more domains are concentrated around smaller number of subscribers.
I expected that TLDs which are popular among domainers will be high in the chart, but it was not true. For example NL is quite low, but this is domainers friendly TLD... Another example are PL and ES - I would expect that ES is placed much lower than PL, but in reality PL and ES are one the same level... Of course this subject requires more advanced statistical tools to make proper analysis, at least to find the distibuton, variation etc. but unfortunately it is almost impossible to gather very detailed data from differnet ccTLD and conduct full analysis... But now, you have to live with this chart only ;)
Subscribe to:
Posts (Atom)