Internal DNS server not updating for changes in the world

Question

Level 1

15 points

Internal DNS server not updating for changes in the world

Yesterday we changed hosting companies (for our web site). I updated the nameservers with Network Solutions. I went home and while surfing the internet found that www.mycompanyname.com was correctly resolving to the new IP address, of the new hosting company. Cool.

This morning I came into work and I tried to go to our web site, but here in the office our DNS server is still resolving www.mycompanyname.com to the old IP! I SSH'd to another computer outside the office, and DNS resolution is correctly working there. It seems that our osx server is not updating...its dns records.

Isnt it supposed to update on its own? If not, how do I manually make it update? And if Im not asking the right questions, let me know that too.

MacPro, Mac OS X (10.5.4)

Posted on Aug 21, 2009 6:58 AM

Reply

Answer 1

Aug 21, 2009 7:15 AM in response to Arbitrage1

Isnt it supposed to update on its own?

Sometimes the changes take a while to propagate from the authoritative server. Manually flush the cache on the server by doing this in Terminal.app on the DNS server:
/usr/sbin/rndc flush

Reply

Answer 2

Camelot

Level 9

58,503 points

Aug 21, 2009 8:19 AM in response to Arbitrage1

In addition to propogation delays, does the internal office server think it's authoritative for mycompanyname.com ?
This is common where you want internal users to see a slightly different view of your domain from the public (e.g. you may include private/internal server addresses in your own view of the domain that you don't publish to the net).

If your server is authoritative then it isn't ever going to update from an upstream server. It thinks (and, indeed, believes) that it knows all there is to know about that domain, so it isn't going to reach out to get updates.

Reply

Answer 3

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 12:32 PM in response to Arbitrage1

Entering this:

/usr/sbin/rndc flush

Results in:
rndc: connect faild: 127.0.0.1#953: connection refused

Ive also tried dacacheutil -flushcache and that command succeeds, but the web address is still not resolving to the new address.

Further, the dns server doesn't thing its authoritative over our web site domain. The domain for our office is different.

Reply

Answer 4

Aug 25, 2009 2:12 PM in response to Arbitrage1

Try it again like this -you must do this on the DNS Server:
sudo /usr/sbin/rndc flush
Also, dscacheutil -flushcache, only clears the OS DNS cache. The information cached by the DNS server is different.

Further, the dns server doesn't thing its authoritative over our web site domain.

That would be normal if you internal domain is different from the external one for your website. There may be a problem with the DNS for your web-hosting company that is creating the problem. What is the webserver's FQDN?

Reply

Answer 5

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 2:20 PM in response to Mabel O'Farrell

sudo /usr/sbin/rndc flush prompts for my password, and then echos the same error...

rndc: connect failed: 127.0.0.1#953: connection refused

Our web hosting company doesn't seem to be the problem, and neither does our ISP, and heres why I think that. I have a laptop on my desk as well, and so I fired up the wifi and connected to one of the open access points in our building, which belongs to a neighboring company. I was then able to ping our domain name, and see that it was correctly resolving. They use the same ISP as we do...

Reply

Answer 6

Aug 25, 2009 3:04 PM in response to Arbitrage1

In Terminal.app on your workstation do:
dig @12.34.56.78 www.mycompanyname.com
where '12.34.56.78' is the IP address of your internal DNS server. Then do:
dig @12.34.56.78 -x <serverIPaddress>
where '12.34.56.78' is the IP address of your internal DNS server and <serverIPaddress> (without the < and > symbols) is the IP address of your server as returned from the first instance of 'dig'.

If the responses don't come back with the proper IP and FQDN of your webserver, then there is a problem with your internal DNS server -possibly firewall or router issues- or with the configuration of your network settings for your workstations -wrong DNS settings.

Reply

Answer 7

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 4:10 PM in response to Mabel O'Farrell

Thanks for the help. The dns server is our osx server box. I might have been unclear about that.

dig @10.0.1.100 www.idintranet.com

> DiG 9.4.1-P1 <<>> @10.0.1.100 www.idintranet.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11815
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.idintranet.com. IN A

;; ANSWER SECTION:
www.idintranet.com. 10800 IN CNAME idserver.idintranet.com.
idserver.idintranet.com. 10800 IN A 10.0.1.100

;; AUTHORITY SECTION:
idintranet.com. 10800 IN NS ns.idintranet.com.

;; Query time: 1 msec
;; SERVER: 10.0.1.100#53(10.0.1.100)
;; WHEN: Tue Aug 25 19:02:59 2009
;; MSG SIZE rcvd: 92

-------------------

$dig @10.0.1.100 -x 10.0.1.100

; <<>> DiG 9.4.1-P1 <<>> @10.0.1.100 -x 10.0.1.100
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49482
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;100.1.0.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
100.1.0.10.in-addr.arpa. 10800 IN PTR idserver.idintranet.com.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa. 10800 IN NS ns.idintranet.com.

;; Query time: 0 msec
;; SERVER: 10.0.1.100#53(10.0.1.100)
;; WHEN: Tue Aug 25 19:04:33 2009

I think its working fine...

Reply

Answer 8

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 4:16 PM in response to Mabel O'Farrell

Using the dig command some more

dig @10.0.1.100 www.ourwebsite.com -> returns the INCORRECT IP address

dig @10.0.1.100 -x TheCorrectIPAddress -> returns the correct dns info for the new hosting company

Reply

Answer 9

Aug 25, 2009 4:45 PM in response to Arbitrage1

You need to remove this CNAME entry:
www.idintranet.com. 10800 IN CNAME idserver.idintranet.com.
from your internal DNS as that points to your internal server and not the one at your web-hosting provider.

You also need to contact your web-hosting provider as their DNS does not does not reverse properly for your website, www.idintranet.com. The IP address assigned points back to one of their generic hostnames and it does not reverse properly either -which is sometimes common practice, but wrong none-the-less.

This is correct:


dig www.idintranet.com
;; QUESTION SECTION:
;www.idintranet.com. IN A
;; ANSWER SECTION:
www.idintranet.com. 86207 IN A 140.99.28.68
;; AUTHORITY SECTION:
idintranet.com. 86207 IN NS ns2.adwebsystems.com.
idintranet.com. 86207 IN NS ns1.adwebsystems.com.

This is wrong:


dig -x 140.99.28.68
;; QUESTION SECTION:
;68.28.99.140.in-addr.arpa. IN PTR
;; ANSWER SECTION:
68.28.99.140.in-addr.arpa. 86338 IN PTR 68.adweb.com.au.
;; AUTHORITY SECTION:
28.99.140.in-addr.arpa. 86338 IN NS ns2.deru.net.
28.99.140.in-addr.arpa. 86338 IN NS ns1.deru.net.

This is wrong:


dig 68.adweb.com.au
;; QUESTION SECTION:
;68.adweb.com.au. IN A
;; AUTHORITY SECTION:
adweb.com.au. 3600 IN SOA ns1.adweb.com.au. root.adweb.com.au. 2009072301 10800 900 1814400 36000

Reply

Answer 10

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 4:55 PM in response to Mabel O'Farrell

www.idintranet.com is a domain name I made up for our intranet. Its only for internal use. Its resolving correctly for our internal use.

I guess I need to use real examples.

dig www.InstinctD.com

; <<>> DiG 9.4.1-P1 <<>> www.instinctd.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.instinctd.com. IN A

;; ANSWER SECTION:
www.instinctd.com. 1252 IN A 65.254.250.108

;; AUTHORITY SECTION:
instinctd.com. 43875 IN NS ns1.powweb.com.
instinctd.com. 43875 IN NS ns2.powweb.com.

If you try that from your side, you'll see the A record IP is 174... and thats what it should be. Mines wrong.

Reply

Answer 11

Arbitrage1 Author

Level 1

15 points

Aug 25, 2009 5:09 PM in response to Arbitrage1

Well, everyone went home so I restarted the server and it fixed the problem. Apparently that's how you clear the cache..

Thanks for the help.

Reply