Score:0

Different DNS answer from 2 local servers configured the same way

cn flag

I have 2 servers setup to forward request for prod.example.com and example.com to GCP. When doing DNS resolution from the same client but using the 2 servers, both of them give me the same answer but one has more things in the answer than the other one: command used: dig test.prod.example.com @server1 or @server2 server 1 answer:

 <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.prod.example.com @server1
global options: +cmd
Got answer:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50915
flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

OPT PSEUDOSECTION:
EDNS: version: 0, flags:; udp: 4096
QUESTION SECTION:
test.prod.example.com. IN      A

ANSWER SECTION:
test.prod.example.com. 300 IN   A       10.100.40.112

AUTHORITY SECTION:
example.com.          4730    IN      NS      ns-gcp-private.googledomains.COM.

ADDITIONAL SECTION:
NS-GCP-PRIVATE.googledomains.com. 141044 IN A   169.254.169.254


Server2 answer:

<<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.prod.example.com @server2
global options: +cmd
Got answer:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3502
flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13

OPT PSEUDOSECTION:
EDNS: version: 0, flags:; udp: 4096
QUESTION SECTION:
test.prod.example.com. IN      A

ANSWER SECTION:
test.prod.example.com. 209 IN   A       10.100.40.112

AUTHORITY SECTION:
com.                    140949  IN      NS      g.gtld-servers.net.
com.                    140949  IN      NS      c.gtld-servers.net.
com.                    140949  IN      NS      e.gtld-servers.net.
com.                    140949  IN      NS      j.gtld-servers.net.
com.                    140949  IN      NS      f.gtld-servers.net.
com.                    140949  IN      NS      i.gtld-servers.net.
com.                    140949  IN      NS      k.gtld-servers.net.
com.                    140949  IN      NS      h.gtld-servers.net.
com.                    140949  IN      NS      l.gtld-servers.net.
com.                    140949  IN      NS      a.gtld-servers.net.
com.                    140949  IN      NS      m.gtld-servers.net.
com.                    140949  IN      NS      b.gtld-servers.net.
com.                    140949  IN      NS      d.gtld-servers.net.


Any ideas why? Does it matter since it can resolve to the correct IP?

Patrick Mevzek avatar
cn flag
And those 2 nameservers are which software and which version? How does their configurations differ? If it is bind, the difference can probably be explained by the configuration parameter `minimal-responses` not being the same in both cases.
cn flag
2 bind servers running the same version (i just double checked), controlled by chef. Config is the same except server1 is the primary and server2 is a slave from server1. I'll check the minimal-responses setting.
Patrick Mevzek avatar
cn flag
Your configuration makes no sense. You are speaking about primary/slave (you should say secondary) which means an authoritative nameserver. Yet your replies are not the same, because different TTL which seems to mean you have recursive nameservers. So this makes no sense, you shouldn't mix authoritative and recursive.
cn flag
From what I've noticed, the TTL when served by BIND decreases over time, if I do the same request over and over I will see the TTL start at 300s and go down. That is on both servers. As for config, the authoritative servers are in GCP. When i query GCP, I get the same answer as server1minus the authority section. For this zone in particular, prod.example.com, both server1 and server2 have it setup as a forward zone in their bind config.
Patrick Mevzek avatar
cn flag
"From what I've noticed, the TTL when served by BIND decreases over time," NO. This has nothing to do with bind. ANY nameserver is either recursive or authoritative. If authoritative, the same query gives the same reply, always. So same TTL, it does not "decrease". If recursive, almost always it has a cache, and hence the same query will get different reply because each one will have a different TTLs... I think this shows you need to first clearly understand the difference between authoritative and recursive service.
cn flag
Fine, but in this situation, server1 and server2 are not authoritative and get different answers when they are configured the same for prod.example.com, why? that is my original question.
Patrick Mevzek avatar
cn flag
You still don't say which software (version) it is, nor how it is configured precisely. If they are not authoritative, it means they are recursive or stub resolvers asking a recursive resolver, in which case answers will always differ. But then your explanations above "Config is the same except server1 is the primary and server2 is a slave from server1. " contradicts the above (primary/secondary only applies to authoritative, not recursive). If you insist on not giving all the details, your question can't be answered.
Score:1
in flag

The answer is (as mentioned) identical, see the actual answer section of the replies, the other parts are of little to no interest but is related to how the server got the information, and what information it has that might be interesting in next/future requests.

ANSWER SECTION:
test.prod.example.com. 209 IN   A       10.100.40.112
Patrick Mevzek avatar
cn flag
The answers are NOT the same. One has TTL 300 the other TTL 209.
in flag
@PatrickMevzek answers are the same, TTL is a value counting down from any caching server.
cn flag
Correct, the TTL just decreased when using Bind.
cn flag
it's just weird that server2 goes to the root servers to get the record when the record is not even publicly available.
Patrick Mevzek avatar
cn flag
Answers ARE NOT the same. The TTL is part of the record. Different TTL means different records. IF you query authoritative nameservers the values should be the same on all.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.