Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to set up a DNS server to change a few domains in my local netwkork - first with bind9, then with dnsmasq. With both software, I resulted in the same problem: When executing nslookup / dig on the dns server itself, I am getting the correctly changed ip matches.

However, when doing a lookup on machines using the DNS server, it returns the wrong (original) host ip, instead of the modified one.

On the dns itself


Address: <correctly modified host ip>

On devices with flushed caches (mac / android):

Server:     <dns server ip>
Address:    <dns server ip>#53

Non-authoritative answer:
Address: <original host ip>

The question is, why is the entry on the server correct, but faulty on the clients?

share|improve this question
What do you mean "correctly modified"? Are you referring to the NAT addresses? – Mathias R. Jessen Jun 6 '13 at 9:13
I am overriding a few domain entries with different IP addresses. With 'correctly modified', I mean it is the new host IP instead of the original one. The main problem is, why is the entry on the server correct but faulty on the clients using the exact same server? – dvcrn Jun 6 '13 at 9:17
TTL? Is that server the only one they get answers from? – NickW Jun 6 '13 at 9:25
server-side caching of entries is disabled during setup, TTL 0. The DNS server is the only one set on the clients. As nslookup / dig confirms, the answer is coming from this server. – dvcrn Jun 6 '13 at 9:46
Check lsof -i:53 -nP and evaluate which programs are listening on which interfaces. It's possible that you have port contention. – Andrew B Jun 6 '13 at 22:49

It takes times to Propagate your modified dns entry to the Internet. New record will automatically replaced when your old record expires as defined in TTL. You have to wait time till TTL expires.

share|improve this answer

The problem was a very stupid and obvious one: My hoster had a UDP block on the machine active.

I assume Mac and Android use a fallback DNS server in case the one set is not reachable? That would explain the wrong (correct) results.

On a linux machine however, a nslookup / dig using the new DNS server resulted in a timeout.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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