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.
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.
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.
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.
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.
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.
// $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.
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.
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:
a zóna fennhatóságának kezdete
egy hitelesített névszerver
egy gép címe
egy álnév kanonikus neve
levélváltó
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).
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.
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.
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.
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>.