DNS jest systemem hierarchicznym – jak to wytłumaczyć hmmm… Są domeny główne – tzw. Top Level Domain’s – domeny najwyższego poziomu (chyba to będzie dobre tłumaczenie). TLD to jest np. ‘com’ (komercyjne), ‘net’ (networks – sieci), czy też ‘pl’ (polska) albo ‘de’ (niemcy). Są to domeny z góry określone przez odpowiednie postanowienia i są opisane w odpowiednich dokumentach, ale to nie tutaj będę o tym pisał. W TLD’s są poddomeny, np. com.pl, wp.pl, wiosenna.com (:->) czy też ahead.de. W poddomenach mogę być kolejne poddomeny albo hosty – np. slayer.wiosenna.com. I tak w kółko. Ale nie przejmuj się jak tego nie rozumiesz, przyjdzie Ci z czasem :-).

Konfiguracja DNS (Bind 8/9)

Według wszelakich norm, każda domena powinna mieć dwa nameservery – podstawowy i zapasowy. Podstawowy posiada wszelakie informacje o domenie, na nim dopisujemy hosty i wszelakie ustawienia, a poprawnie skonfigurowany zapasowy poprostu transferuje sobie plik strefy do siebie i go przechowuje wspomagając tego pierwszego.

/etc/named.conf

Jest to główny plik konfiguracyjny Binda 8.x/9.x – w tym pliku ustawiamy katalog w którym są pliki stref, nazwy domen jakie nasz dns utrzymuje. Plik ten wygląda mniej więcej tak:

options {        directory "/var/named";        // query-source address * port 53;};
zone "." {
        type hint;
        file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
};

Jak widać najpierw jest sekcja options – standardowo definiuje katalog /var/named (w PLD /var/lib/named – gdyż tam named jest chrootowany) aby był domyślnym katalogiem ze strefami. Później jest zdefiniowana strefa ‘.’ – wytłumaczenie tej strefy opiszę za parę dni – w każdym bądź razie plik /var/named/named.ca (named.ca jest zdefiniowane w sekcji zone – file „named.ca”, katalog wyżej, w options) musi się znajdować aby bind poprawnie działał. Czasami ma on nazwę root.cache, albo samo cache. Następny wpis to wpis domeny odwrotnej (rDNS) dla 127.0.0.* – czyli dla localhosta.

Ok, więc dopiszmy teraz jakąś domene. Zakładam że ona już jest wydelegowana na Twój nameserver i jest to podstawowy nameserver, a zapasowy użyczył Ci administrator z Twojej uczelni albo jakoś tak ;) Więc piszemy:

zone "naszadomena.pl" {
	type master;
	file "naszadomena.pl";
	allow-transfer { 213.25.209.97; };
	notify yes;
};

Pokoleji opisuje jeszcze raz co oznacza co:
- zone „naszadomena.pl” – to oznacza że ten wpis w configu będzie się odnosił do domeny naszadomena.pl;
- file „naszadomena.pl” – to oznacza że wszystkie wpisy co do tej domeny będą w pliku naszadomena.pl w katalogu /var/named – katalog ten ustawia się na samym początku configu;
- allow-transfer {ldelim} 213.25.209.97; {rdelim} – tutaj zamiast 213.25.209.97 wpisujemy adresy IP zapasowego serwera DNS; – notify yes – ta opcja włącza powiadamianie zapasowego serwera DNS o tym że zmieniliśmy jakieś wpisy w naszej domenie.

Teraz plik /var/named/naszadomena.pl…

Zaczynamy edycję. Tak w ramach uprzedzenia – wszystkie wpisy w plikach stref poprzedzone średnikami ‘;;’ są ignorowane i traktowane jako komentarz, więc postanowiłem na żywo komentować co oznaczają poszczególne wpisy. Będąc przy okazji katalogów – w PLD wszystkie pliki domen primary znajdują się w katalogu /var/lib/named/M a secondary w /var/lib/named/S. Takie są założenia nameda w PLD i warto się ich trzymać (czytaj: pamiętać o tym przy wpisach zone w named.conf ;)). Generalnie rekordy w takim pliku mają postać: [rekord] IN [typ] wartosc

