A net szívcsakrája – a DNS

Amikor a DNS kerül szóba, nagyon sokaknak hirtelen csak az jut eszébe, hogy rendszerint az internet telefonkönyvéhez hasonlítják durva egyszerűsítéssel, mivel a DNS az egyik, ami elengedhetetlen ahhoz, hogy a gépek és szolgáltatások megtalálják egymást a neten. Holott még ennél sokkal többről van szó!
Való igaz, hogy a DNS szolgáltatás teszi lehetővé, hogy egy adott hosztnévhez  tartozó IP-cím vagy IP-címek azonnal megtalálhatóak legyenek a neten, a levelezőrendszerek tudják, hogy adott hosztnévvel végződő emailt milyen gépen keresztül kell kézbesíteni, és így tovább, a DNS messze nem valami száraz és unalmas téma, sőt! Ha hirtelen meg kellene neveznem üzemeltetés szempontjából néhány történelmi fordulópontot a DNS történetében, kettőt emelnék ki.
Már a net hajnalán többen tapasztalhatták, hogy a webhelyüket és levelezésüket is hosztoló szolgáltató DNS szerverei esetleg túlságosan lassan válaszolnak, ami pedig még rosszabb, a DNS szerverek lehalása esetén az általuk kezelt domainek egyszerűen leesnek a netről. Ekkor többen úgy gondolták, hogy érdemes valamilyen bombabiztosra váltani, amire ingyenes megoldást jelentett a  Namecheap Free DNS szolgáltatása. A Namecheap ingyenességében nem volt semmi csalás vagy rejtett költség, a Namecheap üzleti modelljének alapja vélhetően az volt, hogy ha a felhasználók látják, hogy az ingyenes DNS szolgáltatásuk jó, akkor például domain nevet is náluk fognak regisztrálni, ami be is jött. A free DNS szolgáltatással kapásból 5 névszerver beállítására volt lehetőség, amik már akkor bonyolult CDN-szerű rendszereken futottak, amikor még nem is így hívtuk őket.
Igaz, voltak, akik azt tapasztalhatták, hogy a .hu-s TLD-vel rendelkező domainjükhöz nem tudják beállítani a Namecheap DNS szervereit a magyar ISZT példátlanul szigorú, rugalmatlan és több ponton ésszerűtlen korlátozása miatt, amik a névszerverekkel kapcsolatban fogalmaztak meg feltételeket. Ezeket a szabályokat még a net hajnalán fektették le, a cél éppenséggel nemes volt, csak izomból nem lehet kényszeríteni a tömeget, hogy csak olyan technikai megoldást alkalmazzanak valamivel kapcsolatban, amiről egy szűk kör eldöntötte, hogy csakis az lehet megfelelő. A névszerver szolgáltatásnak elvben teljesen függetlennek kell lennie például attól, hogy ki a regisztrátor.
A második nagy áttörést a Cloudflare jelentette, amelyik rendkívül egyszerűen beállítható, az alapfunkciói ingyenesek és gyakorlatilag eltüntette az egy-egy rekord átírásához kapcsolódó átfutási időt azzal, hogy a CDN-jeivel gyakorlatilag mindenhol ott van. Alighanem többen nem tudják, de a Cloudflare éppen egy éve, Magyarországon is jelen van egy rakás szerverrel a BIX 20 GB-s peering partnereként és láthatóan kell is, hogy legyen: a BIX forgalmi statisztikái szerint ugyanis a teljes forgalma, egy hazai netszolgáltató forgalmához hasonlítható, ami persze nem csak a DNS-kérések kiszolgálásából adódik. A Cloudflare le is tarolta a piacot szerte a világon, éppen az egyszerűsége miatt, az esetek többségében megfelel a célnak, viszont bizonyos rekordtípusokat, amikre szükség lehet, a mai napig nem támogat, ugyan éppen ezért kevésbé is lehet egy-egy beállítást véletlenül elrontani.
Aki igazán ínyenc módon szeretné megoldani a saját domainjéhez tartozó zóna kezelését és freemiumot is kínáló alternatívára után néz, annak érdekes lehet a szintén piacvezetők közt lévő, de Cloudflare-hez képest kevésbé ismert NS1. Nem nagyon van más DNS-szolgáltató, amelyik egyáltalán azt mutatná, hogy mennyi lekérdezés történt összesen vagy egy-egy DNS-rekordot nézve, ráadásul úgy, hogy még azt is mutatja egy térképen, hogy honnan jöttek a kérések.
Ez több, mint érdekes lehet egy felhőbe burkolt világban, már nem a 90-es években vagyunk, nem lehet azt mondani, hogy ha főleg Magyarországról nézegetnek egy webhelyet vagy arra a domainre küldenek email-t, akkor a kérések döntően Magyarország felől záporoznak. A magyarázat a CDN-ek, load balancerek lelki világában keresendőek, ezek üzemeltetői viszont nem teszik ki a kirakatba, hogy pontosan hogyan is működnek.
A NS1 professzionális voltához tartozik, hogy pontosan naplózva van, hogy mikor mit állítottunk át mire, ezen kívül számos olyan rekordtípust támogat, amit a többi szolgáltató nem.
Ezen kívül van olyan sajátossága, ami különösen nagy forgalmú oldalak esetén lehet fontos teljesítmény szempontjából, mégpedig az, hogy rekordonként beállítható, többek közt az, hogy melyik földrajzi régióból várható a legtöbb kérés, a szolgáltatás annak megfelelően fog optimalizálni és minél gyorsabban kiszolgálni a kérést. Vagy éppen drasztikus módszer ugyan, de teljes AS-eket tiltólistára lehet tenni, amik felé az NS1 egyáltalán nem fog válaszolni egy domainnel kapcsolatban. Drasztikus módszernek tűnik, viszont nem elképzelhetetlen olyan szituáció, amikor éppen ezzel fékezhető meg DDoS egy olyan világban, ahol a feketepiacon viszonylag olcsón elvben bárki bérelhet olyan botnet hálózatot, amelyik adott domain és amögötti szolgáltatások ellen intéz támadást.

 

