I'm tryıng to understand how to interpret "additional section" in my dig query.

Here is the additional section for my specific query:

janus.radore.com.   831 IN  A
mimas.rh.com.tr.    458 IN  A
titan.radore.com.   586 IN  A

What do the figures mean? What is 831?

Here is the same section from a dig for google.com:

ns1.google.com.     74569   IN  A
ns2.google.com.     45794   IN  A
ns3.google.com.     74569   IN  A
ns4.google.com.     45794   IN  A

My ultimate goal is to find the performance of the nameservers my domain uses. But still I would like to learn how to interpret "additional section" too.

Thanks, Haluk

  • 1
    if you run the DNS servers in question, you can run queryperf. It's a utility for stress testing bind included with the distribution (it not installed by default, you have to install it yourself from the source).
    – Chris S
    Nov 21, 2010 at 17:46

2 Answers 2


I don't have an official answer (yet), but running dig multiple times in a row shows that number decrementing -- about once a second.

To me that would indicate that's the remaining TTL on the specific entry listed. So,in your example ns4.google.com has 45794 seconds remaining before it is checked again for updates.

Edit: I actually just found this which would corroborate my initial findings:


  • 3
    The official answer is yes, that's the TTL of the cached record in the recursive server it was fetched from. If you query an authoritative server the TTL should not be returned.
    – Chris S
    Nov 21, 2010 at 17:37
  • Now I understand why it was counting down. Thanks a lot!
    – Haluk
    Nov 21, 2010 at 19:54
  • 2
    @Chris the TTL will be included for records the server is authoritative for, it just won't count down. For example, if you query one of google's DNS servers for google's NS records (dig -t ns google.com @ns1.google.com), they will always come back with a TTL of 345600 (4 days in seconds). Nov 21, 2010 at 21:23
  • @Gordon, There's no "Additional Section" when you query and authoritative server. Pretty hard to get the TTL from a section that isn't there.
    – Chris S
    Nov 22, 2010 at 0:34
  • 2
    @Chris Er, no. First, all resource records in the response contain TTLs, no matter which section (authority, answer, or additional) they're in. Second, whether there's an additional section has nothing to do with whether the server's authoritative or not (and just to complicate things, a single DNS response can contain a mix of authoritative and cached data). Try the dig example I gave before, and you'll get a fully authoritative response with an additional section (and both the answer and additional sections will have TTLs). Nov 22, 2010 at 6:45

"Additional section" means: other information that is relevant to your question but not actually the answer to it. For example:

;google.com.            IN  A

We asked for the address (A) of google.com.

google.com.     165 IN  A

This is its IP address.

google.com.     21770   IN  NS  ns4.google.com.
google.com.     21770   IN  NS  ns3.google.com.
google.com.     21770   IN  NS  ns2.google.com.
google.com.     21770   IN  NS  ns1.google.com.

These are the authorities for that question.

ns1.google.com.     19431   IN  A
ns2.google.com.     19542   IN  A
ns3.google.com.     19368   IN  A
ns4.google.com.     19543   IN  A

These are the addresses of the nameservers.

The additional section information is actually present in the DNS answer packet as a way to avoid additional roundtrips.

The numbers you see in each line is the number of seconds for which the record can be cached.

  • 2
    I'd add that the criteria for actually trusting the data in the additional section of a reply packet (thereby reducing round trip) is very selective these days. RFC-2181 §5.4.1 contains the most clearly worded summary I know of.
    – Andrew B
    Jun 3, 2015 at 20:03
  • So if i understand it correctly, the authoritative server (ns1-4.google.com) had the resource record set for google.com(A record for google.com.).So, they have the authority to reply. But in the Query time section, the one that is after the additional section shows the reply coming from a different name server. Can you explain what is going on here Sep 6, 2019 at 21:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .