2206 lines
94 KiB
Plaintext
2206 lines
94 KiB
Plaintext
|
|
DNS HOGYAN
|
|
|
|
Nicolai Langfeldt (dns-howto[at]langfeldt.net), Jamie Norrish és mások
|
|
|
|
v9.0, 2001.12.20
|
|
_________________________________________________________________
|
|
|
|
HOGYAN legyünk rövid idő alatt DNS-adminisztrátorok.
|
|
_________________________________________________________________
|
|
|
|
1. Előszó
|
|
|
|
Kulcsszavak: DNS, BIND, BIND 4, BIND 8, BIND 9, named, dialup, PPP,
|
|
slip, ISDN, Internet, domain, name, resolution, hosts, caching.
|
|
|
|
Ez a dokumentum a Linux Dokumentációs Projekt része.
|
|
|
|
1.1 Szerzői jog
|
|
|
|
(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Ne
|
|
változtasd a szerzői jogi rész helyesbítése nélkül, terjeszd
|
|
szabadon, de tartsd meg a szerzői jogi megjegyzést.
|
|
|
|
1.2 Köszönetnyilvánítások és segítségkérés
|
|
|
|
Meg szeretném köszönni mindenkinek, akit zavartam e HOGYAN olvasásával
|
|
(ők tudják), és az összes olvasónak, akik javaslataikat és
|
|
megjegyzéseiket elküldték levélben.
|
|
|
|
Ez soha nem lesz egy végleges dokumentum; kérlek, küldj egy levelet
|
|
problémáidról és sikereidről. Ezzel jobbá teheted ezt a HOGYANt.
|
|
Kérlek, a megjegyzéseidet és/vagy kérdéseidet vagy a pénzt küldd a
|
|
janl@langfeldt.net <janl@langfeldt.net> címre. Vagy vedd meg a DNS
|
|
könyvemet (a címe "The Concise Guide to DNS and BIND", az
|
|
irodalomjegyzékben megtalálhatók az ISBN számok). Ha levelet küldesz,
|
|
és szeretnél választ rá, kérlek, mutass egy kis udvariasságot azzal,
|
|
hogy megbizonyosodsz róla, hogy a válaszcím helyes és működik.
|
|
Kérlek, olvasd el a [1]Kérdések és válaszok fejezetet, mielőtt írsz
|
|
nekem. Egy másik dolog, hogy csak norvégül és angolul értek.
|
|
|
|
Ez egy HOGYAN. 1995 óta tartottam karban, az LDP részeként. 2000
|
|
folyamán megírtam egy könyvet hasonló tárggyal. Szeretném elmondani,
|
|
hogy bár ez a HOGYAN sok tekintetben olyan, mint egy könyv, ez nem a
|
|
letisztázott, piacra készített könyvváltozat. Ezen HOGYAN olvasói
|
|
segítettek annak felismerésében, hogy mi az, amit nehéz megérteni a
|
|
DNS-ről. Ez segített a könyv megírásában, de a könyv szintén segített
|
|
többet gondolkodnom azon, hogy ennek a HOGYANnak mire van szüksége. A
|
|
HOGYAN hozta létre a könyvet. A könyv hozta létre e HOGYAN 3-as
|
|
változatát. Köszönetem a könyvkiadónak, Que-nak, aki adott egy esélyt
|
|
:-)
|
|
|
|
1.3 Ajánlás
|
|
|
|
Ajánlom ezt a HOGYANt Anne Line Norheim Langfeldt-nek. Bár ő
|
|
valószínűleg soha sem fogja elolvasni, mert nem az a fajta lány.
|
|
|
|
1.4 Frissített változatok
|
|
|
|
Eme HOGYAN frissített változatait megtalálhatod a
|
|
[2]http://langfeldt.net/DNS-HOWTO/ és a [3]http://www.tldp.org/
|
|
oldalon is. Olvasd el azokat is, ha ez a dokumentum 9 hónapnál
|
|
öregebb.
|
|
|
|
1.5 Magyar fordítás
|
|
|
|
A magyar fordítást [4]Füri Zoltán készítette (2003.05.06). A
|
|
lektorálást [5]Szíjjártó László végezte el (2003.07.01). Bármilyen
|
|
fordítással kapcsolatos észrevételt a [6]linuxhowto@sch.bme.hu címre
|
|
küldjetek. Eme dokumentum legfrissebb változata megtalálható a
|
|
[7]Magyar Linux Dokumentációs Projekt honlapján.
|
|
|
|
2. Bevezetés
|
|
|
|
Mi ez, és mi nem
|
|
|
|
A DNS a Domain Name Server (Domain Név Szerver). A DNS átalakítja a
|
|
gépneveket IP címekké, amellyel minden hálózati gép rendelkezik. A
|
|
nevet címmé, és a címet névvé fordítja (vagy "mappeli", ahogy a
|
|
zsargon hívja), és még egyéb feladatokat is ellát. Ez a HOGYAN azt
|
|
dokumentálja, hogyan definiáljunk ilyen megfeleltetéseket Unix
|
|
rendszer használatával, pár Linux-specifikus dologgal együtt.
|
|
|
|
A mappelés egy egyszerű megfeleltetés két dolog között, ez esetben
|
|
egy gépnév, például /ftp.linux.org/, és a gép IP száma (vagy címe),
|
|
199.249.150.4 között. A DNS szintúgy tartalmazza a másik irányú
|
|
megfeleltetést is IP számból gépnévvé; ennek neve "fordított
|
|
megfeleltetés" (reverse mapping).
|
|
|
|
A DNS, a beavatatlanok számára (ez vagy te ;-), a hálózati
|
|
adminisztráció egyik legködösebb területe. Szerencsére a DNS valójában
|
|
nem ilyen nehéz. Ez a HOGYAN megpróbál egy pár dolgot világosabbá
|
|
tenni. Leírja egy egyszerű DNS névszerver felállítását, kezdve egy
|
|
csak gyorsítótáras szerverrel, és folytatva egy tartomány számára egy
|
|
elsődleges DNS szerver felállításával. Bonyolultabb beállításokhoz
|
|
átnézheted ezen dokumentum [8]Kérdések és válaszok fejezetét. Ha az
|
|
nincs leírva ott, el kell olvasnod a Valódi Dokumentációt. Az
|
|
[9]utolsó fejezetben visszatérek rá, mit is tartalmaz ez a Valódi
|
|
Dokumentáció.
|
|
|
|
Mielőtt belekezdesz, be kell állítanod a gépedet, hogy be tudj rá, és
|
|
ki tudj róla telnetelni, és sikerüljön mindenféle hálózati
|
|
kapcsolatokat létrehozni, valamint különösen fontos, hogy képes legyél
|
|
a telnet 127.0.0.1 parancsot kiadni, és a saját gépedet elérni
|
|
(próbáld ki most!). Kiindulásként szükséged lesz még jó, működő
|
|
/etc/nsswitch.conf/, /etc/resolv.conf/ és /etc/hosts/ állományokra is,
|
|
bár funkciójukat nem fogom itt elmagyarázni. Ha még nincs mindez
|
|
beállítva és nem működik, a Networking-HOWTO (Hálózatok-HOGYAN)
|
|
és/vagy a Networking-Overview-HOWTO (Hálózatok-Áttekintés-HOGYAN)
|
|
elmagyarázza, hogyan kell ezeket beállítani. Olvasd el őket.
|
|
|
|
Amikor azt mondom "a te géped", arra a gépre gondolok, amelyiken a
|
|
DNS-t próbálod beállítani, és nem akármelyik másik gépet, amely a
|
|
hálózati környezetedben megtalálható.
|
|
|
|
Feltételezem, hogy nem vagy olyan tűzfal mögött, amely blokkolja a
|
|
névlekérdezéseket. Ha mégis, különleges beállításokra lesz szükséged -
|
|
lásd a [10]Kérdések és válaszok fejezetet.
|
|
|
|
A névszolgáltatást UNIX alatt a named program végzi. Ez része a "BIND"
|
|
csomagnak, mely fejlesztését a The Internet Software Consortium
|
|
koordinálja. A named programot tartalmazza a legtöbb Linux
|
|
disztribúció, és általában /usr/sbin/named programként van telepítve,
|
|
a csomag készítőjének hóbortjától függő kis- vagy nagybetűs BIND
|
|
csomagból.
|
|
|
|
Ha van egy named programod, valószínűleg használhatod; ha nincs,
|
|
beszerezhetsz egyet a Linux ftp oldalról, vagy letöltheted a legutolsó
|
|
és legnagyszerűbb forráskódot az [11]ftp://ftp.isc.org/isc/bind9/
|
|
webhelyről. Ez a HOGYAN a 9-es verziójú BIND-ről szól. A HOGYAN
|
|
régebbi változatai, a 4-es és 8-as verziójú BIND-ről, még mindig
|
|
elérhetők a [12]http://langfeldt.net/DNS-HOWTO/ honlapon, abban az
|
|
esetben, ha 4-es vagy 8-as verziójú BIND-et használsz (mellékesen, ezt
|
|
a HOGYANt is megtalálhatod ott). Ha a named kézikönyv oldala (man
|
|
page) a named.conf állományról beszél (a legeslegvégén, a FILES
|
|
(ÁLLOMÁNYOK) fejezetben), 8-as BIND-ed van; ha named.boot állományról
|
|
van szó, 4-es BIND-ed van. Ha 4-esed van, és tudatosan a biztonságra
|
|
törekszel, tényleg frissítened kell a 8-as BIND legfrissebb
|
|
változatára. Most.
|
|
|
|
A DNS egy hálózati szintű adatbázis. Vigyázz, mit raksz bele. Ha
|
|
szemetet raksz bele, te és mások is szemetet fognak kinyerni belőle.
|
|
Tartsd DNS-ed rendben és konzisztensen, és egy jó szolgáltatást fogsz
|
|
kapni. Tanuld meg használni, adminisztrálni, megkeresni hibáit, és egy
|
|
újabb jó rendszergazda leszel, aki megvédi a hálózatot attól, hogy
|
|
"megfeküdjön" a félremenedzselés miatt.
|
|
|
|
Tipp: Készíts biztonsági másolatot az összes állományról, amelynek
|
|
megváltoztatására utasítalak, ha már megvannak, így ha esetleg semmi
|
|
sem működik, visszajuthatsz a régi, működő állapotba.
|
|
|
|
2.1 Más névszerver megvalósítások
|
|
|
|
Ezt a fejezetet Joost van Baal írta.
|
|
|
|
Különböző csomagok léteznek DNS szerver telepítéshez a gépedre. Van a
|
|
BIND csomag ( [13]http://www.isc.org/products/BIND/); a megvalósítás,
|
|
amiről ez a HOGYAN szól. Ez a legnépszerűbb névszerver mindenfelé,
|
|
és szerte az Interneten a névszolgáltató gépeinek döntő többségén ezt
|
|
használják, és az 1980-as évek óta fejlesztik. A BSD licenc feltételei
|
|
szerint használható. Mivel ez a legnépszerűbb programcsomag, egy
|
|
csomó dokumentáció és tudásanyag található a BIND-ről mindenfelé.
|
|
Azonban biztonsági problémák voltak vele.
|
|
|
|
Aztán van a djbdns ( [14]http://djbdns.org/), egy viszonylag új DNS
|
|
csomag, amelyet Daniel J. Bernstein készített, aki a qmail programot
|
|
is írta. Ez egy nagyon moduláris készlet: különböző kis programok
|
|
gondoskodnak a különböző feladatokról, amit egy névszervernek
|
|
kezelnie kell. A biztonság szempontjának figyelembe vételével
|
|
tervezték. Egy egyszerűbb zóna-állomány formátumot használ, és
|
|
általánosságban egyszerűbb beállítani. Azonban, mivel kevésbé ismert,
|
|
a helyi guru nem biztos, hogy segíthet vele kapcsolatban. Sajnos ez a
|
|
szoftver nem nyílt forráskódú. A szerző hirdetése a
|
|
[15]http://cr.yp.to/djbdns/ad.html honlapon található.
|
|
|
|
Hogy DJB szoftvere tényleg fejlődés-e a régi alternatívákkal szemben,
|
|
sok vita tárgyát képezi. Az ISC csapata otthont ad egy beszélgetésnek
|
|
(vagy inkább anyázásnak?) a BIND kontra djbdns-ről a
|
|
[16]http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html
|
|
honlapon.
|
|
|
|
3. A feloldó, gyorsítótáras névszerver
|
|
|
|
Az első ugrás a DNS beállításhoz. Nagyon hasznos betárcsázós,
|
|
kábel-modemes, ADSL és hasonló felhasználók számára.
|
|
|
|
A Red Hat és a Red Hat-hoz kapcsolódó disztribúciók esetén ezen HOGYAN
|
|
első fejezetéhez hasonló gyakorlati eredmény érhető el a bind,
|
|
bind-utils és caching-nameserver csomagok telepítésével. Ha Debiant
|
|
használsz, egyszerűen csak telepítsd a bind (vagy a bind9 csomagot,
|
|
mivel jelenleg a BIND 9-est nem támogatja a Debian Stable (potato)) és
|
|
a bind-doc csomagot. Persze csak ezen csomagok telepítésével nem
|
|
tanulsz annyit, mint e HOGYAN olvasásával. Szóval telepítsd a
|
|
csomagokat, azután olvass tovább, és ellenőrizd az általuk telepített
|
|
állományokat.
|
|
|
|
A gyorsítótáras névszerver megtalálja a választ a névlekérdezésekre,
|
|
és megjegyzi a választ a legközelebbi alkalomig, amikor szükséged lesz
|
|
rá. Ez jelentősen le fogja rövidíteni a várakozási időt a következő
|
|
alkalommal, különösen ha lassú a kapcsolatod.
|
|
|
|
Először szükséged lesz egy /etc/named.conf nevű állományra
|
|
(Debianban: /etc/bind/named.conf). Ez betöltődik amikor a named
|
|
elindul. Egyelőre csak ezt kell tartalmaznia:
|
|
_________________________________________________________________
|
|
|
|
// Konfigurációs állomány kizárólag gyorsítótáras névszerver számára
|
|
//
|
|
// A HOGYAN ezen változata tartalmazhat a sor elején szóközöket
|
|
// tartalmazó sorokat ebben és más állományokban. El kell távolítanod
|
|
// a szóközöket, hogy bizonyos dolgok működjenek.
|
|
//
|
|
// Figyelem, az állománynevek és a könyvtárak nevei különbözhetnek, ám
|
|
// a lényegi tartalmuknak hasonlónak kell lenniük.
|
|
|
|
options {
|
|
directory "/var/named";
|
|
// E sor engedélyezése segíthet, ha tűzfalon keresztül kell
|
|
// átmenned, és a dolog nem működik. De valószínűleg beszélned
|
|
// kell a tűzfal adminisztrátorával.
|
|
// query-source port 53;
|
|
};
|
|
|
|
controls {
|
|
inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
|
|
};
|
|
|
|
key "rndc_key" {
|
|
algorithm hmac-md5;
|
|
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
|
|
};
|
|
|
|
zone "." {
|
|
type hint;
|
|
file "root.hints";
|
|
};
|
|
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "pz/127.0.0";
|
|
};
|
|
_________________________________________________________________
|
|
|
|
A Linux disztribúciós csomagok eltérő állományneveket használhatnak
|
|
minden egyes, itt említett állománytípusra; azonban közel ugyanazt
|
|
fogják tartalmazni.
|
|
|
|
A "directory" sor megmondja a named programnak, hol keresse az
|
|
állományokat. Minden ezután megnevezett állomány ehhez lesz
|
|
viszonyítva. Tehát a pz egy könyvtár a /var/named alatt, azaz
|
|
megegyezik a /var/named/pz könyvtárral. A /var/named a helyes
|
|
könyvtár, a Linux Fájlrendszer Szabvány alapján.
|
|
|
|
A /var/named/root.hints állomány is megemlítődik benne. A
|
|
/var/named/root.hints állománynak ezt kell tartalmaznia:
|
|
_________________________________________________________________
|
|
|
|
|
|
;
|
|
; Nyitó megjegyzések lehetnek itt, ha már megvan ez az állományod.
|
|
; Ha nem, ne aggódj.
|
|
;
|
|
; A kezdő szóközökről a sorok elején: távolítsd el őket!
|
|
; A sornak egy ;-vel, .-tal vagy betűvel kell kezdődniük, nem szóközzel.
|
|
;
|
|
. 6D IN NS A.ROOT-SERVERS.NET.
|
|
. 6D IN NS B.ROOT-SERVERS.NET.
|
|
. 6D IN NS C.ROOT-SERVERS.NET.
|
|
. 6D IN NS D.ROOT-SERVERS.NET.
|
|
. 6D IN NS E.ROOT-SERVERS.NET.
|
|
. 6D IN NS F.ROOT-SERVERS.NET.
|
|
. 6D IN NS G.ROOT-SERVERS.NET.
|
|
. 6D IN NS H.ROOT-SERVERS.NET.
|
|
. 6D IN NS I.ROOT-SERVERS.NET.
|
|
. 6D IN NS J.ROOT-SERVERS.NET.
|
|
. 6D IN NS K.ROOT-SERVERS.NET.
|
|
. 6D IN NS L.ROOT-SERVERS.NET.
|
|
. 6D IN NS M.ROOT-SERVERS.NET.
|
|
A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4
|
|
B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107
|
|
C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12
|
|
D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90
|
|
E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10
|
|
F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241
|
|
G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4
|
|
H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53
|
|
I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17
|
|
J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10
|
|
K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129
|
|
L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12
|
|
M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33
|
|
_________________________________________________________________
|
|
|
|
Ez az állomány írja le a fő névszervereket a világban. A szerverek
|
|
időről időre változnak, és frissíteni kell őket most és később
|
|
is. A [17]Karbantartás fejezetben olvashatsz ezek naprakészen
|
|
tartásáról.
|
|
|
|
A következő rész a named.conf állományban a zone (zóna). Használatát
|
|
egy későbbi fejezetben fogom elmagyarázni; most csak nevezzük el ezt
|
|
az állományt 127.0.0-nak a pz alkönyvtárban. (Újfent, kérlek távolítsd
|
|
el a sor eleji szóközöket, ha kivágod és beilleszted ezt.)
|
|
_________________________________________________________________
|
|
|
|
|
|
$TTL 3D
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
1 ; Serial
|
|
8H ; Refresh
|
|
2H ; Retry
|
|
4W ; Expire
|
|
1D) ; Minimum TTL
|
|
NS ns.linux.bogus.
|
|
1 PTR localhost.
|
|
_________________________________________________________________
|
|
|
|
A key és a control részek azt határozzák meg, hogy a named programod
|
|
távolról irányítható az rndc programmal ha egy helyi állomásról
|
|
kapcsolódik, ekkor egy kódolt titkos kulccsal azonosítja magát. Ez a
|
|
kulcs olyan, mint egy jelszó. Az rndc működéséhez az /etc/rndc.conf
|
|
állománynak meg kell egyeznie ezzel:
|
|
_________________________________________________________________
|
|
|
|
key rndc_key {
|
|
algorithm "hmac-md5";
|
|
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
|
|
};
|
|
|
|
options {
|
|
default-server localhost;
|
|
default-key rndc_key;
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Amint látod, a secret bejegyzések megegyeznek. Ha az rndc programot
|
|
egy másik gépről szeretnéd használni, a két gép egymáshoz
|
|
viszonyított rendszeridejének 5 percen belül kell lennie. Ehhez
|
|
ajánlom az ntp (xntpd és ntpdate) szoftvert.
|
|
|
|
És most, szükséged lesz egy ehhez hasonló /etc/resolv.conf állományra:
|
|
(Újfent: Távolítsd el a szóközöket!)
|
|
_________________________________________________________________
|
|
|
|
search altartomány.a-te-tartományod.edu a-te-tartományod.edu
|
|
nameserver 127.0.0.1
|
|
_________________________________________________________________
|
|
|
|
A "search" sor határozza meg, milyen tartományban történjen a keresés
|
|
az állomások után, amelyekhez kapcsolódni akarsz. A "nameserver" sor
|
|
határozza meg a névszervered címét, ebben az esetben a saját gépedet,
|
|
mert ez az, ahol a named programod fut (a 127.0.0.1 cím helyes, nem
|
|
számít, ha a gépednek van egy másik címe is). Ha több névszervert
|
|
akarsz felsorolni, rakd mindegyiket egy-egy "nameserver" sorba.
|
|
(Megjegyzés: A named soha nem olvassa el ezt az állományt, a named
|
|
programot használó feloldó teszi ezt. Megjegyzés 2: Néhány resolv.conf
|
|
állományban a "domain" sort találod. Ez helyes, de ne használd a
|
|
"search" és a "domain" kulcsszót is egyszerre, csak az egyikük fog
|
|
működni.)
|
|
|
|
Annak bemutatására, hogy ez az állomány mit csinál: Ha az ügyfél
|
|
megpróbálja kikeresni a foo-t, akkor a
|
|
foo.altartomány.a-te-tartományod.edu-t próbálja először, majd a
|
|
foo.a-te-tartományod.edu-t, és végül a foo-t. Ne akarj túl sok
|
|
tartományt rakni a keresősorba, mivel mindet végigkeresni időt vesz
|
|
igénybe.
|
|
|
|
A példa feltételezi, hogy az altartomány.a-te-tartományod.edu
|
|
tartományba tartozol. A keresősornak nem szabad tartalmaznia a
|
|
legfelső tartományodat (TLD - Top Level Domain), ebben az esetben az
|
|
"edű-t. Ha gyakran kell kapcsolódnod másik tartományban levő
|
|
állomásokhoz, hozzáadhatod azt a tartományt a keresősorhoz, így: (Ne
|
|
felejtsd el eltávolítani a szóközöket a sor elején, ha vannak)
|
|
_________________________________________________________________
|
|
|
|
search altartomány.a-te-tartományod.edu a-te-tartományod.edu másik-tartomány.co
|
|
m
|
|
_________________________________________________________________
|
|
|
|
és így tovább. Nyilvánvalóan valódi tartományneveket kell helyettük
|
|
beraknod. Kérlek figyeld meg a tartománynevek végén a pontok hiányát.
|
|
Ez fontos!
|
|
|
|
3.1 A named indítása
|
|
|
|
Mindezek után itt az idő a named indítására. Ha betárcsázós
|
|
kapcsolatot használsz, először csatlakozz. Most indítsd a named-et,
|
|
vagy a boot szkript futtatásával: /etc/init.d/named start, vagy a
|
|
named-et közvetlenül: /usr/sbin/named. Ha kipróbáltad a BIND előző
|
|
verzióit, valószínűleg az ndc-t használtad. A BIND 9-ben ezt az rndc
|
|
program váltotta fel, ami távolról vezérelheti a named-et, de már nem
|
|
tudja a named-et indítani. Ha megnézed a rendszerüzenetek
|
|
naplóállományát (általában /var/log/messages, a Debianban
|
|
/var/log/daemon, meg lehet még keresni a /var/log egy másik
|
|
állományában is), mialatt indítod a named-et (ezt a tail -f
|
|
/var/log/messages-el teheted meg), valami ilyesmit kell látnod:
|
|
|
|
(a \-el végződő sorok a következő sorban folytatódnak)
|
|
|
|
Dec 23 02:21:12 lookfar named[11031]: starting BIND 9.1.3
|
|
Dec 23 02:21:12 lookfar named[11031]: using 1 CPU
|
|
Dec 23 02:21:12 lookfar named[11034]: loading configuration from \
|
|
'/etc/named.conf'
|
|
Dec 23 02:21:12 lookfar named[11034]: the default for the \
|
|
'auth-nxdomain' option is now 'no'
|
|
Dec 23 02:21:12 lookfar named[11034]: no IPv6 interfaces found
|
|
Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface lo, \
|
|
127.0.0.1#53
|
|
Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface eth0, \
|
|
10.0.0.129#53
|
|
Dec 23 02:21:12 lookfar named[11034]: command channel listening on \
|
|
127.0.0.1#953
|
|
Dec 23 02:21:13 lookfar named[11034]: running
|
|
|
|
Ha bármilyen hibaüzenet megjelenik, akkor ott hiba van. A named
|
|
megnevezi az állományt, amit épp olvas. Menj vissza, és ellenőrizd le
|
|
az állományt. Indítsd újból a named-et, ha megjavítottad.
|
|
|
|
Most letesztelheted a beállításodat. Hagyományosan az nslookup
|
|
használatos erre. Napjainkban azonban már a dig ajánlott:
|
|
|
|
$ dig -x 127.0.0.1
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26669
|
|
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
|
|
|
|
;; QUESTION SECTION:
|
|
;1.0.0.127.in-addr.arpa. IN PTR
|
|
|
|
;; ANSWER SECTION:
|
|
1.0.0.127.in-addr.arpa. 259200 IN PTR localhost.
|
|
|
|
;; AUTHORITY SECTION:
|
|
0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus.
|
|
|
|
;; Query time: 3 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 02:26:17 2001
|
|
;; MSG SIZE rcvd: 91
|
|
|
|
Ha ilyen üzeneteket kaptál, akkor működik. Reméljük. Ha bármi
|
|
teljesen eltérőt kapsz, menj vissza, és ellenőrizz le mindent.
|
|
Minden alkalommal, amikor megváltoztatsz egy állományt, futtasd az
|
|
rndc reload parancsot.
|
|
|
|
Most már beadhatsz egy lekérdezést. Próbálj meg valami hozzád közeli
|
|
gépet. A pat.uio.no közel van hozzám, az Oslói Egyetemen:
|
|
|
|
$ dig pat.uio.no
|
|
; <<>> DiG 9.1.3 <<>> pat.uio.no
|
|
;; global options: printcmd
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15574
|
|
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
|
|
|
|
;; QUESTION SECTION:
|
|
;pat.uio.no. IN A
|
|
|
|
;; ANSWER SECTION:
|
|
pat.uio.no. 86400 IN A 129.240.130.16
|
|
|
|
;; AUTHORITY SECTION:
|
|
uio.no. 86400 IN NS nissen.uio.no.
|
|
uio.no. 86400 IN NS nn.uninett.no.
|
|
uio.no. 86400 IN NS ifi.uio.no.
|
|
|
|
;; Query time: 651 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 02:28:35 2001
|
|
;; MSG SIZE rcvd: 108
|
|
|
|
Ezúttal a dig megkérte a named-et, hogy keresse meg a pat.uio.no
|
|
gépet. Az pedig kapcsolódott a root.hints állományodban levő egyik
|
|
névszerver géphez, és lekérdezte az útvonalát onnan. Eltarthat egy
|
|
röpke pillanatig, míg megkapod az eredményt, mivel végig kell keresnie
|
|
az összes tartományt, amit a /etc/resolv.conf-ban megneveztél.
|
|
|
|
Ha még egyszer lekérdezed ugyanazt, ezt kapod:
|
|
|
|
$ dig pat.uio.no
|
|
|
|
; <<>> DiG 8.2 <<>> pat.uio.no
|
|
;; res options: init recurs defnam dnsrch
|
|
;; got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
|
|
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
|
|
;; QUERY SECTION:
|
|
;; pat.uio.no, type = A, class = IN
|
|
|
|
;; ANSWER SECTION:
|
|
pat.uio.no. 23h59m58s IN A 129.240.130.16
|
|
|
|
;; AUTHORITY SECTION:
|
|
UIO.NO. 23h59m58s IN NS nissen.UIO.NO.
|
|
UIO.NO. 23h59m58s IN NS ifi.UIO.NO.
|
|
UIO.NO. 23h59m58s IN NS nn.uninett.NO.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
nissen.UIO.NO. 23h59m58s IN A 129.240.2.3
|
|
ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2
|
|
nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181
|
|
|
|
;; Total query time: 4 msec
|
|
;; FROM: lookfar to SERVER: default -- 127.0.0.1
|
|
;; WHEN: Sat Dec 16 00:23:09 2000
|
|
;; MSG SIZE sent: 28 rcvd: 162
|
|
|
|
Ahogy azt nyilvánvalóan láthatod, ezúttal ez sokkal gyorsabb volt, 4
|
|
ms a korábbi több, mint fél másodperccel ellentétben. A válasz benne
|
|
volt a gyorsítótárban. A gyorsítótárban lévő eredményeknél esély van
|
|
arra, hogy már elavult, de az eredeti szerverek befolyásolhatják azt
|
|
az időt, amíg a letárolt válaszok érvényesként lesznek nyilvántartva.
|
|
Végül is nagy a valószínűség arra, hogy a kapott válasz érvényes.
|
|
|
|
3.2 Névfeloldás
|
|
|
|
Minden operációs rendszer, ami a C API szabványt alkalmazza,
|
|
rendelkezik a gethostbyname és a gethostbyaddr hívásokkal. Ezek
|
|
különböző forrásokból szerezhetik be az információt. Hogy melyik
|
|
forrásból szerzik ezt be, az Linux (és egyes Unix) rendszereken az
|
|
/etc/nsswitch.conf állományban van beállítva. Ez egy hosszú állomány,
|
|
amely megadja mely állományokból vagy adatbázisokból szerezhetők be
|
|
különböző adattípusok. Általában hasznos megjegyzéseket tartalmaz a
|
|
fejlécében, melyeket körültekintően olvass el. Ezután keresd meg a
|
|
"hosts:" kulcsszóval kezdődő sort; így kell kinéznie:
|
|
_________________________________________________________________
|
|
|
|
hosts: files dns
|
|
_________________________________________________________________
|
|
|
|
(Emlékszel még a szóközökre a sor elején? Nem akarom újra
|
|
megemlíteni.)
|
|
|
|
Ha nincs "hosts:" kulcsszóval kezdődő sor, szúrd be a fentieket.
|
|
Ezek a sorok azt jelentik, hogy a programoknak először a /etc/hosts
|
|
állományban kell keresniük, majd leellenőrzik a DNS-t a resolv.conf
|
|
állomány alapján.
|
|
|
|
3.3 Gratulálok
|
|
|
|
Most már tudod, hogyan kell beállítani a gyorsítótáras named-et. Bonts
|
|
egy sört, tejet, vagy bármit, amivel ünnepelni szeretsz.
|
|
|
|
4. Továbbítás (forwarding)
|
|
|
|
Nagy, jól szervezett, egyetemi vagy Internet szolgáltatói (ISP)
|
|
hálózatokban néha megfigyelheted, hogy a hálózati szakemberek a DNS
|
|
szerverek továbbítói hierarchiáját hozták létre, ami segít a belső
|
|
hálózati terhelés csökkentésében, és a külső szerverekén úgyszintén.
|
|
Nem könnyű megtudni, hogy egy ilyen hálózatban vagy-e. De ha a
|
|
hálózati szolgáltatód DNS szerverét "továbbítóként" használod, a
|
|
lekérdezésekre adott reakciókat gyorsabbá teheted, és csökkentheted a
|
|
forgalmat a hálózatodon. Ez a te névszervered lekérdezéseinek az ISP
|
|
névszervere felé történő továbbításával működik. Minden egyes
|
|
alkalommal, amikor ilyen történik, az ISP névszerverének nagy
|
|
gyorsítótárába nyúlsz bele, így felgyorsítva a lekérdezéseket,
|
|
névszerverednek pedig nem kell mindent magának végeznie. Ha modemet
|
|
használsz ez nagy előny lehet. A példa kedvéért tételezzük fel, hogy
|
|
a hálózati szolgáltatódnak két névszervere van amiket használni
|
|
akarsz, 10.0.0.1 és 10.1.0.1 IP címekkel. Ebben az esetben a
|
|
named.conf állományodba, az "options" kulcsszóval kezdődő részbe
|
|
szúrd be ezeket a sorokat:
|
|
_________________________________________________________________
|
|
|
|
forward first;
|
|
forwarders {
|
|
10.0.0.1;
|
|
10.1.0.1;
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Van még egy szép trükk a továbbítókat használó betárcsázós gépek
|
|
számára, amely a [18]Kérdések és válaszok fejezetben van leírva.
|
|
|
|
Indítsd újra a névszerveredet, és teszteld a dig-el. Még mindig
|
|
rendben kell működnie.
|
|
|
|
5. Egy egyszerű tartomány
|
|
|
|
Hogyan kell felállítani a saját tartományodat?
|
|
|
|
5.1 De először egy kis száraz elmélet
|
|
|
|
Mindenekelőtt: elolvastad az összes cuccot ez előtt, ugye? Erre
|
|
szükség van.
|
|
|
|
Mielőtt tényleg elkezdjük ezt a fejezetet, közzéteszek egy kis
|
|
elméletet, és egy példát, hogyan működik a DNS. És te el fogod
|
|
olvasni, mert az jó neked. Ha nem akarod, legalább fusd át nagyon
|
|
gyorsan. Fejezd be a futást, ha oda érsz, hogy minek kell a named.conf
|
|
állományodba kerülnie.
|
|
|
|
A DNS egy hierarchikus, fa struktúrájú rendszer. A tetejét "."-nak
|
|
írják és "gyökér"-nek (root) ejtik, ahogy az megszokott a fa-típusú
|
|
adatstruktúráknál. A . alatt számos legfelsőbb szintű tartomány (TLD
|
|
- Top Level Domain) van; a legismertebbek az ORG, COM, EDU és a NET,
|
|
de még sok más is van. Éppúgy mint a fának, ennek is van gyökere és
|
|
elágazik. Ha van egy kis számítástechnikai háttered, a DNS-t, mint egy
|
|
keresőfát azonosíthatod, és megtalálhatod a csomópontokat, az ágakat
|
|
és a csúcsokat. A pontok a csomópontok, a csúcsok a neveken vannak.
|
|
|
|
Egy gép keresésekor a lekérdezés rekurzív módon halad a hierarchiában,
|
|
a gyökértől kiindulva. Ha a prep.ai.mit.edu címét akarod megtalálni,
|
|
a névszerverednek el kell kezdenie valahol. A gyorsítótárban való
|
|
kereséssel kezdi. Ha ebben megvan a válasz mert korábban eltárolta,
|
|
azonnal válaszolni fog, ahogy ezt a legutóbbi fejezetben láttuk. Ha
|
|
nem tudja, megnézi milyen közeli választ tud adni a keresett névhez,
|
|
és felhasznál bármilyen információt, amit már eltárolt. A legrosszabb
|
|
esetben nincs más találata, csak a név "."-ja (gyökere), és a
|
|
főszerverekhez kell fordulni. El fogja távolítani a baloldali
|
|
részeket, egyenként ellenőrizve, hogy tud-e valamit az ai.mit.edu.
|
|
tartományról, utána a mit.edu.-ról, utána az edu.-ról, és ha nem,
|
|
utána a .-ról, mert ez volt a hints állományban. Ezután megkérdezi a .
|
|
szervert a prep.ai.mit.edu tartományról. Ez a . szerver nem fogja
|
|
tudni a választ, de segíteni fog a szerverednek a saját módján egy
|
|
hivatkozás megadásával, amellyel megmondja, hol keressen inkább. Ezek
|
|
a hivatkozások a szerveredet végül ahhoz a névszerverhez vezetik,
|
|
amelyik tudja a választ. Most ezt fogom bemutatni. A +norec azt
|
|
jelenti, hogy a dig egy nem-rekurzív lekérdezést végez, így a
|
|
rekurziót magunknak kell elvégeznünk. A többi opció a dig folyamat
|
|
csökkentésére vannak, így ez nem fog több oldalon át futni:
|
|
|
|
$ ;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
|
|
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
|
|
|
|
;; AUTHORITY SECTION:
|
|
. 518400 IN NS J.ROOT-SERVERS.NET.
|
|
. 518400 IN NS K.ROOT-SERVERS.NET.
|
|
. 518400 IN NS L.ROOT-SERVERS.NET.
|
|
. 518400 IN NS M.ROOT-SERVERS.NET.
|
|
|
|
. 518400 IN NS A.ROOT-SERVERS.NET.
|
|
. 518400 IN NS B.ROOT-SERVERS.NET.
|
|
. 518400 IN NS C.ROOT-SERVERS.NET.
|
|
. 518400 IN NS D.ROOT-SERVERS.NET.
|
|
. 518400 IN NS E.ROOT-SERVERS.NET.
|
|
. 518400 IN NS F.ROOT-SERVERS.NET.
|
|
. 518400 IN NS G.ROOT-SERVERS.NET.
|
|
. 518400 IN NS H.ROOT-SERVERS.NET.
|
|
. 518400 IN NS I.ROOT-SERVERS.NET.
|
|
|
|
Ez egy hivatkozás. Ez csak egy felügyeleti részt ("Authority section")
|
|
hoz létre nekünk, válasz részt ("Answer section") pedig nem. A saját
|
|
névszerverünk egy névszerverhez küld tovább. Válasszunk ki
|
|
véletlenszerűen egyet:
|
|
|
|
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
|
|
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
|
|
|
|
;; AUTHORITY SECTION:
|
|
mit.edu. 172800 IN NS BITSY.mit.edu.
|
|
mit.edu. 172800 IN NS STRAWB.mit.edu.
|
|
mit.edu. 172800 IN NS W20NS.mit.edu.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
BITSY.mit.edu. 172800 IN A 18.72.0.3
|
|
STRAWB.mit.edu. 172800 IN A 18.71.0.151
|
|
W20NS.mit.edu. 172800 IN A 18.70.0.160
|
|
|
|
Ez azonnal a MIT.EDU szerverhez küld minket. Újra válasszuk ki egyet
|
|
véletlenszerűen:
|
|
|
|
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
|
|
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
|
|
|
|
;; ANSWER SECTION:
|
|
prep.ai.mit.edu. 10562 IN A 198.186.203.77
|
|
|
|
;; AUTHORITY SECTION:
|
|
ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu.
|
|
ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu.
|
|
ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu.
|
|
ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43
|
|
LIFE.ai.mit.edu. 21600 IN A 128.52.32.80
|
|
ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5
|
|
BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
|
|
|
|
Ezúttal kapunk egy "ANSWER SECTION"-t, és választ a kérdésünkre. Az
|
|
"AUTHORITY SECTION" azt az információt tartalmazza, hogy mely
|
|
szervereket kérdezzük legközelebb az ai.mit.edu-ról. Így, következő
|
|
alkalommal amikor az ai.mit.edu nevekről kíváncsiskodsz, közvetlenül
|
|
őket kérdezheted. A named információt gyűjtött a mit.edu-ról is, így
|
|
legközelebb ha a www.mit.edu lekérdezése fordul elő, sokkal könnyebb
|
|
lesz majd megválaszolni a kérdést.
|
|
|
|
Így a .-tól kezdődően a hivatkozások alapján megtaláltuk az egymás
|
|
utáni névszervereket, a tartománynév minden egyes szintjéhez. Ha a
|
|
saját DNS szerveredet használtad volna mindezen szerverek helyett, a
|
|
named-ed természetesen eltárolta volna mindezt az információt amit a
|
|
kutakodás során talált, és egy ideig nem kellene újra lekérdeznie.
|
|
|
|
A fa-analógiában minden "." a névben egy elágazási pont, és minden
|
|
rész a "."-ok között az egyes ágak nevei a fán. A fa bejárásakor
|
|
fogjuk a nevet amit keresünk (prep.ai.mit.edu), megkérdezve a gyökeret
|
|
(.) vagy bármelyik szervert a gyökértől a prep.ai.mit.edu felé,
|
|
amelyikről van információnk a gyorsítótárban. Ha a gyorsítótár eléri
|
|
kapacitásának határait, a rekurzív feloldó a külső szervereket
|
|
kérdezi le, követve a hivatkozásokat (éleket) tovább a névben.
|
|
|
|
Valamivel kevesebbet beszéltünk róla, de éppoly fontos az in-addr.arpa
|
|
tartomány. Ez is épp úgy szervezett, mint a "közönséges" tartományok.
|
|
Az in-addr.arpa lehetővé teszi számunkra, hogy megkapjuk az állomás
|
|
nevét, ha megvan a címe. Egy fontos dolog, amit meg kell jegyezni,
|
|
hogy az IP címek fordított sorrendben vannak írva az in-addr.arpa
|
|
tartományban. Ha egy gépnek a címe: 198.186.203.77, a named a keresést
|
|
a 77.203.168.198.in-addr.arpa-ra végzi, éppúgy, ahogy azt a
|
|
prep.ai.mi.edu-ra tette. Példa: Ha nem találsz egyetlen találati
|
|
bejegyzést a gyorsítótárban csak a "."-ot, kérdezz le egy főszervert,
|
|
az m.root-servers.net valamelyik másik főszerverhez irányít. A
|
|
b.root-servers.net közvetlenül a bitsy.mit.edu tartományhoz irányít.
|
|
Onnan már képes leszel leszedni.
|
|
|
|
5.2 A saját tartományunk
|
|
|
|
Most következik a saját tartományunk meghatározása. A linux.bogus
|
|
tartományt fogjuk létrehozni, és megadjuk a gépeket benne. Egy
|
|
teljesen hamis tartománynevet használok, hogy biztos ne zavarjunk
|
|
senkit Ott Kint.
|
|
|
|
Még egy dolog, mielőtt elkezdjük: Nem minden karakter megengedett a
|
|
gépnevekben. Az angol ábécé betűire vagyunk korlátozva: a-z, és a 0-9
|
|
számok és a "-" (kötőjel) karakter. Tartsd magad ezekhez a
|
|
karakterekhez (a 9-es BIND nem fog hibásan működni, ha megszeged ezt
|
|
a szabályt, de a 8-as BIND igen). A kis- és nagybetűk egyformák a DNS
|
|
számára, tehát a pat.uio.no megegyezik a Pat.UiO.No-val.
|
|
|
|
Már elkezdtük ezt a részt a named.conf-ban ezzel a sorral:
|
|
_________________________________________________________________
|
|
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "pz/127.0.0";
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Kérlek, vedd észre a "." hiányát a tartománynevek végén ebben az
|
|
állományban. Azt jelenti, hogy mi most a 0.0.127.in-addr.arpa zónát
|
|
fogjuk megadni, hogy mi vagyunk a mesterszerver számára, és hogy a
|
|
pz/127.0.0 állományban van tárolva. Már beállítottuk ezt az állományt:
|
|
_________________________________________________________________
|
|
|
|
$TTL 3D
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
1 ; Serial
|
|
8H ; Refresh
|
|
2H ; Retry
|
|
4W ; Expire
|
|
1D) ; Minimum TTL
|
|
NS ns.linux.bogus.
|
|
1 PTR localhost.
|
|
_________________________________________________________________
|
|
|
|
Kérlek, vedd észre a "."-ot a teljes tartománynevek végén ebben az
|
|
állományban, ellentétben a fenti named.conf állománnyal. Egyesek
|
|
szeretnek minden zónaállományt az //$ORIGIN direktívával kezdeni, de
|
|
ez felesleges. Egy zónaállomány eredete (ahová a DNS hierarchiában
|
|
tartozik) a named.conf állomány zóna fejezetében van meghatározva;
|
|
ebben az esetben ez a 0.0.127.in-addr.arpa.
|
|
|
|
Ez a "zónaállomány" 3 "erőforrásbejegyzést" (RR - resource record)
|
|
tartalmaz: egy SOA RR-t, egy NS RR-t és egy PTR RR-t. A SOA a
|
|
Jogosultság Kezdetének a rövidítése (SOA - Start Of Authority). A "@"
|
|
egy speciális jel ami az eredetet jelenti, és mivel a "tartomány"
|
|
oszlop ezen állomány esetén az 0.0.127.in-addr-arpa-t tartalmazza, az
|
|
első sor valójában ezt jelenti:
|
|
|
|
0.0.127.in-addr.arpa. IN SOA ...
|
|
|
|
Az NS a Névszerver RR. Itt nincs "@" a sor elején; magától értetődő,
|
|
mivel az előző sor egy "@"-el kezdődött. Ez megtakarít egy kis
|
|
gépelést. Tehát az NS sort így is lehet írni:
|
|
|
|
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
|
|
|
|
Ez megmondja a DNS-nek, melyik gép a 0.0.127.in-addr.arpa tartomány
|
|
névszervere, ez az ns.linux.bogus. Az "ns" egy szokványos név a
|
|
névszerverek számára, éppúgy, mint a web szerverek esetében, amiknek
|
|
szokványosan www.valami a nevük. A név bármi lehet.
|
|
|
|
Végül a PTR (Tartomány Név Mutató) bejegyzés megmondja, hogy a
|
|
0.0.127.in-addr.arpa alhálózat 1-es címén, azaz a 127.0.0.1 címen
|
|
található gép neve localhost.
|
|
|
|
A SOA bejegyzés a bevezető az összes zónaállományhoz, és pontosan
|
|
egynek kell lennie minden egyes zónaállományban, a tetején (de a $TTL
|
|
direktíva után). Ez leírja a zónát, honnan származik (egy
|
|
ns.linux.bogus nevű gépről), ki felelős annak tartalmáért
|
|
(hostmaster@linux.bogus, a saját e-mail címedet kell ideírnod), melyik
|
|
változatú zónaállomány ez (serial: 1), és egyéb, a gyorsítótárazással
|
|
és a másodlagos DNS szerverekkel kapcsolatos dolgokat. A maradék
|
|
mezők (refresh - frissítés, retry - újrapróbálkozás, expire - lejárat
|
|
és minimum) tekintetében használd az ebben a HOGYANban használt
|
|
számokat, és nem lesz baj. A SOA elé jön egy kötelező sor, a $TTL 3D.
|
|
Rakd bele az összes zónaállományodba.
|
|
|
|
Most indítsd újra a named-et (rndc stop; named) és használd a dig-et
|
|
ügyeskedésed megvizsgálásához. A -x fordított lekérdezést kér:
|
|
|
|
$ dig -x 127.0.0.1
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944
|
|
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
|
|
|
|
;; QUESTION SECTION:
|
|
;1.0.0.127.in-addr.arpa. IN PTR
|
|
|
|
;; ANSWER SECTION:
|
|
1.0.0.127.in-addr.arpa. 259200 IN PTR localhost.
|
|
|
|
;; AUTHORITY SECTION:
|
|
0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus.
|
|
|
|
;; Query time: 3 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:02:39 2001
|
|
;; MSG SIZE rcvd: 91
|
|
|
|
Szóval ez gondoskodik arról, hogy a 127.0.0.1-ből localhost-ot
|
|
kapjunk; rendben. Most a fő célunk, a linux.bogus tartomány
|
|
érdekében, szúrjunk be egy új "zone" részt a named.conf állományba:
|
|
_________________________________________________________________
|
|
|
|
zone "linux.bogus" {
|
|
type master;
|
|
notify no;
|
|
file "pz/linux.bogus";
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Figyeld meg újból a named.conf állományban a tartománynév végén a "."
|
|
hiányát.
|
|
|
|
A linux.bogus zónaállománya berakunk némi teljesen valótlan adatot:
|
|
_________________________________________________________________
|
|
|
|
;
|
|
; Zone file for linux.bogus
|
|
;
|
|
; The full zone file
|
|
;
|
|
$TTL 3D
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
199802151 ; serial, todays date + todays serial #
|
|
|
|
8H ; refresh, seconds
|
|
2H ; retry, seconds
|
|
4W ; expire, seconds
|
|
1D ) ; minimum, seconds
|
|
;
|
|
NS ns ; Inet Address of name server
|
|
MX 10 mail.linux.bogus ; Primary Mail Exchanger
|
|
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
|
|
;
|
|
localhost A 127.0.0.1
|
|
ns A 192.168.196.2
|
|
mail A 192.168.196.4
|
|
_________________________________________________________________
|
|
|
|
Két dolgot meg kell jegyezni a SOA bejegyzésről. Az
|
|
ns.linux.bogus-nak egy "A" bejegyzéssel rendelkező valódi gépnek kell
|
|
lennie. Nem megengedett az SOA bejegyzésben említett géphez CNAME
|
|
bejegyzést rendelni. A nevének nem kell "ns"-nek lennie, bármely valós
|
|
gép neve lehet. Az ezt követő hostmaster.linux.bogus-t
|
|
hostmaster@linux.bogus-nak kell olvasni. Ennek egy olyan levélcímnek
|
|
kell lennie, amelyet a DNS-t karbantartó személy, vagy személyek
|
|
gyakran olvasnak. Bármely, a tartománnyal kapcsolatos levél az itt
|
|
megadott címre lesz elküldve. A névnek nem kell "hostmaster"-nek
|
|
lennie, lehet ez a rendes e-mail címed, de a "hostmaster" e-mail cím
|
|
létezése sokszor szintén elvárás.
|
|
|
|
Egy új RR típus található ebben az állományban, az MX, vagy a Mail
|
|
eXchanger (levélkiszolgáló) RR. Ez megmondja a levelezőrendszereknek,
|
|
hova legyen küldve a valaki@linux.bogus-nak címzett levél, név szerint
|
|
a mail.linux.bogus-nak, vagy a mail.friend.bogus-nak. A szám minden
|
|
gép neve előtt az adott MX RR prioritása. A legkisebb számmal (10)
|
|
rendelkező RR az, amelyik, ha lehetséges a levelet kapni fogja. Ha ez
|
|
nem sikerül, a levelet el lehet küldeni egy magasabb számmal
|
|
rendelkezőnek, egy másodlagos levélkezelőnek, azaz a
|
|
mail.friend.bogus-nak, amelynek a prioritása itt 20.
|
|
|
|
Töltsük be a tartományokat újból az rndc reload futtatásával.
|
|
Vizsgáljuk meg az eredményeket a dig-el:
|
|
|
|
|
|
$ dig any linux.bogus
|
|
; <<>> DiG 9.1.3 <<>> any linux.bogus
|
|
;; global options: printcmd
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239
|
|
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
|
|
|
|
;; QUESTION SECTION:
|
|
;linux.bogus. IN ANY
|
|
|
|
;; ANSWER SECTION:
|
|
linux.bogus. 259200 IN SOA ns.linux.bogus. \
|
|
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
|
|
linux.bogus. 259200 IN NS ns.linux.bogus.
|
|
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
|
|
|
|
;; AUTHORITY SECTION:
|
|
linux.bogus. 259200 IN NS ns.linux.bogus.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
ns.linux.bogus. 259200 IN A 192.168.196.2
|
|
|
|
;; Query time: 4 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:06:45 2001
|
|
;; MSG SIZE rcvd: 184
|
|
|
|
Alapos vizsgálat után egy hibát fogsz találni. A
|
|
|
|
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
|
|
|
|
sor teljesen rossz. Ennek így kellene kinéznie:
|
|
|
|
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
|
|
Szándékosan hibát vétettem, úgyhogy tanulhatsz belőle :-)
|
|
Beletekintve a zónaállományba ezt a sort találjuk:
|
|
|
|
MX 10 mail.linux.bogus ; Primary Mail Exchanger
|
|
|
|
Hiányzik egy pont. Vagy a "linux.bogus"-ban túl sok van. Ha egy gépnév
|
|
a zónaállományban nem végződik pontra, az eredete hozzáadódik a
|
|
végéhez, a megduplázott linux.bogus.linux.bogus-t eredményezve. Szóval
|
|
vagy
|
|
_________________________________________________________________
|
|
|
|
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
|
|
_________________________________________________________________
|
|
|
|
vagy
|
|
_________________________________________________________________
|
|
|
|
MX 10 mail ; Primary Mail Exchanger
|
|
_________________________________________________________________
|
|
|
|
a helyes. Én az utóbbi változatot preferálom, kevesebbet kell gépelni.
|
|
Vannak olyan BIND szakértők, akik nem értenek egyet ezzel, és vannak
|
|
olyanok akik igen. Egy zónaállmányban a tartományt vagy ki kell írni,
|
|
és "."-al lezárni, vagy egyáltalán nem kell meghatározni, mely esetben
|
|
az eredet lesz az alapértelmezés.
|
|
|
|
Ki kell hangsúlyoznom, hogy a named.conf állományban nem kell "."-nak
|
|
lennie a tartománynevek után. El sem bírod képzelni, hány esetben
|
|
kavarta össze a dolgokat a túl sok vagy túl kevés pont, és hozta ki az
|
|
ördögöt az emberekből.
|
|
|
|
Szóval, kifejtve érveimet itt van az új zónaállomány, némi extra
|
|
információval kiegészítve:
|
|
_________________________________________________________________
|
|
|
|
;
|
|
; Zone file for linux.bogus
|
|
;
|
|
; The full zone file
|
|
;
|
|
$TTL 3D
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
199802151 ; serial, todays date + todays serial #
|
|
8H ; refresh, seconds
|
|
2H ; retry, seconds
|
|
4W ; expire, seconds
|
|
1D ) ; minimum, seconds
|
|
;
|
|
TXT "Linux.Bogus, your DNS consultants"
|
|
NS ns ; Inet Address of name server
|
|
NS ns.friend.bogus.
|
|
MX 10 mail ; Primary Mail Exchanger
|
|
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
|
|
|
|
localhost A 127.0.0.1
|
|
|
|
gw A 192.168.196.1
|
|
TXT "The router"
|
|
|
|
ns A 192.168.196.2
|
|
MX 10 mail
|
|
MX 20 mail.friend.bogus.
|
|
www CNAME ns
|
|
|
|
donald A 192.168.196.3
|
|
MX 10 mail
|
|
MX 20 mail.friend.bogus.
|
|
TXT "DEK"
|
|
|
|
mail A 192.168.196.4
|
|
MX 10 mail
|
|
MX 20 mail.friend.bogus.
|
|
|
|
ftp A 192.168.196.5
|
|
MX 10 mail
|
|
MX 20 mail.friend.bogus.
|
|
_________________________________________________________________
|
|
|
|
A CNAME (Canonical NAME - kanonikus NÉV) egy módszer több név
|
|
megadására egy gép számára. Így a www egy álnév az ns számára. A CNAME
|
|
bejegyzés használata egy kicsit kétértelmű. A legbiztosabb azt a
|
|
szabályt követni, hogy egy MX, CNAME vagy SOA bejegyzés soha nem
|
|
hivatkozhat egy CNAME bejegyzésre, csak egy "A" bejegyzéssel
|
|
rendelkező valamire hivatkozhatnak, tehát megengedhetetlen a
|
|
_________________________________________________________________
|
|
|
|
foobar CNAME www ; NEM!
|
|
_________________________________________________________________
|
|
|
|
de helyes a
|
|
_________________________________________________________________
|
|
|
|
|
|
foobar CNAME ns ; IGEN!
|
|
_________________________________________________________________
|
|
|
|
Töltsük be az új adatbázist az rndc reload futtatásával, amely a named
|
|
állományainak újbóli beolvasását eredményezi.
|
|
|
|
|
|
$ dig linux.bogus axfr
|
|
|
|
; <<>> DiG 9.1.3 <<>> linux.bogus axfr
|
|
;; global options: printcmd
|
|
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linu
|
|
x.bogus. 199802151 28800 7200 2419200 86400
|
|
linux.bogus. 259200 IN NS ns.linux.bogus.
|
|
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
|
|
donald.linux.bogus. 259200 IN A 192.168.196.3
|
|
donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
donald.linux.bogus. 259200 IN TXT "DEK"
|
|
ftp.linux.bogus. 259200 IN A 192.168.196.5
|
|
ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
|
|
ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
gw.linux.bogus. 259200 IN A 192.168.196.1
|
|
gw.linux.bogus. 259200 IN TXT "The router"
|
|
localhost.linux.bogus. 259200 IN A 127.0.0.1
|
|
mail.linux.bogus. 259200 IN A 192.168.196.4
|
|
mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
|
|
ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
|
|
ns.linux.bogus. 259200 IN A 192.168.196.2
|
|
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
|
|
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linu
|
|
x.bogus. 199802151 28800 7200 2419200 86400
|
|
;; Query time: 41 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:12:31 2001
|
|
;; XFR size: 23 records
|
|
|
|
Ez jó. Amint látod, egy kicsit úgy néz ki, mint a zónaállomány maga.
|
|
Ellenőrizzük, mit mond egyedül a www-re:
|
|
|
|
$ dig www.linux.bogus
|
|
|
|
; <<>> DiG 9.1.3 <<>> www.linux.bogus
|
|
;; global options: printcmd
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633
|
|
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
|
|
|
|
;; QUESTION SECTION:
|
|
;www.linux.bogus. IN A
|
|
|
|
;; ANSWER SECTION:
|
|
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
|
|
ns.linux.bogus. 259200 IN A 192.168.196.2
|
|
|
|
;; AUTHORITY SECTION:
|
|
linux.bogus. 259200 IN NS ns.linux.bogus.
|
|
|
|
;; Query time: 5 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:14:14 2001
|
|
;; MSG SIZE rcvd: 80
|
|
|
|
Más szóval a www.linux.bogus valódi neve ns.linux.bogus, és további
|
|
információt is ad neked amivel rendelkezik az ns-ről, elegendőt a
|
|
hozzá való csatlakozáshoz, ha egy program lennél.
|
|
|
|
Most vagyunk félúton
|
|
|
|
5.3 A fordított zóna
|
|
|
|
Most már a programok át tudják alakítani a linux.bogus-ban a neveket
|
|
címekké, amelyekhez csatlakozni tudnak. De szükség van egy fordított
|
|
zónára is, olyanra, amely lehetővé teszi a DNS számára a címek
|
|
átalakítását nevekké. Ezt a nevet rengeteg különböző típusú szerver
|
|
(FTP, IRC, WWW és mások) használja annak eldöntésére, hogy akar-e
|
|
veled kommunikálni vagy nem, és ha igen, talán még arra is, hogy
|
|
milyen prioritást kapjál. Az Internet összes szolgáltatásának teljes
|
|
eléréséhez a fordított zóna szükséges.
|
|
|
|
Rakd be ezt a named.conf állományba:
|
|
_________________________________________________________________
|
|
|
|
zone "196.168.192.in-addr.arpa" {
|
|
type master;
|
|
notify no;
|
|
file "pz/192.168.196";
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Ez pontosan ugyanaz, mint a 0.0.127.in-arpa-val, és a tartalmuk is
|
|
hasonló:
|
|
_________________________________________________________________
|
|
|
|
$TTL 3D
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
199802151 ; Serial, todays date + todays serial
|
|
8H ; Refresh
|
|
2H ; Retry
|
|
4W ; Expire
|
|
1D) ; Minimum TTL
|
|
NS ns.linux.bogus.
|
|
|
|
1 PTR gw.linux.bogus.
|
|
2 PTR ns.linux.bogus.
|
|
3 PTR donald.linux.bogus.
|
|
4 PTR mail.linux.bogus.
|
|
5 PTR ftp.linux.bogus.
|
|
_________________________________________________________________
|
|
|
|
Most újra töltsd be a named-et (rndc reload), és vizsgáld meg a
|
|
munkádat a dig-el újra:
|
|
_________________________________________________________________
|
|
|
|
|
|
$ dig -x 192.168.196.4
|
|
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451
|
|
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
|
|
|
|
;; QUESTION SECTION:
|
|
;4.196.168.192.in-addr.arpa. IN PTR
|
|
|
|
;; ANSWER SECTION:
|
|
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
|
|
|
|
;; AUTHORITY SECTION:
|
|
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
ns.linux.bogus. 259200 IN A 192.168.196.2
|
|
|
|
;; Query time: 4 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:16:05 2001
|
|
;; MSG SIZE rcvd: 107
|
|
_________________________________________________________________
|
|
|
|
tehát jónak néz ki, szedjük ki az egészet, hogy azt is megvizsgáljuk:
|
|
_________________________________________________________________
|
|
|
|
$ dig 196.168.192.in-addr.arpa. AXFR
|
|
|
|
; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
|
|
;; global options: printcmd
|
|
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
|
|
|
|
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
|
|
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
|
|
1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus.
|
|
2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus.
|
|
3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus.
|
|
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
|
|
5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus.
|
|
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
|
|
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
|
|
;; Query time: 6 msec
|
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
|
;; WHEN: Sun Dec 23 03:16:58 2001
|
|
;; XFR size: 9 records
|
|
_________________________________________________________________
|
|
|
|
Jól néz ki! Ha kimeneted nem ilyen, akkor keresd a hibaüzeneteket a
|
|
syslog-ban, az első fejezetben, [19]A named indítása fejezetben
|
|
elmagyaráztam, hogyan tedd ezt.
|
|
|
|
5.4 Intő szavak
|
|
|
|
Van pár dolog, amit itt közre kell adnom. A fenti példában használt IP
|
|
számok a "magánhálózatok" egyik blokkjából lettek véve, azaz nyilvános
|
|
használatuk az Interneten nem megengedett. Így hát biztonságos a
|
|
használatuk egy HOGYAN egy példájában. A másik dolog a notify no; sor.
|
|
Ez megmondja a named-nek, hogy ne értesítse a másodlagos (slave)
|
|
szerverét, amikor az egyik zónaállománya frissült. A 8-as és későbbi
|
|
BIND-ben a named értesítheti a zónaállományban az NS bekezdésben
|
|
felsorolt többi szervert, amikor a zóna frissült. Ez ügyes dolog
|
|
rendes működéskor. De kísérletezések esetén ennek a lehetőségnek
|
|
kikapcsolva kell lennie - nem akarjuk, hogy a kísérlet megkavarja az
|
|
Internetet, ugye?
|
|
|
|
És persze, ez a tartomány erősen hamis, és éppígy a címek benne. Egy
|
|
valódi tartomány valós példájáért nézd meg a következő főfejezetet.
|
|
|
|
5.5 Miért nem működnek a fordított lekérdezések?
|
|
|
|
Van egy pár normális körülmények között névlekérdezésekkel
|
|
elkerülhető "csapda", amellyel gyakran találkozni fordított zónák
|
|
beállításánál. Mielőtt folytatod, szükséged lesz a fordított
|
|
lekérdezések működésére a saját névszervereden. Ha ez nincs így, menj
|
|
vissza, és javítsd ki mielőtt folytatod.
|
|
|
|
A fordított lekérdezések két hibájáról fogok szólni, ahogy azok a
|
|
hálózaton kívülről látszódnak:
|
|
|
|
A fordított zóna nincs delegálva
|
|
|
|
Ha egy hálózati szolgáltatótól egy hálózati címtartományt és egy
|
|
tartománynevet kérsz, a tartománynév rendes esetben delegálva van,
|
|
mint egy magától értetődő dolog. A delegálás az az összeragasztó NS
|
|
bejegyzés, amely segít eljutnod az egyik névszervertől a másikig,
|
|
ahogy ez a száraz elméleti fejezetben el lett magyarázva. Elolvastad,
|
|
ugye? Ha a fordított zónád nem működik, menj vissza, és olvasd el.
|
|
Most.
|
|
|
|
A fordított zónának szintén delegálva kell lennie. Ha a 192.168.196-os
|
|
hálózatot kapod a linux.bogus tartománnyal a szolgáltatódtól, be kell
|
|
rakniuk az NS bejegyzést a fordított zónád számára éppúgy, mint a
|
|
továbbító zónád számára. Ha követed a láncolatot az in-addr.arpa-tól
|
|
felfelé a hálózatodig, valószínűleg szakadást találsz majd a láncban,
|
|
a leginkább valószínű, hogy a szolgáltatódnál. Miután megtaláltad a
|
|
szakadást a láncolatban, vedd fel a kapcsolatot a szolgáltatóddal, és
|
|
kérd meg őket a hiba kijavítására.
|
|
|
|
Egy osztályon kívüli alhálózatod van
|
|
|
|
Ez egy kissé bonyolultabb téma, de az osztályon kívüli alhálózatok
|
|
nagyon elterjedtek manapság, és valószínűleg egy ilyened van, ha egy
|
|
kis cég vagy.
|
|
|
|
Az osztályon kívüli alhálózatok azok, amik az Internetet manapság
|
|
éltetik. Néhány évvel ezelőtt sok volt a hűhó az IP címek
|
|
fogyatkozása miatt. A bölcs emberek az IETF-nél (Internet Engineering
|
|
Task Force, ők tartják működésben az Internetet) összedugták a
|
|
fejüket, és megoldották a problémát. Bizonyos áron. Az ár ott
|
|
mutatkozik, hogy egy "C" alhálózatnál kisebbet kapsz, és bizonyos
|
|
dolgok nem működhetnek. Kérlek nézd át az [20]Ask Mr. DNS (Kérdezd
|
|
DNS urat) cikket egy jó magyarázatért, és hogy hogyan kezeld ezt.
|
|
|
|
Elolvastad? Nem fogom elmagyarázni, szóval kérlek olvasd el.
|
|
|
|
A probléma első része az, hogy az ISP-dnek értenie kell a Mr. DNS
|
|
által leírt technikát. Nem minden kis ISP-nek van hozzáértő dolgozója
|
|
ehhez. Ha így van, lehet, hogy el kell nekik magyaráznod, és
|
|
kitartónak kell lenned. De először légy biztos benne, hogy te érted
|
|
;-). Ezután be fognak állítani egy rendes fordított zónát a
|
|
szerverükön, melynek helyességét megvizsgálhatod a dig-el.
|
|
|
|
A probléma második és egyben utolsó része az, hogy meg kell értened a
|
|
technikát. Ha nem vagy biztos benne, menj vissza, és olvass róla
|
|
ismét. Ezután beállíthatod a saját osztályon kívüli fordított zónádat
|
|
úgy, ahogy azt az Ask Mr. DNS leírja.
|
|
|
|
Lapul egy másik csapda is itt. A (nagyon) régi feloldók nem lesznek
|
|
képesek követni a CNAME trükköt a feloldási láncban, és nem lesznek
|
|
képesek fordítva feloldani a gépedet. Ez egy szolgáltatás esetében
|
|
helytelen hozzáférési osztály hozzárendelését, a hozzáférés
|
|
megtagadását vagy ezekhez hasonlót eredményezhet. Ha egy ilyen
|
|
szolgáltatásba ütközöl, az egyetlen megoldás (amiről én tudok) az
|
|
ISP-d számára az, hogy belerakja a PTR bejegyzésedet közvetlenül az ő
|
|
trükkös osztályon kívüli zónaállományukba a trükkös CNAME bejegyzés
|
|
helyett.
|
|
|
|
Bizonyos ISP-k más módokat fognak ajánlani ennek kezelésére, úgymint
|
|
Web-alapú űrlapokat a fordított hozzárendelés megadásához, vagy más
|
|
automágikus rendszereket.
|
|
|
|
5.6 Másodlagos (slave) szerverek
|
|
|
|
Amint helyesen beállítottad a zónáidat az elsődleges (master)
|
|
szerveren, fel kell állítanod legalább egy másodlagos (slave)
|
|
szervert. A másodlagos szerverek a robusztusság miatt szükségesek. Ha
|
|
az elsődleges leáll, az emberek ott kint a hálón még mindig képesek
|
|
lesznek információt kapni a tartományodról a szolgától. A
|
|
másodlagosnak olyan messze kell lennie tőled, amennyire csak
|
|
lehetséges. Az alábbi dolgok közül az elsődlegesnek és a
|
|
másodlagosnak minél kevesebben kellene osztozniuk: áramellátás, LAN,
|
|
ISP, város és ország. Ha ez mind más az elsődleges és a másodlagos
|
|
esetében, egy tényleg jó másodlagos szervert találtál.
|
|
|
|
A másodlagos szerver egyszerűen egy olyan névszerver, amely a
|
|
zónaállományokat lemásolja az elsődlegesről. Ekképp állíthatod be:
|
|
_________________________________________________________________
|
|
|
|
zone "linux.bogus" {
|
|
type slave;
|
|
file "sz/linux.bogus";
|
|
masters { 192.168.196.2; };
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Az adatok másolására a zónaátvitel nevű mechanizmust használják. A
|
|
zónaátvitelt az SOA bejegyzésed irányítja:
|
|
_________________________________________________________________
|
|
|
|
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
|
|
199802151 ; serial, todays date + todays serial #
|
|
8H ; refresh, seconds
|
|
2H ; retry, seconds
|
|
4W ; expire, seconds
|
|
1D ) ; minimum, seconds
|
|
_________________________________________________________________
|
|
|
|
Egy zóna csak akkor kerül átvitelre, ha a sorozatszáma (serial) az
|
|
elsődleges szerveren nagyobb, mint a másodlagoson. Frissítési
|
|
intervallumonként (refresh) a másodlagos szerver le fogja
|
|
ellenőrizni, hogy az elsődleges frissült-e. Ha az ellenőrzés nem
|
|
hoz eredményt (mert az elsődleges nem elérhető), újrapróbálja a
|
|
megadott intervallumonként (retry). Ha az ellenőrzések a lejárati
|
|
időszak (expire) alatt sem hoznak eredményt, a másodlagos szerver el
|
|
fogja távolítani a zónát az állományrendszeréből, és nem lesz többé
|
|
szerver számára.
|
|
|
|
6. Alapvető biztonsági beállítások
|
|
|
|
Jamie Norrish
|
|
|
|
A konfigurációs opciók beállítása a problémák valószínűségének
|
|
csökkentése érdekében.
|
|
|
|
Van néhány egyszerű lépés amelyet megtehetsz, ezek biztonságosabbá
|
|
teszik a szerveredet, és esetlegesen csökkentik a terhelését is. Az
|
|
itt bemutatott anyag nem több, mint egy kiindulási pont; ha érdekelt
|
|
vagy a biztonságban (és így kellene lennie), kérlek tanulmányozz át
|
|
más forrásmunkákat is a hálózaton (lásd az [21]utolsó fejezetet).
|
|
|
|
A következő beállítási direktívák fordulnak elő a named.conf
|
|
állományban. Az options részben található direktívák az összes zónára
|
|
vonatkoznak. Ha a zone bejegyzésben fordul elő, csak arra a zónára
|
|
vonatkozik. Egy zone bejegyzés felülírja az options bejegyzést.
|
|
|
|
6.1 A zónaátvitelek korlátozása
|
|
|
|
Annak érdekében, hogy a másodlagos szervere(i)d képes legyen
|
|
válaszolni a tartományodra vonatkozó lekérdezésekre, képeseknek kell
|
|
lenniük áthozni a zónainformációt az elsődleges szerveredről. Nagyon
|
|
sokan szeretnének szintén így cselekedni. Ezért korlátozd a
|
|
zónaátvitelt az allow-transfer opció használatával, feltételezve, hogy
|
|
192.168.1.4 az ns.friend.bogus címe, és hozzáadva saját magadat
|
|
hibakeresési célból:
|
|
_________________________________________________________________
|
|
|
|
zone "linux.bogus" {
|
|
allow-transfer { 192.168.1.4; localhost; };
|
|
};
|
|
_________________________________________________________________
|
|
|
|
A zónaátvitelek korlátozásával biztosítod, hogy az egyetlen elérhető
|
|
információ az, amit az emberek közvetlenül kérdeznek - senki sem
|
|
kérdezheti le csak úgy beállításod összes részletét.
|
|
|
|
6.2 Védekezés az "átejtés" ellen
|
|
|
|
Legelőször kapcsolj ki minden lekérdezést, ami nem az általad
|
|
birtokolt tartományokra irányul, kivéve a belső/helyi gépeidről
|
|
indulókat. Ez nem csak a DNS szervered rosszindulatú kihasználását
|
|
előzi meg, de csökkenti szervered felesleges használatát is.
|
|
_________________________________________________________________
|
|
|
|
options {
|
|
allow-query { 192.168.196.0/24; localhost; };
|
|
};
|
|
|
|
zone "linux.bogus" {
|
|
allow-query { any; };
|
|
};
|
|
|
|
zone "196.168.192.in-addr.arpa" {
|
|
allow-query { any; };
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Továbbá kapcsold ki a rekurzív lekérdezéseket, kivéve a belső/helyi
|
|
gépektől. Ez csökkenti a gyorsítótár-mérgezéses támadások esélyét
|
|
(amikor hamis adatokkal tömik a szerveredet).
|
|
_________________________________________________________________
|
|
|
|
options {
|
|
allow-recursion { 192.168.196.0/24; localhost; };
|
|
};
|
|
_________________________________________________________________
|
|
|
|
6.3 A named futtatása nem-root-ként
|
|
|
|
Egy jó ötlet a named-et a root-tól különböző felhasználóként
|
|
futtatni, így ha feltörik a cracker által szerzett jogok a lehető
|
|
legkorlátozottabbak. Először létre kell hoznod egy felhasználót ami
|
|
alatt a named fusson, majd módosítani bármely általad használt, a
|
|
named-et indító init szkriptet. Az új felhasználónevet és csoportot a
|
|
named-nek az -u és -g kapcsolók segítségével add meg.
|
|
|
|
Például: Debian GNU/Linux 2.2-ben módosítanod kell a /etc/init.d/bind
|
|
szkriptet, hogy tartalmazza a következő sort (ahol a named
|
|
felhasználó már létre lett hozva):
|
|
_________________________________________________________________
|
|
|
|
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named
|
|
_________________________________________________________________
|
|
|
|
Ugyanez megtehető a Red Hat-al és más disztribúciókkal is.
|
|
|
|
Dave Lugo leírt egy biztonságos kettős chroot beállítást, amely a
|
|
[22]http://www.etherboy.com/dns/chrootdns.html honlapon található, ez
|
|
még biztonságosabbá teheti a gépet, amelyen a named-et futtatod.
|
|
|
|
7. Egy valódi tartomány-példa
|
|
|
|
Ahol bemutatunk néhány igazi zónaállományt
|
|
|
|
A felhasználók javasolták, hogy illesszem be egy működő tartomány
|
|
valós példáját is, mint szemléltető példát.
|
|
|
|
E példát David Bullock engedélyével a LAND-5-től használom. Ezek az
|
|
állományok 1996. szeptember 24.-én voltak aktuálisak, és ezután
|
|
szerkesztettem át őket, hogy megfeleljenek a 8-as BIND megkötéseinek
|
|
és kiterjesztés-használatának. Szóval az amit látsz, különbözik egy
|
|
kicsit attól, amit a LAND-5 névszerverek lekérdezésekor találsz.
|
|
|
|
7.1 /etc/named.conf (vagy /var/named/named.conf)
|
|
|
|
Itt találhatók az elsődleges szerver zónafejezetei a két szükséges
|
|
fordított zóna számára: a 127.0.0 hálózat éppúgy, mint a LAND-5
|
|
206.6.177-es alhálózata, és az elsődleges sor a land-5 land5.com
|
|
továbbító zónája számára. Figyeld meg, hogy az állományok pz nevű
|
|
könyvtárba való pakolása helyett, ahogy én ezt ebben a HOGYANban
|
|
teszem, ő a zone nevű könyvtárba rakja őket.
|
|
_________________________________________________________________
|
|
|
|
// Boot file for LAND-5 name server
|
|
|
|
options {
|
|
directory "/var/named";
|
|
};
|
|
|
|
controls {
|
|
inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
|
|
};
|
|
|
|
key "rndc_key" {
|
|
algorithm hmac-md5;
|
|
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
|
|
};
|
|
|
|
zone "." {
|
|
type hint;
|
|
file "root.hints";
|
|
};
|
|
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "zone/127.0.0";
|
|
};
|
|
|
|
zone "land-5.com" {
|
|
type master;
|
|
file "zone/land-5.com";
|
|
};
|
|
|
|
zone "177.6.206.in-addr.arpa" {
|
|
type master;
|
|
file "zone/206.6.177";
|
|
};
|
|
_________________________________________________________________
|
|
|
|
Ha ezt berakod a named.conf állományodba kísérletezés céljából, KÉRLEK
|
|
rakd be a "notify no;"-t a két land-5 zóna zone fejezetébe, hogy
|
|
elkerüljük az ütközéseket.
|
|
|
|
7.2 /var/named/root.hints
|
|
|
|
Tartsd szem előtt, hogy ez az állomány dinamikus, és az itt közzétett
|
|
változat régi. Jobban teszed ha egy újabbat használsz, amint azt már
|
|
korábban elmagyaráztam.
|
|
_________________________________________________________________
|
|
|
|
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
|
|
; (1 server found)
|
|
;; res options: init recurs defnam dnsrch
|
|
;; got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
|
|
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
|
|
;; QUERY SECTION:
|
|
;; ., type = NS, class = IN
|
|
|
|
;; ANSWER SECTION:
|
|
. 6D IN NS G.ROOT-SERVERS.NET.
|
|
. 6D IN NS J.ROOT-SERVERS.NET.
|
|
. 6D IN NS K.ROOT-SERVERS.NET.
|
|
. 6D IN NS L.ROOT-SERVERS.NET.
|
|
. 6D IN NS M.ROOT-SERVERS.NET.
|
|
. 6D IN NS A.ROOT-SERVERS.NET.
|
|
. 6D IN NS H.ROOT-SERVERS.NET.
|
|
. 6D IN NS B.ROOT-SERVERS.NET.
|
|
. 6D IN NS C.ROOT-SERVERS.NET.
|
|
. 6D IN NS D.ROOT-SERVERS.NET.
|
|
. 6D IN NS E.ROOT-SERVERS.NET.
|
|
. 6D IN NS I.ROOT-SERVERS.NET.
|
|
. 6D IN NS F.ROOT-SERVERS.NET.
|
|
|
|
;; ADDITIONAL SECTION:
|
|
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
|
|
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
|
|
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
|
|
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
|
|
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
|
|
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
|
|
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
|
|
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
|
|
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
|
|
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
|
|
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
|
|
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
|
|
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
|
|
|
|
;; Total query time: 215 msec
|
|
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4
|
|
;; WHEN: Sun Feb 15 01:22:51 1998
|
|
;; MSG SIZE sent: 17 rcvd: 436
|
|
_________________________________________________________________
|
|
|
|
7.3 /var/named/zone/127.0.0
|
|
|
|
Csak az alapok, a kötelező SOA bejegyzés, és a bejegyzés, mely a
|
|
127.0.0.1-et a localhost-hoz rendeli. Mindkettő szükséges. Semmi
|
|
másnak nem kell lennie ebben az állományban. Valószínűleg soha nem
|
|
lesz frissítve, hacsak a névszervered vagy a rendszergazda címe nem
|
|
változik meg.
|
|
_________________________________________________________________
|
|
|
|
$TTL 3D
|
|
@ IN SOA land-5.com. root.land-5.com. (
|
|
199609203 ; Serial
|
|
28800 ; Refresh
|
|
7200 ; Retry
|
|
604800 ; Expire
|
|
86400) ; Minimum TTL
|
|
NS land-5.com.
|
|
|
|
1 PTR localhost.
|
|
_________________________________________________________________
|
|
|
|
Ha egy véletlenszerűen kiválasztott BIND telepítésre ránézel, azt
|
|
fogod találni, hogy a $TTL sor hiányzik. Ezt azelőtt nem használták,
|
|
és csak a 8.2-es BIND kezdett el figyelmeztetni a hiányára. A 9-es
|
|
BIND-hez szükséges a $TTL.
|
|
|
|
7.4 /var/named/zone/land-5.com
|
|
|
|
Itt látjuk a kötelező SOA bejegyzést, a szükséges NS bejegyzéseket.
|
|
Láthatjuk, hogy van egy másodlagos névszervere az ns2.psi.net-en. Ez
|
|
az ahogy lennie kell, mindig legyen egy telephelyen kívüli másodlagos
|
|
szervered tartalékként. Láthatjuk azt is, hogy van neki egy land-5
|
|
nevű elsődleges gépe is, amely gondoskodik sok különböző Internet
|
|
szolgáltatásról, és azt, hogy ezt CNAME-ekkel csinálta (egy másik
|
|
lehetőség az "A" bejegyzések használata).
|
|
|
|
Amint azt a SOA bejegyzésből láthatod, a zónaállomány eredete a
|
|
land-5.com, a kapcsolattartó személy a root@land-5.com. A hostmaster
|
|
egy másik gyakran használt cím a kapcsolattartó személy számára. A
|
|
sorozatszám a szokásos ééééhhnn formátumban van, a mai sorozatszám
|
|
hozzáadásával; ez valószínűleg a zónaállomány hatodik változata 1996.
|
|
szeptember 20.-án. Jegyezd meg, hogy a sorozatszámnak monoton
|
|
növekvőnek kell lennie, itt csak egy számjegy jelzi a mai
|
|
sorozatszámot, így 9 szerkesztés után várnia kell holnapig, mielőtt
|
|
újra szerkesztheti az állományt. Szokd meg a két számjegy használatát.
|
|
_________________________________________________________________
|
|
|
|
$TTL 3D
|
|
@ IN SOA land-5.com. root.land-5.com. (
|
|
199609206 ; serial, todays date + todays serial #
|
|
8H ; refresh, seconds
|
|
2H ; retry, seconds
|
|
4W ; expire, seconds
|
|
1D ) ; minimum, seconds
|
|
NS land-5.com.
|
|
NS ns2.psi.net.
|
|
MX 10 land-5.com. ; Primary Mail Exchanger
|
|
TXT "LAND-5 Corporation"
|
|
|
|
localhost A 127.0.0.1
|
|
router A 206.6.177.1
|
|
land-5.com. A 206.6.177.2
|
|
ns A 206.6.177.3
|
|
www A 207.159.141.192
|
|
ftp CNAME land-5.com.
|
|
mail CNAME land-5.com.
|
|
news CNAME land-5.com.
|
|
funn A 206.6.177.2
|
|
|
|
;
|
|
; Workstations
|
|
;
|
|
ws-177200 A 206.6.177.200
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177201 A 206.6.177.201
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177202 A 206.6.177.202
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177203 A 206.6.177.203
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177204 A 206.6.177.204
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177205 A 206.6.177.205
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
; {Many repetitive definitions deleted - SNIP}
|
|
ws-177250 A 206.6.177.250
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177251 A 206.6.177.251
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177252 A 206.6.177.252
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177253 A 206.6.177.253
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
ws-177254 A 206.6.177.254
|
|
MX 10 land-5.com. ; Primary Mail Host
|
|
_________________________________________________________________
|
|
|
|
Ha megvizsgálod a land-5 névszerverét, azt találod, hogy a gépnevek
|
|
ws_szám alakúak. A 4-es BIND-től kezdődően a named elkezdte
|
|
szigorítani a megkötéseket, hogy milyen karakterek szerepelhetnek a
|
|
gépnevekben. Így ez a 8-as BIND-el egyáltalán nem működik, és én
|
|
kicseréltem a "-"-re (kötőjel) a "_"-t (aláhúzás) ebben a HOGYANban.
|
|
De ahogy azt korábban említettem, a 9-es BIND nem erőlteti már ezt a
|
|
megkötést.
|
|
|
|
A másik figyelemre méltó dolog az, hogy a munkaállomásoknak nincs
|
|
egyedi nevük, hanem csak egy előtagot követ az IP utolsó két része.
|
|
Egy ilyen megszokás használata jelentősen leegyszerűsítheti a
|
|
karbantartást, de egy kicsit személytelennek tűnhet, és lényegében
|
|
bosszúság forrása lehet az ügyfeleid számára.
|
|
|
|
Látjuk azt is, hogy a funn.land-5.com egy álnév a land-5.com számára,
|
|
de egy "A", és nem egy CNAME bejegyzés használatával.
|
|
|
|
7.5 /var/named/zone/206.6.177
|
|
|
|
Megjegyzéseket ezen állományra lentebb teszek.
|
|
_________________________________________________________________
|
|
|
|
$TTL 3D
|
|
@ IN SOA land-5.com. root.land-5.com. (
|
|
199609206 ; Serial
|
|
28800 ; Refresh
|
|
7200 ; Retry
|
|
604800 ; Expire
|
|
86400) ; Minimum TTL
|
|
NS land-5.com.
|
|
NS ns2.psi.net.
|
|
|
|
; Servers
|
|
;
|
|
1 PTR router.land-5.com.
|
|
2 PTR land-5.com.
|
|
2 PTR funn.land-5.com.
|
|
;
|
|
; Workstations
|
|
;
|
|
200 PTR ws-177200.land-5.com.
|
|
201 PTR ws-177201.land-5.com.
|
|
202 PTR ws-177202.land-5.com.
|
|
203 PTR ws-177203.land-5.com.
|
|
204 PTR ws-177204.land-5.com.
|
|
205 PTR ws-177205.land-5.com.
|
|
; {Many repetitive definitions deleted - SNIP}
|
|
250 PTR ws-177250.land-5.com.
|
|
251 PTR ws-177251.land-5.com.
|
|
252 PTR ws-177252.land-5.com.
|
|
253 PTR ws-177253.land-5.com.
|
|
254 PTR ws-177254.land-5.com.
|
|
_________________________________________________________________
|
|
|
|
A fordított zóna a beállítás azon része, mely a legtöbb fejtörést
|
|
okozhatja. Ezt arra használjuk, hogy megtaláljuk a gépnevet, ha megvan
|
|
a gép címe. Példa: te egy FTP szerver vagy és kapcsolatokat fogadsz el
|
|
FTP kliensektől. Mivel te egy norvég FTP szerver vagy, több
|
|
kapcsolatot szeretnél fogadni norvégiai és más skandináv államokbeli
|
|
kliensektől, és kevesebbet a világ többi részéről. Ha kapcsolat
|
|
érkezik egy klienstől, a C függvénykönyvtár képes neked megmondani a
|
|
csatlakozó gép IP címét, mert a kliens IP számát tartalmazza az összes
|
|
csomag, amely átjött a hálózaton. Most meghívhatsz egy gethostbyaddr
|
|
nevű függvényt, mely kikeresi az adott IP számú kliens nevét. A
|
|
gethostbyaddr meg fogja kérdezni a DNS szervert, amely ezután
|
|
keresztülmegy a DNS-en a gépet keresve. Tételezzük fel, hogy a
|
|
klienskapcsolat a ws-177200.land-5.com-tól jön. Az IP szám, amit a C
|
|
könyvtár átad az FTP szervernek, a 206.6.177.200. A gép nevének
|
|
kitalálásához meg kell találnunk a 200.177.6.206.in-addr-arpa-t. A DNS
|
|
szerver először meg fogja találni az arpa. szervereket, majd
|
|
megtalálja az in-addr.arpa szervereket, követve a fordított sorrendet
|
|
a 206-on, majd a 6-on keresztül, végül legutoljára megtalálva a
|
|
LAND-5-nél a szervert a 177.6.206.in-addr-arpa zóna számára. Amelytől
|
|
végül megkapja a választ, hogy a 200.177.6.206.in-addr.arpa számára a
|
|
"PTR ws-177200.land-5.com" bejegyzésünk van, ami azt jelenti, hogy a /
|
|
206.6.177.200-hoz tartozó név a ws-177200.land.com.
|
|
|
|
Az FTP szerver előnyben részesíti a skandináv országok, azaz a *.no,
|
|
*.se, *.dk felől érkező kapcsolatokat, a ws-177200.land-5.com
|
|
egyértelműen nem tartozik közéjük, és a szerver a kapcsolatot egy
|
|
alacsonyabb sávszélességgel és kevesebb klienskapcsolati lehetőséggel
|
|
rendelkező kapcsolati osztályba sorolja. Ha nem lenne fordított
|
|
megfeleltetése a 206.2.177.200-nak az in-addr.arpa zóna által, a
|
|
szerver képtelen lenne megtalálni a nevet, és a 206.2.177.200-nek a
|
|
*.no, *.se és *.dk-val való összehasonlítása alapján kell döntenie,
|
|
melyek közül egyik sem fog egyezni, sőt még meg is tagadhatja a
|
|
kapcsolatot a besorolás hiánya miatt.
|
|
|
|
Páran azt fogják mondani neked, hogy a fordított lekérdezések
|
|
hozzárendelése csak szerverek esetén fontos, vagy egyáltalán nem
|
|
fontos. Nem így van: sok ftp, news, IRC, sőt még néhány http (WWW)
|
|
szerver nem fognak kapcsolatot fogadni olyan gépektől, melyek nevét
|
|
képtelenek megtalálni. Így hát a fordított hozzárendelés valójában
|
|
kötelező.
|
|
|
|
8. Karbantartás
|
|
|
|
Üzemben tartás.
|
|
|
|
Van egy karbantartási feladat, melyet meg kell tenned a named-eken - a
|
|
futtatáson kívül. Ez pedig a root.hints állomány naprakészen tartása.
|
|
A legegyszerűbb mód a dig használata. Először futtasd a dig-et
|
|
argumentumok nélkül, akkor megkapod a root.hints-et a saját szervered
|
|
alapján. Ezután kérdezd le a felsorolt főszerverek egyikét a dig
|
|
@rootserver paranccsal. Észre fogod venni, hogy a kimenet szörnyen
|
|
hasonló a root.hints állományhoz. Mentsd el egy állományba (dig
|
|
@e.root-servers.net . ns > root.hints.new), és cseréld le a régi
|
|
root.hints állományt vele.
|
|
|
|
Ne felejtsd el újra betölteni a named-et a gyorsítótár-állomány
|
|
cseréje után.
|
|
|
|
Al Longyear elküldte nekem ezt a szkriptet, mely automatikusan
|
|
futtatható a root.hints frissítése érdekében. Telepíts egy crontab
|
|
bejegyzést, hogy havonta egyszer lefusson, és el is felejtheted. A
|
|
szkript feltételezi, hogy a levelezésed működik, és hogy a
|
|
"hostmaster" cím meg van adva. Meg kell hackelned, hogy illeszkedjen a
|
|
beállításaidhoz.
|
|
_________________________________________________________________
|
|
|
|
#!/bin/sh
|
|
#
|
|
# Update the nameserver cache information file once per month.
|
|
# This is run automatically by a cron entry.
|
|
#
|
|
# Original by Al Longyear
|
|
# Updated for BIND 8 by Nicolai Langfeldt
|
|
# Miscelanious error-conditions reported by David A. Ranch
|
|
# Ping test suggested by Martin Foster
|
|
# named up-test suggested by Erik Bryer.
|
|
#
|
|
(
|
|
echo "To: hostmaster <hostmaster>"
|
|
echo "From: system <root>"
|
|
|
|
# Is named up? Check the status of named.
|
|
case `rndc status 2>&1` in
|
|
*refused*)
|
|
echo "named is DOWN. root.hints was NOT updated"
|
|
echo
|
|
exit 0
|
|
;;
|
|
esac
|
|
|
|
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
|
|
export PATH
|
|
# NOTE: /var/named must be writable only by trusted users or this script
|
|
# will cause root compromise/denial of service opportunities.
|
|
cd /var/named 2>/dev/null || {
|
|
echo "Subject: Cannot cd to /var/named, error $?"
|
|
echo
|
|
echo "The subject says it all"
|
|
exit 1
|
|
}
|
|
|
|
# Are we online? Ping a server at your ISP
|
|
case `ping -qnc 1 some.machine.net 2>&1` in
|
|
*'100% packet loss'*)
|
|
echo "Subject: root.hints NOT updated. The network is DOWN."
|
|
echo
|
|
echo "The subject says it all"
|
|
exit 1
|
|
;;
|
|
esac
|
|
|
|
dig @e.root-servers.net . ns >root.hints.new 2> errors
|
|
|
|
case `cat root.hints.new` in
|
|
*NOERROR*)
|
|
# It worked
|
|
:;;
|
|
*)
|
|
echo "Subject: The root.hints file update has FAILED."
|
|
echo
|
|
echo "The root.hints update has failed"
|
|
echo "This is the dig output reported:"
|
|
echo
|
|
cat root.hints.new errors
|
|
exit 1
|
|
;;
|
|
esac
|
|
|
|
echo "Subject: The root.hints file has been updated"
|
|
|
|
echo
|
|
echo "The root.hints file has been updated to contain the following
|
|
information:"
|
|
echo
|
|
cat root.hints.new
|
|
|
|
chown root.root root.hints.new
|
|
chmod 444 root.hints.new
|
|
rm -f root.hints.old errors
|
|
mv root.hints root.hints.old
|
|
mv root.hints.new root.hints
|
|
rndc restart
|
|
echo
|
|
echo "The nameserver has been restarted to ensure that the update is complete.
|
|
"
|
|
echo "The previous root.hints file is now called
|
|
/var/named/root.hints.old."
|
|
) 2>&1 | /usr/lib/sendmail -t
|
|
exit 0
|
|
_________________________________________________________________
|
|
|
|
Néhányan közületek felfigyelhettek rá, hogy a root.hints állomány
|
|
elérhető ftp-vel az Internic-ről is. Kérlek, ne használd az ftp-t a
|
|
root.hints frissítéséhez, a fentebb említett módszer sokkal
|
|
barátságosabb a hálózat és az Internic számára.
|
|
|
|
9. Átállás 9-es BIND-re
|
|
|
|
A 9-es BIND terjesztés - és az előre elkészített változatok szintén -
|
|
tartalmaz egy migration nevű dokumentumot, amely megjegyzéseket
|
|
tartalmaz azt illetően, hogy hogyan álljunk át 8-as BIND-ről 9-es
|
|
BIND-re. A dokumentum nagyon lényegre törő. Ha bináris csomagokat
|
|
telepítettél, feltehetően valahol a /usr/share/doc/bind*-ban vagy a
|
|
/usr/doc/bind*-ban van tárolva.
|
|
|
|
Ha 4-es BIND-et futtatsz, a migration-4to9 dokumentumot ugyanazon a
|
|
helyen találhatod.
|
|
|
|
10. Kérdések és válaszok
|
|
|
|
Kérlek olvasd át ezt a fejezetet, mielőtt írsz nekem.
|
|
1. A named-em egy named.boot állományt akar
|
|
Rossz HOGYANt olvasol. Kérlek nézd meg ezen HOGYAN régebbi
|
|
változatát, amely a 4-es BIND-ről szól, a
|
|
[23]http://langfeldt.net/DNS-HOWTO/ címen.
|
|
2. Hogy használhatom egy tűzfal mögül?
|
|
Segítség: forward only;. Szükséged lehet még a
|
|
_____________________________________________________________
|
|
|
|
query-source port 53;
|
|
_____________________________________________________________
|
|
|
|
sorra a named.conf állomány "options" részén belül, ahogy az a
|
|
példának bemutatott [24]A feloldó, gyorsítótáras névszerver
|
|
fejezetben javasoltam.
|
|
3. Mit tegyek, hogy a DNS körbeforogjon egy szolgáltatás elérhető
|
|
címein, mondjuk a www.busy.site-on, hogy terheléselosztó vagy
|
|
valami hasonló hatást érjek el?
|
|
Csinálj több A bejegyzést a www.busy.site számára, és 4.9.3-as
|
|
vagy későbbi BIND-et használj. Ekkor a BIND round-robin rendszer
|
|
alapján fogja szolgáltatni a válaszokat. Ez nem fog működni a
|
|
BIND korábbi változataival.
|
|
4. DNS-t akarok beállítani egy (zárt) belső hálózaton. Mit
|
|
csináljak?
|
|
Kihagyod a root.hints állományt, és csak a zónaállományokat
|
|
készíted el. Ez azt is jelenti, hogy nem kell állandóan
|
|
útbaigazító állományokat letöltened.
|
|
5. Hogyan kell beállítani egy másodlagos (slave) névszervert?
|
|
Ha az elsődleges szerver címe 127.0.0.1, egy ehhez hasonló sort
|
|
szúrsz be a másodlagos szervered named.conf állományába:
|
|
_____________________________________________________________
|
|
|
|
zone "linux.bogus" {
|
|
type slave;
|
|
file "sz/linux.bogus";
|
|
masters { 127.0.0.1; };
|
|
};
|
|
_____________________________________________________________
|
|
|
|
Több különböző elsődleges szervert is felsorolhatsz a masters
|
|
listán belül, ";"-vel (pontosvessző) elválasztva, melyekről a
|
|
zóna lemásolható.
|
|
6. Futtatni akarom a BIND-et, amikor nem vagyok kapcsolódva a
|
|
hálózathoz.
|
|
Négy lehetőség van:
|
|
+ A 8/9-es BIND-re vonatkozóan, Adam L.Rice ezt a levelet
|
|
küldte nekem arról, hogyan futtassuk fájdalommentesen a DNS-t
|
|
egy betárcsázós gépen:
|
|
|
|
|
|
A BIND újabb változatainál felfedeztem, hogy ez a kavarás az
|
|
állományokkal többé nem szükséges. Van egy "forward" (továbbítás) direktíva
|
|
a "forwarders" (továbbítók) direktíva mellett, amely a használatukat ellenőrzi
|
|
.
|
|
Az alap beállítás a "forward first" (először továbbítsd), amely
|
|
legelőször megkérdezi a továbbítók mindegyikét, és ezután próbálja
|
|
a rendes megközelítést, azaz a munka saját kezű elvégzését, ha ez nem sikerül.
|
|
Ezzel a gethostbyname() normál viselkedésése szokatlanul hosszú időt
|
|
vesz igénybe, amikor a kapcsolat nincs meg. De ha a "forward only" (csak
|
|
továbbítsd) van beállítva, akkor a BIND feladja ha nem kap választ a
|
|
továbbítóktól, és a gethostbyname() azonnal visszatér. Ennélfogva nincs
|
|
szükség bűvészmutatványokra az /etc könyvtárban levő állományokkal, és a szer
|
|
ver újraindítására.
|
|
|
|
Az én esetemben, csak hozzáadtam a
|
|
|
|
forward only;
|
|
forwarders { 193.133.58.5; };
|
|
|
|
sorokat a named.conf állományom options { } fejezetéhez. Nagyon szépen
|
|
működik. Ennek egyetlen hátránya az, hogy degradálja a DNS szoftver
|
|
egy hihetetlenül szofisztikált részét egy buta gyorsítótárrá. Bizonyos
|
|
mértékben, én csak egy buta gyorsítótárat szeretnék futtatni a DNS
|
|
helyett, de úgy tűnik, nincs egy ilyen fajta elérhető szoftver Linuxra.
|
|
|
|
+ Ezt a levelet Ian Clark-tól <ic@deakin.edu.au> kaptam, amiben
|
|
az ő módszerét magyarázza erre:
|
|
|
|
Named-et futtatok itt a "Masquerading" gépemen. Van két root.hints
|
|
állományom, az egyik neve root.hints.real, amely a valódi főszerver-
|
|
neveket tartalmazza, a másiké root.hints.fake, amely ezt tartalmazza:
|
|
|
|
----
|
|
; root.hints.fake
|
|
; this file contains no information
|
|
----
|
|
|
|
Ha kapcsolat nélküli üzemmódba megyek át, átmásolom a root.hints.fake
|
|
állományt a root.hints-be, és újraindítom a named-et.
|
|
|
|
Ha kapcsolódom, átmásolom a root.hints.real-t a root.hints-be, és
|
|
újraindítom a named-et.
|
|
|
|
Illetve ezt az ip-down és az ip-up teszi meg.
|
|
Amikor először végzek egy lekérdezést kapcsolat nélkül egy olyan
|
|
tartománynévre, amelyről a named nem tudja a részleteket, egy ilyen bejegyzést
|
|
rak a messages-be:
|
|
|
|
Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN
|
|
|
|
amivel együtt tudok élni.
|
|
|
|
Ez biztosan működik számomra. Használhatom a névszervert a helyi
|
|
gépek esetében, amikor a Net áll, a külső tartománynevekhez tartozó
|
|
időtúllépési késleltetés nélkül, és mikor a Hálón vagyok, a külső
|
|
tartománynevekre vonatkozó lekérdezések rendben működnek
|
|
|
|
Peter Denison azonban úgy vélte, Ian nem ment el elég
|
|
messzire. Ezt írja:
|
|
|
|
Kapcsolódva) szolgáltatja az eltárolt (és helyi hálózati) bejegyzéseket azon
|
|
nal
|
|
a nem gyorsítótárazott bejegyzések esetén, továbbítja az ISP névszerverem felé
|
|
Kapcsolat nélkül) kiszolgálja a helyi hálózati lekérdezéseket azonnal
|
|
más lekérdezések esetén **azonnal** hibát ad
|
|
|
|
A fő gyorsítótáras állomány cseréjének és a lekérdezések továbbításának
|
|
kombinációja nem működik.
|
|
|
|
Így hát, (a helyi Linux Felhasználók Csoportjával való némi konzultáció után)
|
|
két named-et állítottam be a következő módon:
|
|
|
|
named-online: továbbít az ISP névszervere felé
|
|
mester a helyi hálózati zóna számára
|
|
mester a helyi hálózati fordított zóna számára (1.168.192.in-ad
|
|
dr.arpa)
|
|
mester a 0.0.127.in-addr.arpa számára
|
|
a 60053-as porton figyel
|
|
|
|
named-offline: nincs továbbítás
|
|
"ál" fő gyorsítótáras állomány
|
|
szolga a 3 helyi zóna számára (a mester a 127.0.0.1:60053)
|
|
a 61053-as porton figyel
|
|
|
|
És kombináltam ezt a port-továbbítással, hogy az 53-as portot elküldje a 61053-
|
|
ra, ha
|
|
kapcsolat nélkül vagyok, és a 60053-ra, ha csatlakoztam. (Az új netfilter csoma
|
|
got
|
|
használom 2.3.18 alatt, de a régi (ipchains) módszernek is működnie kell.)
|
|
|
|
Figyelem, ez nem fog pikk-pakk működni, mivel van egy apró hiba a 8.2-es
|
|
BIND-ben, melyet már jelentettem a fejlesztőknek, hogy megakadályozza egy máso
|
|
dlagos szerver
|
|
létrehozását az elsődlegessel megegyező IP címen (még ha külön porton is). Ez
|
|
egy
|
|
egyszerű foltozás, és remélem, nemsokára belekerül.
|
|
|
|
+ Kaptam információt arról is Karl-Max Wanger-től, hogyan hat
|
|
egymásra a BIND az NFS-el és a portmapper-rel egy
|
|
nagyobbrészt kapcsolat nélküli gépen:
|
|
|
|
|
|
Futtatni szoktam a saját named-emet az összes gépemen, melyek csak
|
|
alkalmilag csatlakoznak az Internetre modemen keresztül. A névszerver
|
|
csak gyorsítótárként működik, nincs jogosultsági területe, és mindenért
|
|
a root.cache állományban levő névszervereket kérdezi vissza. Ahogy az a
|
|
Slackware-nél megszokott, az nfsd és a mountd előtt van indítva.
|
|
|
|
Egyik gépemmel (egy Libretto 30-as notebookal) az volt a problémám,
|
|
hogy néha fel tudtam csatolni egy másik, a helyi LAN-omra csatlakozott
|
|
rendszerről, de nagyobbrészt ez nem működött. Ugyanez volt a jelenség,
|
|
függetlenül attól, hogy PLIP-et, egy PCMCIA ethernet kártyát vagy soros
|
|
eszközön keresztüli PPP-t használtam.
|
|
|
|
Némi találgatás és kísérletezés után azt fedeztem fel, hogy
|
|
a named minden bizonnyal belerondít az nfsd és mountd regisztrációs folyamatába
|
|
,
|
|
amit induláskor a portmapper-rel kell elvégezniük (Ezeket a démonokat
|
|
szokás szerint bootoláskor indítom). A named indítása az nfsd és a mountd
|
|
után teljesen semlegesítette ezt a problémát.
|
|
|
|
Mivel nincsenek várható hátrányai az ilyen módosított boot szekvenciának,
|
|
ajánlom, hogy mindenki tegyen így az esetleges gondok elkerülése végett.
|
|
|
|
7. Hol tárolja a gyorsítótáras névszerver a gyorsítótárát? Van rá
|
|
bármi mód, hogy ellenőrizzem a gyorsítótár méretét?
|
|
A gyorsítótár teljes mértékben a memóriában van tárolva, soha nem
|
|
kerül kiírásra a lemezre. Valamennyiszer lelövöd a named-et, a
|
|
gyorsítótár elveszik. A gyorsítótár semmilyen módon nem
|
|
ellenőrizhető, a named gondozza néhány egyszerű szabály
|
|
alapján, és ennyi. Nem ellenőrizheted a gyorsítótárat, vagy annak
|
|
méretét semmilyen módon és semmiképp. Ha akarod, "kijavíthatod"
|
|
ezt a named hackelésével. Ez azonban nem ajánlott.
|
|
8. Lementi a named a gyorsítótárat az újraindítások között?
|
|
Megcsinálhatom, hogy így legyen?
|
|
Nem, a named nem menti le, ha meghal. Ez azt jelenti, hogy a
|
|
gyorsítótárat újra fel kell építeni minden alkalommal, amikor
|
|
lelövöd és újraindítod a named-et. Nincs mód rá, hogy rávedd a
|
|
named-et, hogy lementse gyorsítótárát egy állományba. Ha akarod,
|
|
"kijavíthatod" ezt a named hackelésével. Ez azonban nem ajánlott.
|
|
9. Hogyan szerezhetek be egy tartományt? Fel akarom állítani
|
|
(például) a linux-rules.net nevű tartományomat. Hogyan tehetem
|
|
meg, hogy az általam kívánt tartományt hozzám rendeljék?
|
|
Kérlek lépj kapcsolatba a hálózati szolgáltatóddal. Ők képesek
|
|
lesznek segíteni neked. Kérlek vedd figyelembe, hogy a világ
|
|
legtöbb részén pénzt kell fizetned egy tartományért.
|
|
10. Hogyan tehetem biztonságossá a DNS szerveremet? Hogyan állíthatok
|
|
be felosztott DNS-t?
|
|
Mindkettő haladó téma. A
|
|
[25]http://www.etherboy.com/dns/chrootdns.html honlap szól róluk.
|
|
Nem fogom ezeket a témákat tovább magyarázni itt.
|
|
|
|
11. Hogyan válhatok képzettebb DNS adminná?
|
|
|
|
Dokumentáció és eszközök.
|
|
|
|
Létezik Valódi Dokumentáció. Azonnal olvasható (online) és nyomtatott.
|
|
Ezek közül néhány elolvasása követelmény a kezdő DNS adminból egy
|
|
haladó adminná váláshoz.
|
|
|
|
Megírtam a The Concise Guide to DNS and BIND (Nicolai Langfeldt, én)
|
|
könyvet, kiadta a Que (ISBN 0-7897-2273-9). A könyv hasonlatos ehhez a
|
|
HOGYANhoz, csak részletesebb, és mindenből sokkal több van benne. Le
|
|
van fordítva lengyelre is, és DNS i BIND kiadva a Helion által (
|
|
[26]http://helion.pl/ksiazki/dnsbin.htm, ISBN 83-7197-446-9). Most van
|
|
negyedik kiadásban a DNS and BIND Cricket Liu-tól és P. Albitz-től az
|
|
O'Reilly & Associates gondozásában (ISBN 0-937175-82-X,
|
|
előszeretettel nevezve a Cricket könyvnek). Egy másik könyv a Linux
|
|
DNS Server Administration, Craig Hunt-tól, a Sybex kiadásában (ISBN
|
|
0782127363), még nem olvastam el. Egy másik követelmény a képzett DNS
|
|
adminisztrátor számára a Zen and the Art of Motorcycle Maintenance
|
|
Robert M. Pirsig-től.
|
|
|
|
Megtalálhatod a könyvemet azonnal olvasható formában (online), más
|
|
könyvek tonnáival együtt, amelyek elektronikusan elérhetők mint
|
|
előfizetéses szolgáltatás a [27]http://safari.informit.com/ honlapon.
|
|
Van még anyag a [28]http://www.dns.net/dnsrd/ (DNS Resources
|
|
Directory), [29]http://www.isc.org/bind.html címen; Egy GYIK, egy
|
|
referencia kézikönyv (az ARM-nak szintén benne kell lennie a BIND
|
|
disztribúcióban) éppúgy, mint papírok és protokoll definíciók, és DNS
|
|
hackek (ezeket, és a legtöbb, ha nem az összes, lentebb említett
|
|
RFC-t, szintén tartalmazza a DNS disztribúció). Többségét nem
|
|
olvastam. A [30]news:comp.protocols.tcp-ip.domains hírcsoport a
|
|
DNS-ről szól. Ezekhez adódóan van egy pár RFC a DNS-ről, a
|
|
legfontosabbak valószínűleg az itt felsoroltak. Azok, melyeknek van
|
|
BCP (Best Current Practice - Legjobb Jelenlegi Gyakorlat) száma,
|
|
erősen ajánlottak.
|
|
|
|
/RFC 2671/ P. Vixie, Extension Mechanisms for DNS (EDNS0) 1999
|
|
augusztus. (DNS kiterjesztési mechanizmusok)
|
|
|
|
/RFC 2317/
|
|
BCP 20, H. Eidnes et. al. Classless IN-ADDR.ARPA delegation,
|
|
1998 március. (Osztályon kívüli IN-ADDR.ARPA delegálás) Ez a
|
|
CIDR-ről szól, vagy az osztályon kívüli alhálózatok fordított
|
|
lekérdezéséről.
|
|
|
|
/RFC 2308/
|
|
M. Andrews, Negative Caching of DNS Queries, 1998 március. (A
|
|
DNS lekérdezések negatív gyorsítótárazása) A negatív
|
|
gyorsítótárazásról és a $TTL zónaállomány direktíváról.
|
|
|
|
/RFC 2219/
|
|
BCP 17, M. Hamilton and R. Wright, Use of DNS Aliases for
|
|
Network Services, 1997 október. (A DNS álnevek használata
|
|
hálózati szolgáltatások céljára) A CNAME használatáról.
|
|
|
|
/RFC 2182/
|
|
BCP 16, R. Elz et. al., Selection and Operation of Secondary
|
|
DNS Servers, 1997 július. (A másodlagos DNS szerverek
|
|
kiválasztása és működtetése)
|
|
|
|
/RFC 2052/
|
|
A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location
|
|
of services (DNS SRV), October 1996 (Egy DNS RR a
|
|
szolgáltatások helymeghatározására)
|
|
|
|
/RFC 1918/
|
|
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
|
|
Address Allocation for Private Internets, 1996.02.29.
|
|
(Címlefoglalás magán Internetek számára)
|
|
|
|
/RFC 1912/
|
|
D. Barr, Common DNS Operational and Configuration Errors,
|
|
1996.02.28. (Gyakori üzemeltetési és beállítási DNS hibák)
|
|
|
|
/RFC 1912 Errors/
|
|
B. Barr /Errors in RFC 1912. (Hibák az RFC 1912-ben/ Csak a
|
|
[31]http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html
|
|
címen érhető el.
|
|
|
|
/RFC 1713/
|
|
A. Romao, Tools for DNS debugging, 1994.11.03. (A DNS
|
|
hibakeresés eszközei)
|
|
|
|
/RFC 1712/
|
|
C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding
|
|
of Geographical Location, 1994.11.01. (A földrajzi helyek
|
|
DNS-be kódolása)
|
|
|
|
/RFC 1183/
|
|
R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR
|
|
Definitions, 1990.10.08. (Új DNS RR meghatározások)
|
|
|
|
/RFC 1035/
|
|
P. Mockapetris, Domain names - implementation and
|
|
specification, 1987.11.01. (Tartománynevek - implementáció és
|
|
specifikáció)
|
|
|
|
/RFC 1034/
|
|
P. Mockapetris, Domain names - concepts and facilities,
|
|
1987.11.01. (Tartománynevek - fogalmak és lehetőségek)
|
|
|
|
/RFC 1033/
|
|
M. Lottor, Domain administrators operations guide, 1987.1.01.
|
|
(Tartomány-adminisztrátorok üzemeltetői útmutatója)
|
|
|
|
/RFC 1032/
|
|
M. Stahl, Domain administrators guide, 1987.11.01.
|
|
|
|
(Tartomány-adminisztrátorok útmutatója)
|
|
|
|
/RFC 974/
|
|
C. Partridge, Mail routing and the domain system, 1986.01.01.
|
|
(Levéltovábbítás és a tartományrendszer)
|
|
|
|
References
|
|
|
|
1. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#qanda
|
|
2. http://langfeldt.net/DNS-HOWTO/
|
|
3. http://www.tldp.org/
|
|
4. mailto:zfuri@avaya.com_NO_SPAM
|
|
5. mailto:laca@janus.gimsz.sulinet.hu_NO_SPAM
|
|
6. mailto:linuxhowto@sch.bme.hu_NO_SPAM
|
|
7. http://tldp.fsf.hu/index.html
|
|
8. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#qanda
|
|
9. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#bigger
|
|
10. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#qanda
|
|
11. ftp://ftp.isc.org/isc/bind9/
|
|
12. http://langfeldt.net/DNS-HOWTO/
|
|
13. http://www.isc.org/products/BIND/
|
|
14. http://djbdns.org/
|
|
15. http://cr.yp.to/djbdns/ad.html
|
|
16. http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html
|
|
17. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#maint
|
|
18. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#qanda
|
|
19. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#starting
|
|
20. http://www.acmebw.com/askmrdns/00007.htm
|
|
21. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#bigger
|
|
22. http://www.etherboy.com/dns/chrootdns.html
|
|
23. http://langfeldt.net/DNS-HOWTO/
|
|
24. file://localhost/home/dacas/temp/DNS-HOWTO-hu.html#caching
|
|
25. http://www.etherboy.com/dns/chrootdns.html
|
|
26. http://helion.pl/ksiazki/dnsbin.htm
|
|
27. http://safari.informit.com/
|
|
28. http://www.dns.net/dnsrd/
|
|
29. http://www.isc.org/bind.html
|
|
30. news:comp.protocols.tcp-ip.domains
|
|
31. http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html
|