29.6. Névfeloldás (DNS)
Vissza | 29. fejezet - Hálózati szerverek | Előre

## 29.6. Névfeloldás (DNS)

Készítette: Lee, Chern, Rhodes, Tom és Gerzo, Daniel.

### 29.6.1. Áttekintés

A FreeBSD alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a `www.FreeBSD.org` névre a FreeBSD Projekt webszerverének IP-címét kapjuk meg, miközben a `ftp.FreeBSD.org` pedig a hozzá tartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön.

A FreeBSD jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplő változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált chroot(8) beállítást is magában foglal.

Az interneten keresztüli névfeloldást legfelső szintű tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak.

A BIND fejlesztését jelenleg az Internet Systems Consortium (http://www.isc.org/) felügyeli.

### 29.6.2. Alapfogalmak

A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat.

Fogalom | Meghatározás
--- | ---
Közvetlen névfeloldás (forward DNS) | A hálózati nevek leképezése IP-címekre.
ős (origin) | Egy adott zóna állományban szereplő tartományra vonatkozik.
named, BIND | A FreeBSD-n belüli BIND névszerver különböző megnevezései.
Névfeloldó (resolver) | Az a program a rendszerben, amelyhez a hálózaton levő gépek a zónák adatainak elérésével kapcsolatban fordulnak.
Inverz névfeloldás (reverse DNS) | Az IP-címek leképzése hálózati nevekre.
Gyökérzóna (root zone) | Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba.
Zóna (zone) | Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban.

Példák zónákra:

- A gyökérzónára a leírásokban általában `.` néven szoktak hivatkozni.

- A `org.` egy legfelső szintű tartomány (TLD) a gyökérzónán belül.

- A `minta.org.` a `org.` TLD tartomány alatti zóna.

- A `1.168.192.in-addr.arpa` egy olyan zóna, amelyek a `192.168.1.*` IP-címtartományban szereplő összes címet jelöli.

Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a `minta.org.` sokkal pontosabb meghatározás, mint a `org.`, ahogy az `org.` magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a `/dev` könyvtár a gyökéren belül található, és így tovább.

### 29.6.3. Miért érdemes névszervert futtatni

A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver.

Egy hitelesített névszerverre akkor van szükségünk, ha:

- a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni;

- regisztráltunk egy tartományt (például `minta.org`) és az alatta levő hálózati nevekhez is szeretnénk IP-címeket rendeltetni;

- a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címből ad meg hálózati nevet) is;

- a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell.

A gyorsítótárazó névszerverre akkor van szükségünk, ha:

- egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külső névszerver felé irányuló kérések kiszolgálását.

Amikor valaki lekérdezi a `www.FreeBSD.org` címét, akkor a névfeloldó először általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külső névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belső hálózatunkat, mivel a válasz szerepel a gyorsítótárban.

### 29.6.4. Ahogyan működik

FreeBSD alatt a BIND démon nyilvánvaló okokból named néven érhető el.

Állomány | Leírás
--- | ---
named(8) | A BIND démon.
rndc(8) | A névszervert vezérlő segédprogram.
`/etc/namedb` | A BIND által kezelt zónák adatait tároló könyvtár.
`/etc/namedb/named.conf` | A démon konfigurációs állománya.

Attól függően, hogy miként állítjuk be az adott zónát a szerveren, a hozzá tartozó állományok a `/etc/namedb` könyvtáron belül a `master`, `slave` vagy `dynamic` alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levő névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre.

### 29.6.5. A BIND elindítása

Mivel a BIND alapból elérhető a rendszerben, viszonylag könnyen be tudjuk állítani.

A named alapértelmezett beállítása szerint egy chroot(8) környezetben futó egyszerű névfeloldást végző szerver, amely a helyi IPv4 interfészen (127.0.0.1) fogadja a kéréseket. Ezzel a beállítással a következő parancson keresztül tudjuk elindítani:

`#` `/etc/rc.d/named onestart`

Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következő sort az `/etc/rc.conf` állományba:

named_enable="YES"

Értelemszerűen az `/etc/namedb/named.conf` tele van olyan beállítási lehetőségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a FreeBSD-ben a named indításához használt beállításokra, akkor az `/etc/defaults/rc.conf` állományban nézzük meg `named_`*`` változókat és olvassuk át az rc.conf(5) man oldalt. Emellett még a 11.7. szakasz - Az rc használata FreeBSD alattt is hasznos lehet elolvasni.

### 29.6.6. A konfigurációs állományok

A named beállításait tartalmazó állományok pillanatnyilag az `/etc/namedb` könyvtárban találhatóak és hacsak nem egy egyszerű névfeloldóra tartunk igényt, akkor a használata előtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét.

#### 29.6.6.1. `/etc/namedb/named.conf`

