Join Log in
Score:2
avatar Server

Secondary DNS is not responding to dig

cn flag
iamsumesh

We are new to DNS. we are trying to configure a secondary DNS server using Bind & CentOS for an existing primary server (Eg:142.250.192.110).

Our secondary server configuration is as follows:

    listen-on port 53 { 127.0.0.1; any; };
        listen-on-v6 port 53 { ::1; any; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { any; };

    
zone "example.com" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.forward";
};
zone "192.250.142.in-addr.arpa" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.reverse";
};

When we executed dig @127.0.0.1 host1.example.com we are getting a proper reply. When we executed with local IP (Secondary Server), dig @192.168.1.10 host1.example.com we are getting a proper reply.

But when we execute command with public IP / hostname of a secondary server, Eg: dig @dns2.example.com host1.example.com we are getting errors like ;; connection timed out; no servers could be reached

Please suggest some help to solve this issue. Thanks in advance for your valuable time and help.

Some information and troubleshoot details (IP & hostname is not original):

Primary DNS: 142.250.192.110 (dns1.example.com)

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

nslookup dns2.example.com

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   dns2.example.com
Address: 142.250.192.220

dig @127.0.0.1 host1.example.com - Success

dig @192.168.1.10 host1.example.com - Success

dig @142.250.192.220 host1.example.com - Failed.

dig @dns2.example.com host1.example.com - Failed.

tcpdump shows packet transfer, with dig @127.0.0.1 and dig @192.168.1.10. But shows NO packet transfer, with dig @142.250.192.220 and dig @dns2.example.com.

To check, whether the firewall is blocking port 53, we tested the port with tcpdump and tcpdump shows packet transfer when did telnet 142.250.192.220 53

Note: We have a firewall that does NAT local IP with Public IP. We are waiting for the reply from the network team, whether Firewall is blocking this dig request.

247
1 + 4
A. Darwin avatar
my flag
A. Darwin
Is 192.168.1.10 the private IP of the secondary DNS server?
0
Reply
cn flag
iamsumesh
Yes. it is the private IP of secondary DNS.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
That means `dns2.example.com` does not resolve to your correct IP but something else. The first step for `dig` when using `@` is to resolve that name to be able to contact it to then send a DNS query to it.
1
Reply
cn flag
iamsumesh
Updated question with IP details and troubleshooting steps.
0
Reply
Score:0
avatar Server
in flag
NiKiZe

Always check the logs on both servers. Verify that the slave has been able to fetch the zone. One step is to do the transfer manually using dig @192.168.1.10 axfr example.com from the slave, where @192.168.1.10 is the master in the slave config.

allow-transfer { }; might be needed on master to allow the slave to fetch the zone. Again, all this is in the logs.

Always check local access first. Check with netstat -anp if the server is listening properly, and again check the logs. and as a last resort, try tcpdump to see which packets go where and if there is any reply.

0 + 3
cn flag
iamsumesh
dig @PrimaryDNS_IP axfr example. com is a success. Output is ........ ;; Query time: 2 msec ;; SERVER: PRIMARY_IP.53#53(PRIMARY_IP) ;; WHEN: Tue Jul 27 23:48:17 IST 2021 ;; XFR size: 94 records (messages 1, bytes 2877) It looks like secondary can talk to primary.
0
Reply
cn flag
iamsumesh
Updated question with IP details and troubleshooting steps.
0
Reply
in flag
NiKiZe
note that DNS uses both UDP and TCP on port 53, use "netstat -anp | grep 53" to check both, verify if it listens on specific ips, or the "any" 0.0.0.0 address, (which it should with your config, but don't harm to verify) With the basics covered, I'd say you have a routing/firewall issue.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.