0

I have a DNS server, where I put A record with TTL set to 0:

example.host.com <some.ip.addr.one>

Then I do

dig example.host.com

And get specified ip address. Later I change update record

example.host.com <some.ip.addr.two>

and perform dig again

However, resolved ip is still <some.ip.addr.one>

While referring to DNS server management UI I see that record has changed, however it is still resolved to old one.

What can cache DNS? I have a dnsmasq service, however it has cache-size set to 0.

Is there any way to detect how DNS record resolved and what causes this behavior? Any ideas? Thanks in advance.

Improve this question
1
  • 4
    Provide true hostnames, it is pointless to obfuscate if you would like to have valuable help. Also when using dig always specify which nameserver you are querying when doing troubleshooting otherwise you may see results not coming from where you think they should. And BTW, 0 for TTL is almost never a good idea, and many caching server will just override that with some small value instead. Commented May 14, 2017 at 11:56

1 Answer 1

Reset to default
3

DNS is cached by design. When you update a record, you need to set a new serial number, and then servers with the old one will notice once the old TTL expires.

Your question demonstrates no familiarity with these concepts, which however are quite fundamental. Perhaps you need to familiarize yourself with the DNS world some more before you dive in.

dig produces quite a lot of output about where it fetched its result and what exactly it means, but again, you will probably need to read up on it before you try in practice.

Improve this answer
3
  • Thanks, @tripleee. Can you give an advice how can I upgrade my knowledge and provide some sources to read. > DNS is cached by design. While adding record, TTL is set to 0, which supposed to have no caching. DNS server is not a problem. Problem is a client, which caches itselves DNS requests, as referring to DNS server from another client gives right answer. Commented May 14, 2017 at 7:40
  • Overriding the upstream TTL is standard practice; there are insane TTL values you simply should not obey, and so overrides are part of the reality. Maybe updating your question with some actual diagnostics would help us see what you are really trying to solve here. What software are these clients running and what do the incorrect and the correct results look like? Commented May 14, 2017 at 9:45
  • 1
    If you actually understand these things, maybe edit your question to rule out the common misunderstandings. Commented May 14, 2017 at 9:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.