// $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétől, vagy másrészt felesleges forgalmat tudunk // generálni // options { // A chroot könyvtárhoz relatív elérési út, amennyiben létezik directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésből. // A hálózatunk többi részéről pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; // Az alábbi zónákat már a lentebb található üres zónák eleve lefedik. // Ha tehát a lenti üres zónákat kivesszük a konfigurációból, akkor // ezeket a sorokat is tegyük megjegyzésbe. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Ha a szolgáltatónk névszervert is elérhetővé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; * // Ha a 'forwarders' rész nem üres, akkor alapértelmezés szerint a // 'forward first' értékkel rendelkezik. Ekkor a kérést a helyi szerver // kapja abban az esetben, amikor a 'forwarders' részben megadott // szerverek nem tudják megválaszolni. Emellett a névszerverben a // következő sor hozzáadásával letilthatjuk, hogy önmagától ne // kezdeményezzen kéréseket: // forward only; // Ha a kérések továbbítását az /etc/resolv.conf állományban megadott // bejegyzések mentén szeretnénk automatikusan konfigurálni, akkor vegyük // ki a megjegyzésből az alábbi sort és adjuk hozzá az /etc/rc.conf // állományhoz a name_auto_forward=yes sort. Emellett használható még a // named_auto_forward_only beállítás is (amely fentebb leírt funkciót // valósítja meg). // include "/etc/namedb/auto_forward.conf";

Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a `forwarders` beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban először a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk.

### Figyelem:

Itt a `127.0.0.1` megadása nem működik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére.

/* A BIND legújabb változataiban alapértelmezés szerint minden egyes kimenő kérésnél más, véletlenszerűen választott UDP portot használnak, ezáltal jelentős mértékben csökkenthető a gyorsítótár meghamisíthatóságának (cache poisoning) esélye. Javasoljuk mindenkinek, hogy használják ki ezt a lehetőséget és eszerint állítsák be a tűzfalakat. Ha nem sikerül a tűzfalat hozzáigazítani ehhez a viselkedéshez AKKOR ÉS CSAK IS AKKOR engedélyezzük a lenti beállítást. Alkalmazásával sokkal kevésbé lesz ellenálló a névszerver a különböző hamisítási kísérletekkel szemben, ezért lehetőség szerint kerüljük el. Az NNNNN helyére egy 49160 és 65530 közti számot kell beírnunk. */ // query-source address * port NNNNN; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban első helyen megadni a 127.0.0.1 címet. Sőt, az // /etc/rc.conf állományból se felejtsük ki. // A hagyományos "root-hints" megoldás. Használjuk ezt VAGY a lentebb // megadott alárendelt zónákat. zone "." { type hint; file "named.root"; }; /* Több szempontból is előnyös, ha a következő zónákat alárendeljük a gyökér névfeloldó szervereknek: 1. A helyi felhasználók kéréseit gyorsabban tudjuk feloldalni. 2. A gyökérszerverek felé nem megy semmilyen hamis forgalom. 3. A gyökérszerverek meghibásodása vagy elosztott DoS támadás esetén rugalmasabban tudunk reagálni. Másfelöl azonban ez a módszer a "hints" állomány alkalmazásával szemben több felügyeletet igényel, mivel figyelnünk kell, nehogy egy váratlan meghibásodás működésképtelenné tegye a szerverünket. Ez a megoldás leginkább a sok klienst kiszolgáló névszerverek esetén bizonyulhat jövedelmezőbbnek. Óvatosan bánjunk vele! A módszer alkalmazásához vegyük ki a megjegyzésből a következő bejegyzéseket és tegyük megjegyzésbe a fenti hint zónát. */ zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; } zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Az alábbi zónák helyi kiszolgálásával meg tudjuk akadályozni, hogy a belőlük indított kérések elhagyják a hálózatunkat és a elérjük a gyökér névfeloldó szervereket. Ez a megközelítés két komoly előnnyel rendelkezik: 1. A helyi felhasználók kéréseit gyorsabban tudjuk megválaszolni. 2. A gyökérszerverek felé nem továbbítódik semmilyen hamis forgalom. */ // RFC 1912 zone "localhost" { type master; file "master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; // A helyi IPv6 címek részére létrehozott RFC 1912-szerű zóna zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; // "Ez" a hálózat (RFC 1912 és 3330) zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; // Magáncélú hálózatok (RFC 1918) zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Helyi link/APIPA (RFC 3330 és 3927) zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; // Dokumentációs próbahálózat (RFC 3330) zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Útválasztási teljesítmény tesztelésére (RFC 3330) zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; }; // Az IANA részére fentartott - a régi E osztályú címtér zone "240.in-addr.arpa" { type master; file "master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "master/empty.db"; }; // Hozzárendelés nélküli IPv6-címek (RFC 4291) zone "1.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.ip6.arpa" { type master; file "master/empty.db"; }; zone "c.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "master/empty.db"; }; // IPv6 helyi link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Elavult IPv6 helyi címek (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; }; // Az IP6.INT már elavult (RFC 4159) zone "ip6.int" { type master; file "master/empty.db"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is // tartozik. Az elsődleges névszerverhez tartozó IP-címet érdeklődjük meg // az illetékes hálózati rendszergazdától. // // Soha ne felejtsünk el megadni zónát az inverz kereséshez! A neve az IP-cím // tagjainak fordított sorrendjéből // származik, amelyhez hozzátoldunk még egy // ".IN-ADDR.ARPA" (illetve IPv6 esetén ".IP6.ARPA") részt. // // Mielőtt nekilátnánk egy elsődleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelő szinten ismerjük a névfeloldás és // a BIND működését. Gyakran ugyanis egyáltalán nem nyilvánvaló // csapdákba tudunk esni. Egy alárendelt zóna beállítása általában sokkal egyszerűbb feladat. // // FONTOS: Ne kövessük vakon a most következő példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ /* Példa inverz alárendelt zónákra zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */

