DNS

A DNS ( angolul  Domain Name System  "domain name system") egy számítógépes elosztott rendszer a tartományokkal kapcsolatos információk megszerzésére . Leggyakrabban arra használják, hogy IP-címet kapjanak egy gazdagépnévből (számítógép vagy eszköz), levelek útválasztási információi és/vagy szerverállomások a tartományban lévő protokollokhoz ( SRV rekord ).

Az elosztott DNS-adatbázist egy adott protokollon keresztül együttműködő DNS-kiszolgálók hierarchiája támogatja .

A DNS alapja a hierarchikus névstruktúra és a zónák ötlete . Minden névért felelős szerver átruházhatja a felelősséget a domain további részéért egy másik szerverre (adminisztratív szempontból - más szervezetre vagy személyre), ami lehetővé teszi, hogy az információk relevanciájáért felelősséget rendeljen a különböző szerverek szervereihez. szervezetek (emberek), amelyek csak a "saját" rész domainnevükért felelősek.

2010-től kezdődően a DNS-rendszer DNSSEC -nek ( DNS Security Extensions ) nevezett adatintegritás-ellenőrzéseket hajt végre . A továbbított adatok nem titkosítottak, de hitelességüket kriptográfiai módszerekkel ellenőrzik. A megvalósított DANE szabvány biztosítja a megbízható kriptográfiai információk ( tanúsítványok ) átvitelét a DNS-en keresztül, amelyet a szállítási és alkalmazási rétegek közötti biztonságos kapcsolatok létrehozására használnak .

A DNS fő jellemzői

A DNS a következő jellemzőkkel rendelkezik:

• Az adminisztráció elosztása . A hierarchikus struktúra különböző részeiért különböző személyek vagy szervezetek felelősek.
• Információtárolás elosztása . Minden hálózati csomópontnak feltétlenül csak azokat az adatokat kell tárolnia, amelyek a felelősségi körébe tartoznak , és (esetleg) a gyökér DNS-kiszolgálók címeit .
• Információ gyorsítótár . Egy csomópontbizonyos mennyiségű adatot tárolhat a felelősségi körén kívül, hogy csökkentse a hálózati terhelést .
• Hierarchikus struktúra , amelyben az összes csomópont egy fába van egyesítve , és minden csomópont függetlenül meghatározhatja a downstream csomópontok munkáját, vagy delegálhatja (átviheti) őket más csomópontokhoz.
• Foglalás . Több szerver (általában) felelős a fizikailag és logikailag is elkülönített csomópontjai (zónái) tárolásáért és karbantartásáért, ami biztosítja az adatok biztonságát és a munka folytatását akkor is, ha valamelyik csomópont meghibásodik.

A DNS fontos az internet működéséhez , mivel a gazdagép IP-címére vonatkozó információkra van szükség a gazdagéphez való csatlakozáshoz, és az emberek könnyebben megjegyezhetik az alfabetikus (általában értelmes) címeket, mint egy számsorozatot. Bizonyos esetekben ez lehetővé teszi virtuális kiszolgálók, például HTTP-kiszolgálók használatát, megkülönböztetve őket a kérés neve alapján. Kezdetben a tartomány és az IP-címek közötti átalakítás egy speciális hosts szövegfájl segítségével történt , amelyet központilag fordítottak le, és automatikusan elküldtek a helyi hálózat minden egyes gépére. A Web növekedésével szükség volt egy hatékony, automatizált mechanizmusra, amely DNS lett.

A DNS-t Paul Mokapetris fejlesztette ki 1983- ban ; a működési mechanizmusok eredeti leírását az RFC 882 és az RFC 883 tartalmazza . 1987- ben az RFC 1034 és RFC 1035 kiadása megváltoztatta a DNS-specifikációt, és elavulttá vált az RFC 882 , RFC 883 és RFC 973 .

További funkciók

• dinamikus frissítések támogatása
• adatvédelem ( DNSSEC ) és tranzakciók ( TSIG )
• különböző típusú információk támogatása

Történelem

