0

I am trying to replace an authoritative DNS server running on RHEL 6 with an authoritative DNS server running on RHEL 7. DNSSEC is enabled.

I copied the zone files, keys, etc from the RHEL 6 DNS server to the RHEL 7 DNS server and confirmed named-chroot was resolving names with dig @localhost xxx.xx.xxx.xxxx.

To keep things as simple as possible I want to move the IP address in use by the RHEL 6 server to the RHEL 7 server.

I turned off the RHEL 6 server's interface and brought up the RHEL 7 server's interface. I assigned it the IP address but I am unable to connect to it. Traceroute shows no response. I dropped iptables, tried traceroute again and still got no response.

I deleted the ip address from the RHEL 7 server, turned off it's interface, and brought up the RHEL 6 server's interface. Traceroute now shows a response and the RHEL 6 server resolves names correctly.

I asked our firewall (Sonic Wall) admin if there was anything in the rules that would discriminate based on the server's hostnames (they are different) but he showed me the rule that sends all DNS traffic to the IP address so that would not seem to be the problem.

Any suggestions on what else I can look at? Could DNSSEC be causing this problem?

  • Check that the port 53 is open on your server, also try to change the key. If your servers are both under the same router and they have different local IP's then this need to be changed from the router. – Talal Al-Khalifa Jul 24 '19 at 20:41
  • 1
    From the RHEL7 server, check that you can ping your local gateway and a remote public IP that is known to be pingable. Some ARP issues can lead to a change of IP being non-instantaneous, if your gateway doesn't update its ARP table. It could take 10 minutes or more in some cases for an ARP table entry to expire. Bottom line, don't begin your testing until you're sure RHEL7 can ping its gateway and can ping something on the public internet. Connectivity first, functionality second. – Jim L. Jul 25 '19 at 0:03
  • To give a different perspective on what @JimL. says, it makes no difference what your bigger purpose is with the DNS etc. When you shut off the iface on server1 and start it on server2, you can't reach the IP. THis is a network configuration/connectivity issue. This is an IPv4 network connectivity issue, DNS is irrelevant. – 0xSheepdog Jul 25 '19 at 14:35
2

To keep things as simple as possible I want to move the IP address in use by the RHEL 6 server to the RHEL 7 server.

I turned off the RHEL 6 server's interface and brought up the RHEL 7 server's interface. I assigned it the IP address but I am unable to connect to it. Traceroute shows no response. I dropped iptables, tried traceroute again and still got no response.

Your technical issue has nothing to do with DNS. Stop making things difficult.

  1. Shut off the RHEL6 interface.
  2. Configure the proper IP and network settings on the RHEL7 server interface, and bring it up.
  3. Thoroughly test the network connectivity on the REHL7 server WITHOUT relying on DNS in any way at all. Ping, traceroute, netcat, nmap. Also test it locally on the RHEL7 system, see if it can ping the IP.

If you cannot ping the IP on RHEL7 from another device on the network, you have a layer 2 or layer 3 network problem, and that needs to be resolved before you can even THINK about working on DNS.

Remember, your layer2/layer3 problems may not be with your server configuration at all. Are network cables plugged in? Is the RHEL7 server on the same broadcast domain as the RHEL6 server (same physical switch, same VLAN, etc.)?

0

Localhost is usually 127.0.0.1, so test using dig again but using the DNS routable IP ( The IP that external clients will use).

Check that DNS is listening (binding) on all the interfaces, restart DNS if needed and check with dig locally again (but using the routable IP) and then from other host on the same network.

The DNS process probably binds to all IPs and DNS Port on start of the process, new IPs are not taken into consideration after process has been started.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.