Szerző: Paul Cobbaut
Közzététel dátuma: 2015. május 24
Fordítás: A. Panin
Az átutalás időpontja: 2015. július 11

4. fejezet Bevezetés a DNS-kiszolgálókba

4.3. DNS gyorsítótárazó szerverek

Az olyan DNS-kiszolgálót, amely nem szolgálja ki a DNS-zónát, de más névkiszolgálókhoz kapcsolódik a lekérdezések gyorsítótárazásához, gyorsítótárazó DNS-kiszolgálónak nevezzük. A DNS-gyorsítótárazó kiszolgálók nem működnek az erőforrásrekordokat tartalmazó DNS-zóna-adatbázisokkal. Ehelyett más névszerverekhez csatlakoznak, és gyorsítótárazzák a kapcsolódó információkat.

A DNS-kiszolgálóknak két típusa van. Ezek DNS-továbbítási kiszolgálókat használó DNS-kiszolgálók és DNS-gyökérszervereket használó DNS-kiszolgálók.

4.3.1. Gyorsítótárazó DNS-kiszolgáló, amely nem használ továbbítószervert

A gyorsítótárazó DNS-kiszolgálónak, amely nem használ továbbítási kiszolgálót, máshonnan kell megszereznie az információkat. Amikor egy ügyféltől kérést kap, kapcsolatba lép az egyik gyökérkiszolgálóval. A gyökérkiszolgáló elküldi a gyorsítótárazó kiszolgálónak a megcélzott legfelső szintű tartományt kiszolgáló kiszolgálóról szóló információkat, amelyek viszont egy másik DNS-kiszolgálóhoz irányítják. Ez utóbbi kiszolgáló vagy információval rendelkezhet a kérés megválaszolásához, vagy információkat adhat át egy másik DNS-kiszolgálóról, amely rendelkezhet ezekkel az információkkal. Végül DNS-szerverünk megkapja a kérés megválaszolásához szükséges információkat, és visszaküldi a választ a kliensnek.

Az alábbi ábra azt a folyamatot mutatja be, amikor egy kliens IP-címre vonatkozó kérést küld a linux-training.be tartománynévhez. Gyorsítótárazó szerverünk csatlakozik a gyökérkiszolgálóhoz, és átirányítja a .be legfelső szintű tartományt kiszolgáló szerverre. Ezután csatlakozik a .be legfelső szintű tartományt kiszolgáló szerverhez, és átirányítja az Openminds szervezet egyik névszerverére. Az egyik névszerver (jelen esetben az nsq.openminds.be) a linux-training.be tartománynévvel rendelkező szerver IP-címével válaszol a kérésre. Miután a gyorsítótárazó szerverünk továbbítja ezeket az információkat az ügyfélnek, az ügyfél csatlakozhat a kérdéses webhelyhez.

Ha a tcpdump sniffert használja a tartománynév feloldásához, a következő kimenetet kapja (minden sor első 20 karaktere eltávolítva).

192.168.1.103.41251> M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr \ aining.be. (46) M.ROOT-SERVERS.NET.domain> 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268> d.ns.dns.be.domain: A385%? linux-képzés. \ be. (46) d.ns.dns.be.domain> 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514> ns2.openminds.be.domain8: A 6088% linux-train \ ing.be. (46) ns2.openminds.be.domain> 192.168.1.103.7514: 60888 * - 1/0/1 A 188.93.155. \ 87 (62)

4.3.2. DNS-gyorsítótárazási kiszolgáló átirányítási szerver használatával

A továbbítási kiszolgálót használó gyorsítótárazó DNS-kiszolgáló egy olyan DNS-kiszolgáló, amely minden szükséges információt megkap a továbbítási kiszolgálótól (továbbítótól). Például egy internetszolgáltató DNS-kiszolgálója továbbító DNS-kiszolgálóként működhet.

A fenti ábra egy DNS-kiszolgálót mutat be egy vállalat helyi hálózatán, amely egy internetszolgáltató által biztosított DNS-kiszolgálót használ továbbító DNS-kiszolgálóként. Ha az internetszolgáltató által megadott DNS-kiszolgáló IP-címe 212.71.8.10, akkor a következő soroknak kell szerepelniük a vállalat DNS-kiszolgálójának named.conf konfigurációs fájljában:

Szállítmányozók (212.71.8.10;);

Ezenkívül a DNS-kiszolgálót úgy is beállíthatja, hogy feltételes továbbítókkal működjön együtt. A konfigurációs fájlban egy feltételesen átirányító DNS-kiszolgáló leírása így néz ki:

Zone "someotherdomain.local" (type forward; forward; forwarders (10.104.42.1;););

4.3.3. Iteratív vagy rekurzív lekérdezés

A rekurzív lekérdezés egy DNS-lekérdezés, amely után az ügyfél végső választ vár a DNS-kiszolgálótól (a fenti ábrán a MacBookról a DNS-kiszolgálóra mutató félkövér piros nyíl jelzi). Az iteratív lekérdezés egy DNS-lekérdezés, amely után a kliens nem vár végső választ a DNS-kiszolgálótól (a fenti ábrán három, a DNS-kiszolgálóról mutató fekete nyíllal van ábrázolva). Az iteratív lekérdezések leggyakrabban névszerverek között történnek. A root névszerverek nem válaszolnak a rekurzív lekérdezésekre.

A DNS-zónát kezelő DNS-kiszolgálót a zóna mérvadó DNS-kiszolgálójának nevezik. Ne feledje, hogy a DNS-zóna csak erőforrásrekordok gyűjteménye.

A DNS-zóna első mérvadó DNS-kiszolgálóját elsődleges DNS-kiszolgálónak nevezik. Ez a szerver a DNS zóna adatbázis olvasási és írási másolatával fog működni. Ha meghibásodás esetén javítani kell az adatok integritását, javítani kell a kiszolgáló teljesítményét vagy a terheléselosztást, telepíthet egy másik DNS-kiszolgálót, amely szintén kezelni fogja ezt a DNS-zónát. Erre a szerverre másodlagos DNS-kiszolgálóként hivatkozunk.

A másodlagos szerver a zónaátvitel során beszerzi a DNS-zónaadatbázis másolatát az elsődleges kiszolgálótól. A DNS zóna adatátvitelét a másodlagos szerverek kérik meghatározott időközönként. Ezeknek az időréseknek a hossza a SOA erőforrásrekord részeként van beállítva.

A DNS-zónaadatok kényszerfrissítését az rndc segédprogrammal kezdeményezheti. Az alábbi példa DNS-átvitelt kezdeményez a fred.local webhelyre, és kinyomtatja a / var / log / syslog naplófájl megfelelő részét.

[e-mail védett]: / etc / bind # rndc frissítés fred.local [e-mail védett]: / etc / bind # grep fred / var / log / syslog | farok -7 | vágott -c38- zóna fred.local / IN: értesítés küldése (soros 1) fogadott vezérlőcsatorna parancs "refresh fred.local" zóna fred.local / IN: Az átvitel megkezdődött. "fred.local / IN" átvitele 10.104.109.1 # 53: 10.104.33.30 # 57367 zónával csatlakoztatva fred.local / IN: átvitt 2. soros "fred.local / IN" átvitele 10.104.109.1 # 53-ról: Transfer # 53 kész: 1 üzenet, 10 rekord, 264 bájt, 0,001 mp (264000 bájt / mp) zóna fred.local / IN: értesítések küldése (2. soros) [e-mail védett]: / etc / bind #

Amikor másodlagos DNS-kiszolgálót ad hozzá egy DNS-zónához, beállíthatja azt az elsődleges kiszolgáló szolga DNS-kiszolgálójaként. Az elsődleges DNS-kiszolgáló a fő DNS-kiszolgáló lesz a másodlagos szerverhez képest.

Leggyakrabban az elsődleges DNS-kiszolgáló a főkiszolgáló, amely az összes szolgakiszolgálóval működik. Néha egy szolgakiszolgáló a következő szintű szolgakiszolgálók főkiszolgálójaként is működhet. Az alábbi ábrán az ns1 nevű kiszolgáló az elsődleges, az ns2, ns3 és ns4 nevű kiszolgálók pedig másodlagos kiszolgálók. Bár az ns1 az ns2 és ns3 mestere, az ns2 az ns4 mestere.