Az egyszerűbb és megjegyezhetőbb név használata a numerikus állomáscím helyett az ARPANET korszakból származik . A Stanford Research Institute (jelenleg SRI International ) egy HOSTS.TXT szövegfájlt tartott fenn, amely a gazdagépneveket numerikus számítógépcímekre képezte le az ARPANET -en . A numerikus címek, az úgynevezett hozzárendelt számok listájának karbantartását Jon Postel a Dél-Kaliforniai Egyetem Információtudományi Intézetében (ISI) végezte, amelynek csapata szorosan együttműködött az NII-vel [1] .

A címek manuálisan lettek hozzárendelve. Gazdanév és cím kéréséhez, valamint számítógép hozzáadásához a főfájlhoz a felhasználók telefonon keresték fel az Elisabeth Feinler által működtetett SRI Network Information Centert (NIC), munkaidőben.

Az 1980-as évek elejére az egyetlen, központosított hoszttábla fenntartása lassú és nehézkessé vált, és a növekvő hálózatnak automatikus elnevezési rendszerre volt szüksége a technikai és személyi problémák kezelésére. Postel azt a feladatot tűzte ki maga elé, hogy kompromisszumot dolgozzon ki öt versengő javaslat között a Paul Mokapetris által felvetett probléma megoldására. Ehelyett a Mokapetris megalkotta a hierarchikus domain névrendszer koncepcióját.

Az IETF Munkacsoport 1983 novemberében tette közzé az RFC 882 és RFC 883 eredeti specifikációit.

1984-ben négy UC Berkeley diák, Douglas Terry, Mark Painter, David Riggle és Songnian Zhou megírta a BIND (Berkeley Internet Name Daemon) névszerver első verzióját. 1985-ben a DEC munkatársa, Kevin Dunlap jelentősen átalakította a DNS megvalósítását. Mike Karel, Phil Almquist és Paul Vixey azóta is támogatja a BIND -et . Az 1990-es évek elején a BIND -ot a Windows NT platformra vitték át . Széles körben elterjedt, különösen Unix rendszereken, és még mindig a legszélesebb körben használt DNS-szoftver az interneten.

1987 novemberében elfogadták a DNS-specifikációkat - RFC 1034 és RFC 1035 . Azóta több száz RFC -t fogadtak el a DNS módosítására és kiegészítésére.

Biztonsági problémák

Kezdetben a biztonsági aggályok nem voltak fő szempontok a DNS-szoftverek vagy a korai Interneten telepítendő szoftverek fejlesztése során, mivel a hálózat nem volt nyitott a nagyközönség számára. Az 1990-es években azonban az internet növekedése a kereskedelmi szektorban megváltoztatta az adatintegritás és a felhasználói hitelesítés védelmét szolgáló biztonsági intézkedések követelményeit.

Számos sebezhetőséget fedeztek fel és használtak ki a támadók. Az egyik ilyen probléma a DNS-gyorsítótár-mérgezés , amelyben az adatokat a gyorsítótár-feloldóknak továbbítják azzal az ürüggyel, hogy hiteles eredetkiszolgálók, és ezáltal az adattárat potenciálisan hamis információkkal és hosszú lejárati dátumokkal (élettartam) szennyezik. Ezt követően a legitim alkalmazásoktól érkező kérések átirányíthatók a támadó által felügyelt hálózati gazdagépekre.

A DNS-válaszokat korábban nem írták alá kriptográfiailag, ami számos támadási lehetőséget tesz lehetővé. A modern tartománynév-biztonsági bővítmények ( DNSSEC ) módosítják a DNS-t, hogy támogassák a kriptográfiailag aláírt válaszokat. Más bővítmények, például a TSIG, támogatják a kriptográfiai hitelesítést a megbízható társak között, és általában zónaátvitelek vagy dinamikus frissítési műveletek engedélyezésére használják.

Egyes domain nevek hamisítási hatások elérésére használhatók. Például a paypal.com és a paypa1.com különböző nevek, de előfordulhat, hogy a felhasználók nem tudják megkülönböztetni őket a grafikus felhasználói felületen a felhasználó által választott betűtípustól függően. Sok betűtípusban az l betű és az 1-es szám nagyon hasonlónak vagy akár teljesen azonosnak tűnik. Ez a probléma akut azoknál a rendszereknél, amelyek támogatják a nemzetköziesített tartományneveket, mivel az ISO 10646 karakterkódok közül sok megjeleníthető a tipikus számítógép-képernyőkön. Ezt a biztonsági rést időnként adathalászat során használják ki .