Typy wpisów, najczęściej stosowane to:

- A – wpis wskazujący na adres IP – czyli że dany host w domenie ma podany adres IP:

komp1	IN	A	192.168.1.1

- NS – wpis informujący o tym że dany fragment domeny jest obsługiwany przez konkretne serwery DNS:

poddomena	IN	NS	dns1.jakasfirma.pl.
poddomena	IN	NS	dns2.jakasfirma.pl.

I tutaj mała uwaga. Jeżeli wpis dotyczy jakiegoś hosta w naszej domenie, np. tak jak przy przykładzie wpisu IN A użyłem hosta komp1, to domyślnie jest doklejana jest nazwa domeny do hosta, inaczej mówiąc jeżeli robimy wpis komp1 IN A 192.168.1.1 w pliku domeny naszadomena.pl, to w tym momencie przypisalismy nazwie komp1.naszadomena.pl adres IP 192.168.1.1. Natomiast jak widzicie na przykładzie rekordu IN NS na końcu dns*.jakasfirma.pl dodałem kropki. Dlaczego? Bo jak bym wpisał dns1.jakasfirma.pl bez kropki, to w tym momencie Bind dokleiłby na końcu dns*.jakasfirma.pl nazwe naszej domeny i przykladowo efekt bylby taki ze poddomena.naszadomena.pl jest obsługiwana przez dns*.jakasfirma.pl.naszadomena.pl ;-). Więc pamiętaj o tych kropkach jeżeli wpis jest spoza domeny. Tak btw. to przy wpisie komp1 można równierz wpisać komp1.naszadomena.pl. IN A 192.168.1.1, ale po co jeżeli można prościej samo komp1 ;-). Nadążasz? To dobrze, ja też nie, jest 4:15 nad ranem i sam się dziwie że jeszcze chce mi się kończyć ten tekst. Dobra. Jedziemy dalej ;-).

- MX – wpis informujący jaki serwer trzyma pocztę dla danej (pod)domeny:

poczta	IN	MX	5	listonosz

Taki wpis oznacza że wszystkie maile w formie użytkownik@poczta.naszadomena.pl będą kierowane na komputer który się zowie listonosz.naszadomena.pl. Oczywiście musimy mu jakiś adres IP przydzielić pisząc np. listonosz IN A 217.8.186.23. Ta cyferka między MX a listonosz definiuje priorytet z jakim ma być używany serwer listonosz.naszadomena.pl. Możemy naprzykład zdefiniować dwa serwery do poczty:

poczta	IN	MX	5	listonosz
poczta	IN	MX	10	poczta.jakasdomena.pl.

Efekt takiego wpisu jest taki, że jeżeli listonosz.naszadomena.pl sobie padnie, to w tym momencie cała poczta jest puszczana do poczta.jakasdomena.pl. Oczywiście obydwa serwery muszą być poprawnie skonfigurowane, a poczta.jakasdomena.pl powinna być wysyłana na listonosz.naszadomena.pl gdy ten powróci do życia. Ale tego zdeydowanie w bindzie się nie skonfiguruje tylko gdzie indziej. Jeżeli masz tylko jeden serwer pocztowy poprostu wpisz jeden z numerkiem np. 10.

- CNAME – tzw. alias:

www	IN	CNAME	superserwer
ftp	IN	CNAME	ftp.uczelnia.pl.

tak więc www.naszadomena.pl to alias dla superserwer.naszadomena.pl. Natomiast jak ktoś wbije się na ftp.naszadomena.pl to defacto połączy się z ftp.uczelnia.pl – tam jest dosyć duże i ładne archiwum niech tam sobie ludzie szukają ;-). I znowu uwaga co do kropek!

Te cztery wpisy są najczęściej używane. Do tego dochodzi jeszcze rekord SOA, ale o nim napiszę już poniżej, w przykładowym pliku sterfy:

$TTL 86400
$ORIGIN naszadomena.pl.

;; Te dwie linijki oznaczają jaki ma być domyślny czas
;; ważności rekordów w sekundach, oraz jaką domenę opisujemy.
;; 86400 = 1 dzień. Są to informacje dla bind'a które określają
;; co ma doklejić do rekordu jeżeli na jego końcu nie ma '.'