A SOA erőforrásrekord tartalmazza a frissítés nevű DNS-zóna frissítési gyakoriságát. Ha ez az érték 30 percre van állítva, a szolga szerver 30 percenként kérelmet küld a DNS zóna adatainak másolatának átvitelére. Ez a rekord egy újrapróbálkozás nevű időtúllépési időszak hosszának értékét is tartalmazza. Ez az érték akkor használatos, ha a főkiszolgáló nem válaszolt a legutóbbi DNS-zóna adatátviteli kérésére. Az expiry time nevű érték azt az időtartamot állítja be, ameddig a szolgakiszolgáló válaszolhat az ügyfelektől érkező kérésekre a DNS-zónaadatok frissítése nélkül.

A következő példa az nslookup segédprogram használatára mutat be egy DNS-zóna (linux-training.be) SOA-erőforrásrekord-adatainak beolvasását.

[e-mail védett]:~# nslookup > set type = SOA > szerver ns1.openminds.be > linux-képzés.be Szerver: ns1.openminds.be Cím: 195.47.215.14 # 53 linux-training.be origin = ns1.openminds.be levélcím = hostmaster.openminds.be soros = 2321001133 frissítés = 14430 =0 újra 1440 =0 újra 1440 6

A DNS zóna adatátvitelre csak a DNS zóna adatbázisokban bekövetkezett adatváltozások esetén kerül sor (vagyis egy vagy több erőforrásrekord hozzáadása, törlése vagy módosítása esetén a főkiszolgáló oldalon). A szolgakiszolgáló összehasonlítja a SOA-erőforrásrekord saját másolatának sorozatszámát a megfelelő főkiszolgáló SOA-erőforrásrekordjának verziószámával. Ha a verziószámok megegyeznek, nincs szükség adatfrissítésre (mivel más erőforrásrekord nem került hozzáadásra, eltávolításra vagy módosításra). Ugyanebben az esetben, ha a SOA-erőforrásrekord verziószáma a szolga szerver oldalon kisebb, mint ugyanazon rekord verziószáma a megfelelő főkiszolgáló oldalon, DNS-átviteli kérés történik.

Az alábbiakban a Wireshark szippantó ablak pillanatképe látható a DNS-zóna adatátvitele során elfogott adatokkal.

4.9. DNS-zónák teljes vagy részleges átvitele

A DNS-zóna adatátvitel lehet teljes vagy részleges. A mód használatára vonatkozó döntés az átvitt adatok mennyiségétől függ a DNS zóna adatbázisának teljes frissítéséhez a slave szerveren. A zónaadatok részleges átvitele előnyös, ha a megváltozott adatok teljes mennyisége kisebb, mint a teljes adatbázis mérete. A teljes DNS-zóna átvitel az AXFR protokollal, a részleges DNS-zónaátvitel pedig az IXFR protokoll használatával történik.

A WordPress 5.3 kiadása egy új blokkal, intuitívabb interakciókkal és jobb hozzáférhetőséggel javítja és bővíti a WordPress 5.0-ban bevezetett blokkszerkesztőt. Új funkciók a szerkesztőben [...]

