DNSSEC: érvek s ellenérvek

DNSSEC: érvek s ellenérvek Pásztor Miklós, ISZT/PPKE Dunaújváros, 2008. március Tartalom DNSSEC motiváció, elv, érvek, ellenérvek 2 DNS m ködés.............................................. 2 Milyen veszélyek fenyegetnek?.................................. 2 A nagy mumus: phishing, pharming.............................. 3 A DNSSEC elve............................................ 3 Bevezetünk új rekordokat.................................... 4 A DNSSEC kriptográa sajátosságai.............................. 5 Hogyan épül a bizalmi lánc?................................... 5 Kulcs rekord............................................ 5 Aláírás............................................... 5 Hogyan tudjuk aláírni a nincs ilyen üzenetet?........................ 6 Biztonsági kockázat, amit a DNSSEC nyit: DNS walk.................... 6 DS rekord............................................. 7 Bevezetünk új ag-eket a DNS üzenetekben.......................... 7 Mi szól a bevezetése mellett?..................................... 7 Segédeszközök........................................... 8 Példa drill használatra...................................... 8 Ki használ most DNSSEC-et (2008. március)?......................... 8 DNSSEC tudású rezolver, alkalmazás.............................. 9 Mi szól a bevezetése ellen?....................................... 9 A DNSSEC bevezetése nagyon sok változtatást és er forrást igényel............. 9 N a kockázat........................................... 9.hu nídz DNSSEC???......................................... 9 1. Kinek van szüksége DNSSEC-re?............................... 9 2. Kell-e a.hu-ban DNSSEC?.................................. 9 Olvasnivaló 10 1

DNSSEC motiváció, elv, érvek, ellenérvek DNS m ködés Az 1 internet név szerver szolgáltatást, a DNS-t folyamatosan használja minden internet felhasználó: levelezés, web böngészés, fájl letöltés közben mindig nevekkel hivatkozunk az egyes er forrásokra, de az egyes használt programjaink már nem nevekkel, hanem IP címekkel bánnak. Ezért szükség van a név cím kapcsolatok megtalálására, vagyis a DNS szolgáltatásaira. A DNS osztott, hierarchikus adatbázis, ahol a feloldás rekurzívan történik a hierarchián. Ez látható az 1. ábrán: ha egy felhasználó például a www.kedvencbankom.hu web lapot akarja meglátogatni, akkor a gépében futó DNS kliens, a rezolver megkérdezi a felhasználó számára kijelölt caching (látó) név szervert a www.kedvencbankom.hu fel l. Általános esetben ezt a kérdezett név szerver nem tudja magától megválaszolni, hanem a többi mutató (autoritatív) név szerverrel kommunikálva válaszolja meg a kérést. El ször a hierarchia csúcsán lev gyökér (.) név szervert kérdezi. Az nem ad választ a kérdésre, de annyit segít, hogy a.hu alatti nevek esetén milyen név szervereket érdemes kérdezni. Ezek egyikét (vagy akár többet) ismét megkérdezi a látó (caching) név szerver, de a válasz megint csak az lesz, hogy én nem tudom, de a kedvencbankom.hu nevek dolgában ide és ide fordulhatsz. A kedvencbankom.hu név szerverei azután már szolgáltatják a látó név szervernek a kért címet, és ezt aztán a látó név szerver közli a felhasználó PC-jével. Ebben a példában 3 lépést kellett haladni a gyökér név szervert l lefele a hierarchiában. A gyakorlatban 4-5, s t akár több lépés is elképzelhet. A megtanult információt azután a látó névszerver egy bizonyos ideig (jellemz en 1-2 óráig) megjegyzi, cache-eli: nem kérdezi újra, hanem a hozzá forduló klienseknek azonnal válaszol a most megtudott adatokkal. ábra 1: DNS m ködés Milyen veszélyek fenyegetnek? A DNS forgalom, a DNS protokoll könnyen sebezhet, a DNS információk könnyen hamisíthatók. Amint láttuk, több DNS válasz üzenet szükséges ahhoz, hogy például a www.kedvencbankom.hu nevet feloldjuk. Ezen válaszok bármelyike lehet téves, s t nem csak téves, hanem szándékosan, rosszindulatúan hamisított is. Egy imposztor birtokba veheti (akár 1-2 válasz erejéig): ˆ a caching névszerverünket (ami tipikusan az intézmény, vagy a szolgáltató kezelésében van), ˆ bármelyik autoritatív név szervert. 1 A Networkshop-on 2008-ban, Dunaújvároson elhangzott el adás b vített, átdolgozott változata 2