Az olyan technikák, mint a fordított DNS közvetlen rekordellenőrzéssel, szintén használhatók a DNS-eredmények érvényesítésére, de ezek kriptográfiailag nem érvényesek; ez nem veszi figyelembe az útválasztási információk helyettesítésének lehetőségét ( angol  BGP-hijacking ).

Terminológia és működési elvek

A DNS kulcsfogalmai a következők:

• Domain ( angol  domain  "terület") - egy csomópont a névfában, a hozzá tartozó összes csomóponttal együtt (ha van ilyen), vagyis egy elnevezett ág vagy részfa a névfában. A tartománynév szerkezete a hierarchia csomópontjainak sorrendjét tükrözi; a domain név balról jobbra olvasható a junior tartományoktól a legfelső szintű tartományokig (fontossági sorrendben): felül a gyökérdomain ("." (pont) azonosítóval), lent az első szintű tartományok ( domain zónák ), majd - a második szintű tartományok, a harmadik stb. (például egy címnélru.wikipedia.org.az első szintű tartományorg, a másodikwikipedia, a harmadikru). A DNS lehetővé teszi, hogy ne adja meg a gyökértartomány pontját.
• Aldomain ( angol  subdomain ) - alárendelt tartomány (példáulwikipedia.org - a domain aldomainjeorgésru.wikipedia.org - a domainwikipedia.org). Elméletileg egy ilyen felosztás legfeljebb 127 szint mélységű lehet, és minden címke legfeljebb 63 karaktert tartalmazhat, amíg a teljes hossza pontokkal együtt el nem éri a 254 karaktert. A gyakorlatban azonban a domain név regisztrátorok szigorúbb korlátozásokat alkalmaznak. Ha például rendelkezik nézetdomainnelmydomain.ru, létrehozhat hozzá különböző nézetaldomaineketmysite1.mydomain.rustbmysite2.mydomain.ru.
• Az erőforrásrekord  az információ tárolásának és továbbításának egysége a DNS-ben. Minden erőforrásrekordnak van neve (vagyis egy adott tartománynévhez , a névfa egy csomópontjáhozvan kötve ), egy típusa és egy adatmezője , amelyek formátuma és tartalma a típustól függ.
• A zóna  egy tartománynévfa része (beleértve az erőforrásrekordokat is ), egyetlen egységként tárolva néhány tartománynévszerveren ( DNS-kiszolgáló , lásd alább), és gyakrabban - egyidejűleg több szerveren (lásd alább). A fa egy részének külön zónába történő elkülönítésének célja a megfelelő tartomány felelősségének (lásd alább) átruházása egy másik személyre vagy szervezetre. Ezt delegációnak nevezik (lásd alább). A fa összefüggő részeként a belső zóna is egy fa. Ha a DNS-névteret zónák struktúrájának tekintjük, nem pedig az egyes gazdagépeknek / neveknek, akkor egy fát is kapunk; indokolt szülő és gyermek zónákról, idősebbekről és beosztottakról beszélni. A gyakorlatban a legtöbb 0 és 1 szintű zóna ('.', ru, com, …) egyetlen csomópontból áll, amelynek a gyermekzónák közvetlenül alá vannak rendelve. A nagyvállalati tartományokban (2. vagy több szint) néha további alárendelt szintek jönnek létre anélkül, hogy azokat alárendelt zónákra osztanák.
• A delegálás a domain névfa egy részének felelősségének egy másik személyre vagy szervezetre  történő átruházása . A DNS-ben történő delegálás biztosítja az elosztott adminisztrációt és tárolást. Technikailag a delegálást a fa ezen részének egy külön zónához való hozzárendelésében fejezik ki , és ennek a zónának az adott személy vagy szervezet által kezelt DNS-kiszolgálón való elhelyezésében (lásd lent). Ugyanakkor a gyermekzóna DNS-kiszolgálóira mutató mutatókat tartalmazó „ ragasztó ” erőforrásrekordok (NS és A) a szülőzónában szerepelnek, a gyermekzónával kapcsolatos minden egyéb információ pedig már tárolva van a gyermekzóna DNS-kiszolgálóin . gyermek zóna.
• DNS-szerver  - speciális szoftver a DNS kiszolgálására, valamint a számítógép, amelyen ez a szoftver fut. Előfordulhat, hogy a DNS-szerver felelős bizonyos zónákért, és/vagy kéréseket továbbíthat az upstream szerverekhez.
• A DNS-kliens  egy speciális könyvtár (vagy program) a DNS-sel való munkára. Egyes esetekben a DNS-kiszolgáló DNS-kliensként működik.
• Authority ( eng.  autoritative ) - a zóna helyének jele a DNS-kiszolgálón. A DNS-kiszolgáló válaszai kétféleek lehetnek: mérvadó (amikor a szerver azt állítja, hogy magáért a zónáért felelős) és nem hiteles ( eng.  Non-authoritative ), amikor a szerver feldolgozza a kérést, és választ ad vissza más szerverektől. Bizonyos esetekben a DNS-kiszolgáló a kérés továbbadása helyett egy már ismert értéket adhat vissza (a korábbi kérések alapján) (gyorsítótárazási mód).
• DNS-lekérdezés ( eng.  DNS query ) – kérés az ügyféltől (vagy szervertől) a szerverhez. A lekérdezés lehet rekurzív vagy nem rekurzív (lásd: rekurzió ).

A DNS-rendszer DNS-kiszolgálók hierarchiáját tartalmazza , amely megfelel a zónák hierarchiájának . Minden zónát legalább egy hiteles DNS-kiszolgáló támogat (az angol  autoritative  - autoritatív szóból), amely információkat tartalmaz a tartományról.

A név és az IP-cím nem azonos  – egy IP-címnek több neve is lehet, ami lehetővé teszi több webhely támogatását egy számítógépen (ezt hívják virtuális tárhelynek ). Ennek a fordítottja is igaz – sok IP-cím leképezhető ugyanarra a névre: ez lehetővé teszi a terheléselosztás létrehozását .

A rendszer stabilitásának növelése érdekében sok azonos információt tartalmazó szervert használnak, és a protokoll rendelkezik eszközökkel a különböző szervereken található információk szinkronizálására. 13 root szerver van , ezek címe gyakorlatilag nem változik. [2]

A DNS-protokoll az 53-as TCP- vagy UDP - portot használja a lekérdezések megválaszolásához. Hagyományosan a kérelmeket és a válaszokat egyetlen UDP-datagramként küldik el . A TCP akkor használatos, ha a válaszadat mérete meghaladja az 512 bájtot, és AXFR kérések esetén.

Rekurzió

A DNS-ben a rekurzió kifejezés a DNS-kiszolgáló viselkedési algoritmusára utal : "a kliens nevében teljes körű keresést hajt végre a szükséges információkért a teljes DNS-rendszerben, ha szükséges, hivatkozva más DNS-kiszolgálókra" .

A DNS-lekérdezés lehet rekurzív  – teljes keresést igényel – és nem rekurzív (vagy iteratív ) – teljes keresést nem igényel.

Hasonlóképpen, a DNS-kiszolgáló lehet rekurzív (teljes kikeresésre képes) és nem rekurzív (nem tud teljes keresést végrehajtani). Egyes DNS-kiszolgálószoftverek, mint például a BIND , beállíthatók úgy, hogy egyes klienseket rekurzívan , másokat pedig nem rekurzívan kérdezzenek le .

Amikor egy nem rekurzív lekérdezésre válaszol , valamint a rekurzív lekérdezések végrehajtásának képtelensége vagy tiltása esetén a DNS-kiszolgáló vagy adatokat ad vissza arról a zónáról, amelyért felelős , vagy hibát ad vissza. A nem rekurzív szerver beállításai, amikor a válasz azon szerverek címét adja vissza, amelyek több információval rendelkeznek a kért zónáról, mint a válaszoló szerver (leggyakrabban a gyökérszerverek címei), hibásak, és egy ilyen szerver DoS támadások szervezésére használják .

