Odmowa transferu strefy powiązania

10

AKTUALIZACJA:

Wersja BIND:

[[email protected]] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5

System operacyjny:

CentOS release 5.6 (Final)

Po uruchomieniu [[email protected]] $ dig @10.224.45.130 example.com. axfr:

Niewolnik:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options:  printcmd
; Transfer failed.

Mistrz:

28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied

Ten sam komunikat o błędzie jak poprzednio.

AKTUALIZACJA 2:

[[email protected] ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 171K   23M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0           
57196 6930K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
  688 57376 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
37869 6120K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  392 21216 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
   74  5275 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    3   192 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:389 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:465 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
   13   832 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:636 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:694 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:843 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:873 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:953 
  119  7584 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:993 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    1    48 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5901 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.224.45.130       tcp dpt:10000 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11211 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11212 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11213 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11511 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11512 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11513 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2987  372K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 

Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
 pkts bytes target     prot opt in     out     source               destination

Prawdopodobnie patrzyłem na każdą stronę dotyczącą konfiguracji BIND master / slave i przez całe życie nie mogę uruchomić transferu strefy.

Oto moja konfiguracja: (przewiń w dół, aby wyświetlić opis problemu)

Mistrz: 10.224.45.130

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify explicit;
    allow-transfer {
        10.224.45.131;
    };
    also-notify {
        10.224.45.131;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type master;
    file "data/example.com.hosts";
};

Slave: 10.224.45.131

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify yes;
    allow-transfer { "none"; };
    allow-notify {
        10.224.45.130;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type slave;
    file "slaves/example.com.hosts";
    masters {
        10.224.45.130;
    };
};

Oto problem. Kiedy ponownie uruchamiam nazwę na serwerze podrzędnym, widzi, że pliki strefy jeszcze nie istnieją i żąda transferu z serwera głównego:

named.log (Slave)

[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53

... po czym serwer główny otrzymuje żądanie przeniesienia:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -

... i odpowiada na żądanie przeniesienia, które zostaje odrzucone:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied

... na serwerze podrzędnym jest wyświetlany jako ODMOWY:

named.log (Slave)

[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED

Przeglądając wszystkie konfiguracje w kółko, nie mogę znaleźć niczego złego w ustawieniach. Mam adres IP serwera głównego wymieniony w mastersustawieniach konfiguracji strefy podrzędnej, Mam adres IP serwera podrzędnego wymieniony w allow-transferustawieniach ustawień opcji głównych.

Wszystkie adresy IP są takie, jakie powinny być, to nie jest tak, że próbuje użyć publicznego adresu IP i zostaje odrzucony, ponieważ adres IP nie pasuje. Mam konfigurację iptables, aby umożliwić połączenia TCP / UDP na porcie 53 (i 953) na obu serwerach. Prawidłowo skonfigurowałem uprawnienia do plików, aby użytkownik mógł zapisać katalog / slaves, w którym przechowywane są pliki strefy slave named.

Bez względu na to, co robię, zawsze pojawia się ten sam błąd. Jeśli ktokolwiek może dać mi wskazówkę co do tego, czego mi brakuje, naprawdę byłbym wdzięczny!

centos bind centos5 dns-zone master-slave Sarah Ryan
źródło
2
Czy próbowałeś (tymczasowo) ustalanie allow-transferaby anyzobaczyć czy to rozwiązuje problem? Twoja allow-transferklauzula wygląda poprawnie, ale to wyeliminuje wszelkie szanse na problemy ...
voretaq7
Nie, wciąż pojawia się ten sam błąd. Próbowałem też dodać adres WAN IP serwera głównego do ustawienia „master”, na wszelki wypadek, i to też nie naprawiło.
Sarah Ryan,
1
Czy działałeś rndc reconfigpo zmianie konfiguracji w systemie głównym?
Cakemox

Odpowiedzi:

3

Aby rozpocząć, spróbuj sprawdzić, czy transfer strefy działa.

Na slave, wydaj dig @master your-domain. axfr

Jakie wersje BIND i jaki system operacyjny?

dmourati
źródło
Zaktualizowałem moje pytanie o dane wyjściowe i dzienniki tego polecenia. Pokazuje to jako odrzucone, tak jak w zwykłym żądaniu transferu strefy. Dodałem również informacje dotyczące wersji i systemu operacyjnego. Przepraszamy za pozostawienie tych ważnych informacji.
Sarah Ryan,
1
OK, więc fakt, że polecenie dig nie powiedzie się, wskazuje, że nadal występuje problem z urządzeniem głównym. @ voretaq7 powyżej sugeruje zezwolenie na przeniesienie do dowolnego, który zgadzam się, jest rozsądnym krokiem do rozwiązania problemu. Dodaj localhost, aby zezwolić na transfery, spróbuj wykonać polecenie dig od master na localhost. Skonfiguruj również „tcpdump -i dowolny port 53” na urządzeniu głównym, aby zweryfikować źródłowy / docelowy adres IP. Mówisz „Mam konfigurację iptables, aby zezwalać na połączenia TCP / UDP na porcie 53 (i 953) na obu serwerach”, ale proszę dodać wynik „iptables -L -n -v” na urządzeniu głównym. To lub zamknij iptables na master i przetestuj ponownie.
dmourati
Dodałem localhost (jak również wszystkie inne nazwy hostów i adresy IP, które mogą być) do ustawienia zezwolenia na transfer i nadal otrzymuję ten sam błąd. Dodałem dane wyjściowe z żądanej komendy iptables, a także wyłączono iptables podczas ponownej próby. Wciąż nie ma szczęścia.
Sarah Ryan
3

Znalazłem problem. Używam chrootowanego BIND, ale edytowałem pliki conf w / etc, a nie w / var / named / chroot / etc. Tak więc zmiany, które wprowadzałem, nie były widoczne. Skopiowałem pliki conf do katalogu chroot i teraz wszystko działa dobrze.

Sarah Ryan
źródło
1
Dobry chroot. Cieszę się, że to znalazłeś.
dmourati,
1

Może się wydawać, że jest to już uwzględnione w allow-transferinstrukcji w options, ale spróbuj dodać jawną allow-transferinstrukcję w strefie.

Naprawdę nie widzę nic złego w twojej konfiguracji. Wygląda na to, że powinno działać. Czy bind nasłuchuje w ogóle na tym porcie? (Tj. Czy jakieś żądania się powiodły? A może wszystkie się nie powiedzą?)

Mam jeszcze dwa pomysły, które warto wypróbować.

  1. Upewnij się, że oba zegary są aktualne (przynajmniej w rozsądnym zakresie) na obu serwerach.

  2. Być może przeszkadza Ci SELinux. Spróbuj wyłączyć tymczasowo, aby przetestować.

bahamat
źródło
Próbowałem umieścić opcję zezwolenia na transfer w konfiguracji strefy i nadal daje mi ten sam błąd. To tylko nieudane żądania przesyłania. Mogę pomyślnie zapytać serwer o dowolny typ rekordu, a on zwróci go zgodnie z oczekiwaniami. Ale kiedy próbuję wykonać transfer strefy, otrzymuję odmowę / ODMOWNE komunikaty o błędach.
Sarah Ryan,
Sprawdź moją odpowiedź na aktualizację.
bahamat