@	IN	SOA	naszserwer.pl. root.naszadomena.pl. (

;; Start Of Authority czyli rekord SOA - opisuje on kto
;; zarządza naszą domeną (root@naszadomena.pl) oraz czasy
;; ważności wpisów w domenie, odświeżania i
;; numer seryjny domeny. Zamiast @ w adresie e-mail
;; (root.naszadomena.pl) należy wpisać '.'! Podobnie znak
;; '(' jest konieczny gdyż na tym rekord SOA się nie kończy.
;; A co oznacza to @ na początku? '@' znaczy iż rekord
;; dotyczy naszadomena.pl samej w sobie.
;; Pierwsze pole (naszserwer.pl) oznacza iz pod tym adresem
;; znalezc mozna glowny DNS tej domeny - wpisuje sie tam nazwe
;; Primary DNS.

2001052501

;; Numer seryjny domeny - powinien być przy każdej modyfikacji
;; pliku strefy zwiększany, a w dobrym tonie jest utrzymywanie
;; go w formacie YYYYMMDDnn - czyli rok, miesiąc, dzień i
;; i numer modyfikacji danego dnia o ile jest to któraś
;; z koleji modyfikacja danego dnia

1200

;; refresh - To pole rekordu SOA definiuje jak często serwery
;; slave mają sprawdzać czy dane o domenie zmieniły się na
;; masterze. Według RFC, wartość ta powinna się zawierać
;; pomiędzy 1200 a 43200 (czyli od 20 minut do 12 godzin).
;; W praktyce, najlepsza wartość to 3600-7200 sekund.

1200

;; retry - Tutaj ustawiamy po jakim czasie secondary ma ponowić
;; próbę kontaktu z masterem gdy taka się nie powiedzie.
;; Zalecana wartość to 120-7200 sekund.

2419200

;; expire - Ta wartość określa po jakim czasie dane domeny mają
;; zostać uznane za nieaktualne gdy secondary nie będzie mógł
;; się dobić do primary dns'a. Zalecana wartość to od 1209600
;; do 2419200 sekund (od 2 do 4 tygodni).

86400 )

;; time-to-live - czyli TTL. Określa ile czasu informacja o
;; każdym rekordzie ma być ważna, czyli ile czasu nameserver
;; który gdzieś po drodze zcacheował jakiś rekord z naszej
;; domeny ma go pamiętać. Zalecana wartość to 86400 - 432000
;; (1 do 5 dni). Na końcu tego pola znajduje się znak ')'
;; oznaczający rekord SOA.

@	IN	NS	naszserwer.pl.
@	IN	NS	czyjsdns.innasiec.pl.

;; Tutaj zdefiniowalismy że domene obsługują w/w serwery dns.
;; No dobrze, a jak nasz komputer nie ma żadnej domeny jeszcze,
;; albo chcemy mieć ładne wpisy dns1.naszadomena.pl i
;; dns2.naszadomena.pl ? Osoba która nam wydelegowała domene
;; (w przypadku .pl to jest nask ale o tym poniżej)
;; prawdpopdobnie wzieła od nas adresy IP i odrazu je
;; definiowała ale my też powinniśmy to wpisać w taki sposób:
;;
;;	@	IN	NS	dns1
;;	@	IN	NS	dns2
;;	dns1	IN	A	192.168.1.1
;;	dns2	IN	A	192.168.1.2
;;
;; Oczywiście te adresy IP to nasz adres i adres zapasowego
;; DNS'a.

;; definiujemy że poczta@naszadomena.pl obsługiwana jest przez
;; serwer mail.naszadomena.pl:

@	IN	MX	10	mail

;; który musimy oczywiście jakoś stworzyć:

mail	IN	A	192.168.1.3

;; natomiast poczta@poczta.naszadomena.pl ma iść na serwer
;; mail2.naszadomena.pl:

poczta	IN	MX	5	mail2

;; chyba że mail2 padnie to wtedy ma iść na serwer mail:

poczta	IN	MX	10	mail

;; definiujemy jeszcze tylko mail2 (mail już wyżej
;; zdefiniowaliśmy):