Rekurzív lekérdezés esetén a DNS szerver lekérdezi a szervereket (a névben szereplő zónaszint csökkenő sorrendjében), amíg választ nem talál, vagy nem találja, hogy a tartomány nem létezik (a gyakorlatban a keresés a legközelebbi DNS-ről indul. szervereket a kívánt szerverre, ha a róluk elérhető információk gyorsítótárazottan és naprakészen állnak rendelkezésre, előfordulhat, hogy a szerver nem kérdez le más DNS-kiszolgálókat).

Tekintsük a példát a teljes rendszer működésére.

Tegyük fel, hogy beírtuk a böngészőbe a címet ru.wikipedia.org. A böngésző egyezést keres e cím és a hosts fájlban található IP - cím között . Ha a fájl nem tartalmaz egyezést, akkor a böngésző megkérdezi a DNS-kiszolgálót: "mi az IP-címe ru.wikipedia.org"? Előfordulhat azonban, hogy a DNS-kiszolgáló nem csak a kért névről tud semmit, hanem akár a teljes tartományról is wikipedia.org. Ebben az esetben a szerver felveszi a kapcsolatot a gyökérszerverrel  – például 198.41.0.4. Ez a szerver azt mondja: "Nincs információm erről a címről, de tudom, hogy a 204.74.112.1 felelős a zónáért org." Ezután a DNS-kiszolgáló elküldi kérését a 204.74.112.1-re, de azt válaszolja: "Nincs információm erről a szerverről, de tudom, hogy a 207.142.131.234 felelős a zónáért wikipedia.org." Végül ugyanazt a kérést elküldik a harmadik DNS-kiszolgálónak, és választ kap - egy IP-címet, amelyet továbbít a kliensnek - a böngészőnek.

Ebben az esetben egy név feloldásakor, azaz az IP név szerinti keresése során:

• a böngésző rekurzív kérést küldött az általa ismert DNS-kiszolgálónak - az ilyen típusú kérésekre válaszul a szervernek egy „kész eredményt” kell visszaadnia, azaz egy IP-címet, vagy egy üres választ és egy NXDOMAIN hibakódot;
• A böngészőtől a kérést fogadó DNS-szerver sorban küldött nem rekurzív kéréseket, amelyekre más DNS-kiszolgálóktól kapott válaszokat mindaddig, amíg a kért zónáért felelős szervertől nem kap választ;
• a többi említett DNS-kiszolgáló nem rekurzívan dolgozta fel a kéréseket (és nagy valószínűséggel nem dolgozta volna fel a kéréseket rekurzívan, még akkor sem, ha ilyen követelmény szerepelt a kérésben).

Néha előfordulhat, hogy a kért szerver rekurzív lekérdezést küld egy „felfelé irányuló” DNS-kiszolgálónak, és vár a kész válaszra.

A rekurzív lekérdezésfeldolgozással minden válasz átmegy a DNS-kiszolgálón, és az lehetőséget kap a gyorsítótárba helyezésére. Az azonos nevekre vonatkozó ismételt kérés általában nem haladja meg a szerver gyorsítótárát , egyáltalán nem hívnak más szervereket. A válaszok gyorsítótárának megengedett ideje a válaszokkal együtt érkezik ( az erőforrásrekord TTL mezője ).

A rekurzív kérések több erőforrást igényelnek a kiszolgálótól (és nagyobb forgalmat generálnak), ezért általában a szerver tulajdonosa által „ismert” csomópontokból fogadják el őket (például a szolgáltató lehetőséget biztosít rekurzív kérések csak az ügyfelei számára, vállalati környezetben). hálózat, rekurzív kéréseket csak a helyi szegmensből fogadunk el). A nem rekurzív lekérdezések általában a hálózat összes gépétől érkeznek (és csak a gazdagép által üzemeltetett zónára vonatkozó lekérdezések kapnak értelmes választ, a többi zónára vonatkozó DNS-lekérdezések általában más szerverek címeit adják vissza).

