Statistika DNSSEC resolverů

Jako správce české domény máme poměrně dobrý přehled o tom, kolik existuje zabezpečených domén s koncovkou .CZ. Jak to ale vypadá na druhé straně?

Samotné měření toho, kolik je validujících resolverů, není bohužel jednoduchá záležitost. Žádný resolver nehlásí autoritativnímu serveru „já jsem validující“, takže pro detekci lze použít nepřímé techniky, které využívají znalost toho, jakým způsobem validující resolver žádá o DNS záznamy. Asi nejkomplexnější metodu měření navrhl Olafur Gudmundsson a Steve Crocker na konferenci SATIN 2011; popsanou ji najdete v článku Guðmundsson, Crocker: Observing DNSSEC validation in the wild. Tuto metodiku jsme použili pro naše měření. Kromě toho, že nemá smysl znovu vynalézat kolo, je jednotná metodika také důležitá pro srovnání s ostatními registry. V případě, že by každý registr vynalézal znovu a znovu metodiku měření validujících resolverů, bylo by následné porovnávání výsledků příslovečným porovnáváním jablek s hruškami.

Stručné shrnutí metodiky:

Pro zjednodušení bereme jednu IP adresu za jeden resolver, i když ve skutečnosti se za jednou IP adresou může v případě NATu skrývat více resolverů.

Pro detekci validujících resolverů se metodika snaží hledat odlišnosti mezi chováním „zastaralých“, tedy nevalidujících resolverů, a těch validujících. Ty se liší především dotazy na DS a DNSKEY záznamy:

  1. dotaz na DS záznam – resolver označíme jako určitě validující
  2. opakovaný dotaz na DNSKEY záznam v časových intervalech odpovídající době platnosti (TTL) tohoto záznamu – resolver také označíme jako určitě validující
  3. samostatný dotaz na DNSKEY záznam – resolver označíme jako pravděpodobně validující

Z charakteru protokolu DNS vyplývá, že není možné, aby byla tato metodika absolutně spolehlivá. K jistému zjednodušení dochází proto, protože na straně autoritativního serveru není možné poznat, zda-li položený dotaz na DS nebo DNSKEY záznam vznikl na základě požadavku na validaci nebo jej vznesl nějaký testovací nebo monitorovací skript. Ke zkreslení výsledků přispívají i lidé, kteří prostými dotazy pomocí různých DNS nástrojů mohou způsobit zařazení IP adresy do jedné z výše uvedených kategorií. Podrobnější diskuzi nad použitou metodikou lze nalézt ve výše zmíněném článku.

Nejprve uvedeme výsledky měření z dubna 2011 a pak pro porovnání z prosince 2011. Měření se provádělo vždy tři pracovní dny na stejných autoritativních serverech.

Data z dubna 2011

Dle popsané metodiky jsme v našich DNS datech našli 6767 určitě a 727 pravděpodobně validujících resolverů. Vzhledem k tomu, že většina provozovatelů DNS serverů nemá ve svých sítích pouze jeden server, tak jsme získané IP adresy následně museli ručně agregovat na základě vlastníka IP adresy serveru. Toto seskupení představuje další zjednodušení, které ovšem v případě resolverů s největším provozem můžeme zanedbat.

V následující tabulce naleznete top 10 českých společností jejichž sítě provozují validující resolvery (podle počtu DNSKEY dotazů zaslaných z validujících resolverů).

#DNSKEY   ISP
  5320    Casablanca
  4224    České Radiokomunikace
  3024    Telefónica O2
  2089    GTS NOVERA
  1624    UPL Telecom
  1338    NFX
   710    OMEGA tech
   537    Dial Telecom
   513    Ignum
   441    VUT Brno

Data z prosince 2011

Počet validujících resolverů se zvýšil: evidujeme 11403 určitě a 1201 pravděpodobně validujících resolverů.

Pořadí top 10 českých společností počtu DNSKEY dotazů z validujících resolverů se mírně promíchalo:

#DNSKEY   ISP
  7894    Telefónica O2
  6309    Vodafone
  4342    ACTIVE 24
  3441    UPC
  3285    GTS NOVERA
  3075    RIOMEDIA
  2712    2 connect
  2029    T-Mobile
  1946    Casablanca
  1737    CESNET

Pokud by vás zajímalo, zda váš ISP validuje, podívejte se na www.dnssec.cz, kde najdete jednoduchý a průkazný test. V komentářích nám potom můžete napsat, jak jste uspěli či neuspěli, kdo má nebo nemá zájem na větším bezpečí svých zákazníků.

Ondřej Mikle

Autor:

Komentáře (2)

  1. ahmul říká:

    Heh, nějaké zdůvodnění proč Casablance poklesla čísla na polovic?

  2. Ondrej Mikle říká:

    @ahmul: To bych skutečně jenom hádal. Může to být třeba v důsledku změny síťové topologie na jejich straně, ale možností je více.

Zanechte komentář