UP | HOME

DNSSEC: érvek s ellenérvek

Tartalomjegyzék

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.

dns.png

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.

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, 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 Networkshop-on, 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 modifications 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
  • 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áfia sajátosságai

Aki PGP, SSH, vagy TLS kriptográfiáról hallott, annak meglepetést okozhat néhány dolog. A DNSSEC kriptográfiá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= )

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 megfigyelni 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 lexikografikus sorrendbe rendezzük, és az így keletkező intervallumokat írjuk alá. Az intervallumokat az NSEC (Next Secure) rekord definiá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 lexigrafikus 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 az ellenőrző, kérdező oldalon is szükség van kriptográfiai műveletre, itt is képezni kell hash-t a nemlétező rekord nevéből a megadott módon. Példa:

H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
H(ns1.example)   = 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 flag-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 flag-eket vezetünk be:

  • DO (Dnssec Ok)

A DO flag 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 flag 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 flag 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:

  • 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.

DNSSEC tudású rezolver, alkalmazás

Már elérhető DNSSEC kiegészítés több programhoz, például Firefox-hoz és Postfix-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ó.

Olvasnivaló

Ez a dokumentum pdf formában is letölhető: http://deneb.iszt.hu/~pasztor/dnssec-2008.pdf

Lábjegyzet:

1 A Networkshop-on 2008-ban, Dunaújvároson elhangzott előadás bővített, átdolgozott változata

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 Angriffe http://www.dorisdiedrich.de/ssl.pdf

Szerző: Pásztor Miklós, ISZT/PPKE

Validate XHTML 1.0