Tudható, hogy a DNS-szolgáltatók piaci részesedése rendkívül egyenetlen és fontos tudni, hogy alapvetően azért senki ne piszkáljon zónafájlt anélkül, hogy tudná, mit is csinál pontosan, ezen kívül egy-egy módosítást követően fontos, hogy az újonnan megadott értékeket tényleg betűről betűre ellenőrizzük, különben kellemetlen meglepetések érhetnek. A Namecheap ingyenes és fizetős verziójában is egy textbox máig maximálisan 255 karakter hosszúságú adat vihető be, ami elegendőnek is tűnik. De csak annak tűnik. A mai ajánlások szerint a levelek aláírásához legalább 2048 bites DKIM kulcsot érdemes használni, amit ha vágólapra másolunk, majd beillesztjük a Namecheap DNS vezérlőpultjában, el is menjük, az Namecheap egyáltalán nem figyelmeztet azzal kapcsolatban, hogy a kulcs második felét egyszerűen levágta.
Aki manapság egy szervezetnél DNS-t konfigurál, esetleg saját DNS-szervert üzemeltet, érdemes lehet megfontolni egy jobb üzemeltetői tanfolyam elvégzését, így érthetővé válik, hogy mi is történik a motorháztető alatt egy olyan szolgáltatás esetében, ami az eredeti formájához képest talán a legnagyobb változáson ment keresztül.

Szemléletmódváltás vagy halál?

A legkülönbözőbb területeken lassan már nem is az lesz a kérdés, hogy egy-egy eszköz okoseszköz-e, valamint csatlakozik-e valamilyen módon a nethez, hanem az, hogy mennyire képes egyáltalán működni smart-funkciók és net nélkül, már ha ezek egyáltalán elválaszthatók.

