Is my DNS resolver broken? Returning A record only on ANY query

Question

The Main Problem

I'm trying to resolve the domain picard.tn.tinloaf.de using my home router's DNS resolver. It should resolve to an A record pointing to 10.17.1.10 (a host in my VPN network). The router sits at 192.168.0.1 and is a cheap-ish thing supplied by my ISP. It would not suprise me to find that its resolver is just broken.

If I use dig to query for ANY, this is what I get:

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52368
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: db6540198fc3d64c316539ba5db350d5ea576f0f0c9323e9 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   180 IN  A   10.17.1.10

;; Query time: 131 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:47:34 CEST 2019
;; MSG SIZE  rcvd: 93

Nice. Not sure about the TTL in that response (see below for additional shenanigans), but the A record is there. Let's query with -t A:

tinloaf@janeway ~ $ dig -t A picard.tn.tinloaf.de @192.168.0.1

; <<>> DiG 9.14.4 <<>> -t A picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25118
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e3d7c44265c696ae29b2bd405db35122345a154db36bffcc (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  A

;; Query time: 143 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:48:50 CEST 2019
;; MSG SIZE  rcvd: 77

How can that be? Can it be any kind of misconfiguration on my side (I'm managing my DNS zone myself) that makes an A record appear when I query for ANY, but disappear when I query for A? The DNS lookup tool at mxtoolbox.com does not show any errors for that domain.

The TTLs seem bogus, too

If I run multiple -t ANY queries in rapid succession, this is what happens:

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22050
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ea0a9ccb1c56115a19c257145db352208dbc41f9e58cf134 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   507 IN  A   10.17.1.10

;; Query time: 277 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:05 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56509
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c642b601eed33f15938e59585db3522167f6c0ab9733d818 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   494 IN  A   10.17.1.10

;; Query time: 159 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:06 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14446
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bb9a410f8db063f22d3bb66d5db35223580d725b203cbdfa (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   504 IN  A   10.17.1.10

;; Query time: 303 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:07 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39213
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: eceda0ed18efd5d15e90b7de5db3522584f3b33cf5bbabf8 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   496 IN  A   10.17.1.10

;; Query time: 277 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:09 CEST 2019
;; MSG SIZE  rcvd: 93

Note that there are only a couple of seconds between those queries, however the TTL field seems to be jumping around erratically. Is that normal? I could imagine that the cheap router box does not really run a caching (stub) resolver, but just forwards the requests to resolvers at my ISP, and there's a round robin load balancer there, so I get replies from different servers every time. Is that a realistic scenario?

Answer 1

To prevent some specific attacks (see https://en.wikipedia.org/wiki/DNS_rebinding), some recursive nameservers are filtering records using IP addresses in private space.

But besides that known major public recursive DNS services resolve it just fine:

$ dig picard.tn.tinloaf.de +short @8.8.8.8
10.17.1.10
$ dig picard.tn.tinloaf.de +short @1.1.1.1
10.17.1.10
$ dig picard.tn.tinloaf.de +short @9.9.9.9
10.17.1.10

If you use online checking tool, they show the name as resolving:

• https://dnsviz.net/d/picard.tn.tinloaf.de/dnssec/ (unfortunately no history for now, so this link will rerun the check at the moment you hit it)
• (Zonemaster unfortunately seems completely confused by this domain for whatever reason)

You can check the whole resolution yourself by doing something like dig picard.tn.tinloaf.de +trace @1.1.1.1

In short with it, we find the last authoritative nameservers to be lukas-barth.net. and ns1.n621.de. and they both reply properly for your record.

So the summary of all of this is that the global configuration of the domain seems fine as well as the resolution of this record, and hence problems you may see are probably more related to specific things in your local configuration.

Do not use query type ANY. This never meant "ALL" contrary to what people believe and there is a standard now (see https://www.rfc-editor.org/rfc/rfc8482) on how to deal with it and potentially nameservers will not reply to it anymore. In short, it is not a good troubleshooting tool. If you need to check for the A record, query that type, nothing else.

As for changes in replies, it can be both due to the fact that you are using ANY that has specific semantics, and as you described yourself, indeed, your resolver can forward queries to other resolvers, that can be behind load balancers or anycasting setups, so that you hit different servers.

But again, the real check is by checking the A record, nothing else.