Ilyen birtokbavétel történhet a név szerver gép operációs rendszerének sikeres támadásával, vagy magának a név szerver programnak a sikeres támadásával. A hamis DNS információ azután egy hamis - de az eredetihez hasonló - web laphoz vezethet, és ilyen módon az imposztor az internetez k kárára akár pénzt vehet fel. A károkozásnak más módjai is lehetségesek: a hamisított DNS információ például illegális adatgy jtésre is módot adhat. Ilyen DNS forgalom hamisítást megtehet bárki, aki a kommunikáció útján eszközt/vonalat birtokol. Sokszor nem b nöz k, hanem egy-egy szolgáltató, vagy valamilyen hatóság az, aki ilyen DNS válasz hamisítást végez, hogy - úgymond -, megóvja a felhasználót a veszélyes, tiltott tartalomtól, vagy segítséget nyújtson a hálózat jobb, hatékonyabb használatában. Okunk van arra, hogy kétségbe vonjuk az ilyen eljárás helyességét, és védekezzünk ellene, ahogy tudunk. Újra és újra hírek jönnek arról, hogy szolgáltatók reklámokkal bombázzák a felhasználót, ha elgépel egy URL-t: az ilyen nincs (NXDOMAIN) választ kicserélik a reklámra mutató rekordra. Nagy nemzetközi felháborodást keltett, amikor 2003-ban a Verisign, a gyökér (.) zóna gazdája tett ilyet. Ezt a módszert használják diktatórikus kormányok is: nem csak a nincs ilyen választ, hanem a tényleges választ is kicserélik, ha az olyan tartalomhoz vezet, amit veszélyesnek ítélnek saját hatalmuk szempontjából. Egy másik veszély, ha az imposztor hamis DNS rekordokat csempészik a caching név szerver cache-ébe (cache poisoning). Erre módot ad, hogy egy-egy kérdésre küldött válasz-üzenet nem csak a kérdezett információra adott választ tartalmazza, hanem más úgynevezett authority és additional (járulékos) adatokat is. Ezek hasznosak és szükségesek, ha például a válasz ilyesfajta: A www.valahol.hu-ra vonatkozóan nem tudok felvilágosítást adni, de azt tudom, hogy a valahol.hu dolgában a szerver.isp.hu gépet kell kérdezni, és a szerver.isp.hu címe 11.22.33.44. Ilyen esetben a kedvencbankom.hu NS rekordja és a szerver.isp.hu A rekordja bekerül a kérdez DNS szerver cache-ébe. Lehet arra késztetni a látó név szervert, hogy kérdezze meg mondjuk a valahol.hu név szervereit. Ezek névszervereit birtokolhatja a támadó, aki a valahol.hu-ra vonatkozó válasz járulékos részében hamis információt ad a kedvencbankom.hu név szerverére vonatkozóan. A nagy mumus: phishing, pharming Gyakori és veszedelmes támadás a phishing, az adathalászat. A támadó ilyenkor elhiteti a böngész felhasználójával, hogy mondjuk a www.kedvenc-bankom.hu lapon jár, ehelyett valójában gonosz.utan.zo lapján. Ilyen módon a támadó a felhasználó sok adatát kihalászhatja: személyes adatokat, bankszámlaszámot és így tovább. Phishing áldozatául eshetünk sokféle okból: ˆ Véletlen elgépelés ˆ Cache poisoning ˆ Spam-ben kapott URL ˆ... A pharming támadásnál a DNS-fának nem csak egyetlen levelét, hanem egy egész ágát m velés alá veszi a támadó. Ilyen módon nem csak a www.aldo.zat web lapot látogatók esnek áldozatául, hanem akár több tucat web lap, a domain alatti teljes levelezés stb. A DNSSEC elve Az interneten a böngész k a letöltött web lapok hitelességét és sértetlenségét az SSL/TLS szabvány szerint nyilvános kulcsú titkosítás, digitális aláírás elvének felhasználásával rutinszer en ellen rzik. A hitelesség ellen rzése azon alapul, hogy a böngész gyártója által elfogadott hitelesít - ritkább esetben maga a felhasználó - ellen rizte, hogy az aláíró kulcs - egy bizonyos id ben valóban annak a birtokában volt, 3

