DNS

A DNS története

A 70-es években az emberek belefáradtak abba, hogy emlékezzenek az elérni kívánt szerverek IP-címére. Ugyanakkor felmerült az ötlet, hogy a numerikus állomáscím helyett egyszerűbb és megjegyezhetőbb nevet használjunk.

A Stanford Research Institute dolgozói egy HOSTS.TXT szöveges fájllal álltak elő , amely az ARPANET-en lévő számítógépek karakterláncneveinek listáját és a hozzájuk tartozó numerikus címeket tartalmazza.

A címek manuálisan lettek hozzárendelve. Gazdanév és cím kéréséhez, vagy számítógép hozzáadásához a főfájlhoz a felhasználók telefonon keresték fel a Stanford hálózati információs központját 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.

1984-ben négy UC Berkeley diák megírta a hierarchikus domain névrendszer első változatát. Ma már széles körben használják, különösen Unix rendszereken, és még mindig a legszélesebb körben használt DNS-szoftver az interneten.

Bevezetés a DNS-be

A Domain Name System (DNS) egy terjesztési rendszer a tartományokkal kapcsolatos információk tárolására és lekérésére. Leggyakrabban arra használják, hogy IP-címet szerezzenek állomásnévből (számítógép vagy eszköz), levelek útválasztási információi szerezzenek be és/vagy állomások szolgáljanak ki a tartományban lévő protokollokhoz.

A rendszer a DNS-kiszolgálók meghatározott hierarchiájába szerveződik, amelyek egy bizonyos protokoll szerint működnek együtt. A DNS megértésének alapja a név és a zónák hierarchikus szerkezetének megértése.

Minden egyes tartományzónáért felelős szerver átruházhatja a felelősséget a tartomány további részéért egy másik szerverre, ami lehetővé teszi, hogy az információk relevanciájáért felelősséget rendeljenek különböző szervezetek szervereihez, amelyek csak a tartomány "saját" részéért felelősek. domain név.

A DNS-rendszer a zónahierarchiának megfelelő DNS-kiszolgálók hierarchiáját tartalmazza. Minden zónát legalább egy hiteles DNS-kiszolgáló támogat, amely a tartományra vonatkozó információkat tárol.

Fontos! A név és az IP-cím nem feltétlenül kapcsolódik egymáshoz. Egy IP-címhez több domain név is tartozhat, ami lehetővé teszi, hogy több webhelyet támogasson egy számítógépen (ezt nevezzük megosztott tárhelynek ).

Ez fordítva is történhet - sok IP-cím társítható egy tartománynévhez: ez lehetővé teszi a terheléselosztás létrehozását, és aktívan használják a CDN-hálózatokban .

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.

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

DNS rekordok

A DNS-kiszolgáló minden tartománynévhez paraméterkészletet tárol. Ezek rekordok a domain névről, annak IP-címéről, valamint különféle szolgáltatási információkról.

Összesen több tucat ilyen bejegyzés van, ezért csak a legnépszerűbbeket vesszük figyelembe közülük:

A legérdekesebbek itt a következők:

• Az A rekord lehetővé teszi egy tartománynak megfelelő IP-cím megadását.
• A CNAME lehetővé teszi a név szinonimájának beállítását, például www.codegym.cc == codegym.cc.
• Az MX rekord információkat tartalmaz a levelezőszerverről: mi a teendő, ha levél érkezik az xxx@codegym.cc címre.
• NS - a DNS-kiszolgáló címét jelzi, amely információkat tartalmaz erről a tartományról. Hasznos, ha a rekordokat gyorsítótárban tárolják és nem natív csomópontokon tárolják.

IP-cím keresése

Nézzük meg, hogyan működik a DNS-rendszer.

Tegyük fel, hogy az api.codegym.cc címet írta be a böngészőbe. A böngésző felveszi a kapcsolatot a helyi DNS-szolgáltatással, és megkéri, hogy adjon meg egy IP-címet az api.codegym.cc tartományhoz. Íme, mi lesz ezután...

Először a DNS-szolgáltatás megvizsgálja, hogy ez a tartomány szerepel-e a számítógép helyi hosts fájljában. Ha van, akkor onnan veszi az IP-címet. Ha nem, akkor kérést küld az általa ismert DNS-kiszolgálónak: „Mi az api.codegym.cc IP-címe?”.

