Efektivnější sběr informací z DNS serverů

Od konce ledna 2021 se ze všech autoritativních DNS serverů provozovaných sdružením CZ.NIC sbírají informace o DNS transakcích (dotazech a odpovědích) s využitím nového standardního formátu Compacted-DNS (C-DNS). Jeho specifikace je obsažena v RFC 8618. Pro sběr těchto dat používáme software DNS Probe vyvinutý v Laboratořích CZ.NIC ve spolupráci s FIT VUT Brno. Završila se tím zhruba půlroční etapa přechodu od tradičního a námi dříve používaného formátu PCAP, během níž jsme testovali výkon a stabilitu DNS Probe a porovnávali výsledky získané v obou formátech.

C-DNS byl na rozdíl od PCAP vytvořen speciálně pro ukládání a přenos velkých počtů DNS transakcí. Je navržen tak, aby byl co nejefektivnější a nejpružnější, což je na druhé straně zaplaceno jeho relativní složitostí. Podrobnější popis jde proto za rámec tohoto příspěvku, zde jsou ale jeho základní charakteristiky:

  • používá se binární kódování CBOR (RFC 7409) – oprava: RFC 8949,
  • časové značky mají volitelnou přesnost,
  • není nutné ukládat všechna dostupná data; naproti tomu je možné přidat i položky, které nejsou ve standardu,
  • data o DNS dotazu a příslušné odpovědi se ukládají společně, sdílené položky se neduplikují,
  • větší počty těchto transakcí se sdružují do bloků proměnné délky (doporučená velikost bloku je 10 tisíc transakcí),
  • bloky dále obsahují určitá metadata a statistiky, a také se v nich uplatňují další postupy komprese dat.

Úkolem softwaru DNS Probe je tedy ze síťového provozu (jak UDP, tak i TCP) extrahovat DNS dotazy klientů a odpovědi serveru, spárovat ty, které k sobě patří, a podle konfigurace pak generovat data C-DNS. Ta je možno ukládat buď na lokální disk anebo je rovnou šifrovaným TLS spojením odesílat k dalšímu zpracování. Součástí projektu DNS Probe je proto i datový přijímač (balíček dns-probe-collector). V našem uspořádání pak takto přijatá data ukládáme do databáze Apache Hadoop.

Hlavní výhodou formátu C-DNS oproti PCAP by mělo být výrazné snížení objemu ukládaných a přenášených dat. To se v našem případě ukazuje zcela jednoznačně. V následující tabulce jsou uvedeny objemy nasbíraných dat v obou formátech za prosinec 2020 na devíti vybraných produkčních DNS serverech (v obou případech dále zkomprimovaných pomocí xz). Střední hodnota posledního sloupce tabulky (poměr velikostí C-DNS/PCAP) je 15,6 %.

Server C-DNS [GB] PCAP [GB] Podíl [%]
cecolo-cz 47 261 18,0
cra-ca 15 108 13,9
decix-ca 33 289 11,4
decix-cz 63 372 16,9
linx-ca 55 451 12,2
linx-cz 148 802 18,5
mix-cz 14 77 18,2
vix-ca 40 296 13,5
vix-cz 45 254 17,7

Porovnáním dat jsme navíc zjistili, že DNS Probe systematicky reportuje transakce, které z PCAP dat nedostaneme. V UDP provozu je tento rozdíl vcelku zanedbatelný (nejvýše 1 %), ale v případě TCP je to obvykle 5–10 %, a pro některé servery ještě výrazně více. Důvodem mohou být jak známé problémy formátu PCAP (odpověď v něm například může někdy být uložena před příslušným dotazem), tak i případné nedostatky v softwaru, kterým jsme v souborech PCAP vyhledávali a párovali dotazy a odpovědi.

Plánujeme využít i výše zmíněnou rozšiřitelnost C-DNS a přidat vlastní volitelné položky týkající se klientů (resolverů): číslo autonomního systému (ASN) a kód země získaný z GeoIP databáze.

Autor:

Komentáře (2)

  1. Marek říká:

    > … známé problémy formátu PCAP …

    Jaké jsou prosím známé problémy formátu PCAP? To je tak primitivní formát, že v něm na nějaké problémy snad ani není prostor.

    To, že se odpověď uloží dříve než dotaz není problém formátu, ale nástroje, který zachytává data a zapisuje je do souboru. Je to problém postupu / procesu, ne datového formátu.

  2. Ladislav Lhotka říká:

    Ano, to máte pravdu, napsal jsem to přílliš zkratkovitě. Je ale fakt, že tyto problémy se v různé míře projevovaly u obou nástrojů, které jsme dříve používali, tj. dnscap a netsniff-ng.

Zanechte komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..