akir l/amir l az aláírás állítja. (Zárójelben érdemes megjegyezni, hogy ennek módszernek is vannak hátrányai és korlátai. Lásd pl. 2, 3 és 4 ) A DNSSEC kezdeményezés célja, hogy hasonló technológiát használjunk ne csak web lapoknál, hanem DNS rekordoknál is: ˆ Az egyes DNS rekordokat nyilvános kulcsú digitális aláírással látjuk el ˆ A DNS delegáláshoz hasonlóan, a magasabb szinten aláírjuk a delegált zónában használt publikus kulcsot (DS rekord) ˆ A DNS adat hitelességét és sértetlenségét garantáljuk A gondolat régi. A DNSSEC-r l az els RFC 1997-ben jelent meg: RFC2065. 2000-ben a Networkshopon, Gödöll n szó volt err l: DNS biztonsági kérdések. Ma, (2008. március) az irányadó RFC sorozat: ˆ RFC4033, Introduction and requirements Ez a bevezet dokumentum a DNSSEC elvét és feltételeit tárgyalja ˆ RFC4034, Resource records Ez az RFC tárgyalja az egyes DNSSEC rekordokat ˆ RFC4035, Protocol modications Ez a dokumentum arról szól, hogy milyen protokoll módosításokkal jár a DNSSEC. Ez a három RFC képezi a DNSSEC m ködés alapját, de megjelenésük (2005) óta már több módosító és kiegészít RFC született. Például az NSEC3 rekordról szóló RFC5155, mely éppen 2008. márciusában jelent meg, amikor ez az ismertet készül. Az NSEC3 bevezetése jelent s változásokat hozhat és segítheti a DNSSEC technológia elterjedését. Err l kés bb részletesebben lesz szó. Bevezetünk új rekordokat A digitális aláírás eszközei DNS esetében a dolog természetéb l adódóan maguk is DNS rekordok: ˆ DNSKEY: kulcs, amivel aláírunk DNS rekordokat ˆ RRSIG: egy-egy RRset-hez tartozó aláírás ˆ DS: (Delegated Signer) az apuka zónában a gyerek kulcsát igazoló rekord ˆ NSEC: hitelesen tudjuk mondani: nincs ilyen Az RRSIG rekord szolgál a DNS rekordok digitális aláírására. A DNSSEC egyik f elve, hogy nem röptében keletkeznek az aláírások (az RRSIG rekordok) - mint például az SSL-es web lapok letöltésénél -, hanem akkor, amikor egy-egy rekord bekerül a zónába. Ennek a módszernek nyilván vannak hátrányai - például er sen megnöveli a zóna méretét -, de sok el nye is van: ˆ Az autoritatív név szerverek közül a másodlagos névszerverek sose írnak alá ˆ A másodlagos névszerverek hiteles aláírásokat szolgáltathatnak anélkül, hogy birtokában lennének az aláíró kulcs titkos részének ˆ A rekordok aláírása történhet más gépen, mint ahol a zónát szolgáltatják, így a titkos kulcs nem kell jelen legyen egyetlen névszerveren, vagy akár egyetlen hálózatba kötött gépen sem 2 Ellison C. & Schneier B.: Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure, Computer Security Journal, v 16, n 1, 2000 http://www.counterpane.com/pki-risks.html 3 Eric Rescorla: The Internet is Too Secure Already http://www.rtfm.com/toosecure-usenix.pdf 4 Doris Dietrich: SSL, robuster Protokollentwurf und Angrie http://www.dorisdiedrich.de/ssl.pdf 4