Kilenc hónapos fejlesztés után elérhető az FFmpeg 4.2 multimédiás csomag, amely egy sor alkalmazást és egy könyvtár gyűjteményt tartalmaz a különféle multimédiás formátumokon végzett műveletekhez (rögzítés, konvertálás és [...]

Új funkciók a Linux Mint 19.2 Cinnamonban

A Linux Mint 19.2 egy hosszú távú támogatási kiadás, amely 2023-ig lesz támogatott. Frissített szoftverrel érkezik, fejlesztéseket és sok új [...]

Megjelent a Linux Mint 19.2 disztribúciója

Bemutatják a Linux Mint 19.2 disztribúciós készlet kiadását, a Linux Mint 19.x ág második frissítését, amely az Ubuntu 18.04 LTS csomagalapján alakult és 2023-ig támogatott. A disztribúció teljesen kompatibilis [...]

Új BIND-szolgáltatási kiadások érhetők el, amelyek hibajavításokat és funkciójavításokat tartalmaznak. Az új kiadások letölthetők a fejlesztő webhelyének letöltési oldaláról: [...]

Az Exim egy üzenetátviteli ügynök (MTA), amelyet a Cambridge-i Egyetemen fejlesztettek ki, az internethez csatlakozó Unix rendszereken való használatra. A [...]

Közel két évnyi fejlesztés után megjelent a ZFS on Linux 0.8.0, a ZFS fájlrendszer megvalósítása a Linux kernel moduljaként. A modult a 2.6.32-es Linux kernelekkel tesztelték [...]

A WordPress 5.1.1 javítja a webhelyvezérlési sebezhetőséget

Az internetes protokollok és architektúrák fejlesztésével foglalkozó Internet Engineering Task Force (IETF) befejezte az RFC kialakítását az Automatic Certificate Management Environment (ACME) protokollhoz [...]

A közösség által irányított, mindenki számára ingyenes tanúsítványt biztosító Let’s Encrypt non-profit tanúsító központ az elmúlt év eredményeit összegezte és a 2019-es tervekről beszélt. […]

Megjelent a Libreoffice új verziója - a Libreoffice 6.2

A DNS (Domain Name System) egy fontos és meglehetősen nehezen konfigurálható komponens, amely a weboldalak és szerverek működéséhez szükséges. Sok felhasználó a tárhelyszolgáltatója által biztosított DNS-szerverekhez fordul, azonban a saját DNS-szervernek van néhány előnye.

Ebből az oktatóanyagból megtudhatja, hogyan telepítheti a Bind9-et, és hogyan konfigurálhatja gyorsítótárazó vagy továbbítási DNS-kiszolgálóként egy Ubuntu 14.04-szerveren.

Követelmények

• A DNS-kiszolgálók alapvető típusainak megismerése. A részletekért lásd.
• Két gép, amelyek közül legalább egy Ubuntu 14.04 fut. Az első gép kliensként (IP-cím 192.0.2.100), a második pedig DNS-kiszolgálóként (192.0.2.1) lesz konfigurálva.

Megtanulja, hogyan konfigurálhat egy ügyfélgépet úgy, hogy DNS-kiszolgálón keresztül küldjön lekérdezéseket.

DNS-kiszolgáló gyorsítótárazása

Az ilyen típusú kiszolgálókat minősítőknek is nevezik, mivel rekurzív lekérdezéseket dolgoznak fel, és általában DNS-keresést is végezhetnek más szervereken.

Amikor a gyorsítótárazó DNS-kiszolgáló figyeli az ügyfél kérésére adott választ, visszaküldi a választ az ügyfélnek, és a gyorsítótárban is tárolja a megfelelő DNS-rekordok TTL-je által megengedett ideig. A gyorsítótár ezután válaszforrásként használható a következő kérésekre, hogy felgyorsítsa a kérések teljes feldolgozási idejét.

A hálózati konfigurációban szereplő szinte minden DNS-kiszolgáló gyorsítótárat fog tárolni. A gyorsítótárazó DNS-kiszolgáló sok helyzetre jó választás. Ha nem szeretne a tárhelyszolgáltató DNS-kiszolgálóira vagy más nyilvános DNS-kiszolgálóira hagyatkozni, állítsa be saját gyorsítótárazó DNS-kiszolgálóját. Minél kisebb a távolság a DNS-kiszolgáló és az ügyfélgépek között, annál rövidebb a DNS-lekérdezések kiszolgálási ideje.

DNS-kiszolgáló továbbítása

A kliens szemszögéből az átirányító DNS-kiszolgáló szinte teljesen megegyezik a gyorsítótárazó szerverrel, de a mechanizmusok és a munkaterhelés teljesen eltérő.

Az átirányító DNS-kiszolgáló ugyanazokkal az előnyökkel rendelkezik, mint a gyorsítótárazó kiszolgáló. Valójában azonban nem hajt végre rekurzív lekérdezést. Ehelyett minden kérést átirányít egy külső engedélyező kiszolgálóra, majd gyorsítótárazza az eredményeket a következő kérésekhez.

Ez lehetővé teszi az átirányítási kiszolgáló számára, hogy a gyorsítótárból kiszolgálja a kéréseket a rekurzív kérések feldolgozása nélkül. Így ez a szerver csak egyes kéréseket (átirányított ügyfélkérelmeket) kezel, és nem a teljes rekurziós eljárást. Ez előnyös lehet olyan környezetekben, ahol a külső sávszélesség korlátozott, ahol a gyorsítótárazó szervereket gyakran kell cserélni, és olyan helyzetekben, amikor a helyi kéréseket át kell irányítani az egyik szerverre, a külső kéréseket pedig egy másikra.

1. lépés – A Bind telepítése DNS-kiszolgálóra

A Bind csomag megtalálható a hivatalos Ubuntu tárolóban. Frissítse a csomagindexet, és telepítse a Bind alkalmazást az apt manager segítségével. Ezenkívül telepítenie kell néhány függőséget.

sudo apt-get frissítés
sudo apt-get install bind9 bind9utils bind9-doc

Ezt követően megkezdheti a szerver konfigurálását. A gyorsítótárazó kiszolgáló konfigurációját használhatja sablonként egy továbbítási kiszolgáló konfigurálásához, ezért először egy gyorsítótárazó DNS-kiszolgálót kell konfigurálnia.

2. lépés - gyorsítótárazó DNS-kiszolgáló konfigurálása

Először is be kell állítania a Bindot gyorsítótárazó DNS-kiszolgálóként. Ez a konfiguráció arra készteti a kiszolgálót, hogy rekurzív módon választ keressen az ügyféllekérdezésekre más DNS-kiszolgálókon. Sorban lekérdezi az összes releváns DNS-kiszolgálót, amíg választ nem talál.

A kötési konfigurációs fájlok az / etc / bind könyvtárban tárolódnak.

A legtöbb fájlt nem kell szerkeszteni. A fő konfigurációs fájl neve named.conf (a named és a bind ugyanazon alkalmazás két neve). Ez a fájl a named.conf.options, named.conf.local és named.conf.default-zones fájlokra vonatkozik.

A gyorsítótárazó DNS-kiszolgáló konfigurálásához csak a named.conf.options fájlt kell szerkesztenie.

sudo nano named.conf.options

Ez a fájl így néz ki (a megjegyzéseket az egyszerűség kedvéért kihagytuk):

opciók (
könyvtár "/ var / cache / bind";
dnssec-validation auto;

listen-on-v6 (bármilyen;);
};

Gyorsítótárazó kiszolgáló beállításához létre kell hoznia egy hozzáférés-vezérlési listát vagy ACL-t.

Meg kell védenie a DNS-kiszolgálót, amely feldolgozza a támadóktól származó rekurzív lekérdezéseket. A DNS-erősítő támadások különösen veszélyesek, mert bevonhatják a szervert az elosztott szolgáltatásmegtagadási támadásokba.

A DNS-erősítő támadások a szerverek és webhelyek leállításának egyik módja. Ennek érdekében a támadók megpróbálnak nyilvános DNS-kiszolgálókat találni, amelyek rekurzív lekérdezéseket dolgoznak fel. Meghamisítják az áldozat IP-címét, és egy kérést küldenek, amely igen terjedelmes választ küld a DNS-kiszolgálónak. Ebben az esetben a DNS-szerver túl sok adatot ad vissza az áldozat szerverének egy kis kérésre, megnövelve a támadó elérhető sávszélességét.

Nyilvános rekurzív DNS-kiszolgáló üzemeltetése gondos konfigurációt és adminisztrációt igényel. A kiszolgáló veszélyeztetésének elkerülése érdekében állítsa be azoknak az IP-címeknek vagy hálózati tartományoknak a listáját, amelyekben a szerver megbízhat.

A beállítások blokk előtt adjon hozzá egy ACL blokkot. Hozzon létre egy címkét az ACL-csoporthoz (ebben az oktatóanyagban a csoport neve goodclients).

acl jó ügyfelek (
};
opciók (
. . .

Ebben a blokkban sorolja fel azokat az IP-címeket vagy hálózatokat, amelyek hozzáférhetnek ehhez a DNS-kiszolgálóhoz. Mivel a szerver és a kliens / 24 alhálózaton fut, korlátozhatja az alhálózathoz való hozzáférést. Fel kell oldania a localhost és a localnet blokkolását is, amelyek automatikusan csatlakoznak.

acl jó ügyfelek (
192.0.2.0/24;
helyi kiszolgáló;
helyi hálózatok;
};
opciók (
. . .

Most már van egy biztonságos kliens ACL-je. A kérésfeloldás konfigurálását a beállítások blokkban kezdheti el. Adja hozzá a következő sorokat:

opciók (
könyvtár "/ var / cache / bind";
rekurzió igen;

. . .

A beállításblokk kifejezetten engedélyezi a rekurziót, majd beállítja az allow-query paramétert az ACL használatára. Egy másik paraméterrel is hivatkozhat egy ACL-csoportra, például az engedélyezési rekurzióra. Ha a rekurzió engedélyezve van, az engedélyezés-rekurzió meghatározza azon ügyfelek listáját, amelyek rekurzív szolgáltatásokat használhatnak.

Ha azonban az allow-recursion paraméter nincs beállítva, a Bind visszakerül az allow-query-cache listába, majd az engedélyezési lekérdezés listába, végül pedig az alapértelmezett helyi hálózatok és helyi gazdagépek listáira. Mivel csak a gyorsítótárazó szervert konfiguráljuk (nincs saját zónái, és nem továbbítja a kéréseket), az engedélyezési lekérdezés lista mindig csak a rekurzióra vonatkozik. Ez a legáltalánosabb módja az ACL-ek meghatározásának.

Mentse és zárja be a fájlt.

Ezeket a beállításokat hozzá kell adni a gyorsítótárazott DNS-kiszolgáló konfigurációs fájljához.

jegyzet: Ha csak ezt a típusú DNS-t szeretné használni, ellenőrizze a konfigurációkat, indítsa újra a szolgáltatást és konfigurálja a klienst.

3. lépés – Továbbított DNS-kiszolgáló beállítása

Ha egy DNS-továbbítási kiszolgáló megfelelőbb az infrastruktúrához, érdemes lehet kissé módosítani a beállítást.

Jelenleg a named.conf.options fájl így néz ki:

acl jó ügyfelek (
192.0.2.0/24;
helyi kiszolgáló;
helyi hálózatok;
};
opciók (
könyvtár "/ var / cache / bind";
rekurzió igen;
enable-query (jókliensek;);
dnssec-validation auto;
auth-nxdomain nem; # megfelel az RFC1035 szabványnak
listen-on-v6 (bármilyen;);
};

Ugyanezzel az ACL-lel korlátozhatja a DNS-kiszolgálót az ügyfelek meghatározott listájára. Ehhez azonban néhány konfigurációs módosításra van szükség, hogy a szerver többé ne próbáljon meg rekurzív lekérdezéseket végrehajtani.

Ne módosítsa a rekurziót no-ra. Az átirányító szerver támogatja a rekurzív szolgáltatásokat. Átirányítási kiszolgáló beállításához létre kell hoznia a gyorsítótárazó kiszolgálók listáját, amelyekre a kéréseket továbbítja.

Ez az opciók () blokkban történik. Először is létre kell hozni benne egy új továbbító blokkot, amely eltárolja azoknak a rekurzív névszervereknek az IP-címeit, amelyekre a kéréseket át akarja irányítani. Ebben az esetben ezek a Google DNS-kiszolgálói (8.8.8.8 és 8.8.4.4):

. . .
opciók (
könyvtár "/ var / cache / bind";
rekurzió igen;
enable-query (jókliensek;);
szállítmányozók (

8.8.8.8;

8.8.4.4;

};
. . .

Ennek eredményeként a konfiguráció így néz ki:

acl jó ügyfelek (
192.0.2.0/24;
helyi kiszolgáló;
helyi hálózatok;
};
opciók (
könyvtár "/ var / cache / bind";
rekurzió igen;
enable-query (jókliensek;);
szállítmányozók (
8.8.8.8;
8.8.4.4;
};
csak előre;
dnssec-validation auto;
auth-nxdomain nem; # megfelel az RFC1035 szabványnak
listen-on-v6 (bármilyen;);
};

Az utolsó módosítás a dnssec paraméterre vonatkozik. Az aktuális konfiguráció mellett és a kéréseket átirányító DNS-kiszolgálók beállításaitól függően a következő hibák jelenhetnek meg a naplókban:

jún. 25. 15:03:29 gyorsítótár neve: hiba (chase DS szerverek) az "in-addr.arpa/DS/IN" megoldása során: 8.8.8.8 # 53
jún. 25. 15:03:29 gyorsítótár neve: hiba (nincs érvényes DS) a "111.111.111.111.in-addr.arpa/PTR/IN" megoldása során: 8.8.4.4 # 53

Ezek elkerülése érdekében módosítsa a dnssec-validation paramétert yes-re, és kifejezetten engedélyezze a dnssec-et.

. . .
csak előre;
dnssec-enable igen;
dnssec-validation igen;
auth-nxdomain nem; # megfelel az RFC1035 szabványnak
. . .

Mentse és zárja be a fájlt. A továbbító DNS-kiszolgáló most konfigurálva van.

4. lépés: A beállítások ellenőrzése és a Bind újraindítása

Most meg kell győződnie arról, hogy a beállítások a várt módon működnek.

A konfigurációs fájlok szintaxisának ellenőrzéséhez írja be:

sudo named-checkconf

Ha nincs hiba a fájlokban, a parancssor nem jelenít meg semmilyen kimenetet.

Ha hibaüzenetet kap, javítsa ki, és ellenőrizze újra.

Ezután újraindíthatja a Bind démont a beállítások frissítéséhez.

sudo service bind9 újraindítás

Ezután ellenőriznie kell a szervernaplókat. Futtassa a parancsot a szerveren:

sudo tail -f / var / log / syslog

Most nyisson meg egy új terminált, és folytassa az ügyfélgép konfigurálásával.

5: kliens beállítása

Jelentkezzen be az ügyfélgépre. Győződjön meg arról, hogy az ügyfél szerepel a konfigurált DNS-kiszolgáló ACL-csoportjában. Ellenkező esetben a DNS-kiszolgáló megtagadja az ügyfél kérésének kiszolgálását.

Szerkessze az /etc/resolv.conf fájlt úgy, hogy a kiszolgálót a névszerverre irányítsa.

Az itt végrehajtott változtatások csak az újraindításig maradnak fenn, ami tesztelésre kiváló. Ha elégedett a tesztbeállítás eredményével, ezeket a beállításokat állandóvá teheti.

Nyissa meg a fájlt sudo segítségével egy szövegszerkesztőben:

sudo nano /etc/resolv.conf

A fájlnak fel kell sorolnia azokat a DNS-kiszolgálókat, amelyeket a kérések megoldására használunk. Ehhez használja a nameserver direktívát. Írja megjegyzésbe az összes jelenlegi bejegyzést, és adjon hozzá egy névszerver sort, amely a DNS-kiszolgálóra mutat:

névszerver 192.0.2.1
# névszerver 8.8.4.4
# névszerver 8.8.8.8
# névszerver 209.244.0.3

Mentse és zárja be a fájlt.

Most tesztkérést küldhet annak ellenőrzésére, hogy a probléma megfelelően megoldódott-e.

Ehhez használhatja a ping parancsot:

ping -c 1 google.com
PING google.com (173.194.33.1) 56 (84) bájtnyi adat.
64 bájt a sea09s01-in-f1.1e100.net (173.194.33.1) fájlból: icmp_seq = 1 ttl = 55 idő = 63,8 ms
--- google.com ping statisztika ---
1 csomag elküldve, 1 fogadott, 0% csomagvesztés, idő 0 ms
rtt min / átlag / max / mdev = 63,807 / 63,807 / 63,807 / 0,000 ms

Az internet sebessége – mind az utolsó mérföld, mind a főbb csatornák – minden évben egyre nagyobb. Csak egy dolog változtathatatlan – a késleltetés már a fizikai korlátokba ütközött: a fénysebesség az üvegszálban körülbelül 200 ezer kilométer per másodperc, és ennek megfelelően ~ 150 ms-nál gyorsabban nem érkezik válasz az Atlanti-óceánon túli szerverről. belátható időn belül (bár persze vannak olyan élvezetek, mint a légmagos optikai szál vagy a rádiórelé kommunikáció, de ez az egyszerű halandók számára aligha elérhető).

Amikor például Oroszországból megpróbálunk megnyitni egy USA-ban található webhelyet (az NS szerverei valószínűleg ugyanott vannak), és a domain nem található a szolgáltató DNS-gyorsítótárában, akkor várnunk kell egy gigabites interneten is hosszú ideig, talán egy egész másodpercig: míg mi az óceánon túl, megkapjuk a domain NS-szervereinek nevét, miközben levágjuk az IP-jüket, miközben magát a DNS-kérést küldjük és fogadjuk. ..

Néhány éve a Google elindította saját nyilvános DNS-szervereit, és az ezekre való átállás ösztönzésére kifejlesztették a NameBench segédprogramot, amely DNS-teszteket futtat a szörfözési előzményeken, és megmutatja, mennyivel gyorsabb a Google DNS, mint az internetszolgáltató DNS-kiszolgálója.

De sikerült elkészítenem egy saját DNS-szervert, ami gyorsabban működik, mint a Google Public DNS, és ebben a rövid megjegyzésben szeretném megosztani az eredményeket.

PDNSD

pdnsd- DNS-proxy gyorsítótárazása. A DNS-kérelmek banális gyorsítótárazásán túl (a minimális TTL merev beállításával - nagyon rossz interneten ez szükséges lehet) képes egyidejűleg kérelmet küldeni több "szülő" DNS-kiszolgálónak, és megadni a ügyfél az első választ küldte vissza.

A párhuzamos szavazás alkalmazása jelenti a fő előnyt a gyorsaság terén. mivel Ha valamelyik szolgáltató gyorsítótárában megtalálható az eredmény, nagyon gyorsan megkapjuk az eredményt, és nem számítunk teljes és lassú felbontásra, ha az első szolgáltató nem válaszol a gyorsítótárban.

Az Ubuntu - a banális apt-get -be van telepítve.

Pár pont a konfigurációban

global (perm_cache = 10240; // A gyorsítótár maximális mérete kilobájtban. // Alapértelmezés szerint 1024 volt, az összes rekordot nem zavarták meg. cache_dir = "/ var / cache / pdnsd"; [...] min_ttl = 60m; // A bejegyzés gyorsítótárba mentéséhez szükséges minimális idő. // Még ha a TTL 60 percnél rövidebb idő alatt érkezik is, 60 perc lesz max_ttl = 1w // A bejegyzés gyorsítótárba való mentésének maximális ideje neg_ttl = 5m; // A negatív válaszok gyorsítótárazásának ideje (vagyis ha a tartomány nem található) [..] par_queries = 3; // Az egyidejűleg lekérdezett "szülő" DNS-kiszolgálók száma) szerver (címke = "fő"; ip = 85.21.192.5 // 4 szerver van, ha az első 3 nem válaszol, akkor a rendszer kérést küld a 4.-re, 213.234.192.7 // Az első 2 szerver a szolgáltatód szervere, és néhány szomszédé, a 8.8.4.4 // Ez a Google nyilvános DNS - minden ritka gyorsítótárban van, és gyorsan megoldják, 8.8.8.8; [.. ])

A gyorsítótárazást elvileg kevésbé agresszívvé lehet tenni (min_ttl = 1m pl.), de a munkaév során nem volt különösebb probléma. Probléma esetén - ha szeretné, törölhet egy bejegyzést a gyorsítótárból:
sudo pdnsd-ctl rekord 3.14. törléssel vagy egyszerre:
sudo pdnsd-ctl üres gyorsítótár

Teszt eredmények a NameBenchben

Azt látjuk, hogy a kérések 50%-ára kevesebb, mint 10 ms alatt kapunk választ, 85%-kal gyorsabban, mint a Google nyilvános DNS-e, majd az eredmények természetesen egybeesnek a Google-lel.

A teszteredmények alapján a NameBench örömmel tudatja velünk:

8.8.8.8 A SYS-192.167.0.98 lassabb replikája 8.8.4.4 A SYS-192.167.0.98 lassabb replikája

Így egy intelligens gyorsítótárazású DNS-proxy párhuzamos kérésekkel akár 100 megabites internetet is felgyorsíthat. A lassú (rádió) kapcsolatoknál pedig nagy késleltetéssel és csomagvesztéssel a különbség olyan lehet, mint ég és föld között.