Az egészségügyben az egészen egyszerű vagy annak tűnő eszközöktől az egészen bonyolult diagnosztikai eszközökig minden gyártó követte vagy egyenesen diktálta a trendet, legyen szó vezeték nélküli kapcsolattal ellátott pacemakerekről és inzulinpumpákról, amikkel kapcsolatban a biztonsági aggályok már évekkel ezelőtt bejárták a világsajtót. Nem kérdés, hogy egy-egy ilyen eszközön még a firmware frissítés is rejt magában rizikót. Az orvosi képalkotó diagnosztikában természetesen adta magát az igény arra, hogy a kapott adattenger minél egyszerűbben elérhető legyen PC-n is, ahogy pedig az lenni szokott ilyenkor a gyártók egyrészt nem szeretnének lemaradni a versenytársaikhoz képest, szeretnének minél több kényelmi fícsört beépíteni, igen, még olyan áron is, ha a fejlesztés közben a biztonságból kell engedni.
Nemrég jelent meg a TheHackerNews cikke, ami szerint a támadók kimondottan röntgen-gépeket és MRI gépeket támadtak, ezen kívül sejthetően a gyártók IT-infrastruktúráját.
Több fejlesztő és fehér kalapos hekker előszeretettel hülyézi le azokat a fejlesztőket, akik egyszerűen nem szokták meg, hogy a secure coding valóban fontos, pontosabban lassan más típusú fejlesztésről nincs is értelme beszélni kicsit is komoly helyen.
A programozás, ha úgy tetszik nyelvhasználat. A natív nyelvhasználatnak, azaz ember-ember kommunikációnak pedig általános sajátossága, hogy nem kérdőjelezzük meg más szavahihetőségét, amíg erre nincs alapos okunk. A programozáskor a fejlesztő meghatározza, hogy a gépnek mit kell vagy kellene csinálnia, részletkérdés, hogy bizonyos programozási nyelvek esetén ugyanazt a feladatot minél kevesebb féle módon lehet lekódolni, mint a Pythonban vagy éppenséggel nagyon sokféle módon, mint a Perl-ben. De az eredeti paradigma szerint a fejlesztő fejleszt, tesztel, majd elhiszi, hogy a kód csak úgy működhet, ahogyan azt megírták. Miért? Mert a bizalomközpontú ember-ember kommunikációból indult ki a fejlesztő, amikor lefejlesztette azt, amit kellett.
A metaforát folytatva, a fejlesztésre alkalmazva sokáig azért nem foglalkoztak egyáltalán azzal a fejlesztők, hogy az alkalmazás vagy szolgáltatás megfelelő bemenetet kap-e, mert nem feltételezték, hogy esetleg lesz valaki, aki majd olyan bemenetet küld, amin keresztül akár az operációs rendszer szintjén valami nagyon kellemetlen dolog történik, például.
Csakhogy az éles szoftverfejlesztés és az internet természete más, bizonyos értelemben éppen fordítottja az ember-ember kommunikációnak.  Az elektronikus levelezés nagyon jó példa a netes szolgáltatások természetének megértésére. A spamek és phishing ellen vívott küzdelemben eredeti formájához képest technikai téren az emailezés teljesen megfordult: egészen addig feltételezik a levelezőrendszerek, hogy az email hamis, amíg sok-sok kifinomult lépésen keresztül nem bizonyosodik meg róla címzett, hogy hiteles.
Hasonló trend, ami szerint ha gépekről van szó, semmi sem hiteles, amíg nincs hitelesítve avagy a megfelelősége tesztelve, a fejlesztés és üzemeltetés területén markánsabban vagy kevésbé, de mindenhol ott van ugyanez.
Azaz az információáramlás natív természetével, az ember-ember kommunikációval ellentétben amikor az ember mondja meg a gépnek, hogy mit csináljon a fejlesztésen keresztül,  mindegy, hogy egy apró webappról, egy levelezőrendszerről az internet valamelyik elemi szolgáltatásáról van szó, a gépeknek, a fejlesztőnek és az üzemeltetőnek azt kell feltételezniük, hogy az információ vagy egy működés nem fogadható el hitelesnek, amíg több mechanizmus nem igazolta, hogy valóban az.
Alighanem mindenki találkozott már azzal a védhetetlen véleménnyel, hogy “hozzánk minek akarnának betörni” vagy éppen egy szoftverrendszer jó úgy, ahogy van, elkészült időre, holott annak kellene általános gyakorlatnak lennie, hogy a fejlesztést követően több tesztelési metodikát is bevetve igazolható legyen az elvárható szintű stabilitás és biztonság.
Persze, hogy lesznek többen a piacon, akik függetlenül attól, hogy inzulinpumpát, röntgengépet vagy lélegeztetőgépet gyártanak, amik a maguk módján okoseszközök, például lehetővé teszik a vezeték nélküli firmware-frissítést, a gyártók engedve a kisebb ellenállásnak, fejlesztés közben a biztonságra és a tesztelésre fognak a legkevesebb figyelmet fordítani.
Természetesen függően attól, hogy milyen eszközről van szó, más előírásoknak kell megfelelnie egy inzulinpumpának és egy intenzív betegellátásban vagy aneszteziológiában használatos lélegeztetőgépnek, a lényeg viszont ugyanaz: ha a fejlesztők nem szakítanak a korábbi megszokással és a kódolás nem lesz eleve biztonságos kódolás, annak beláthatatlan következményei lesznek.
Kevesen tudják, hogy ami sokak számára sci-fi, az a gyógyszergyártásban már a jelen, a gépek szemet kápráztató sebességgel és pontossággal teszik a dolgukat, egyre kevesebb emberi felügyelet mellett. Ahogy az az iparágnak megfelelően megkövetelhető, rendkívül szigorú szabályok vannak ugyan, de az elvi lehetőségét nem zárhatjuk ki annak, hogy sosem hakkolnak meg egy robotot például egy patkolt filmware-rel. Márpedig ha egy high-tech robot egy-egy hatóanyag ezerszeresét adagolja a készülő gyógyszerkészítménybe, ráadásul úgy, hogy azt ne is lehessen észrevenni rutinszerűen, tragikus következményekkel járhat.
Végül megjegyzem, még ha eléggé biztonságosan is működnek az atomreaktorok PLC-i, a légi forgalomirányításban használt valós idejű rendszerek, sokkal gyorsabban árasztanak el az okoseszközök, minthogy ahhoz a végfelhasználók hozzá tudnának szocializálódni vagy a jogalkotók eléggé gyorsan tudnának megfelelő kontrollokat beépíteni.

J. A. után szabadon azt írnám, hogy programozni és tesztelni csakis szépen, ahogyan a csillag megy az égen, úgy érdemes, úgy szabad.

kép: Alibaba