ˆ Az autoritatív név szervereket nem terheli a CPU igényes aláírási folyamat. Az autoritatív név szerverek gyakran így is er s terhelés alatt vannak, nem ritkán percenként több tizezer, vagy még több kérést válaszolnak meg. Az NSEC rekord jelentése és használata külön magyarázatot igényel. A probléma az, hogy nem csak az egyes DNS rekordokat akarjuk aláírni, hanem azt az üzenetet is, melynek tartalma nincs ilyen rekord (NXDOMAIN). Hiszen hiába van aláírva például a www.tutibiztos.hu-hoz tartozó A rekord, ha egy támadó el tudja hitetni, hogy www.tutibiztos.hu nem is létezik! Ezért az ilyen rekord nem is létezik üzeneteket is digitális aláírással akarjuk ellátni. Mivel nem akarjuk az ilyen üzeneteket röptében a kérdés feladásának pillanatában aláírni, szükség van valamilyen el re ismert információra, amit aláírunk, és ami bizonyítja, hogy valóban nincs olyan rekord, mint amit kértek. Természetesen az NSEC rekordhoz is tartozik digitális aláírás, RRSIG rekord. A DNSSEC kriptográa sajátosságai Aki PGP, SSH, vagy TLS kriptográáról hallott, annak meglepetést okozhat néhány dolog. A DNSSEC kriptográában lejárati idejük a kulcsoknak nincs, van viszont az aláírásoknak. Hogyan épül a bizalmi lánc? Ahogy fent már arról szó volt, a DS (Delegated Signer) az apuka zónában a gyerek kulcsát igazoló rekord. A DS rekord a gyerek nyilvános kulcsának a hash-ét tartalmazza. A DS rekord az apuka által aláirandó (tartozik hozzá RRSIG). Kulcs rekord A DNSSEC-ben a nyilvános kulcsokat DNSKEY rekordok tartalmazzák. Íme egy példa: hu. 86400 DNSKEY 256 3 5 ( AwEAAa1ibOSVb1eyX03MwD5414YmIU7ngIu2 6vzE3krs26Mmz4oD3+id5/xQPln3AmUQNWRD ikvr7qkjtolqlrhty2amb/ixona7ypv2sy+c fth5tit7owgnahpg6jcd3ypcxirh2hsh0wot ohhtmzv1ngapqs+sat9vqgndm/a6coof ) ; key id = 51261 Használat szempontjából egy DNSSEC kulcs lehet: ˆ KSK Key Signing Key, viszonylag ritkán változik, hosszú ˆ ZSK Zone Signing Key, viszonylag gyakran változik, nem túl hosszú kulcs Az apuka zónában a KSK-t írják alá (pontosabban a hash-ét), a DS rekordot. A KSK-val a zóna gazdája aláírja a ZSK-t, a ZSK-val az egyes rekordokat. Aláírás Az egyes rekordok aláírása RRSIG (RRset Signature) rekorddal történik. hu. 86400 RRSIG SOA 5 1 86400 20080403123030 ( 20080304123030 51261 hu. faxrvq3g3twb6i5y2wv/heiidg7ixwgqhbx0 DsiOzVqlY7f4Az07HBbhATByxIVMK8zmk3Za i9pt0i9uuygcw0tsvaouyon3kdgo89gowxkd YEa/tl7R52eZn94HsChLKuViwHApIC11B9Wn m3agu1hjbrz3iwot3jhp50uqfcg= ) 5

