DNS / Infrastruktúra
A domainnév egy kérdés.
Úgy gondolsz a domainnevedre, mint a fix helyedre az interneten, pedig az valójában csak egy kérdés. Minden látogatáskor ez a kérdés fut végig egy láthatatlan láncolaton: csupa olyan idegen gépen és szolgáltatón keresztül, amelyeket nem te irányítasz. A domained bármelyik láncszemnél elnémulhat. A válaszadó szervert fojtogathatja egy túlterhelés, egy technikai hiba kivonhatja a hálózatból, a névfeloldást meghamisíthatják, vagy a regisztrátornál csendben átírhatják a rekordjaidat.
Ezerszer leírtad, begépelted már.
A névjegykártyádon szereplő domainnevet. A címsorba írt webcímet. Az @ jel utáni részt.
Úgy gondolsz rá, mint egy állandó helyre. Mintha ott „lakna” a weboldalad, ahogy egy épület áll egy utcai házszám alatt.
Pedig nem.
A domainneved egy kérdés.
Valahányszor valaki el akar érni, a gépe hangosan felteszi ezt a kérdést, és várja, hogy valaki válaszoljon rá. A böngésző önmagában nem tudja, hol található a weboldalad. Megkérdez egy névfeloldót (resolvert), amelyet többnyire a látogató internetszolgáltatója vagy egy nyilvános hálózat üzemeltet. Mivel a névfeloldó semmit sem tud, továbbkérdez egy gyökérszervert (root server): ki kezeli az ilyen végződésű neveket?
A DNS gyökérzónáját tizenhárom név szerint azonosított gyökérszerver szolgálja ki, és tizenkét szervezet üzemelteti őket több mint ezer fizikai gépen. Az egyikük válaszol, majd megmondja, merre kell tovább keresni. Ezután a névfeloldó megkérdezi a domainvégződést kezelő nyilvántartót (registryt). Ők működtetik például a .com, a .hu vagy éppen az általad választott végződés rendszerét. A nyilvántartó végül a te névszervereidhez irányítja a kérést. Csak a lánc legvégén érkezik meg a konkrét válasz: ez az IP-cím, ide kell menni.
Ez a folyamat minden egyes látogatáskor lezajlik.
A lánc szereplőinek többsége azonban nem a tiéd.
Nem te építetted a root rendszert. Nem te működteted a nyilvántartót. A DNS-feloldást sem te végzed, hanem a látogató által használt névfeloldó. Legfeljebb a lánc utolsó elemét, a névszervert irányítod. És többnyire még azt is csak egy szolgáltatótól béreled.
A rendszer az ősidők óta elvárja, hogy legalább két névszervert adj meg, így az utolsó láncszem nem egyetlen gépen múlik. Azt viszont szinte senki sem ellenőrzi, hogy ez a két szerver ugyanabban az épületben található, ugyanazon a hálózaton fut, vagy ugyanahhoz a felhasználói fiókhoz tartozik.
Ha a redundancia ugyanazon a kritikus hibaponton osztozik, az valójában nem redundancia.
Ezen felül számolni kell a láncolat memóriájával is.
Ha megváltoztatod, hogy a domainneved hová mutasson, semmi sem indul el kifelé a világhálón. Nincs jel, amely végigsöpörne az interneten. Nem létezik központi kapcsoló, amely egyszerre frissíti a globális hálózatot.
Minden resolver egyszerűen megőrzi az utoljára kapott választ a beállított élettartam végéig. Ezt az időt a TTL (Time To Live) határozza meg: egy másodpercekben kifejezett érték, amelyet te állítasz be előre.
Ha ezt egy napra állítod, akkor egy délben elkövetett hibád még éjfélkor is ott kísért a gyorsítótárakban. Ha viszont öt percre, akkor egy kávé elfogyasztása alatt átmozgathatod a teljes online jelenlétedet.
A TTL tehát már előre meghatározza, milyen gyorsan jut el egy változtatás a felhasználókhoz.
Az interneten semmi sem „terjed szét”. Egyszerűen csak lejárnak a régi válaszok.
A körültekintő rendszermérnök éppen ezért csökkenti a TTL értékét napokkal egy migráció előtt, jóval az éles beavatkozás kezdete előtt. Ez a főkapcsoló ugyanis csak akkor ér valamit, ha időben állítod át.
A névfeloldást végző resolvert nem te választod ki, hanem a látogatód – vagy az internetszolgáltatója.
Ma már rengetegen néhány nagy nyilvános resolveren keresztül érik el az internetet. Ilyen a Google 8.8.8.8-as vagy a Cloudflare 1.1.1.1-es szolgáltatása, esetleg az a szerver, amelyet a készülékük vagy az internetszolgáltatójuk alapértelmezésként használ.
Az, hogy a látogatód milyen gyorsan kap választ, mennyire friss információt lát, vagy egyáltalán eljut-e hozzád, teljesen láthatatlan, általad nem befolyásolható gépektől függ.
Amíg minden működik, ebből semmit sem veszünk észre.
Amikor viszont elromlik a gépezet, rendszerint mindenki számára egyszerre omlik össze.
Történt már ilyen összeomlás, méghozzá nagyon emlékezetes módon.
2016. október 21-én támadók eltérített kamerákból és bébiőrökből álló botnetet irányítottak egyetlen DNS-szolgáltatóra, a Dynre. Európában és Észak-Amerikában a felhasználók órákon át nem érték el a Twitter, a Spotify, a Reddit, a PayPal, a Netflix és a GitHub oldalait.
Pedig ezekkel a cégekkel semmi gond nem volt.
Szervereik hibátlanul működtek. Nem álltak le.
A kérésük egyszerűen válasz nélkül maradt. A válaszadó gépet ugyanis értelmetlen forgalommal temették maga alá a támadók.
Öt évvel később a hiba az ellenkező irányból érkezett. 2021. október 4-én a Facebook egyik rutinszerű karbantartási művelete véletlenül leválasztotta a vállalat adatközpontjait a saját gerinchálózatáról. A Facebook névszerverei ekkor a beépített protokoll alapján azonnal kivonták magukat az internet útválasztási térképéről, amint elvesztették a kapcsolatot az „otthonukkal”.
A vállalat saját megfogalmazása szerint a szerverek elérhetetlenné váltak, annak ellenére, hogy fizikailag továbbra is működtek.
A Facebook, a WhatsApp és az Instagram nagyjából hat órára teljesen letörlődött az internetről. Nem támadás érte a válaszadókat. Egyszerűen saját magukat radírozták le a térképről, így senki sem tudta többé, hol tegye fel nekik a kérdést.
A hiba odáig fajult, hogy még a Facebook mérnökeit is kizárta a helyreállításhoz szükséges belső rendszerekből. Eközben a világ minden tájáról érkező újrapróbálkozások áradata megterhelte a nyilvános resolvereket is, és a DNS-forgalom a többszörösére ugrott.
Az egyik esetben a válaszadó szerver belefulladt a túlterhelésbe.
A másikban egyszerűen köddé vált.
A végeredmény azonos: a világ legnagyobb vállalatainak domainnevei mindkét esetben elnémultak.
Ami a legrosszabb: a válasznak még csak igaznak sem kell lennie.
A névfeloldó mindent elhisz, amit mondanak neki.
Az eredeti DNS-protokoll minden lekérdezést mindössze egy 16 bites azonosítóval védett. Ez nagyjából 65 ezer lehetséges értéket jelent, ami megdöbbentően kevés. Megfelelő sebességgel próbálgatva egy külső támadó könnyedén kitalálhatja.
2008-ban Dan Kaminsky biztonsági kutató megmutatta, miként lehet e gyenge pont kihasználásával hamis választ csempészni egy resolver gyorsítótárába, hogy aztán tartósan ott is maradjon. Ezzel elérte, hogy egy teljesen legitim domain egy támadó által irányított szerverre mutasson.
Az iparág még aznap kiadta a javítást. Ez a folt azonban inkább csak megnehezítette a találgatást, a valódi problémát nem szüntette meg.
A tényleges megoldást a DNSSEC jelenti.
Ez a rendszer kriptográfiai aláírással látja el a válaszokat, így a resolver meg tudja különböztetni a valódit a hamistól.
Több mint tizenöt év telt el, és a mindennap használt domainek többsége még mindig nem kapott ilyen aláírást.
Ezekben az esetekben a lánc továbbra is a vak bizalomra épül: aki először válaszol, és kellően meggyőző, annak hisznek.
Ebben rejlik a láthatatlan fenyegetés.
Valaki más is válaszolhat a nevedben. A látogatód gépének pedig esélye sincs ezt felismerni.
Létezik azonban egy láncszem, amely mindezeknél mélyebben húzódik.
A láncolat minden egyes válasza egy egyszerű rekordként kezdi az életét. Valaki beállítja egy felhasználói fiókban, a regisztrátoránál vagy a nyilvántartó rendszerében.
Aki megszerzi a hozzáférést ehhez a fiókhoz, annak semmit sem kell megtámadnia. Már a forrásánál megváltoztatja a választ. Az internet pedig gépiesen, engedelmesen terjeszteni kezdi az új információt.
2019-ben az ICANN épp egy ilyen összehangolt támadássorozatra figyelmeztetett. A támadók a célba vett nevek mögötti rekordokat írták át, hogy eltérítsék a forgalmat. Egyetlen szervert sem kellett feltörniük. A választ egyszerűen átírták ott, ahol azt a tulajdonos rögzítette.
Az online jelenléted egyetlen sérülékeny láncolat. Ráadásul a láncszemek közül szinte egyiket sem tartod a kezedben.
A döntéshozók örömmel vásárolnak redundanciát mindahhoz, ami a szemük előtt van.
Két betáp. Két adatközpont. Tartalék sávszélesség.
A minderre mutató domainnév viszont gyakran egyetlen szolgáltatónál fut, és egyetlen fiókhoz kötődik. Egyetlen jelszó védi, és tartalék nélkül, magányosan adja a válaszokat.
A vállalat egyik legkritikusabb eleme sokszor éppen ott marad védtelen, ahová senki sem tekint.
Ha már átlátod a lánc működését, a teendő hálátlan, de rendkívül konkrét.
Használj egynél több DNS-szolgáltatót. Így az egyikük üzemzavara nem rántja magával azonnal a te rendszeredet is.
A regisztrátori és nyilvántartói fiókokat védeni kell – a szervereknél is szigorúbban. Ezek jelentik a rólad szóló válaszok ősforrását.
Aktiváld az összes létező védelmi funkciót. Követeld meg a többfaktoros hitelesítést. Olyan kapcsolattartói e-mailt adj meg, amely nem szűnik meg egy kolléga felmondásával.
Kísérd figyelemmel a domain lejárati dátumát. Kezeld ugyanolyan fegyelemmel, mint a havi bérkifizetéseket. A lejárt nevekre perceken belül lecsapnak az erre szakosodott vadászok.
A TTL értékét a költözés előtt csökkentsd, sohasem utána.
Tudd pontosan, melyik idegen szerver beszél a nevedben. Legyél tisztában azzal is, kinek van jogosultsága megváltoztatni ezen szerver szavait.
Ezek nem titkos varázslatok.
A felelős üzemeltetés alapkövei.
A névjegyeden szereplő domainnév sosem egy konkrét helyet jelentett.
Csupán egy ígéretet.
Azt ígéri, hogy amikor egy idegen gépezet kérdést tesz fel rólad, valaki válaszol a nevedben.
Az egyetlen dolog, ami igazán számít: kire bíztad ezt a válaszadást.
És vajon azon a napon, amikor ezt a hangot elnyomják, elnémítják, meghamisítják vagy csendben átírják, marad-e még egyáltalán bárki, aki képes helyetted válaszolni.