Fordított DNS-lekérdezés

A DNS-t elsősorban a szimbolikus nevek IP-címekké alakítására használják, de fordított folyamatot is végrehajthat. Ehhez a meglévő DNS-eszközöket használják. A tény az, hogy különféle adatok összehasonlíthatók egy DNS-rekorddal, beleértve néhány szimbolikus nevet is. Létezik egy speciális tartomány, in-addr.arpaamelynek bejegyzései az IP-címek szimbolikus nevekké alakítására szolgálnak. Például egy cím DNS-nevének beszerzéséhez 11.22.33.44lekérdezhet egy bejegyzést a DNS-kiszolgálótól, 44.33.22.11.in-addr.arpaés az a megfelelő szimbolikus nevet adja vissza. Az IP-cím részei írásának fordított sorrendje azért van, mert az IP-címeknél a magas bitek az elején, a szimbolikus DNS-neveknél pedig a magas bitek (a gyökérhez közelebb találhatók) a végén találhatók.

DNS rekordok

A DNS -rekordok vagy az erőforrásrekordok ( angol nyelvű  erőforrásrekordok , RR ) az információk tárolásának és továbbításának egységei a DNS-ben. Minden erőforrásrekord a következő mezőkből áll [3] :

• név (NAME) – az a domain név, amelyhez ez az erőforrásrekord kapcsolódik vagy „tulajdonban van”,
• erőforrásrekord típusa (TYPE) – meghatározza ennek az erőforrásrekordnak a formátumát és célját,
• az erőforrásrekord osztálya (CLASS); elméletileg úgy gondolják, hogy a DNS nem csak TCP / IP -vel használható , hanem más típusú hálózatokkal is, az osztály mezőben lévő kód határozza meg a hálózat típusát [3] ,
• TTL (Time To Live) – az erőforrásrekord tárolásának megengedett ideje egy felelőtlen DNS-kiszolgáló gyorsítótárában ,
• adatmező hossza (RDLEN),
• adatmező (RDATA), amelynek formátuma és tartalma a rekord típusától függ .

A DNS-rekordok legfontosabb típusai a következők:

• Az A ( címrekord ) vagy címrekord egy állomásnevet társít egy IPv4-címhez. Például egy A-rekord lekérdezése egy névre referrals.icann.org, az IPv4-címet adja vissza - 192.0.34.164.
• Az AAAA ( IPv6- címrekord ) egy gazdagépnevet társít egy IPv6 -címhez . Például egy AAAA rekord lekérdezése egy névre , az IPv6 -címet K.ROOT-SERVERS.NETadja vissza - .2001:7fd::1
• Egy CNAME rekord ( kanonikus névrekord ) vagy egy kanonikus névrekord (alias) egy másik névre való átirányításra szolgál.
• Az MX rekord ( mail Exchange ) vagy levélcserélő határozzameg az adott tartományhoz tartozó mail Exchange szerver(eke) t.
• Az NS rekord ( névszerver ) az adott tartomány DNS-kiszolgálójára mutat.
• A PTR rekord ( pointer [4] [5] ) egy fordított DNS vagy pointer rekord , amely egy gazdagép IP-címét társítja a kanonikus nevéhez. A gazdagép IP-címére vonatkozó tartományi lekérdezés fordított formában az adott gazdagép nevét ( FQDN ) adja vissza (lásd: Fordított DNS-lekérdezés ). Például (az írás idején) egy IP-cím esetében a PTR-rekord lekérdezése a kanonikus nevét adja vissza . A kéretlen levelek (spam) mennyiségének csökkentése érdekében sok e-mailt fogadó szerver képes ellenőrizni, hogy van-e PTR-rekordja annak a gazdagépnek, amelyről azt küldik. Ebben az esetben az IP-cím PTR rekordjának meg kell egyeznie a küldő levelezőszerver nevével, amely az SMTP -munkamenet során látszik .in-addr.arpa192.0.34.164164.34.0.192.in-addr.arpareferrals.icann.org
• A SOA ( Start of Authority ) rekord vagy a zóna kezdeti rekordja jelzi, hogy a tartomány referenciainformációi melyik szerveren vannak tárolva, tartalmazza a zónáért felelős személy elérhetőségeit, a zóna információinak gyorsítótárazási időzítését (időparamétereit) és az interakciót. DNS szerverek között.
• Az SRV-rekord ( kiszolgálókiválasztás ) a szolgáltatásokhoz tartozó szervereket határozza meg, különösen a Jabber és az Active Directory számára .