Amint látható az RRSIG rekord egyik paramétere az a DNS típus, amire vonatkozik az aláírás. Azonos baloldalú és azonos típusú rekordok egyetlen úgynevett RRset-et (Resource Record set) alkotnak. Például SOA rekordból minden zónában egy van, így ez az RRSET egyetlen rekordból áll, de például NS, vagy DNSKEY rekordból több is, és ezeket - ha a baloldalukon ugyanaz áll - egyetlen aláírás védi. Érdemes meg- gyelni a rekordban az alárás keletkezésének (20080403123030) és lejáratának (20080304123030) idejét, és az aláíró kulcs azonosítóját (51261) is. Hogyan tudjuk aláírni a nincs ilyen üzenetet? Az autoritatív név szerverek egyik feladata, hogy arról is értesítsék a rekurzív név szervert és így a felhasználót, hogy pl. az ilyentutihogynincs.valami.hu rekord nem létezik a valami.hu zónában. Az ilyen információ aláírása viszont nem történhet röptében, menet közben egyrészt, mert sok er forrást igényelne, nagyon drága lenne minden nincs ilyen választ aláírni, másrészt rendszerint nincs is az autoritatív DNS szerveren titkos kulcs, különösen a másodlagos név szervereken, de még az els dlegeseken sem: az az ajánlott, hogy az aláírás, a háttérben, egy internetr l nem elérhet gépen történjen: általában ne legyen az internetr l elérhet olyan gép, ahol az aláíró kulcspár titkos részét tároljuk. A megoldás az, hogy a zóna rekordjait, azok baloldalát lexikograkus sorrendbe rendezzük, és az így keletkez intervallumokat írjuk alá. Az intervallumokat az NSEC (Next Secure) rekord deniálja. Íme egy példa: hu. 86400 NSEC 0-24.hu. NS SOA TXT RRSIG NSEC DNSKEY Ez a.hu zónában az els NSEC rekord, ami a zóna elejére vonatkozik. Amint látható, mutatja, hogy ehhez a.hu névhez milyen rekordok tartoznak (NS, SOA, XT, RRSIG, NSEC és DNSKEY), és azt, hogy lexigrakus sorrendben a következ rekord a 0-24.hu. Vegyük észre, hogy ett l minden klasszikus rekordhoz legalább +2 rekord keletkezik: az NSEC rekord és a hozzátartozó RRSIG rekord. Ezáltal a zóna mérete többszörösére n (a csak delegálásokat tartalmazó.hu 7-szeresére) Biztonsági kockázat, amit a DNSSEC nyit: DNS walk Ha NSEC rekordok vannak, akkor hiába tiltjuk a zóna transzfert, az úgynevezett DNS walk segítségével letapogathatjuk a zóna rekordjait: $ldns-walk ripe.net @ns-pri.ripe.net ripe.net. A NS SOA MX AAAA RRSIG NSEC DNSKEY _sip._udp.ripe.net. SRV RRSIG NSEC _stun._udp.ripe.net. SRV RRSIG NSEC adsl.ripe.net. A RRSIG NSEC e0.adsl.ripe.net. A RRSIG NSEC aironet10.ripe.net. A RRSIG NSEC aironet11.ripe.net. A RRSIG NSEC aironet2.ripe.net. A RRSIG NSEC... A DNS walk azon alapul, hogy az éppen megtanult intervallum fels végénél egy kicsit feljebb menve kaphatunk olyan intervallumot - NSEC rekordot -, aminek alsó vége az el z intervallum fels vége. Ilyen módon a DNSSEC-cel védett, és NSEC rekordokat tartalmazó zónák letapogathatók! Ez volt az egyik oka annak, hogy megszületett az NSEC rekord alternatívája, az NSEC3 rekord. Ezt évek óta több internet draft tárgyalta, de éppen e sorok írásával egyid ben, 2008. márciusában jelent meg az RFC5155, ami véglegesíti ezeket az elképzeléseket. E sorok írásakor a népszer név szerver programok közül a BIND még nem, de az NSD már támogatja. Az NSEC3 rekord nem a zónában lev nevekkel, hanem a nevekb l képett hash-ekkel operál, ezeket rendezi sorrendbe, és ezekb l képezi azokat az intervallumokat, amikkel a nemlétezést bizonyítani lehet. Mindehhez szükség van az NSEC3PARAM nev rekordra, ahol kiderül, hogy milyen algoritmussal, és milyen salt-tal kell képezni a nevekb l a hash-t. Az NSEC3 alkalmazásánál 6

