Puncte:2

DNS secundar nu răspunde la dig

drapel cn

Suntem noi în DNS. încercăm să configuram un server DNS secundar folosind Bind & CentOS pentru un server primar existent (de exemplu: 142.250.192.110).

Configurația serverului nostru secundar este următoarea:

    portul de ascultare 53 { 127.0.0.1; orice; };
        portul listen-on-v6 53 { ::1; orice; };
        directorul „/var/named”;
        dump-file "/var/named/data/cache_dump.db";
        fișierul-statistici „/var/named/data/named_stats.txt”;
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        fișier recurs "/var/named/data/named.recursing";
        secroots-file "/var/named/data/named.secroots";
        permite-interogare { orice; };

    
zona „example.com” ÎN {
        tip slave;
        masters { 142.250.192.110; };
        fișierul „slaves/example.forward”;
};
zona "192.250.142.in-addr.arpa" IN {
        tip slave;
        masters { 142.250.192.110; };
        fișierul „slaves/example.reverse”;
};

Când am executat dig @127.0.0.1 host1.example.com primim un răspuns corect. Când am executat cu IP local (Server secundar), dig @192.168.1.10 host1.example.com primim un răspuns corect.

Dar când executăm comanda cu IP-ul public / numele de gazdă al unui server secundar, de exemplu: dig @dns2.example.com host1.example.com primim erori de genul ;; conexiunea a expirat; niciun server nu a putut fi atins

Vă rugăm să sugerați ceva ajutor pentru a rezolva această problemă. Vă mulțumim anticipat pentru timpul și ajutorul dumneavoastră prețios.

Câteva informații și detalii de depanare (IP și numele de gazdă nu sunt originale):

DNS primar: 142.250.192.110 (dns1.example.com)

DNS secundar: 192.168.1.10 (IP local), 142.250.192.220 (dns2.example.com)

nslookup dns2.example.com

Server: 8.8.8.8
Adresă: 8.8.8.8#53

Răspuns neautorizat:
Nume: dns2.example.com
Adresa: 142.250.192.220

dig @127.0.0.1 host1.example.com - Succes

dig @192.168.1.10 host1.example.com - Succes

dig @142.250.192.220 host1.example.com - A eșuat.

dig @dns2.example.com host1.example.com - A eșuat.

tcpdump arată transferul de pachete, cu dig @127.0.0.1 și sapă @192.168.1.10. Dar spectacole FĂRĂ transfer de pachete, cu dig @142.250.192.220 și dig @dns2.example.com.

Pentru a verifica dacă firewall-ul blochează portul 53, am testat portul cu tcpdump și tcpdump arată transferul de pachete când a făcut telnet 142.250.192.220 53

Notă: Avem un firewall care face NAT IP local cu IP public. Așteptăm răspunsul echipei de rețea, dacă Firewall blochează această solicitare de săpături.

A. Darwin avatar
drapel my
Este 192.168.1.10 IP-ul privat al serverului DNS secundar?
drapel cn
Da. este IP-ul privat al DNS-ului secundar.
Patrick Mevzek avatar
drapel cn
Asta înseamnă că `dns2.example.com` nu se rezolvă la IP-ul tău corect, ci la altceva. Primul pas pentru `dig` când se folosește `@` este să rezolve acel nume pentru a-l putea contacta pentru a-i trimite apoi o interogare DNS.
drapel cn
Întrebare actualizată cu detalii IP și pași de depanare.
Puncte:0
drapel in

Verificați întotdeauna jurnalele de pe ambele servere. Verificați dacă sclavul a reușit să preia zona. Un pas este să faci transferul manual folosind dig @192.168.1.10 axfr example.com de la sclav, unde @192.168.1.10 este masterul în configurația slave.

permite-transfer { }; ar putea fi necesar pe master pentru a permite sclavului să preia zona. Din nou, toate acestea sunt în jurnale.

Verificați întotdeauna accesul local mai întâi. Verificați cu netstat -anp dacă serverul ascultă corect și verificați din nou jurnalele. și ca ultimă soluție, încercați tcpdump pentru a vedea ce pachete merg unde și dacă există vreun răspuns.

drapel cn
dig @PrimaryDNS_IP exemplu axfr. com este un succes. Ieșirea este ........ ;; Timp de interogare: 2 ms ;; SERVER: PRIMARY_IP.53#53(PRIMARY_IP) ;; CÂND: marți, 27 iulie, 23:48:17 IST 2021 ;; Dimensiune XFR: 94 de înregistrări (mesaje 1, octeți 2877) Se pare că secundar poate vorbi cu primar.
drapel cn
Întrebare actualizată cu detalii IP și pași de depanare.
drapel in
rețineți că DNS utilizează atât UDP, cât și TCP pe portul 53, utilizați „netstat -anp | grep 53” pentru a le verifica pe ambele, verificați dacă ascultă pe anumite ip-uri sau adresa „orice” 0.0.0.0 (care ar trebui să fie cu configurația dvs. , dar nu face rău pentru a verifica) Cu elementele de bază acoperite, aș spune că aveți o problemă de rutare/firewall.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.