Fenntartott domain nevek

Az RFC 2606 ( Fenntartott felső szintű DNS-nevek) olyan tartományneveket határoz meg, amelyeket példaként (például a dokumentációban) és tesztelési célokra kell használni. A example.com, example.orgésexample.net mellett ebbe a csoportba tartozik még a teststb invalid.

Nemzetközi tartománynevek

A tartománynév csak korlátozott számú ASCII -karakterből állhat, ami lehetővé teszi a tartománycím beírását a felhasználó nyelvétől függetlenül. Az ICANN jóváhagyott egy Punycode - alapú IDNA -rendszert , amely bármely Unicode -karakterláncot érvényes DNS-karakterkészletté alakít át.

DNS szoftver

Névszerverek:

• BIND (Berkeley Internet Name Domain) [1]
• djbdns ( Daniel J. Bernstein DNS-e) [2]
• dnsmasq [3]
• MaraDNS [4]
• NSD (Name Server Daemon) [5]
• PowerDNS [6]
• OpenDNS [7]
• Microsoft DNS Server ( Windows NT operációs rendszerek szerververzióiban )
• MyDNS [8]

Lásd még

• Az EDNS  az új DNS protokoll szabvány
• Alternatív DNS gyökérkiszolgálók
• OpenDNS
• Google nyilvános DNS
• Yandex.DNS
• Cyberguggolás
• Types guggolás
• Dinamikus DNS
• Round robin DNS  – terheléselosztás az azonos szerverek között.
• TUDOM
• DNSSEC
• DNS kliens
• DNS szerver
• Nslookup
• DNS zóna átvitel

Jegyzetek

1. ↑ IEEE Annals [3B2-9] man2011030074.3d 11:54. . - 011.07.29. — 74. oldal p.
2. ↑ A gyökérzóna aktuális verziója mindig a következő címen található: ftp://ftp.internic.net/domain/named.root
3. ↑ 1 2 Domain Name System (DNS) IANA  szempontok . tools.ietf.org. Letöltve: 2019. február 7. Az eredetiből archiválva : 2020. augusztus 2..
4. ↑ P.V. Mockapetris. Domain nevek – fogalmak és lehetőségek  . tools.ietf.org. Letöltve: 2019. február 7. Az eredetiből archiválva : 2018. június 23.
5. ↑ P.V. Mockapetris. Domain nevek - megvalósítás és specifikáció  (angol) . tools.ietf.org. Letöltve: 2019. február 7. Az eredetiből archiválva : 2019. április 3.

Linkek

• DNS-erőforrás  könyvtár
• DNS- és BIND-források archiválva 2006. szeptember 2-án a Wayback Machine -nél 
• CircleID DNS  Társaság
• DNS-biztonsági fejlesztés (DNSSEC  )
• Az IETF kiterjesztett DNS-specifikációval foglalkozó munkabizottsága (DNSEXT  )
• Root DNS Servers  webhely
• Egy tartomány DNS-rekordjainak megtekintése
• DNS Web Tools katalógus a dmoz.org webhelyen archiválva : 2018. november 13. a Wayback Machine -nél 

Cikkek

• A DNS-támadások sémáinak és típusainak áttekintése

RFC-k

• RFC 1034  – Domain nevek – Fogalmak és szolgáltatások
• RFC 1035  – Domain nevek – Megvalósítás és specifikáció
• RFC 1912  – Gyakori DNS működési és konfigurációs hibák
• RFC 1591  – Domain névrendszer felépítése és delegálása
• RFC 1713  – Eszközök a DNS-hibakereséshez
• RFC 2606  – Fenntartott legfelső szintű DNS-nevek