mail2	IN	A	192.168.1.4

;; Generalnie chcemy aby przy użyciu naszadomena.pl był
;; podawany taki adres IP:

@	IN	A	192.168.1.10

;; będzie to nasz serwer www, więc dajmy mu takowy wpis:

www	IN	A	192.168.1.10

;; Jest to poprawne - kilka domen/hostów może wskazywać na
;; dany adres IP... Stwórzmy jeszcze wpisy na komputery w
;; naszej sieci:

komp1	IN	A	192.168.1.101
komp2	IN	A	192.168.1.102
komp3	IN	A	192.168.1.103
komp4	IN	A	192.168.1.104
komp5	IN	A	192.168.1.105

;; No tak, znajomemu się bardzo nazwa naszej domeny
;; spodobała i chciałby sobie cosik w niej pomajstrować,
;; więc wydelegujmy mu poddomene, która będzie obsługiwana
;; przez jego serwer DNS:

znajomy	IN	NS	znajomy.pl.

;; i zapasowy damy mu u siebie:

znajomy	IN	NS	dns

;; i przydzielmy hostowi dns.naszadomena.pl w końcu jakiś
;; adres:

dns	IN	A	192.168.1.7

;; Zróbmy jeszcze wpis ftp.naszadomena.pl. W sumie to więcej
;; oprogramowania jest u nas na uczelni i niech tam sobie
;; ludziki grzebią ;)

ftp	IN	CNAME	ftp.uczelnia.edu.pl.

;; Uf... To już chyba wszystko. Możemy zapisać plik z naszą
;; domeną.

Ok, domena stworzona, trzeba teraz uruchomić nasz serwer DNS. Jeżeli jest już uruchomiony, wystarczy poprostu rozkazać mu przeładować konfiguracje. Robi się to na kilka sposobów:
- komendą named.reload – spowoduje to wywołanie skryptu zmuszającego binda do przeładowania konfiguracji;
- komendą killall -HUP named – efekt ten sam jak wyżej;
- /etc/rc.d/init.d/named reload – efekt ten sam jak wyżej, komenda zadziała na RedHat’ach, Mandrake’ach i tym podobnych (nie wiem jak SuSe i Debian – jak ktoś by mógł mnie uświadomić…)
- /etc/rc.d/init.d/named restart – spowoduje to zatrzymanie pracy binda (o ile chodził już) i jego ponowne uruchomienie.

Jeżeli bind nie uruchamia się automatycznie podczas startowania sewera to są 3 sposoby na zmuszenie go do pracy:
- W Slackware modyfikacja pliku /etc/rc.d/rc.inet2;
- W RH, MDK, PLD, Gentusie, prawdopodobnie SuSE i podobnych: chkconfig –level 345 named on;
- echo „/usr/bin/named -u nobody -g nobody” >> /etc/rc.d/rc.local – metoda nieestetyczna ale skuteczna ;-). W tym momencie trzeba zmienić właścieciela katalogu bind’a: chown nobody.nobody /var/named (lub inny katalog ustalony w /etc/named.conf).

Jeżeli chcemy zmodyfikować jakiś wpis w domenie zmieniamy numer seryjny w pliku strefy przy każdej zmianie. Na tej podstawie serwery DNS rozpoznają.

Zapasowy DNS

A jeżeli chcemy postawić zapasowy DNS? To już jest o wiele prostsze. Wystarczy że ktoś wpisze adres IP w allow transfer w /etc/named.conf i w tym momencie nasz dns ma prawo tranferu sterfy. W tym momencie należy wykonać następujący wpis w /etc/named.conf na secondary dns:

zone "naszadomena.pl" IN {
        type slave;
        file "naszadomena.pl";
        masters { 195.116.163.58; };
};

W polu masters ustawiamy adres IP podstawowego DNS’a. Należy się upewnić czy użytkownik z którego pracuje bind (ps -aux|grep named) ma prawa do zapisu w katalogu z plikami stref. Po paru chwilach od wykonania killall -HUP named powinniśmy mieć w katalogu ze strefami ściągnięty plik strefy. Oczywiście zasady tworzenia strefy na podstawowym NS’ie są takie same jak opisałem powyżej.

