A root dns-ben
A névfeloldó rendszer alapelvei
Az összes aldomainre vonatkozó információkat tartalmazó gyökérzónák: net. com. org. ru. su. és így tovább. Pontosabban, az ezen domaineket kiszolgáló szerverekről.
A domain érett. amely tartalmazza az összes aldomainről szóló információkat, valamint az ezen a területen közvetlenül regisztrált szerverek nevét, például www. érett. net.
1. ábra A nevek DNS-ben történő fordítása
Ez a DNS-architektúra lehetővé teszi a terhelés terjesztését és a rendszer működésének felelősségét az egyes tartományok adminisztrátorai között. Feladataik közé tartozik a normál teljesítmény biztosítása a zónába tartozó lekérdezések megválaszolásakor, a nevek egyediségének fenntartása a zónán belül, valamint az övezet kiszolgálóinak változásainak szülői zónájáról való értesítése.
Ez a hierarchikusan elosztott DNS-architektúra több mint egynegyedét szolgáltatta a rendszer hosszú életének és evolúciós evolúciójának.
De van egy olyan funkció a DNS rendszerben, amely megkülönbözteti azt a sok más decentralizált internetrendszertől. Ez ugyanaz a pont, a DNS-fa gyökere. ahol minden friss kérés kezdődik. Többet fogunk róla beszélni.
DNS gyökérszintje
A DNS gyökérkiszolgálói (CS) a rendszer kritikus elemei, mivel hozzáférést biztosítanak a DNS gyökér zónájához. A gyökér zóna információkat tartalmaz minden legfelső szintű domainről: nemzeti domainekről (pl. .ru), általános tartományokról (például .com) és szponzorált domainekről (például .museum). Ez az információ megmondja az ügyfélnek, hogy mely DNS-kiszolgálók küldjenek egy újabb kérést az FQDN további megoldására. Más szóval, bármely "friss" (vagyis nem tárolódik az ügyfél gyorsítótárában) kérelem a gyökérszerverhez való hozzáféréssel kezdődik.
A mai root kiszolgáló rendszer és működésének koordinálása
Nézzük meg részletesen az SCS résztvevõit. Ehhez forduljunk a 2. ábrán látható gyökérzónák tartalmának módosításához.
2. ábra A gyökérzónában végrehajtott változtatások folyamata
A változási kérelem a legfelső szintű domain rendszergazdától (ccTLD, gTLD stb.) Származik, és az IANA fenntartja. Az ilyen jellegű kérelem tipikus példája a domain kiszolgáló kiszolgálók összetételének módosítása.
Ezután a változásokat továbbítják a szervezet DNS-zónájának aktuális szerkesztéséhez és közzétételéért felelős szervezetnek. Ezt a szerepet jelenleg a VeriSign végzi. Egyébként ugyanez a vállalat 2 root szerver üzemeltetõje - a.root-servers.net és j.root-servers.net.
A zónát eredetileg a rejtett master kiszolgálón teszik közzé, majd a TSIG protokoll használatával minden replikációra elosztva, amely az átvitel során módosítja az adatokat.
A COP operátorai
A COP operátorai olyan szervezetek, amelyek viszonylag távoli múltban jogosultak a kiszolgálók kezelésére, amikor az ilyen problémák formálisan megoldódtak. A piaci szereplők közül az egyetemek, az Egyesült Államok Védelmi Minisztériuma, nonprofit egyesületek szervezetei. Az üzemeltetők pénzügyileg és jogilag függetlenek az ICANN-tól, amely szerint az IANA működik. Működési döntések meghozatala során a gazdasági szereplőket a technikai alkalmasság és a meglévő szabványok (például az RFC2870) vezérlik, elsősorban a status quo támogatásával. Ez a legnagyobb megoldás, amelyet az önálló szerver f. root - szerverek. net az ISC-nél, döntés született az anycast technológia alkalmazásáról. Bár ezt a döntést alaposan megvizsgálták a szakértők, az ICANN vagy valamelyik igazgatósága nem szabályozta. Ezt követően számos más szereplő csatlakozott az ISC-hez.
Általánosságban úgy vélik, hogy a CC-üzemeltetők ilyen függetlensége és heterogenitása a rendszer egészének technikai és politikai stabilitása alapja, kizárva bármelyik fél irányításának bitorlását.
A CC-üzemeltetők informális csoportot alkotnak, amelynek célja a közös tevékenységek összehangolása és operatív információk és tapasztalatok cseréje. A csoport évente háromszor rendszeres üléseket tart, időzítve az IETF üléséhez. Az ilyen találkozók egyik eredménye a TSIG protokoll magánkulcsának létrehozása.
A csoport tagjai szintén az ICANN (Root Server System Advisory Committee, RSSAC) Tanácsadó Tanácsának tagjai, amelynek feladata a KSK kezelésének és a rendszer különböző módosításainak megfogalmazása.
Egészen a közelmúltig nem volt hivatalos kapcsolat a szolgáltatók és az ICANN / IANA között. Ez a helyzet az ICANN és az ISC szerver üzemeltetője, az f.root-serve r s.net közötti első megállapodás aláírásával változott. Ez a megállapodás nem tartalmaz pénzügyi számításokat, és csak a felek kölcsönös felelősségét határozza meg a COP irányításával kapcsolatban. Ismeretes, hogy számos szereplő hasonló megállapodásokat vitat meg az ICANN-val.
Az alábbiakban az aktuális SCS-operátorok listája és rövid leírása található.
Alternatív SCS
Bár a COP munkájának szándékos megsértése vagy a gyökérzónák bármelyik szereplőjének vagy az ICANN / IANA-nak a módosítása nem valószínű, szigorúan szólva jelenleg nincs olyan formális folyamat vagy nemzetközi jogszabály, amely megakadályozná ezt. Elmondhatjuk, hogy az SCS rendes működése részben függ a résztvevők "jóakaratától".
Meg kell jegyezni, hogy az ilyen "informális" függések, amelyek a bizalomra épülnek, jellemzőek a DNS rendszer (és számos módon az internet) működésére. Végső soron a felhasználandó COP-ok kiválasztása az ügyfél számára marad. Ez az információ megtalálható a konfigurációs fájlban, és módosítható.
Ez a funkció, amely az ICANN által vezetett meglévő SCS irányítási rendszerrel való elégedetlenséggel párosulva egy ország kormánya - az Egyesült Államok részvételével - az úgynevezett alternatív SCS létrehozásához vezetett. Ilyen rendszerek például a Public Root, az Open Root Server Network (ORSN) és az UnifiedRoot. Bár ezek a rendszerek a gyökér zóna aktuális állapotát másolják, maga az architektúra azt írja elő, hogy bizonyos feltételek mellett az alternatív SCS-k alternatív névteret biztosíthatnak. A DNS-ügyfelek rendszergazdája (általában egy vállalati felhasználókat vagy kábelhálózati ügyfeleket kiszolgáló DNS-kiszolgáló) alternatív SCS-t választhat a hivatkozási fájl megfelelő módosításával.
Alternatív SCS kapott kritikai értékelését az IETF megnyitotta az esetleges osztott egyetlen interneten (lásd. RFC2826).
A DNS gyökérszintjének technikai fejlesztése
A DNS gyökérszint-rendszere nagyon konzervatív. Ez érthető - minden változás ezen a szinten befolyásolja a globális tartománynévrendszer működését. Mindazonáltal a RAS és a gyökérzónában számos fontos változás történt az utóbbi években.
Lehet, hogy észrevette, hogy a több COP és COP pontos neve „boldog” száma 13. Ez nem egy kihívás, hogy babona, a 13-as szám annak köszönhető, hogy a korlátozás az üzenet mérete 512 bájt, állítsa be a DNS szabvány [RFC1035 4.2.1]. Annak ellenére, hogy ezt a korlátozást az UDP csomagok korlátozása okozta, amelyek nem engedélyezik a töredezettséget, a DNS protokollban továbbra is léteznek, annak ellenére, hogy új hálózati protokollok, például az IPv6 megjelenése megtörtént. Részletes szabványos DNS (EDNS0, RFC2671 2.3, 4.5) egy előzetes megállapodást összege közötti kommunikáció a kliens és a szerver, de ennek mértéke protokoll a jelenlegi DNS rendszer nem elegendő ahhoz, hogy távolítsa el a korlátozást 512 bájt a közeljövőben.
Mind a 13 CS név (a.root - servers.net - m. Root - servers.net) illeszkedik az elosztott 512 bájtba, és a keresések nagy részében tizennégy név esetében a válasz nem tud teljesen illeszkedni az elosztott 512 bájtba. Az eredmény jelentősen csökkentheti a rendszer teljesítményét, mivel néhány ügyfélnek meg kell ismételnie a kérést, de most sokkal lassabb TCP protokollt használ.
Az Anycast technológia a leginkább alkalmas az UDP protokollt használó alkalmazásokhoz. hosszú távú kapcsolat létrehozása nélkül dolgozik. Ellenkező esetben, az Internet topológiában bekövetkező változások (amelyek folyamatosan előfordulnak), a legrövidebb út vezetheti az ügyfelet egy másik hálózatba. és a kapcsolat megszakad.
Első pillantásra egy egyszerű feladat, az információnak a gyökérzónába való felvétele a fő problémához kapcsolódott - meghaladva a válasz méretét, és különösen az alapozó lekérdezésre adott választ, ugyanazt az 512 bájtot!
Végül a harmadik lehetséges probléma lehet köztes rendszerek, például tűzfalak, amelyek nem tudnak áthaladni az 512 byte-nál nagyobb DNS-csomagokat, vagy IPv 6 bejegyzéseket tartalmaznak.
E kérdések tanulmányozása kimutatta, hogy nincs különösebb aggodalomra okot adó ok: a legmodernebb ügyfelek támogatják az EDNS 0 kiterjesztést, amely lehetővé teszi a nagyobb DNS-csomagok továbbítását. Még ha nem is, az elsődleges kérelemre adott válasz, amely nem haladja meg az 512 bájtot, elegendő információt tartalmaz a keresés elindításához. A tesztelés nem mutatott semmi problémát a hivatkozások fájljában lévő új bejegyzésekkel kapcsolatban.
A fő probléma, mint kiderül, lehet köztes rendszerek, de vizsgálat kimutatta, hogy sok közülük nem korlátozhatja a méret a továbbított DNS csomagot. Ennek a problémának az egyetlen módja kiterjedt oktatási munka volt.
Az IDN az internacionalizált domainnevek közé tartozik. vagy nemzetközi domainneveket, és a nemzeti ábécék használatának lehetőségét jelenti egy domain vagy szerver nevének meghatározásakor. A technológia nagyon vonzó, mind technikai, mind politikai szempontból, mivel a nem latin betűkkel rendelkező felhasználók számára szinte teljesen kizárja a latin ábécé használatának szükségességét, amikor az interneten dolgozik.
Az alap DNS szabvány azonban csak egy 7 bites karakterkódolást engedélyez, az úgynevezett ASCII táblát. és még akkor is némi korlátozással a gazdanevek számára. Ugyanakkor a Unicode a nemzeti írásos nyelvek szimbólumainak kódolásának szabványos formája.
A Unicode karakterek érvényes DNS-karakterkészletekbe történő lefordításához az úgynevezett Punycode-t használják. Nevek Pyunikode meg egy kicsit furcsa, például a „test” -ként jelenik meg xn - 80akhbyknj4f, de azok teljes mértékben megfelelnek a DNS szabványoknak.
Jelenleg az úgynevezett Fast Track eljárásról van szó, amely lehetővé teszi a meglévő nemzeti felső szintű domainek üzemeltetői számára, hogy ezeket a domaineket nemzeti nyelveken regisztrálja.
Az IDN használatával számos probléma merül fel. Például az IDN nyit több lehetőséget spoofing (hamisítás) neve a kiszolgáló nevét kifelé nagyon hasonlít egy másik nevet, de valójában használja a többi karaktert, az úgynevezett homográfia. Valóban, hogyan lehet megkülönböztetni www. paypal. com a www. p és ypal. com, amelyben a második "a" betű cirill van feltüntetve. Összehasonlítva a közönséges nevekkel, ahol az 1 hasonló az l-hez. és 0-tól O-ig. Az IDN sokkal több homogramot tartalmaz. A probléma megoldása szigorú ellenőrzést igényel a domainregisztrálóknál, korlátozza a tartományon belüli támogatott nyelvek számát, és megtiltja a különböző nyelvek keverését a tartománynévben.
A DNS legfőbb hátránya a gyenge adatvédelmi rendszer. Ez azt jelenti, hogy az adatoknak a szerverről az ügyfélre történő átvitelének folyamatában az adatok módosíthatók. Lehetőség van olyan hamis DNS-kiszolgálók létrehozására is, amelyek módosított adatokat szolgáltatnak. DNSSEC. amely a DNS-szabvány kiterjesztése. megoldhatja ezt a problémát azáltal, hogy hitelesíti az adatokat a tartományi rendszergazda digitális aláírásával, amelyből az adatokat megkapta. A domain rendszergazda aláírását a szülői zóna rendszergazda tanúsítja. Ez az azonosító lánc folytatódik a gyökér zónáig, és a DNS-ügyfél ellenőrizheti, hogy a küldöttségek neve és teljes lánca érvényes-e, és nem módosult-e.
Jelenleg a DNSSEC támogatás elég szétszóródott a DNS-fa felett. amely a legtöbb esetben nem teszi lehetővé az úgynevezett bizalmi láncok kialakítását. A gyökérzónában nincs DNSSEC támogatás. Mindez lényegében elutasítja a DNSSEC előnyeit.
A RIPE NCC technikai igazgatója, Andrey Robachevsky
A cikkben ismertetett vélemények nem feltétlenül tükrözik a RIPE NCC hivatalos álláspontját