Előfordulhat azonban, hogy a DNS-kiszolgáló nem csak a kért névről, de még a teljes codegym.cc tartományról sem tud semmit. 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 ru zónáért."

Ezután a DNS-szerver elküldi kérését a 204.74.112.1-re, de az azt válaszolja: "Nincs információm erről a szerverről, de tudom, hogy a 207.142.131.234 felelős a codegym.cc zónáért." Végül ugyanazt a kérést elküldik egy harmadik DNS-kiszolgálónak, és választ kap - egy IP-címet, amelyet továbbít a kliensnek, azaz a böngészőnek.

Ebben az esetben az IP név szerinti keresése során a következő szabályok működtek:

• A böngésző rekurzív kérést küldött egy ismert DNS-kiszolgálónak (ilyen típusú kérésre válaszul a szervernek egy IP-címet, vagy üres választ és egy NXDOMAIN hibakódot kell visszaadnia).
• A böngészőtől a kérést fogadó DNS-kiszolgáló egymás után nem rekurzív kéréseket küldött, amelyekre más DNS-kiszolgálóktól is kapott választ, egészen addig, 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 valószínűleg nem dolgozta volna fel rekurzívan a kéréseket, 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.

Fontos! 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 ugyanazon tartománynevekre vonatkozó ismételt kérés általában nem haladja meg a szerver gyorsítótárát, és más szerverek hívása egyáltalán nem történik meg.

A válaszok gyorsítótárának megengedett ideje a válaszokkal együtt érkezik (az erőforrásrekord TTL mezője).

hosts fájl

Észrevettük, hogy az első keresés a helyi hosts fájlban történik. Ez a HOSTS.TXT fájl örököse, amelyet még az ARPANET idejében találtak fel. Igen, még mindig létezik és még mindig használatban van.

Az út mentén található:

• /etc/hosts Linuxon.
• %SystemRoot%\system32\drivers\etc\hosts Windows rendszeren.
• /system/etc/hosts androidon.

A fájl általában tartalmazza a localhost csomópont helymeghatározását:

127.0.0.1   	localhost

Felépítése nagyon egyszerű: először jön az IP-cím, majd a domain név.

Hasznos

A hosts fájl segítségével lehetőség van a hirdetések szűrésére úgy, hogy a bannerek domain címét a 127.0.0.0, 127.0.0.1 vagy 0.0.0.0 címre irányítja át.

A 127.0.0.1 használata általában nem ajánlott, mivel válaszidőtúllépést és kapcsolódó késéseket eredményez, ha a kiszolgáló nem létezik vagy rosszul van beállítva. És ha bármilyen hirdetési tartományt leképez a 0.0.0.0 IP-címre, akkor minden arra irányuló kérés azonnal leesik).

Nyilvános DNS-kiszolgálók

Általában egy DNS-kiszolgálót kap az internetszolgáltatással együtt, amikor csatlakoztatja azt. De egy ilyen ingyenes DNS-kiszolgáló nem mindig a legjobb megoldás. Ezenkívül előfordulhat, hogy nem szeretne lekérdezést küldeni a tartománynévvel minden alkalommal, amikor felkeres egy webhelyet az internetszolgáltató DNS-kiszolgálójához.

Ezért sokan inkább nyilvános, ingyenes DNS-kiszolgálókra váltanak. Először is, nagyon gyorsak, és nagy gyorsítótárral rendelkeznek a domain nevek között. Gyorsabb webhelybetöltést és üzemidőt érhet el, minimális technikai problémákkal.

Másodszor a biztonság. Egyes DNS-szolgáltatások blokkolhatják az adathalász és rosszindulatú webhelyekhez való hozzáférést, és tartalomszűrést kínálnak, hogy megvédjék a gyermekeket a nem megfelelő online tartalmaktól.

Az ilyen DNS-kiszolgálók akár a csalók ellen is felvehetik a harcot. Például felmegyünk egy hamis bank weboldalára, és a DNS-szerver nem a csalók IP-címét adja meg, hanem a biztonsági szolgáltatását.

Az ilyen szerverek listája