Obydwa NS’y na jednym serwerze

Jeżeli posiadamy dwa adresy IP na jednym hoście możemy dns’a skonfigurować w taki sposób że on sam obsługuje odstawowy dns:

@	IN	NS	dns1.naszadomena.pl.
@	IN	NS	dns2.naszadomena.pl.
dns1	IN	A	192.168.1.30
dns2	IN	A	192.168.1.31

Oczywiście 192.168.1.30 i 31 to nasz serwer. W tym momencie ustawiamy opcje allow-transfer na none w /etc/named.conf i konfigurujemy dns’a tak jakby był to podstawowy dns.

Uf… No to w sumie by było na tyle. Mam nadzieje że o niczym nie zapomniałem. Uwagi mile widziane. Wszystko opisałem najprościej jak się dało – jeżeli nie rozumiesz tego co napisałem nie męcz mnie – nie mam nic więcej do powiedzenia w temacie DNS ;-)…

W normalnych wpisach DNS nazwy wskazują na adresy IP. Oczywiście adres IP może także wskazywać na nazwę. Takie coś nazywamy rDNS (reverse DNS – DNS odwrotny). Wpisy takie są zapisane w specjalnych domenach in-addr.arpa, i są w nich przechowywane w formie odwrotnej. Jak to by wytłumaczyć… Hm. Otóż reversdns dla adresu IP 213.25.100.23 jest zapisany w postaci 23.100.25.213.in-addr.arpa – czyli jak widać odwrotnej ;). No i oczywiście służy do tego specjalny typ rekordu – PTR. Czyli taki rekord to przykładowo:

23.100.25.213.in-addr.arpa	IN	PTR	netserv.baseciq.eu.org.

Dzięki takiemu rekordowi wiemy, że pod adresem IP 213.25.100.23 kryje się nazwa ‘netserv.baseciq.eu.org’. A jak z delegacją? Tutaj sprawa się komplikuje – minimalna domena w takim przypadku jaką można wydelegować to 100.25.213.in-addr.arpa, czyli 255 adresów. Jeżeli dostaliśmy od providera tak dużą ilość adresów IP to wtedy on nam deleguje takiego typu domene. Zasady jej tworzenia są tak jak w przypadku normalnych domen (napisałem już jak je się tworzy), z tym że możemy sobie darować rekordy IN MX, IN CNAME czy inne. Poprostu postępujemy tak jakby ktoś nam wydelegował (dla przykładu) domenę 100.25.213.in-addr.arpa. Oczywiśc można np. utworzyć host www.100.25.213.in-addr.arpa ale po co ? :-). Oto taka przykładowa domenka (dla 255 adresów z klasy 213.25.100.*):

$TTL	86400
$ORIGIN	100.25.213.in-addr.arpa.

;; Start of authority i czasy ...

@	IN	SOA	dns1.naszadomena.pl. hostmaster.naszadomena.pl. (
 2001073001 21600 7200 1209600 86400 )

;; Serwery dns dla tej domeny

@	IN	NS	dns1.naszadomena.pl.
@	IN	NS	secdns.provider.pl.

;; No i już konkretne hosty. Jako że są to hosty w tejże domenie,
;; piszemy kolejno 1 dla 213.25.100.1, 2 dla 213.25.100.2, itd..
;; Nie zapominajmy o kropkach na końcu wpisów. Jeżeli przy
;; 1 IN PTR napiszemy router.naszadomena.pl bez kropki,
;; to faktyczny rDNS dla 213.25.100.1 przyjmie wartość
;; router.naszadomena.pl.100.25.213.in-addr.arpa. - czyli te same
;; uwagi co wcześniej co do kropek.

1	IN	PTR	router.naszadomena.pl.
2	IN	PTR	netserv.baseciq.eu.org.
3	IN	PTR	www.baseciq.eu.org.
40	IN	PTR	komp40.naszadomena.pl.

;; i tak dalej...

