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.
> … 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.
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.