2

We have a primary, secondary and tertiary servers, all located in different regions. All three machines run Windows Server 2008 R2. The secondary and tertiary servers provide backup for the primary server.

Every week, we do a test fail-over from the primary to the secondary, and the primary to the tertiary. This test has no issues when testing the secondary, but has a networking problem on the tertiary.

I log into the primary server to access the site on our tertiary server. The site's DNS is resolved using easyDNS which we update to point to the tertiary server, then wait the allotted time for the records to update.

This process works fine, but my question is that why does it behave differently if I change the hosts file of the primary server to point to the tertiary, versus if I do it in easyDNS.

In other words:

Scenario A:
  Using Primary server
  Edit hosts file -> points to Tertiary Server
  Access site from primary server, while being hosted tertiary server, no issues.

Scenario B:
  Using Primary server
  Log into easyDNS, update the dns A record
  Access site from primary server, while being hosted tertiary server, site has networking / other accessibility issues.

What is the difference in the DNS look ups between scenarios A and B?

illmortem
  • 29
  • 1
  • 4
  • DNS look ups can take some time to propagate out, test using `nslookup` or similar querying specific servers - ie `nslookup example.com 8.8.8.8` to use googles' public dns – ivanivan Jul 13 '17 at 22:00
  • Our TTL on the easyDNS service is 5 minutes. Hosts should update immediately, provided there aren't any browsers open, correct? We also wait 15 minutes and flush the DNS resolver cache before testing. – illmortem Jul 13 '17 at 22:02
  • easydns may take a bit before refreshing its own internal data, the various dns caches, etc. there is really no way to be 100% sure, which is why you should start by querying at the authority server and working your way out to "the world". but yes, in theory it should update really quickly for you... – ivanivan Jul 13 '17 at 22:05
  • Thank you, I will try this new testing methodology. If the refresh TTL is the underlying factor, would using the hosts method of my question be the more reliable test of if the server is working correctly? – illmortem Jul 13 '17 at 22:26
  • If you are just testing A/AAA records then yes. If you are testing MX records or cname entries then no, you'll need "real" dns to be working – ivanivan Jul 13 '17 at 22:59
  • I've tested the server's IP via the nslookup application, and got some unusual results. Sometimes the primary server's IP was returned, and other times the IP of our tertiary server was returned. I will open a ticket with easyDNS. **nslookup nnnnn.com 8.8.8.8** Server: google-public-dns-a.google.com Address: 8.8.8.8 **Non-authoritative answer:** Name: nnnnn.com Address: 1xx.1xx.1xx.1x **nslookup nnnnn.com 8.8.8.8** Server: google-public-dns-a.google.com Address: 8.8.8.8 **Non-authoritative answer:** Name: nnnnn.com Address: 7x.6x.2xx.2x – illmortem Jul 13 '17 at 23:18
  • Use `dig` instead of `nslookup` for DNS troubleshooting, and provide the true IP/domain names, do not obfuscate them if you want some help. – Patrick Mevzek Jul 27 '17 at 12:10
  • Thank you. I will test with dig. The obfuscation of the ip and domain names was at the request of the site's owner, sorry for any confusion that caused. – illmortem Jul 27 '17 at 21:27

0 Answers0