Ponad rok temu NASK zawarł umowę z CommunityDNS na obsłuję 20 serwerów typu ANYCAST DNS, tym samym znacznie poprawiając bezpieczeństwo naszego systemu DNS w Polsce. Od początku listopada 2008, DNS dla domen obsługiwanych przez NASK (.pl, .com.pl, .waw.pl, itd.), obsługiwany jest przez kolejne 14 serwerów w 14 różnych lokalizacjach na całym świecie.
O obsłudze DNS dla domen .PL można przeczytać m.in. na blogu pod adresem.
Teraz mamy o 14 serwerów więcej, tym razem od firmy NeuStar (jednej z największych firm dostarczających bezpieczną infrastrukturę IP i telekomunikacji dla m.in. rządu USA, operatorów telco, a także obsługującą domeny .biz). Więcej o NeuStar można przeczytać na NeuStar.biz, a konkretnie o ich usługach DNS pod adresem: ultraDNS.com.
ANYCAST polega na równomiernym rozłożeniu obciążenia DNS, dzięki temu komunikacja z serwerami DNS komputera użytkownika Internetu wpisującego w przeglądarce „webhosting.pl”, może odbyć się z serwerem np. w Niemczech czy USA w sytuacji kiedy przykładowo któryś z serwerów DNS w Polsce zostanie zaatakowany, „koparka przerwie światłowód” u któregoś z ISP bądź nasz dostawca Internetu woli wymieniać ruch z ISP w Niemczech niż z TP S.A. bo jest taniej.
To bezpieczeństwo, to przede wszystkim odporność na ataki Distributed Denial of Service.
Atak DDoS polega na „zalaniu” serwerów i łączy taką liczbą zapytań „fałszywych”, że te prawdziwe zapytania od realnych użytkowników, nie mają szansy na obsługę. Przed takimi atakami są różne możliwości obrony i prewencji, ale najbardziej skuteczna to zapewnienie takiej wydajności serwerów i pojemności łączy aby „obsłużyć” atak DDoS. To powoduje, że skuteczny atak DDoS staje się coraz bardziej kosztowny i tym samym nie opłaca się atakować dobrze zabezpieczonego DNS. I to właśnie robimy, inwestujemy w taką infrastrukturę, aby obsłużyć największe obecnie przeprowadzane na świecie ataki DDoS, tudzież takie, które mogą pojawić się w przyszłości.
Bezpieczeństwo to również dostępność Internetu w przypadku chociażby klęsk żywiołowych czy ataków terrorystycznych. Dzięki naszej infrastrukturze przy hipotetycznym ataku na infrastrukturę w Warszawie i zniszczeniu powiedzmy całego centrum Warszawy, użytkownicy Internetu których ISP wymieniają ruch również poza Warszawą nawet nie zauważy, że są jakieś kłopoty z DNS. Ba, nawet zniszczenie siedziby NASK będzie niezauważalne dla użytkowników Internetu. DNS będzie działał...
Aktualna mapa lokalizacji serwerów DNS dla .pl znajduje się pod adresem.
A na koniec tego bloga trochę postraszę. Pamiętajmy, że zabezpieczone są tylko domeny obsługiwane przez NASK, jak chociażby domeny rejestrowane bezpośrednio w .pl lub .com.pl. Ale już przykładowo domeny w domenie .gov.pl czyli nasze „rządowe” domeny, nie mają za sobą tej technologii i atak DDoS którego klienci NASK nawet nie zauważą, dla domen rządowych będzie katastrofą. Oczywiście więcej serwerów DNS w profesjonalnie obsługiwanej technologii ANYCAST wraz z bieżącym monitorowaniem i zarządzaniem routingiem, to (znacznie) większy koszt, ale nie możemy pozwolić sobie jako Polska na atak podobny jak doświadczyła Estonia czy Gruzja...
Thursday, 20 November 2008
Wednesday, 19 November 2008
Kompletny brak zainteresowania nowymi gTLD?
ICANN ogłosił 24 października otwarcie konsultacji publicznych dotyczących zasad, na których będą funkcjonowały nowe gTLD. Jak wszyscy wiemy, od kilku lat toczy się dyskusja o otwarciu ICANN na nowe TLD zarówno w wersji ze znakami narodowymi (IDN) dla poszczególnych krajów, jak również globalne TLD niezwiązane z konkretnym krajem (analogocznie jak .com, .net czy .org). ICANN był ostro krytykowany za to, że nie dopuszcza nowych TLD, że utrudnia składanie aplikacji i wreszcze, że zasady sa niejasne (a raczej nie było dotychczas żadnych zasad).
ICANN ogłosił konsultacje. W Kairze odbyła się specjalna konferencja, na której zgromadziło się ponad 1000 osób. Było wiele publikacji dotyczących kontrowersji związanych z proponowaną umową na nowe gTLD, jak chociażby materiały na tak znanych portalach jak DNjournal.com, DomainState.com, ICANNwatch.org, circleID.com czy wielu innych.
Na Webhosting.pl też poruszaliśmy ten temat dwukrotnie:
ICANN chce likwidacji limitów cenowych
Tired pricing
Na różnorakich dyskusyjnych forach domeniarskich temat był zaś wałkowany od poczatku listopada. Jak się jednak okazuje, międzynarodowe środowisko domenowe (nawet. gdy jest możliwość przedstawiania publicznego komentarzy), zupełnie z tego nie korzysta. Zaglądnąłem sobie dzisiaj na stronę ICANN, gdzie można ogladać komentarze. Wszedłem na podstronę dotycząca właśnie kwestii umowy z nowymi gTLD, a tam jak zwykle – kilka wypowiedzi, z czego tylko dziewięć dotyczyło Tired Pricing...
Patrząc na wszystkie komentarze, nie tylko te negujące Tiered Pricing, można odnieść wrażenie, że z wielkiej chmury będziemy mieli mały deszcz.
Po rozmowach z ludźmi z ICANN-u, a także po chociażby bardzo krótkim okresie na zgłaszanie komentarzy (tylko do 8 grudnia), jestem wręcz przekonany, że ICANN będzie zatwierdzał nowe zasady dotyczące gTLD już z początkiem marca 2009. Zobaczymy, ile będzie nowych aplikacji...
ICANN ogłosił konsultacje. W Kairze odbyła się specjalna konferencja, na której zgromadziło się ponad 1000 osób. Było wiele publikacji dotyczących kontrowersji związanych z proponowaną umową na nowe gTLD, jak chociażby materiały na tak znanych portalach jak DNjournal.com, DomainState.com, ICANNwatch.org, circleID.com czy wielu innych.
Na Webhosting.pl też poruszaliśmy ten temat dwukrotnie:
ICANN chce likwidacji limitów cenowych
Tired pricing
Na różnorakich dyskusyjnych forach domeniarskich temat był zaś wałkowany od poczatku listopada. Jak się jednak okazuje, międzynarodowe środowisko domenowe (nawet. gdy jest możliwość przedstawiania publicznego komentarzy), zupełnie z tego nie korzysta. Zaglądnąłem sobie dzisiaj na stronę ICANN, gdzie można ogladać komentarze. Wszedłem na podstronę dotycząca właśnie kwestii umowy z nowymi gTLD, a tam jak zwykle – kilka wypowiedzi, z czego tylko dziewięć dotyczyło Tired Pricing...
Patrząc na wszystkie komentarze, nie tylko te negujące Tiered Pricing, można odnieść wrażenie, że z wielkiej chmury będziemy mieli mały deszcz.
Po rozmowach z ludźmi z ICANN-u, a także po chociażby bardzo krótkim okresie na zgłaszanie komentarzy (tylko do 8 grudnia), jestem wręcz przekonany, że ICANN będzie zatwierdzał nowe zasady dotyczące gTLD już z początkiem marca 2009. Zobaczymy, ile będzie nowych aplikacji...
Friday, 14 November 2008
Tiered Pricing
W nawiązaniu do materiału "ICANN chce likwidacji limitów cenowych przy odnawianiu domen gTLD" zamieszczonego w Webhosting.pl, pragnę dorzucić moje trzy grosze...
Otóż omawiana sprawa dotyczy paragrafu 7.3 umów ICANN z Rejestrami gTLD „Pricing for Domain Name Registrations and Registry Services”. Paragraf ten zawiera zapis o cenie maksymalnej a dla jasności warto tutaj przytoczyć najważniejszy fragment z tego paragrafu:
Zapis ten z jednej strony mówi o tym, jaka może być cena maksymalna, a z drugiej określa, że warunki oferowane przez rejestr gTLD muszą być takie same dla wszystkich akredytowanych rejestratorów ICANN, a wyjatkiem są m.in. upusty ale też pod warunkiem, że te same reguły będa dotyczyć wszystkich podmiotów, które spełnią określone kryteria.
Teoretycznie prawdą jest, że jeśli nowe zasady dla gTLD wejdą w życie, i że te zasady będą mogły stosować istniejące rejestry gTLD (jak chociażby VeriSign dla domen .com), to może dojsc do sytuacji, kiedy za odnowienie domeny u jednego registrara będzie się płacić znacznie więcej niż u innego. Problem ten określany jest jako „Tiered Pricing”, stąd przy poszukiwaniu informacji w Internecie, warto posługiwać się tym właśnie określeniem. Ogólne znaczenie tego terminu określa sytuacje, kiedy różne grupy klientów obciążane są różnymi kwotami za ten sam produkt lub usługę.
Moim zdaniem, ICANN nie dopuści do usunięcia zapisów o cenie maksymalnej i równym traktowaniu registrarów przez rejestry, ponieważ może to prowadzić do pewnych nadużyć. Nawet gdyby te zapisy o cenie maksymalnej zniknęły, to wątpię, aby takie podmioty jak VeriSign, zdecydowały się na „tiered pricing”, czyli różnicowanie cen, a w szczególności podnoszenie tych cen. Należy pamiętać, że kontrakty na obsługę domen gTLD są określone w czasie, i ewentualny „zgrzyt” w relacjach z rejestratorami, spowodowałby trudności w przedłużeniu kontraktów z ICANN.
Sprawa jest raczej medialna niż praktyczna, niemniej jednak ICANN zdaje sobie sprawę z problemu, o czym możemy przekonać się czytając komentarze Kierena McCarthy z ICANN (kiedyś świetnego niezależnego dziennikarza, teraz równie dobrą „lokomotywę” PR w ICANN).
Komentarz autora (18 listopada 2009 r.):
Kieren McCarty odszedł miesiąc temu z ICANN.
Otóż omawiana sprawa dotyczy paragrafu 7.3 umów ICANN z Rejestrami gTLD „Pricing for Domain Name Registrations and Registry Services”. Paragraf ten zawiera zapis o cenie maksymalnej a dla jasności warto tutaj przytoczyć najważniejszy fragment z tego paragrafu:
(d) Maximum Price. The Maximum Price for Registry Services subject to this Paragraph 7.3 shall be as follows:
1. from the Effective Date through 31 December 2006, US$6.00;
2. for each calendar year beginning with 1 January 2007, the smaller of the preceding year's Maximum Price or the highest price charged during the preceding year, multiplied by 1.07; provided, however, that such increases shall only be permitted in four years of any six year term of the Agreement. In any year, however, where a price increase does not occur, Registry Operator shall be entitled to increase the Maximum Price by an amount sufficient to cover any additional incremental costs incurred during the term of the Agreement due to the imposition of any new Consensus Policy or documented extraordinary expense resulting from an attack or threat of attack on the Security or Stability of the DNS, not to exceed the smaller of the preceding year's Maximum Price or the highest price charged during the preceding year, multiplied by 1.07.
(e) No price discrimination. Registry Operator shall charge the same price for Registry Services subject to this Section 7.3, not to exceed the Maximum Price, to all ICANN-accredited registrars (provided that volume discounts and marketing support and incentive programs may be made if the same opportunities to qualify for those discounts and marketing support and incentive programs is available to all ICANN-accredited registrars).
Zapis ten z jednej strony mówi o tym, jaka może być cena maksymalna, a z drugiej określa, że warunki oferowane przez rejestr gTLD muszą być takie same dla wszystkich akredytowanych rejestratorów ICANN, a wyjatkiem są m.in. upusty ale też pod warunkiem, że te same reguły będa dotyczyć wszystkich podmiotów, które spełnią określone kryteria.
Teoretycznie prawdą jest, że jeśli nowe zasady dla gTLD wejdą w życie, i że te zasady będą mogły stosować istniejące rejestry gTLD (jak chociażby VeriSign dla domen .com), to może dojsc do sytuacji, kiedy za odnowienie domeny u jednego registrara będzie się płacić znacznie więcej niż u innego. Problem ten określany jest jako „Tiered Pricing”, stąd przy poszukiwaniu informacji w Internecie, warto posługiwać się tym właśnie określeniem. Ogólne znaczenie tego terminu określa sytuacje, kiedy różne grupy klientów obciążane są różnymi kwotami za ten sam produkt lub usługę.
Moim zdaniem, ICANN nie dopuści do usunięcia zapisów o cenie maksymalnej i równym traktowaniu registrarów przez rejestry, ponieważ może to prowadzić do pewnych nadużyć. Nawet gdyby te zapisy o cenie maksymalnej zniknęły, to wątpię, aby takie podmioty jak VeriSign, zdecydowały się na „tiered pricing”, czyli różnicowanie cen, a w szczególności podnoszenie tych cen. Należy pamiętać, że kontrakty na obsługę domen gTLD są określone w czasie, i ewentualny „zgrzyt” w relacjach z rejestratorami, spowodowałby trudności w przedłużeniu kontraktów z ICANN.
Sprawa jest raczej medialna niż praktyczna, niemniej jednak ICANN zdaje sobie sprawę z problemu, o czym możemy przekonać się czytając komentarze Kierena McCarthy z ICANN (kiedyś świetnego niezależnego dziennikarza, teraz równie dobrą „lokomotywę” PR w ICANN).
Komentarz autora (18 listopada 2009 r.):
Kieren McCarty odszedł miesiąc temu z ICANN.
Thursday, 13 November 2008
AFTERMARKET: .pl Domain Parking recent statistics
Recent statistics on parking shows that 5,42% of registered names under .pl are parked. Previous statistics showing market share of the parking sites were based on the data collected from the parking companies and included also domains that were parked in the past but than removed.
NASK recent data shows, that as of October 31st, 2008, the real percentage of the parked names is 5,42%.
9% of such names is parked using URL redirection and 91% is parked using Name Servers delegation.
Two companies dominated parking market in Poland: SEDO with 41% market and Name Drive with 59% of the total paring market in Poland.
Aftermarket includes not only parked names but also domain names for sale and sites that are developed for future sales. Rough estimation of this part of the market is 2-5 percentage points.
As of today, the whole aftermarket in Poland should be estimated for 8-9%
NASK recent data shows, that as of October 31st, 2008, the real percentage of the parked names is 5,42%.
9% of such names is parked using URL redirection and 91% is parked using Name Servers delegation.
Two companies dominated parking market in Poland: SEDO with 41% market and Name Drive with 59% of the total paring market in Poland.
Aftermarket includes not only parked names but also domain names for sale and sites that are developed for future sales. Rough estimation of this part of the market is 2-5 percentage points.
As of today, the whole aftermarket in Poland should be estimated for 8-9%
Monday, 10 November 2008
Udział w rynku domen parkowanych to 5,42%
Co to jest parkowanie domen? To działanie biznesowe polegające na zarabianiu na ruchu generowanym przez użytkowników Internetu. Osoba, która wchodzi na stronę WWW zaparkowanej domeny, widzi przed sobą listę linków do innych stron internetowych. Klikając umieszczone tam linki, generuje zysk dla właściciela domeny, ponieważ na każdym wejściu na znajdujący się na tej stronie link właściciel zaparkowanej strony zarabia. Czemu zarabia? Ponieważ właściciele stron, na które wchodzi nasz „klikający” klient, płacą za takie wejścia, to zarabia też właściciel zaparkowanej strony.
Parkowanie w .pl
Dotychczas w celu określenia liczby domen pozostających na parkingach NASK opierał się zarówno na własnych danych, jak również na danych pochodzących od firm zajmujących się parkowaniem domen. To powodowało trudności przy porównywaniu danych. Obecnie całość analiz przeprowadzamy bezpośrednio, opierając się na własnym systemie, który sprawdza każdą aktywną domenę z DNS-ie. Sprawdzamy zarówno, na jakie serwery nazw domena jest delegowana, jak również czy parkowanie jest oparte na przekierowaniu z użyciem URL.
Dane NASK-u różnią się od danych uzyskiwanych wcześniej od firm zajmujących się parkingiem domen, ponieważ firmy parkingowe z jednej strony uwzględniają w swoich raportach domeny już nieaktywne (ale aktywne np. kilka miesięcy wcześniej), a z drugiej nie uwzględniają chociażby domen zaparkowanych na ich serwerach, ale niedodanych jeszcze do paneli klienckich. NASK sprawdza natomiast wszystkie domeny istniejące w DNS-ie, a zaparkowane w chwili sprawdzenia.
I tak na przełomie października i listopada 2008 roku 5,42% domen .pl (dokładniej we wszystkich strefach obsługiwanych przez NASK) było zaparkowanych. Z tego prawie 9% domen jest parkowanych z użyciem URL, a ponad 91% przez skonfigurowanie serwerów nazw.
Na rynku parkingu pierwsze miejsce ma NameDrive z udziałem prawie 60%, a drugie miejsce zajmuje Sedo z udziałem ponad 40%. Pozostałe firmy parkingowe nie mają istotnego statystycznie udziału w rynku.
Warto nadmienić, że powyższe dane nie odzwierciedlają bezpośrednio wielkości „rynku wtórnego”. Aftermarket to nie tylko parkowanie, ale również sprzedaż domen czy też rozwijanie serwisów wokół tych domen, aby później uzyskać wyższą cenę sprzedaży.
Parkowanie w .pl
Dotychczas w celu określenia liczby domen pozostających na parkingach NASK opierał się zarówno na własnych danych, jak również na danych pochodzących od firm zajmujących się parkowaniem domen. To powodowało trudności przy porównywaniu danych. Obecnie całość analiz przeprowadzamy bezpośrednio, opierając się na własnym systemie, który sprawdza każdą aktywną domenę z DNS-ie. Sprawdzamy zarówno, na jakie serwery nazw domena jest delegowana, jak również czy parkowanie jest oparte na przekierowaniu z użyciem URL.
Dane NASK-u różnią się od danych uzyskiwanych wcześniej od firm zajmujących się parkingiem domen, ponieważ firmy parkingowe z jednej strony uwzględniają w swoich raportach domeny już nieaktywne (ale aktywne np. kilka miesięcy wcześniej), a z drugiej nie uwzględniają chociażby domen zaparkowanych na ich serwerach, ale niedodanych jeszcze do paneli klienckich. NASK sprawdza natomiast wszystkie domeny istniejące w DNS-ie, a zaparkowane w chwili sprawdzenia.
I tak na przełomie października i listopada 2008 roku 5,42% domen .pl (dokładniej we wszystkich strefach obsługiwanych przez NASK) było zaparkowanych. Z tego prawie 9% domen jest parkowanych z użyciem URL, a ponad 91% przez skonfigurowanie serwerów nazw.
Na rynku parkingu pierwsze miejsce ma NameDrive z udziałem prawie 60%, a drugie miejsce zajmuje Sedo z udziałem ponad 40%. Pozostałe firmy parkingowe nie mają istotnego statystycznie udziału w rynku.
Warto nadmienić, że powyższe dane nie odzwierciedlają bezpośrednio wielkości „rynku wtórnego”. Aftermarket to nie tylko parkowanie, ale również sprzedaż domen czy też rozwijanie serwisów wokół tych domen, aby później uzyskać wyższą cenę sprzedaży.
Friday, 7 November 2008
Al-Kaida DNS: bojownicy DNSSEC
Niewątpliwie to, co bezpośrednio dotyczy abonentów domen .pl, firm rejestrujących domeny (takich jak NetArt, home.pl, Az.pl, Active 24, Onet.pl i wielu innych), to kwestia DNSSEC. Środa 5 listopada 2008 roku na spotkaniu ICANN to niewątpliwie dzień DNSSEC, a dokładnie wielkie pranie mózgów, że DNSSEC uratuje świat, a przynajmniej zabezpieczy DNS przed wieloma zagrożeniami.
Co ciekawe, te zagrożenia są hipotetyczne i proste przeciwdziałanie im (jak rozdzielenie funkcji autorytatywnych i rekursywnych w DNS-ie) rozwiązuje problem. Można nawet powiedzieć, że pojawiła się grupa ludzi (nazwijmy ich dla ustalenia uwagi „Al-Kaida”), która za wszelką cenę chce, aby został „podpisany” rootserwer oraz aby rejestry narodowe i gTLD wdrożyły DNSSEC. Osoby, które miały okazję słuchać Steve'a Crockera czy innych przedstawicieli tej Al-Kaidy, wiedzą, o czym mówię...
Ale wracając do kwestii DNSSEC, która była tak często podnoszona na ICANN. Aby DNSSEC zadziałał, musi zostać wdrożony przez:
* ICANN i VeriSign na poziomie root,
* wszystkie rejestry ccTLD i gTLD,
* rejestratorów domen, a abonenci zostają „uświadomieni”, co to DNSSEC,
* wszystkich ISP,
* użytkowników przez zainstalowanie systemów operacyjnych na swoich domowych komputerach, które obsługują DNSSEC.
Wdrożenie na poziomie „root” wydaje się relatywnie proste, chociaż dyskusja trwa już trzy lata. Załóżmy też, że problemów z wdrożeniem (poprawnym) nie będą miały rejestry ccTLD. Załóżmy także, że rejestratorzy domen (a więc u nas to prawie 100 podmiotów na czele z wymienionymi na początku) będą obsługiwały DNSSEC i przekonają klientów rejestrujących domeny (i zmieniających delegacje), że muszą podpisywać swoje strefy (domeny). Pozostają użytkownicy Internetu, 1,4 miliarda ludzi...
DNSSECC nie ma sensu, jeśli cała droga od komputera użytkownika przez cache DNS serwer należący do ISP oraz pozostałe serwery DNS nie jest zabezpieczona. No i pytanie, czy najpopularniejszy OS na rynku, czyli Windows (zarówno w wersji serwerowej, jak i desktopowej), będzie obsługiwał DNSSEC? Według przedstawiciela Microsoftu Windows Server 2008 R2 i Windows 7 będą dostępne za trzy lata (czytaj: za cztery lata). Czyli w roku 2012 Microsoft rozpocznie sprzedaż nowych Windows. Można oczekiwać, że za kolejne 5 lat (2017 rok?) ok. 30–40% komputerów wykorzystujących Windows będzie wyposażone w obsługę DNSSEC (bo taki jest cykl wymiany systemów operacyjnych przez użytkowników końcowych, zarówno biznesowych, jak i indywidualnych).
Pozostają takie kwestie, jak co robić, jeśli np. ISP nie obsługuje DNSSEC – czy wtedy komputer użytkownika podłączającego się przez takiego ISP powinien odmówić otwarcia strony WWW czy nie? Ta wręcz banalna kwestia nie jest ustandaryzowana, mimo że chcemy mieć DNSSEC w „root” serwerze...
No ale załóżmy, że mamy ten DNSSEC, domeny są podpisane, serwery DNS obsługują DNSSEC. Co dzięki temu osiągamy?
Wiemy, że jeśli zapytamy o adres www.mójBANKon-line.pl, to odpowiedź DNS, zwrócona do naszego komputera będzie zawierała niezmienioną informację, ale nadal nie będziemy wiedzieli, do kogo faktycznie należy strona WWW odpowiadająca domenie „mójBANKon-line.pl” i czy nie jest to jakaś strona phishingowa (bo nasz bank ma faktycznie domenę „mójBANKonline.pl”, a nie „mójBANKon-line.pl”). Oczywiście możemy to sprawdzić w WHOIS, ale nie mamy pewności, że dane w WHOIS są prawdziwe. NASK czy każdy inny rejestr TLD może weryfikować wszystkie dane w WHOIS, ale wtedy proces rejestracji będzie ręczny i będzie trwał kilka dni, podobnie jak to ma miejsce przy wystawianiu certyfikatów SSL – pytanie, czy rejestratorzy domen chociażby w Polsce chcieliby, aby wydłużyć proces rejestracji domeny do 2 tygodni oraz żądać dokumentów od abonentów.
Rozwiązaniem powyższego problemu, istniejącego od lat, są certyfikaty SSL, które faktycznie wystawiane są ręcznie, a proces trwa kilka dni (lub nawet tygodni dla certyfikatów typu Extended Validation). Jeśli więc zostaniemy skierowani na stronę obsługiwaną przez przestępców (phisherów), to sprawdzając certyfikat, będziemy mogli sprawdzić, czy faktycznie strona, na której jesteśmy, należy do banku. A DNSSEC nie da nam takiej pewności, ponieważ phisherzy też będą potrafili poprawnie wygenerować klucze, podpisać strefę itd. i nie mamy żadnej możliwości sprawdzenia, do kogo należy strona WWW. Będziemy mieli natomiast fałszywe poczucie bezpieczeństwa, ale wspomniani przyjaciele Al-Kaidy nie interesują się tym – ich interesuje tylko podpisanie „root”...
Mała demonstracja:
Jeśli ktoś wejdzie na stronę www.dns.pl po HTTPS, a więc na https://www.dns.pl/, to dostanie np. w Mozilla Firefoksie następującą informację:
Nazwa firmy na zielonym pasku to właśnie certyfikat typu Extended Validation, a sprawdzając dane kryjące się za tym certyfikatem, mamy pewność, do kogo należy strona:
Gdybyśmy zamiast SSL wykorzystali DNSSEC, nie mamy szans na uzyskanie takich informacji...
Zobaczymy, jak potoczą się losy DNSSEC. Na chwilę obecną wdrożyły go (ale tylko fragmentarycznie, bez całego procesu obsługi certyfikatów) rejestry .se, .bg oraz .cz. Jeśli natomiast chodzi o ISP, to w Europie DNSSEC obsługuje tylko Telia w Szwecji.
Więcej o DNSSEC od przedstawicieli Al-Kaidy można przeczytać na stronie ICANN.
Co ciekawe, te zagrożenia są hipotetyczne i proste przeciwdziałanie im (jak rozdzielenie funkcji autorytatywnych i rekursywnych w DNS-ie) rozwiązuje problem. Można nawet powiedzieć, że pojawiła się grupa ludzi (nazwijmy ich dla ustalenia uwagi „Al-Kaida”), która za wszelką cenę chce, aby został „podpisany” rootserwer oraz aby rejestry narodowe i gTLD wdrożyły DNSSEC. Osoby, które miały okazję słuchać Steve'a Crockera czy innych przedstawicieli tej Al-Kaidy, wiedzą, o czym mówię...
Ale wracając do kwestii DNSSEC, która była tak często podnoszona na ICANN. Aby DNSSEC zadziałał, musi zostać wdrożony przez:
* ICANN i VeriSign na poziomie root,
* wszystkie rejestry ccTLD i gTLD,
* rejestratorów domen, a abonenci zostają „uświadomieni”, co to DNSSEC,
* wszystkich ISP,
* użytkowników przez zainstalowanie systemów operacyjnych na swoich domowych komputerach, które obsługują DNSSEC.
Wdrożenie na poziomie „root” wydaje się relatywnie proste, chociaż dyskusja trwa już trzy lata. Załóżmy też, że problemów z wdrożeniem (poprawnym) nie będą miały rejestry ccTLD. Załóżmy także, że rejestratorzy domen (a więc u nas to prawie 100 podmiotów na czele z wymienionymi na początku) będą obsługiwały DNSSEC i przekonają klientów rejestrujących domeny (i zmieniających delegacje), że muszą podpisywać swoje strefy (domeny). Pozostają użytkownicy Internetu, 1,4 miliarda ludzi...
DNSSECC nie ma sensu, jeśli cała droga od komputera użytkownika przez cache DNS serwer należący do ISP oraz pozostałe serwery DNS nie jest zabezpieczona. No i pytanie, czy najpopularniejszy OS na rynku, czyli Windows (zarówno w wersji serwerowej, jak i desktopowej), będzie obsługiwał DNSSEC? Według przedstawiciela Microsoftu Windows Server 2008 R2 i Windows 7 będą dostępne za trzy lata (czytaj: za cztery lata). Czyli w roku 2012 Microsoft rozpocznie sprzedaż nowych Windows. Można oczekiwać, że za kolejne 5 lat (2017 rok?) ok. 30–40% komputerów wykorzystujących Windows będzie wyposażone w obsługę DNSSEC (bo taki jest cykl wymiany systemów operacyjnych przez użytkowników końcowych, zarówno biznesowych, jak i indywidualnych).
Pozostają takie kwestie, jak co robić, jeśli np. ISP nie obsługuje DNSSEC – czy wtedy komputer użytkownika podłączającego się przez takiego ISP powinien odmówić otwarcia strony WWW czy nie? Ta wręcz banalna kwestia nie jest ustandaryzowana, mimo że chcemy mieć DNSSEC w „root” serwerze...
No ale załóżmy, że mamy ten DNSSEC, domeny są podpisane, serwery DNS obsługują DNSSEC. Co dzięki temu osiągamy?
Wiemy, że jeśli zapytamy o adres www.mójBANKon-line.pl, to odpowiedź DNS, zwrócona do naszego komputera będzie zawierała niezmienioną informację, ale nadal nie będziemy wiedzieli, do kogo faktycznie należy strona WWW odpowiadająca domenie „mójBANKon-line.pl” i czy nie jest to jakaś strona phishingowa (bo nasz bank ma faktycznie domenę „mójBANKonline.pl”, a nie „mójBANKon-line.pl”). Oczywiście możemy to sprawdzić w WHOIS, ale nie mamy pewności, że dane w WHOIS są prawdziwe. NASK czy każdy inny rejestr TLD może weryfikować wszystkie dane w WHOIS, ale wtedy proces rejestracji będzie ręczny i będzie trwał kilka dni, podobnie jak to ma miejsce przy wystawianiu certyfikatów SSL – pytanie, czy rejestratorzy domen chociażby w Polsce chcieliby, aby wydłużyć proces rejestracji domeny do 2 tygodni oraz żądać dokumentów od abonentów.
Rozwiązaniem powyższego problemu, istniejącego od lat, są certyfikaty SSL, które faktycznie wystawiane są ręcznie, a proces trwa kilka dni (lub nawet tygodni dla certyfikatów typu Extended Validation). Jeśli więc zostaniemy skierowani na stronę obsługiwaną przez przestępców (phisherów), to sprawdzając certyfikat, będziemy mogli sprawdzić, czy faktycznie strona, na której jesteśmy, należy do banku. A DNSSEC nie da nam takiej pewności, ponieważ phisherzy też będą potrafili poprawnie wygenerować klucze, podpisać strefę itd. i nie mamy żadnej możliwości sprawdzenia, do kogo należy strona WWW. Będziemy mieli natomiast fałszywe poczucie bezpieczeństwa, ale wspomniani przyjaciele Al-Kaidy nie interesują się tym – ich interesuje tylko podpisanie „root”...
Mała demonstracja:
Jeśli ktoś wejdzie na stronę www.dns.pl po HTTPS, a więc na https://www.dns.pl/, to dostanie np. w Mozilla Firefoksie następującą informację:
Nazwa firmy na zielonym pasku to właśnie certyfikat typu Extended Validation, a sprawdzając dane kryjące się za tym certyfikatem, mamy pewność, do kogo należy strona:
Gdybyśmy zamiast SSL wykorzystali DNSSEC, nie mamy szans na uzyskanie takich informacji...
Zobaczymy, jak potoczą się losy DNSSEC. Na chwilę obecną wdrożyły go (ale tylko fragmentarycznie, bez całego procesu obsługi certyfikatów) rejestry .se, .bg oraz .cz. Jeśli natomiast chodzi o ISP, to w Europie DNSSEC obsługuje tylko Telia w Szwecji.
Więcej o DNSSEC od przedstawicieli Al-Kaidy można przeczytać na stronie ICANN.
Tuesday, 4 November 2008
Spotkanie ICANN w Kairze, 4 listopada 2008, wtorek
Pierwszy tydzień listopada 2008 roku to czas spotkania ICANN w Kairze. To pewna ceremonia, gdyż decyzje i tak zapadają poza samym spotkaniem, a ICANN Board służy tylko „przyklepaniu” uzgodnionych wcześniej kwestii. Dla ccTLD rola ICANN jest i tak bardzo ograniczona i sprowadza się do „ręcznych” zmian delegacji serwerów nazw (to, co w NASK-u robimy automatycznie). Niemniej jednak są sprawy, które nas bezpośrednio interesują, jak na przykład kwestia wdrożenia DNSSEC na poziomie „root” i związana z tym polityka ICANN czy też nowe IDN-TLD dla takich krajów, jak Bułgaria, Rosja, Grecja, Ukraina itd.
Ale co do głównych tematów spotkań w poniedziałek (3 listopada 2008) i wtorek (4 listopada 2008):
Nowe gTLD
Jeden z dokumentów opublikowanych przez ICANN tuż przed spotkaniem ICANN w Kairze dotyczy nowych gTLD. Dokument nosi nazwę „New gTLD Program: Draft Applicant Guidebook” i można go znaleźć pod adresem. W trakcie spotkania ICANN odbywa się natomiast dyskusja dotycząca wyżej wymienionej propozycji.
Dokument ten, trzeba przyznać, jest dość dobrze napisany, a procedura zgłaszania TLD i ich oceny – jasna i czytelna. Moim zdaniem to najlepszy dokument, jaki ICANN przygotował (dokładniej przygotowała firma doradcza). Zupełnie nie pasuje to do ICANN, gdzie generalnie procedury są uznaniowe i bardzo niejasne. Ale to dobry znak, że w przypadku nowych gTLD sprawy będą załatwiane profesjonalnie, oczywiście pod warunkiem, że procedura dla nowych TLD zostanie zaakceptowana przez zarząd ICANN.
Wszystko wskazuje na to, że wcześniej będą nowe gTLD niż nowe IDN-ccTLD i osoby zainteresowane nowymi gTLD niedługo będą mogły o takie nazwy aplikować. Oczywiście trzeba mieć trochę pieniędzy – dla samego ICANN (w wersji optymistycznej, że nie będzie dodatkowych etapów weryfikacji wniosku) trzeba przygotować 185 000 USD. Koszt opracowania wniosku to kolejne 100 000–200 000 USD. No i trzeba dysponować profesjonalnym zapleczem technicznym do obsługi rejestracji i rozwiązywania nazw (DNS).
Przy okazji tego tematu ponawiam propozycję: jeśli ktoś byłby zainteresowany w Polsce domenami TLD typu .warsaw, .krakow, .cracow, .poznan etc., dysponuje poparciem Rady Miasta i ma zaplecze finansowe, to NASK gotowy jest pomóc na poziomie technicznym w przygotowaniu takiego wniosku i następnie wspólnej aplikacji o taką domenę.
Dotychczas zainteresowanie swoimi nazwami już wyraziły już: Barcelona, Paryż, Nowy Jork oraz Berlin.
Nowe ccTLD
Tutaj sprawy posuwają się swoim tempem (znaczy wolno, bo zaczęło się wszystko w 2001 roku...). Ale pewien postęp jest: aż 32 kraje zgłosiły swoje zainteresowanie dla wersji IDN swoich ccTLD, a przed samym spotkaniem ICANN ogłosił „Draft Implementation Plan for the IDN ccTLD Fast Track Process”, który można znaleźć pod adresem
„Dzięki” temu, że dokument został opublikowany dopiero tydzień temu, rządy i poszczególne rejestry nie miały okazji się do niego ustosunkować... Ale wygląda na to, że generalny odbiór dokumentu jest dobry i rejestry zainteresowane nowymi TLD dla swoich krajów będą wspierały opisany w tym dokumencie proces. Spotkanie przedstawicieli rządów jeszcze trwa (wtorek), więc stanowisko GAC (Governmental Advisory Committee) nie jest jeszcze znane.
Jeśli chodzi o Unię Europejską, to zainteresowanie jest po stronie Bułgarii oraz Grecji, co jest zrozumiałe ze względu na używane alfabety (grecki i cyrylica) przez oba te kraje. Potencjalnie zainteresowany będzie także EURid, ponieważ wspomniane dwa kraje (członkowie Unii Europejskiej) chciałyby mieć rozszerzenie .eu w swoich językach narodowych.
Ale co do głównych tematów spotkań w poniedziałek (3 listopada 2008) i wtorek (4 listopada 2008):
Nowe gTLD
Jeden z dokumentów opublikowanych przez ICANN tuż przed spotkaniem ICANN w Kairze dotyczy nowych gTLD. Dokument nosi nazwę „New gTLD Program: Draft Applicant Guidebook” i można go znaleźć pod adresem. W trakcie spotkania ICANN odbywa się natomiast dyskusja dotycząca wyżej wymienionej propozycji.
Dokument ten, trzeba przyznać, jest dość dobrze napisany, a procedura zgłaszania TLD i ich oceny – jasna i czytelna. Moim zdaniem to najlepszy dokument, jaki ICANN przygotował (dokładniej przygotowała firma doradcza). Zupełnie nie pasuje to do ICANN, gdzie generalnie procedury są uznaniowe i bardzo niejasne. Ale to dobry znak, że w przypadku nowych gTLD sprawy będą załatwiane profesjonalnie, oczywiście pod warunkiem, że procedura dla nowych TLD zostanie zaakceptowana przez zarząd ICANN.
Wszystko wskazuje na to, że wcześniej będą nowe gTLD niż nowe IDN-ccTLD i osoby zainteresowane nowymi gTLD niedługo będą mogły o takie nazwy aplikować. Oczywiście trzeba mieć trochę pieniędzy – dla samego ICANN (w wersji optymistycznej, że nie będzie dodatkowych etapów weryfikacji wniosku) trzeba przygotować 185 000 USD. Koszt opracowania wniosku to kolejne 100 000–200 000 USD. No i trzeba dysponować profesjonalnym zapleczem technicznym do obsługi rejestracji i rozwiązywania nazw (DNS).
Przy okazji tego tematu ponawiam propozycję: jeśli ktoś byłby zainteresowany w Polsce domenami TLD typu .warsaw, .krakow, .cracow, .poznan etc., dysponuje poparciem Rady Miasta i ma zaplecze finansowe, to NASK gotowy jest pomóc na poziomie technicznym w przygotowaniu takiego wniosku i następnie wspólnej aplikacji o taką domenę.
Dotychczas zainteresowanie swoimi nazwami już wyraziły już: Barcelona, Paryż, Nowy Jork oraz Berlin.
Nowe ccTLD
Tutaj sprawy posuwają się swoim tempem (znaczy wolno, bo zaczęło się wszystko w 2001 roku...). Ale pewien postęp jest: aż 32 kraje zgłosiły swoje zainteresowanie dla wersji IDN swoich ccTLD, a przed samym spotkaniem ICANN ogłosił „Draft Implementation Plan for the IDN ccTLD Fast Track Process”, który można znaleźć pod adresem
„Dzięki” temu, że dokument został opublikowany dopiero tydzień temu, rządy i poszczególne rejestry nie miały okazji się do niego ustosunkować... Ale wygląda na to, że generalny odbiór dokumentu jest dobry i rejestry zainteresowane nowymi TLD dla swoich krajów będą wspierały opisany w tym dokumencie proces. Spotkanie przedstawicieli rządów jeszcze trwa (wtorek), więc stanowisko GAC (Governmental Advisory Committee) nie jest jeszcze znane.
Jeśli chodzi o Unię Europejską, to zainteresowanie jest po stronie Bułgarii oraz Grecji, co jest zrozumiałe ze względu na używane alfabety (grecki i cyrylica) przez oba te kraje. Potencjalnie zainteresowany będzie także EURid, ponieważ wspomniane dwa kraje (członkowie Unii Europejskiej) chciałyby mieć rozszerzenie .eu w swoich językach narodowych.
Subscribe to:
Posts (Atom)