Bind i niedzialajacy jeden DNS

[Wojciech Błaszkowski]

Witam,
> Dnia czwartek 28 styczeń 2010 o 12:27:51 Wojciech Błaszkowski napisał(a):
> > Dnia czwartek 28 styczeń 2010, Arkadiusz Chomicki napisał:
> > > witam
> >
> > Witam,
> >
> > > Jest domena w sieci dla ktorej dziala tylko jeden DNS (z dwoch
> > > wpisanych) Moj DNS (Bind) odpytuje (chyba) tylko jeden z nich i jesli
> > > trafi na niedzialajacy to zwraca ze domena nieznaleziona.
> >
> > Zawsze można zerknąć do
> > http://tools.ietf.org/html/rfc1034 gdzie w punkcie 5.3 resolver internals
> >  mamy opisane w jaki sposób powinien działać resolver, a konkretnie w
> >  5.3.3. Algorithm czytamy o naprzemiennej kolejności odpytywania dnsów
> > ,,In addition to the names and addresses of the servers, the SLIST data
> > structure can be sorted to use the best servers first, and to insure that
> > all addresses of all servers are used in a round-robin manner.  The
> > sorting can be a simple function of preferring addresses on the local
> > network over others, or may involve statistics from past events, such as
> > previous response times and batting averages.''
> >
> > Dlaczego tak jest zrobione? Po to by nie przeciążać jednego serwera dns
> >  (np. primary) milionami zapytań podczas gdy pozostałe nic by nie robiły.
> >
> > Niektóre implementacje resolverów (np. w tworach z Redmond m.in. NT więc
> > w XP zapewne też) stosują się dodatkowo do powyższego ,,of preferring
> > addresses on the local network over others'' po to by np. kierować
> > zapytania do serwera w LANie ale i tak stosują round robin.
> >
> > Na potwierdzenie słów prosty test - proponuję wejść na
> > http://www.dnsreport.com/tools/dnsreport.ch?domain=nask.pl i popatrzeć na
> > linijkę: [These were obtained from X] - gdzie przy każdym przeładowaniu X
> >  się zmienia - po prostu round robin działa.
> >
> > > jak zrobic by moj Bind odpytywal drugi DNS jesli pierwszy nie dziala i
> > >  zwracal informacje z tego drugiego (dzialajacego)
> > >
> > > z poważaniem
> 
> Ale moj przypadek jest taki:
> Mam resolv ustawione na siebie,
> wykonuje host altona.pl i dostaje:
> # host altona.pl
> altona.pl has address 195.85.230.20
> ;; connection timed out; no servers could be reached
> Host altona.pl not found: 3(NXDOMAIN)

Raczej nie tak. Trzeba sprawdzić konkretnie dany serwer, a nie na "chybił 
trafił". Tu akurat przypadek, że wybrano 195.85.230.20.

$ host -at a altona.pl 195.85.230.20
Trying "altona.pl"
Using domain server:
Name: 195.85.230.20
Address: 195.85.230.20#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15688
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;altona.pl.                     IN      A

;; ANSWER SECTION:
altona.pl.              14400   IN      A       195.85.230.20

;; AUTHORITY SECTION:
altona.pl.              14400   IN      NS      195.85.230.21.
altona.pl.              14400   IN      NS      195.85.230.20.

Received 97 bytes from 195.85.230.20#53 in 20 ms

W odpowiedzi mamy nagłówek z flagami. Interesuje nas 2 flaga "aa", authotity 
answer. Oznacza to, że na zapytanie o domenę altona.pl otrzymaliśmy odpowiedź 
rzeczywiście od 195.85.230.20, którego to pytaliśmy. Serwer ten nie pytał 
innego serwera o rozwiązanie tej nazwy.

Pójdźmy dalej i sprawdźmy SOA na obydwu serwerach:

host -at soa altona.pl 195.85.230.20
Trying "altona.pl"
Using domain server:
Name: 195.85.230.20
Address: 195.85.230.20#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34767
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;altona.pl.                     IN      SOA

;; ANSWER SECTION:
altona.pl.              14400   IN      SOA     195.85.230.20. root.altona.pl. 
2010012701 14400 3600 1209600 86400

;; AUTHORITY SECTION:
altona.pl.              14400   IN      NS      195.85.230.21.
altona.pl.              14400   IN      NS      195.85.230.20.

Received 122 bytes from 195.85.230.20#53 in 48 ms

oraz:

$ host -at soa altona.pl 195.85.230.21
Trying "altona.pl"
Using domain server:
Name: 195.85.230.21
Address: 195.85.230.21#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43989
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;altona.pl.                     IN      SOA

;; ANSWER SECTION:
altona.pl.              14400   IN      SOA     195.85.230.20. root.altona.pl. 
2010012701 14400 3600 1209600 86400

;; AUTHORITY SECTION:
altona.pl.              14400   IN      NS      195.85.230.20.
altona.pl.              14400   IN      NS      195.85.230.21.

Received 122 bytes from 195.85.230.21#53 in 27 ms

Wygląda na to, że błąd został poprawiony.

> no wiec sprawdzam dig'iem:
> # dig @195.85.230.20 altona.pl
> [...]
> 
> gdzie moze lezec problem?
> moze w NASK Registry sa inne serwery podane?

W NASK tworzone są glue records, wiążące hosta z numerem IP. Geleralnie jest 
tak, że IP widoczne na whois jako przypisane do hostów są równoważne z glue 
records w registry NASK.

> z poważaniem

-- 
Pozdrawiam, Best regards, Mit freundlichen Grüßen,

Wojciech "Wojtosz" Błaszkowski
www.blaszkowski.com
GSM: +48 600 197 207
JID: wojtosz w jabber.biz.pl