az ellen rz, kérdez oldalon is szükség van kriptográai m veletre, itt is képezni kell hash-t a nemlétez rekord nevéb l a megadott módon. Példa: H(example) H(ns1.example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom = 2t7b4g4vsa5smi47k61mv5bv1a22bojr 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) Az NSEC3 opt-in mechanizmust is megenged: a következ jelentheti a következ DNSSEC-cel védett rekordot, ilyen módon egy jellemz en delegálásokat tartalmazó zónában - mint amilyenek a TLD-k -, a nem DNSSEC delegálások átugorhatók DS rekord A DS, Delegated Signer rekord szolgál arra, hogy a DNS hierarchiában egy magasabb szinten, az apuka zónában hitelesíthessünk egy gyerek zónában használt kulcsot. Ehhez nem a kulcsot, a KSK DNSKEY rekordot, hanem egy rövidebb dolgot, a kulcsból képzett hash-t írjuk alá. Példa: ris.ripe.net. 0 IN DS 25861 5 1 4c856668a2dfe12981ae7f61fbb873a97bfe52cc A DS rekord tartalmazza a delegált zóna KSK-hoz tartozó nyilvános kulcs ID-t (25861), a használt algoritmusok kódját, és a kulcs hash-ét. A DS rekord a delegáló zóna ZSK-jával aláirandó. Bevezetünk új ag-eket a DNS üzenetekben A DNS üzenetek klasszikus szerkezete átalakításra, b vítésre szorul, ha DNSSEC-et akarunk használni. A DNS fejrészben új ag-eket vezetünk be: ˆ DO (Dnssec Ok) A DO ag kérdésben használatos. Jelentése az, hogy a kérdez a válasszal együtt a válaszhoz tartozó DNSSEC rekordokat is kéri. ˆ CD (Checking Disabled) A CD ag is kérdésben használatos. Jelentése: te ne ellen rizz, majd én. Az ilyen kérdésekre a dns szerver akkor is válaszol, ha ellen rizné és hiányosnak, vagy hibásnak találná az adatot. ˆ AD (Authenticated Data) Az AD ag válaszokban használatos. Azt jelenti, hogy a kérdez név szerver a bizalmi láncon végigment, ellen rizte és rendben találta az információt DNSSEC szerint. A bitek helyéhez szükség van EDNS0-ra (Extended DNS, RFC2671) és szükség van az EDNS0 által bevezetett hosszabb csomagméretre is - a klasszikus DNS csak legfeljebb 512 byte hosszú csomagokat használ. Mi szól a bevezetése mellett? Ha DNSSEC-et használunk, akkor a hálózati szolgáltatásainkon egy lakattal (kerítéssel, riasztóval, kutyával) több ami védi az udvarunkat: bizonyos típusú visszeélések ellen védve leszünk. A DNSSEC használatára sokan rá akarnak beszélni. A RIPE valóságos roadshow-t tart, járja a világot, és mindenütt DNSSEC-re agitál. Az amerikai kormányhivatalok sürgetik a bevezetést: http://csrc.nist.gov/publications/pubssps.html. Több webhely DNSSEC népszer sítés céljából készült, például: 7

ˆ dnssec-deployment.org ˆ dnssec.[net org com] ˆ dnssec-tools.org Segédeszközök A DNSSEC használatát, bevezetését több segédeszköz teheti könnyebbé, egyszer bbé. ˆ A Net::DNS::SEC egy Perl modul, amivel dnssec tudású alkalmazások írhatók. ˆ Az ldns egy programcsalád és egy library c programok számára amivel dnssec tudású alkalmazások írhatók. Az Nlnetlabs nev vállalkozás terméke, akik pl. az NSD nev autoritatív név szervert is készítik. Ennek a programcsaládnak a terméke a fent már szóba került ldns-walk is. ˆ A drill a dig-hez hasonló segédeszköz, DNS és DNSSEC nézegetésre, amieleve a DNSSEC támogatásra jött létre. Ez is az Nlnetlabs terméke és természetesen ldns-en alapul. Példa drill használatra $drill -T -t ns -k ~/dnssec/keys/kripe.net.+005+00811.key ris.ripe.net ;; Domain:. ;; No DNSKEY record found for. ;; No DS for net. ;; Domain: net. ;; No DNSKEY record found for net. ;; No DS for ripe.net. ;; Domain: ripe.net. [T] ripe.net. 3600 IN DNSKEY 256 3 5 ;{id = 64728 (zsk), size = 1216b} ripe.net. 3600 IN DNSKEY 256 3 5 ;{id = 1725 (zsk), size = 1216b} ripe.net. 3600 IN DNSKEY 257 3 5 ;{id = 21238 (ksk), size = 2064b} ripe.net. 3600 IN DNSKEY 257 3 5 ;{id = 811 (ksk), size = 2064b} [T] ris.ripe.net. 0 IN DS 25861 5 1 4c856668a2dfe12981ae7f61fbb873a97bfe52cc ;; Domain: ris.ripe.net. [T] ris.ripe.net. 3600 IN DNSKEY 256 3 5 ;{id = 20613 (zsk), size = 1216b} ris.ripe.net. 3600 IN DNSKEY 256 3 5 ;{id = 20103 (zsk), size = 1216b} ris.ripe.net. 3600 IN DNSKEY 257 3 5 ;{id = 25861 (ksk), size = 2064b} ris.ripe.net. 3600 IN DNSKEY 257 3 5 ;{id = 21022 (ksk), size = 2064b} [T] ris.ripe.net. 1800 IN NS sec1.apnic.net. ris.ripe.net. 1800 IN NS ns-pri.ripe.net. ;;[S] self sig OK; [B] bogus; [T] trusted Ki használ most DNSSEC-et (2008. március)? A DNSSEC úttör top level domain (TLD) a svéd felhasználók domain-je, a.se. Világviszonylatban is el ször k vezették be a dnssec-et 2007-ben. DNSSEC-et használ már az nlnetlabs.nl, a ripe.net és a RIPE által kezelt 193.in-addr.arpa. 8

