3

For normal DNS lookups, one can use Dig to get an answer including the remaining TTL for a DNS record. If that answer is from a cache, the TTL will "count down" until the next authoritative query, and the remaining time until that query will appear (as noted in this question: Check remaining TTL for nameserver).

How can I get the corresponding "remaining time" for a negative-cached record? The answer is by definition a "NXDOMAIN" or non-existent domain; there appears to be no TTL associated with this answer aside from the SOA record (max possible time value).

I also have access to the [BIND 9] server directly, so ways to get this information out of the cache directly are also welcome, even though I am hoping there is a query-based way to do this.

Community
  • 1
Watki02
  • 537
  • 2
  • 12
  • 21

2 Answers2

4

There is no query based way to get server state. Glue, negative cache timers, etc. must be dumped from memory using the rndc dumpdb command.

  • Record types beginning with \- are negatively cached. \-A, \-AAAA, etc.
  • \-ANY indicates a true NXDOMAIN. No records live alongside or beneath this entity.

The above might be confusing if you have not been exposed to the concept of NODATA before. (RFC 2308) It means an answer of NOERROR with 0 answers was seen, as opposed to NXDOMAIN. NXDOMAIN indicates that no records with that name exist at all.

Example negative cached entries:

test1.example.com. 442 \-ANY ;-$NXDOMAIN
test2.example.com. 352 \-AAAA ;-$NXRRSET

Parsing this file automatically is not for the faint of heart, especially when the label name is omitted due to repetition.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
1

Firstly the TTL for a NXDOMAIN should be conveyed via an SOA record in the AUTHORITY SECTION of the reply. See my answer to How long does negative DNS caching typically last? for details.

Regarding the question about seeing a decrementing TTL on subsequent queries. I believe this is an DNS server implementation detail.

In my testing I have observed that some recursive nameservers do not return an AUTHORITY SECTION with a SOA record with a decrementing TTL for subsequent requests whereas others do.

For example the cloudflare resolver does (note the decrementing TTL value):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

While the default resolver in an AWS VPC will respond with an authority section only on the first request:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Note that an authoritative server should always return the full TTL which should be the lesser of the SOA.MINIMUM field and the TTL of the SOA record itself. You will only see a decrementing TTL in answers from a recursive (caching) nameserver.

Also note that when querying recursive servers you will often be hitting a load balancer and consequently you will get divergent answers depending on which load balanced server you happen to be hitting.

htaccess
  • 406
  • 5
  • 5