Nicméně začněme pěkně od začátku. Že adresy typu 10.0.0.1 nebo fd12:3456:7890:1::1 mají smysl jen v lokální síti, je jasné. Stejně tak je jasné, že jen v lokální síti může mít smysl řešit pro ně DNS. A pokud je lokální síť nepoužívá, nemají v DNS vůbec co dělat. Přesto kořenové servery zaznamenávají velký počet reverzních dotazů typu „hledám jméno k adrese 10.0.0.1“.
Lokální řešení
Prvním protiopatřením bylo RFC 6303, které požaduje, aby každý rekurzivní server odpovídal na reverzní dotazy vyvolané lokálními adresami. Jako odpověď má poslat chybový kód NXDOMAIN, tedy že poptávané jméno neexistuje, s příznakem autoritativní odpovědi. Má se chovat jako autoritativní server, který pro danou doménu obsahuje jen po jednom záznamu typu SOA a NS.
V RFC 6303 jsou vyjmenovány všechny domény, na něž se toto opatření vztahuje. Jedná se o domény reverzních dotazů pro neveřejné adresy podle RFC 1918, speciální IPv4 adresy podle RFC 5735 a 5737, unikátní lokální IPv6 adresy, lokální linkové IPv6 adresy, dokumentační prefix a podobně. Dohromady jich je něco přes třicet.
Samozřejmě se to týká jen těch, které místní síť nepoužívá. Budete-li adresovat lokální stroje adresami z bloku 10.0.0.0/8 a přiřadíte jim jména, budete pro ně nejspíš mít i reverzní záznamy v zóně 10.in-addr.arpa. Ale pro ostatní adresy z RFC 1918 už by se váš rekurzivní server měl chovat popsaným způsobem.
Dobrou zprávou je, že aktuální verze DNS serverů se popsaným způsobem implicitně chovají, aniž byste museli něco zapínat nebo obnovovat. Platí to pro BIND někdy od verze 9.9, Unbound 1.49 či PowerDNS Recursor 3.1.5. Čili pokud je server, který zodpovídá dotazy v lokální síti, alespoň trochu aktuální, měl by se chovat mravně. Jestli mezi ně ten váš patří, zjistíte celem snadno. Prostě se zeptejte na nějakou lokální adresu z rozsahu, který se u vás nepoužívá. Třeba
dig -x 172.16.1.1
Odpověď by měla vypadat nějak takto:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33636
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.1.16.172.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
16.172.in-addr.arpa. 10800 IN SOA
localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 0 msec
;; SERVER: 147.230.1.1#53(147.230.1.1)
;; WHEN: Thu Jun 11 14:32:50 2015
;; MSG SIZE rcvd: 100
Důležité znaky: výsledek NXDOMAIN, příznak AA pro autoritativní odpověď a místní rekurzivní server jako odesilatel. Všimněte si také obskurních dat v přibaleném záznamu SOA. RFC 6303 požaduje, aby se údaje v SOA a NS lišily od normálních zón. Konkrétně doporučuje, aby se jméno autoritativního serveru shodovalo se jménem domény (a nebyl pro ně záznam A ani AAAA), stejné jméno bylo uvedeno v SOA jako primární server a kontakt v SOA byl nobody.invalid. Implementace se od doporučení odchylují (např. zde BIND používá jako server localhost), nicméně platí, že obsah SOA a NS je neobvyklý a umožňuje rozpoznat tuto nestandardní odpověď.
AS112
Díky RFC 6303 a jeho implementaci v současných DNS programech by reverzních dotazů na lokální adresy mělo postupně ubývat. Praxe se s teorií bohužel poněkud rozchází. Cílem projektu AS112 je, aby napáchaly co nejméně škod a byly zodpovězeny pokud možno blízko svého vzniku.
Základní myšlenka je celkem jednoduchá: Vytvořit síť autoritativních serverů pro inkriminované domény a adresovat je anycastově. Všechny tedy mají stejnou adresu a směrování se postará, aby byl dotaz doručen nejbližšímu exempláři. Název AS112 vychází z čísla autonomního systému, do nějž jsou tyto adresy zařazeny a jehož prostřednictvím jsou šířeny informace o jejich směrování.
Podrobně je fungování AS112 popsáno v RFC 7534. Servery jsou dva a mají jména blackhole-1.iana.org a blackhole-2.iana.org. Starají se především o domény řešící reverzní dotazy na adresy podle RFC 1918, tedy domény 10.in-addr.arpa, 168.192.in-addr.arpa a spol.
Snahou je, aby se chovaly zcela podle standardů DNS. Příslušné domény jsou jim z in-addr.arpa regulérně delegovány a pokud se některého z nich zeptáte třeba na
dig @blackhole-1.iana.org -x 172.16.1.1
odpoví vám spořádaným autoritativním NXDOMAIN, podobně jako lokální server výše. Tentokrát ovšem záznamy SOA a NS obsahují zcela korektní informace. Tazatel si proto vše může standardně uložit do vyrovnávací paměti a pokud bude v brzké době řešit další reverzní dotaz ze stejného adresního prostoru, nebude s ním obtěžovat kořenové servery, ale obrátí se rovnou na jeden z blackhole. Příslušné NS záznamy mají životnost týden, takže vydrží ve vyrovnávací paměti báječně dlouho.
Jedinou nestandardností je ono anycastové adresování. Díky němu lze vybudovat libovolně hustou síť serverů, aby nesmyslné dotazy necestovaly sítí dlouho a neužíraly zbytečně přenosové kapacity. Ideálním umístěním pro ně jsou peeringová centra, kde jeden server bezbolestně obslouží řadu poskytovatelů. NIX.CZ takový provozuje, v současnosti zodpovídá kolem 200 dotazů za sekundu. Dokonce se jedná o nejstarší DNS anycast ve střední Evropě.
Na seznamu AS112 serverů žádný další z České republiky nenajdete, což ale neznamená, že neexistuje. Koordinace správců je spíše volná a pokud například některý poskytovatel uvede do provozu AS112 server pro své zákazníky, nemusí o tom nikomu dávat vědět (i když se to doporučuje).
Novinka: DNAME
Výše popsaným způsobem funguje AS112 už řadu let. Nedávno vydané RFC 7534 a zejména RFC 7535 ovšem otevírá novou možnost – kdokoli může libovolnou část svého DNS prostoru převést do kompetence AS112 polykačů pomocí záznamů typu DNAME.
Tento typ DNS záznamů původně vznikl ve spojitosti s alternativní konstrukcí reverzních domén pro IPv6. Ta byla později opuštěna, nad DNAME se dlouho vznášely otazníky, nicméně RFC 6672 jej vrátilo do hry a v současnosti je velmi slušně podporován (podle měření zmiňovaných v příloze RFC 7535 je zvládne přes 98 % klientů).
V podstatě se jedná o CNAME hromadného ničení. Zatímco CNAME zavádí přezdívku pro jedno jméno, DNAME dělá totéž pro celý podstrom – nahradí koncovku libovolného jména jinou.
Ilustrujme si to na příkladu. Řekněme, že root.cz by chtěl přejít na doménu koren.iinfo.cz a po přechodnou dobu udržovat obě domény, aniž by byla zónová data zdvojena. Dalo by se to zařídit vložením záznamu
root.cz. DNAME koren.iinfo.cz.
do domény root.cz. Když pak bude někdo hledat řekněme www.root.cz, dopracuje se až k serveru domény root.cz, který mu pošle inkriminovaný DNAME záznam. Z něj se dozví, že má koncovku root.cz nahradit koren.iinfo.cz. Změní tedy hledané jméno na www.koren.iinfo.cz a začne hledat znovu.
Zmíněné RFC 7535 umožňuje použít tento mechanismus k odeslání libovolné domény do AS112. Zavádí k tomu novou doménu empty.as112.arpa s jediným autoritativním serverem blackhole.as112.arpa. Má jiné adresy než výše uvedené servery, také samozřejmě z rozsahu spadajícího do AS112. Doména je opět prázdná a správci serverů AS112 by ji měli na svých strojích nastavit.
Libovolnou doménu pak lze potopit do AS112 záznamem DNAME, jehož obsahem bude empty.as112.arpa. Řekněme, že bychom chtěli vytvořit prázdnou doménu void.root.cz. Pak stačí do domény root.cz přidat záznam
void DNAME empty.as112.arpa.
Kdyby pak někdo hledal cosi.kdesi.void.root.cz, dopracuje se při hledání do domény root.cz, od jejího serveru dostane DNAME záznam, změní hledané jméno na cosi.kdesi.empty.as112.arpa a bude pokračovat v hledání. Od serveru domény empty.as112.arpa se pak dozví, že takové jméno neexistuje.
A k čemu je to dobré? Upřímně řečeno, zatím je varianta s DNAME určena spíše „na pozorování“. Autoři RFC 7535 uvádějí, že potenciálními kandidáty na její použití jsou všechny domény uvedené v RFC 6303. Nicméně zatím se bude postupovat opatrně a zejména na provozu reverzních domén pro adresy z RFC 1918 se nebude nic měnit. Teprve pokud praxe ukáže, že DNAME nezpůsobuje problémy, bude se uvažovat o případném zrušení stávajícího uspořádání domén 10.in-addr.arpa a spol a jejich převedení na DNAME. Ale na to si rozhodně dost počkáme.
ČLÁNKY DO MAILU