Ha van, amiről mindenki beszél, elvben már mindenki fel van rá készülve, mégsem merik bevezetni az internetes szabványok közt, az IPv6 mellett a DNSSEC ott a dobogón. Ugyan a DNSSEC többek szerint kimondottan ellenjavallt és a rendelkezésre állást súlyosan veszélyezteti, tény, hogy a domainekhez tartozó zónafájlok rekordjainak hitelesítése nagyban fokozná a teljes internet biztonságát, amihez viszont több dologra elemi szükség lenne:
0x100. egyrészt arra, hogy a DNS hoszting szolgáltatók, a resolverek és a kliensek kivételesen pontosan tartsák magukat az IETF által rögzített vagy ajánlott szabványokhoz - ilyen szabvány vagy szolgáltatás viszont gyakorlatilag máig nem született a net történetében
0x200. mivel ma már egyre ritkább esetben történik parancssoros környezetben valamilyen IT-szolgáltatás beállítása, a DNS-hoszting szolgáltatók felelőssége lenne egyértelművé tenni, hogy _pontosan_ mi is történik, amikor a végfelhasználó valamit webes felületen keresztül - pl. a Cloudflare zónaszerkesztőjében állít be
A Cloudflare még 2015-ben jelentette be, hogy általánosan támogatni fogja a DNSSEC-et, az ügyfeleknek tényleg nincs más dolga, csak rátaposni a bekapcsolás gombra, illetve a regisztrátornál megjelölniük, hogy a domainjük DNSSEC-et használ, és egészen pontosan milyen módon - a Cloudflare a mai napig csak az ECDSA-t támogatja az erőforrásrekordok hitelesítéséhez. A DNSSEC-et támogató regisztrátoroknál, mint amilyen a Namecheap, szinte hülyebiztosan beállítható a szükséges DS rekord. A beállításhoz persze nem árt alaposan ismerni a DNSSEC-természetét, a beállítás tényleg nem volt több a saját domainem esetén néhány percnél. A beállítás helyessége pedig a https://dnssec-debugger.verisignlabs.com/ és a http://dnsviz.net/ oldalakon keresztül seperc alatt ellenőrizhető.
Mindez roppant szép és jó, de azonnal kiderül belőle, hogy a Cloudflare a domain A, MX, SOA, NS és TXT rekordjait írja alá, naivan úgy gondolhatnánk, hogy az aldomainek esetén hasonló a helyzet. A Cloudflare az aldomaineknél csak az A-rekordot írja alá, van viszont egy sokkal súlyosabb probléma is. Abban az esetben, ha egy aldomain kezelését egy aláíratlan NS-rekord megadásával másik névszerverre bízzuk, amelyik már nem irkál alá semmit, naivan úgy gondolnánk, hogy ez egyértelműen jelzi a resolver felé, hogy onnantól már nem kell ellenőrizni a DNSSEC-et. Ehelyett az történik, hogy a DNSSEC szerves részét képző NSEC, NSEC3, NSECPARAM rekordok miatt a felsőbb szintű névszerver azt fogja jelezni a resolver felé, hogy az adott domain biztosan nem létezik!
Ilyennek pedig egyenes következménye, hogy az érintett aldomain leesik a net azon részéről, ahol be van állítva, hogy a resolver ellenőrizze az zónarekordok RRSIG aláírásait, ha pedig igen, foglalkozzon-e vele vagy sem.
A probléma nem csak az, hogy a Cloudflare nem hívja fel a figyelmet arra, hogy az aldomainek NS-rekordjait nem írja alá, ami pedig már logikus, hogy onnantól kezdve más névszerver által kezelt aldomainek érvénytelennek lesznek nyilvánítva. Hanem az, hogy a regisztrátor Namecheapnél konkrétan csetes supportot kellett kérni a DS-rekord eltávolításához, addig nem engedte a Cloudflare az egész DNSSEC-et kikapcsolni, holott két piacvezető szolgáltatóról van szó.
A problémát relatív gyorsan azonosítottam, de akkor is sikerült úgy lábon lőnöm magam, hogy 61 percig az érintett aldomain nem csak, hogy elérhetetlen volt az erre érzékeny resolvereket használó gépek felé, de még az is bekerülhetett néhány gyorsítótárba, hogy biztosan nem létezik. Ez viszont nem derül ki azonnal egy megszokott dig lekérdezéssel, ha nem adjuk meg, hogy a DNSSEC-et is ellenőrizze és egy olyan resolvert, ami nem gyorsítótárból dolgozik és fel van készítve a DNSSEC-re, azaz a hagyományos lekérdezés alapján semmilyen hibát nem fogunk észlelni.
Na most ha valaki nem ír rá szkriptet, hogy a
dig MX +additional +multiline +dnssec dnsviz.net. @8.8.8.8
fusson le valami megbízható helyen percenként és riasszon valamilyen módon olyan esetben, ha az aláírással para van, akkor teljes aldomainek vagy domainek eshetnek le a netről olyan módon, hogy azt az admin észre sem veszi. Ráadásul a fizetős uptime monitoring toolok többségében sincs olyan beállítás, ami a DNSSEC-et is figyelembe venné. Külön szép az egészben, hogy a regisztrátornál megadott DS TTL értékébe nem lehet belenyúlni, azaz a kikapcsolást követően is ideig-óráig a domain vagy látszik vagy sem.
Persze, lehet azt mondani, hogy aki nem parancssori környezetben állít be valamit, ami azért feltételezi, hogy az admin tudja, hogy mit csinál, az megérdemli, ez már egyre kevésbé életszerű. A DNS-hoszting szolgáltatók eleve nem is adnak SSH-t, másrészt tömegigényt kell kielégítenie, azaz minél inkább bolondbiztos, hibákra is figyelmeztető webes felületeket biztosítani ezen a területen is, hogy az ügyfelek kevesebb tudással is be tudják állítani, amit szeretnének úgy, hogy minél ritkábban kelljen supportot kérni. Azaz hasonlóan, mint az egyszerű webhoszting szolgáltatók esetén, ahol alapértelmezés szerint az SSH le is van tiltva. Nagycéges környezetben persze más a helyzet, de az IT-sek érhető módon mindenhol az olyan megoldást fogják előnyben részesíteni, amihez tartozik pofás webes felület.
Összességében: a világ sokmindenre megérett már, de hogy a DNSSEC tömegessé válására nem, az biztos.
