Jednalo se o český neutrální peeringový uzel NIX.CZ, se kterým často sdílíme technické know-how a vzájemně si vypomáháme tam, kde to dává smysl. Dále pak o doménový registr státu Guatemala provozující ccTLD .gt, kterému jsme vyšli vstříc v rámci naší dlouhodobé podpory rozvíjejícím se registrům, stejně jako tomu bylo dříve v případě registrů Angoly, Malawi, Tanzanie nebo Severní Makedonie.
Peeringový uzel i národní doména
V případě NIX.CZ se jednalo o přibližně dvacet SLD domén (tedy domén druhé úrovně) a motivací byla konsolidace stávající infrastruktury v jiném datovém centru, kde provozují slave DNS instanci v jiném autonomním systému.
Guatemalský registr chtěl rozšířit dostupnost svých TLD (tedy domén nejvyššího řádu) a SLD domén v rámci dalších DNS uzlů běžících ve světě. Registr spravuje osm zón o celkovém počtu přibližně 20 000 doménových jmen.
Pokusím se popsat, jak je takováto spolupráce technicky provedena.
DNS infrastruktura
Ze všeho nejdříve je potřeba stanovit, na kterých DNS slave instancích mají být požadované domény dostupné. Rozlišujeme totiž dvě prostředí; DNS anycast a SLD servery, které se liší počtem serverů (výpočetním výkonem), geografickým rozmístěním a požadovanou dostupností.
DNS anycast je naše hlavní DNS prostředí, na kterém provozujeme ccTLD .CZ a nejvýznamnější domény drhouhé řádu (např. nic.cz, mojeid.cz apod.) a je dostupné na čtyřech nezávislých IP rozsazích, které označujeme písmeny A–D. V rámci anycastu a pomocí protokolu BGP pak jednotlivé servery v různých lokalitách ve světě oznamují daný IPv4 prefix /24 + IPv6 prefix /48 a stahují na sebe DNS provoz.
Celkem je v DNS anycastu zahrnuto více než 100 serverů, na kterých provozujeme vzhledem k diverzitě různé DNS démony (KNOT, BIND, NSD) a routing démony (BIRD, QUAGGA, FRROUTING). Pro hosting ccTLD zón využíváme vyhrazené IP adresy z rozsahu D anycastu.
Naopak SLD servery používáme pro ostatní domény druhého řádu a jedná se o samostatně fungující DNS servery, bez routing démona. Dva servery jsou umístěné v obou našich pražských datacentrech a jeden server pak mimo naši síť, tedy v rámci jiného autonomního systému. Na rozdíl od DNS anycastu nejsou servery provozovány v zahraničních lokalitách a i zde zachováváme diverzitu DNS démonů.
Proč tedy máme dvě prostředí, když by stačilo mít pouze DNS anycast? Důvodem je poměrně velká časová náročnost pro přidání/odebrání byť jedné DNS zóny na DNS anycastu a nenulové riziko vzniku chyby, která by s ohledem na nejvyšší důležitost tohoto systému mohla mít fatální dopad na provoz domény .CZ.
Správa domén na SLD serverech naopak zabere našim administrátorům méně času a případný negativní dopad plynoucí z konfigurační chyby je také menší. Správa zón na DNS anycastech totiž znamená upravit konfigurace postupně na více než 100 serverech a vždy pečlivě zkontrolovat, zda se změna úspěšně provedla. Ačkoliv je to DNS anycast, žádný z administrátorů si „netroufne“ konfiguraci a reload DNS zón provést na všech serverech najednou.
Změny konfigurace DNS serverů
O tom, na jakém DNS prostředí poběží jednotlivé zóny, máme již jasno. Zóny ccTLD .gt budeme provozovat na celém D anycastu, podobně jako např. ccTLD .mk, .tz, .ao nebo .mw. Domény druhého řádu NIX.CZ budou dostupné jen na SLD serverech. Jaké kroky jsou potřeba k tomu, aby se zóny dostaly až na DNS servery?
Nejdříve musíme nakonfigurovat naše skryté (hidden) master servery (dále jen „HM“). Jedná se o servery, které běží „schované“ uvnitř naší sítě, udržují zónové soubory aktuální a posílají je na všechny servery v DNS anycastu nebo na SLD servery.
Jednotlivé kroky jsou následující:
- Sdělíme IP prefixy našich HM serverů, které si subjekt na své straně povolí ve firewallu, a umožní nám tak aktualizaci zón.
- Získáme IP adresy DNS masteru, odkud budeme stahovat obsah zón pomocí AXFR na naše HM servery.
- Domluvíme si TSIG klíč pro zabezpečení přenosu zón.
- Vyzkoušíme získání zóny, např. utilitou dig:
# dig @DNS_MASTER axfr TLD -y TSIG_ALG:TSIG_KEYNAME:TSIG_SECRET
- Připravíme konfigurační soubory pro jednotlivé domény.
Jakmile se objeví všechny požadované zóny na našich HM serverech, můžeme připravit konfiguraci pro cílové DNS servery, které budou tyto zóny hostovat uživatelům v Internetu. Vzhledem k různým DNS démonům máme v našem Ansible připraveny jednotlivé role, které na základě provozovaného démona připraví již finální konfigurace pro každou zónu tak, aby DNS servery získávaly aktualizace zón přímo z našich HM serverů. Zbývá pak jen spustit Ansible playbooky na požadované servery.
Následující schéma ukazuje zjednodušené workflow aktualizace zón.
(Původně napsáno pro blog CZ.NIC.)