Oki. Teraz kilka zasad. W sumie najważniejsze w dzisiejszych czasach wykorzystanie rDNS to IRC. Tak więc kilka zasad. Otóż poza tym że jest rekord PTR w rDNS’ie, potrzeba jeszcze aby host na który wkazuje adres IP, wskazywał na ten adres. Dobrze a jak provider nam daje mniejszą ilość adresów? Możemy albo jego poprosić o ustawienie rdns’a u siebie, albo o delegacje pojedyńczych hostów. Delegacje pojedyńczych hostów robi się poprzez wskazanie w domenie odwrotnej za pomocą rekordów IN CNAME na hosty w innej domenie (którą my możemy kontrolować) i ustawienie w tamtej domenie odpowiednich rekordów PTR. Oto przykład (zakładając że delegowane są adresy 213.25.100.0-7, a my możemy kontrolować domene naszadomena.pl):

;; W domenie 100.25.213.in-addr.arpa muszą być stworzone wpisy:
;; (oczywiście pamiętamy o kropkach na końcu!)

0	IN	CNAME	rdns0.naszadomena.pl.
1	IN	CNAME	rdns1.naszadomena.pl.
2	IN	CNAME	rdns2.naszadomena.pl.
3	IN	CNAME	rdns3.naszadomena.pl.
4	IN	CNAME	rdns4.naszadomena.pl.
5	IN	CNAME	rdns5.naszadomena.pl.

;; Hm, adres IP 213.25.100.6 należy do mojego prywatnego
;; servera i ja w swojej własnej domenie będę ustawiał
;; reverse-dns dla mnie ;-)))

6	IN	CNAME	revdns.dla.baseciq.eu.org.
7	IN	CNAME	rdns7.naszadomena.pl.

;; A w naszadomena.pl ustawiamy sobie już właściwy rDNS.

rdns0	IN	PTR	netaddr.naszadomena.pl.
rdns1	IN	PTR	router.naszadomena.pl.
rdns2	IN	PTR	netserv.naszadomena.pl.
rdns3	IN	PTR	dyrekcja.naszadomena.pl.
rdns4	IN	PTR	sekretariat.naszadomena.pl.
rdns5	IN	PTR	serwis.naszadomena.pl.
;; rdns6 nie ma bo go ustawiamy w innej domenie ;)))
rdns7	IN	PTR	broadcast.naszadomena.pl.

;; No i oczywiście muszę sobie ustawić reverse dns
;; dla mojego servera pod 213.25.100.6 w mojej domenie -
;; - baseciq.eu.org:

revdns.dla	IN	PTR	boski.baseciq.eu.org.

Powyższe zmiany należy wprowadzić w trzech plikach oczywiście (provider w strefie odwrotnej, my w domenie naszadomena.pl i ja sam dla siebie w baseciq.eu.org). Oczywiście i tutaj hosty które ustawimy w rekordzie PTR muszą posiadać rekord IN A.

A może by tak sobie ułatwić?

W sumie wpisywanie ‘[cyfra] IN CNAME r[cyfra].costam.pl.’ może być na dłuższą metę nużące. Równie dobrze, możemy powiedzieć binowi (z tego co wiem przynajmniej w wersji 9.x) aby zrobił coś z nas. Teoretycznie, chcemy wykonać wpisy ‘[cyferka] IN CNAME rev[cyferka].naszadomena.pl.’, gdzie cyferka jest od 0 do 7 (czyli pierwsze 8 adresów). Zamiast klepać kolejne rekordy można użyć:

$GENERATE 0-7 $ CNAME rev$.naszadomena.pl.

Czyli: ‘wygeneruj od 0 do 7 i zrób podany rekord wstawiając kolejne cyfry w miejsce znaku $’. Działa to oczywiście także dla stref prostych. Np:

$GENERATE 0-255 komp$ A 192.168.1.$

Co w efekcie da name wpisy ‘komp0 IN A 192.168.1.0′ … ‘komp255 IN A 192.168.1.255′. Fajne? Mi się też to podoba.

I taka mała uwaga na koniec: nie, nie pomogę ci na zmiane revdns dla twojego łącza z SDI/Neostrada/chello czy innego ustrojstwa – dlaczego ci nie pomoge? Bo sie nie da. Providerzy tychże usług odmawiają zmiany rDNS jak i jego delegacji.