A `named.conf` állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat.

Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a `named.conf` állományban.

Például a `minta.org` címhez tartozó legegyszerűbb ilyen bejegyzés így néz ki:

zone "minta.org" { type master; file "master/minta.org"; };

Ez egy központi zóna, ahogy arról a `type` mező, vagyis a típusa is árulkodik. Továbbá a `file` mezőben láthatjuk, hogy a hozzá tartozó információkat az `/etc/namedb/master/minta.org` állományban tárolja.

zone "minta.org" { type slave; file "slave/minta.org"; };

Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétől kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhető el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket.

#### 29.6.6.2. A zóna állományok

A `minta.org` címhez tartozó példa központi zóna állomány (amely az `/etc/namedb/master/néven.org` érhető el) tartalma az alábbi:

$TTL 3600 ; alapértelmezés szerint 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ; TTL negatív válasz ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek www IN CNAME minta.org.

A „.”-ra végződő hálózati nevek abszolút nevek, míg minden más „.” nélküli név az ősére vezehető vissza (tehát relatív). Például az `ns1` névből az `ns1.`minta.org`` keletkezik.

A zóna állományok felépítése a következő:

rekordnév IN rekordtípus érték

A névfeloldásban leggyakrabban alkalmazott rekordok típusai:

SOA

  a zóna fennhatóságának kezdete

NS

  egy hitelesített névszerver

A

  egy gép címe

CNAME

  egy álnév kanonikus neve

MX

  levélváltó

PTR

  mutató a tartománynévre (az inverz feloldás használja)

minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le 300 ) ; TTL negatív válasz

`minta.org.`

  a tartomány neve, amely egyben a zóna őse

`ns1.minta.org.`

  a zóna elsődleges/hitelesített névszervere

`admin.minta.org.`

  a zónáért felelős személy neve, akinek az e-mail címét a „@” behelyettesítésével kapjuk meg. (Tehát a `<admin@example.org>` címből `admin.example.org` lesz.)

`2006051501`

  az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot `ééééhhnnvv` alakban adják meg. A `2006051501` tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a `01` pedig arra utal, hogy aznap először. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára.

IN NS ns1.minta.org.

Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének.

localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5

Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az `ns1.minta.org` név a `192.168.1.2` címre képződik le.

IN A 192.168.1.1

Ez a sor `192.168.1.1` címet rendeli az aktuális őshöz, amely jelen esetünkben az `example.org`.

www IN CNAME @

A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a `www` a „főgép” egyik álneve, amely itt éppenséggel a `minta.org` (`192.168.1.1`) tartományneve. A CNAME rekordok mellé más típusú rekordokat ugyanarra a hálózati névre soha ne adjunk meg.

IN MX 10 levelezes.minta.org.

Az MX rekord adja meg, hogy milyen levelező szerverek felelősek a zónába érkező levelek fogadásáért. A `levelezes.minta.org` a levelező szerver hálózati neve, ahol a 10 az adott levelező szerver prioritása.

Több levelező szerver is megadható 10-es, 20-as stb. prioritásokkal. A `minta.org` tartományon belül először mindig a legnagyobb MX prioritással rendelkező levelező szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkező rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük.

Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett.

$TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat 300 ) ; TTL negatív válasz IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org.

Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését.

Érdemes megemlíteni, hogy a PTR rekordok jobb oldalán álló nevek mindegyikének teljes hálózati névnek kell lennie (vagyis „.” karakterrel kell végződnie).

### 29.6.7. A gyorsítótárazó névszerver

A gyorsítótárazó névszerver az a névszerver, amely elsődleges feladata a rekurzív kérések kiszolgálása. Egyszerűen továbbítja a beérkező kéréseket, majd megjegyzi azokat, így később közvetlenül tud válaszolni.

### 29.6.8. Biztonság

Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket.

A FreeBSD azonban a named démont automatikusan egy chroot(8) környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat.

Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a FreeBSD security notifications levelezési lista címére, hogy folyamatosan értesüljünk az interneten és a FreeBSD-ben talált különböző biztonsági hibákról.

### Tipp:

Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával.

### 29.6.9. Egyéb olvasnivalók

A BIND/named man oldalai: rndc(8) named(8) named.conf(5)

- Az ISC BIND hivatalos honlapja (angolul)

- Az ISC BIND hivatalos fóruma (angolul)

- O'Reilly DNS and BIND 5th Edition

- RFC1034 - Domain Names - Concepts and Facilities

- RFC1035 - Domain Names - Implementation and Specification

Vissza | Fel | Előre
29.5. A hálózat automatikus beállítása (DHCP) | Főoldal | 29.7. Az Apache webszerver

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.