DNSSEC tudású rezolver, alkalmazás Már elérhet DNSSEC kiegészítés több programhoz, például Firefox-hoz és Postx-hez. Azonban jelenleg (2008. március) nem ismert szolgáltató, aki DNSSEC-et nyújtana a rekurzív (látó) név szerverein. 2007- ben a Teliasonera nev svéd ISP bevezette, de még aznap visszavonta: a DSL router-ek nem tolerálták, hogy AD=1 válaszokat kaptak. Mi szól a bevezetése ellen? A DNSSEC bevezetése nagyon sok változtatást és er forrást igényel ˆ Az aláírt zónák mérete többszörösére n. Például 2008 tavaszán a.hu zóna kb 380 ezer delegálás, 20M, aláírva 140M, tehát a zóna mérete hétszeres lett. A.hu zóna aláírása kb. 1 óráig tartott egy átlagos hardveren. ˆ A DNSSEC-cel többszörösére n a DNS okozta hálózati forgalom. N az ütésváltások száma és n az üzenetek nagysága is: el fordul, hogy nem is elég az UDP, egyszer névfeloldáshoz is TCP-re kell áttérni. ˆ A DNSSEC bevezetésével sokkal gyakrabban változik egy-egy zóna. Az aláírások lejárta miatt nem tartható az eddigi gyakorlat, amikor sok esetben évekig hozzá se nyúltak egy-egy zónához: most át kell írni cca havonta, illetve el bb mint hogy lejárnának az aláírások. N a kockázat ˆ Ha elrontunk valamit (pl. elfelejtkezünk arról, hogy lejárt az aláírás), akkor még rosszabb helyzetbe kerülünk, mint DNSSEC nélkül: a DSNSSEC-et használó rekurzív névszerverek mögött egyáltalán nem tudják feloldani a zónába tartozó neveket. ˆ A DNSSEC bonyolult a programok szintjén is. A BIND-ban az utóbbi években nem fedeztek fel biztonsági rést kivéve a DNSSEC kódot..hu nídz DNSSEC??? E kett s értelm kérdést igyekszünk megválaszolni mindkét értelemben. 1. Kinek van szüksége DNSSEC-re? Ahol nagyon fontos a biztonság, ezt is érdemes bevezetni, de tisztában kell lenni a korlátaival és veszélyeivel is. 2. Kell-e a.hu-ban DNSSEC? Bizonyára kell, de nem érdemes sietni vele. Érdemes várni, míg NSEC3 és opt-in használatával lehet. Így megakadályozzuk a walk-ot, és a zónának is csak egy töredékét érinti a bevezetés, nem fog hétszeres méretnövekedést okozni a DNSSEC bevezetés. Tisztában kell lennünk azzal, hogy a DNSSEC bevezetésének nem csak technikai vonatkozásai vannak. Sok szervezési és szabályozási kérdés is felmerül. Például kedvencbankom.hu NS rekordjai nem közvetlenül, hanem a regisztrátor által kerülnek a.hu-ba, de a DS rekordra ez vélhet leg nem tartható. 9

Olvasnivaló ˆ RFC1671, Extension Mechanisms for DNS (EDNS0) ˆ RFC3225, Indicating Resolver Support of DNSSEC ˆ RFC4033, Introduction and requirements ˆ RFC4034, Resource records ˆ RFC4035, Protocol modications ˆ RFC4641, Operational practices ˆ RFC5155, Hashed Authenticated Denial of Existence (NSEC3) ˆ dnssec-deployment.org ˆ dnssec. net org com ] ˆ dnssec-tools.org ˆ http://www.ppke.hu/ pasztor/ Ez a dokumentum html formában is elérhet : http://deneb.iszt.hu/~pasztor/dnssec-2008.html 10