search wiosenna.com
nameserver 127.0.0.1
nameserver 194.204.159.1
nameserver 194.204.152.34

Hm… Czyli najpierw lokalny bind, później "kochane" ns’y tpsy… A jak rozwiązuje sobie domeny spoza świata lokalny bind? Używa resolv.conf? Hm… Chyba nie… Oki, wycinamy z resolv.conf ipki, SIGHUP w named’a i jedziemy. # dig wiosenna.com @0 … Zadziałało, więc już mamy pewność że to nie resolv.conf. So what?

zone "." in {
        type hint;
        file "root.cache";
};

Czyli 13 ROOT-SERVERS… Popingujmy je. Wiem, mogą mieć zablokowane możliwości pingowania… Z 13 które ja miałem w fabrycznym root.cache odpowiedziało 5:

64 bytes from 192.33.4.12: icmp_seq=0 ttl=242 time=250.402 ms
64 bytes from 192.203.230.10: icmp_seq=0 ttl=53 time=311.281 ms
64 bytes from 192.5.5.241: icmp_seq=0 ttl=54 time=310.181 ms
64 bytes from 192.112.36.4: icmp_seq=0 ttl=240 time=280.216 ms
64 bytes from 198.32.64.12: icmp_seq=0 ttl=242 time=340.989 ms

W przypadku dns i dns2 tpsa.pl czasy te są około 30-40 ms… Więc 10 razy szybciej. Jaki z tego morał? Standardowy Bind skonfigurowany jest na ROOT-SERVERS, co w dzisiejszych czasach raczej nie wróży nam zbyt szybkiej pracy. Nie wierzącym polecam odpalenie iptrafa albo innego ustrojstwa i monitorowanie połączeń UDP. Bind ma głęboko w nosie resolv.conf, co w sumie jest bardzo logiczne. Więc należy jakoś zmusić by korzystał z bliższych ns’ów niż ROOT-SERVERS (naprawdę, dns.tpsa.pl wcale nie jest taki makabryczny). Zmodyfikować mu root.cache? Podobno można, u mnie to słabo pomogło. A może przedefiniować mu strefę "."? To już bardziej logiczne. Pół godziny studiowania wyniku komendy ‘man named.conf’ nasunął mi pewne wnioski. So, usuwamy strefę "." z /etc/named.conf i wpisujemy zamiast niej coś takiego:

zone "." IN {
        type forward;
        forward only;
        forwarders { 194.204.159.1; 194.204.152.34; };
        check-names ignore;
    // Uwaga! Opcja check-names jest obsługiwana tylko
    // przez Bind'a 8.x. W Bindzie 9.x nie jest ona wymagana!
};

Tak zupełnie BTW. ostatnio się zorientowałem że w Bind 9.x (dokładnie 9.2.1 z PLD) można to prościej. Wystarczy w sekcji options { } dopisać (bez konieczności defioniowania strefy ".":

options {
    forwarders { 194.204.159.1; 194.204.152.34; };
}

W miejsce 194.204… Należy wpisać IPki serwerów dns z których chcemy korzystać. Polecam ns1.ikp.pl – niestety nie wszystkich on lubi ;). Istnieje także dns.tpi.pl – działa jak narazie całkiem cacy. Dobra. Mniam! Mimo tego iż wygląda na to że bind nie cachuje nic z forwardowanych zapytań (przynajmniej ja tak wnioskowałem), to jednak pamięta wpisy o które się odpytywaliśmy :-). HUPnełem named’a znowu, odpytałem się któryś z root servers o domenkę unroutable.net: Total query time: 5319 msec – no i teraz sobie wyobraź(cie) ile czasu trwało odpytanie root-server’s… Błe… A później się dziwie że mi nie rozwiązuje domenek a przez modem jak ustawiam dns’y providera to prawie odrazu. A wogóle po co mi to? Otóż uparłem się iż w sieci lokalnej będę korzystał z DNS’a na serwerze od maskarady ;)… Po kilku chwilach namysłu z resolv.conf wyciełem wszystkie ipki poza 127.0.0.1 – po co lokalny resolver ma puszczać coś poza serwer?