#DNS trivia, especially for those have ever used the "It was DNS" meme. What is wrong with this (real) dig response and what is the likely cause? AI probably won't help you.
John Kristoffdig @1.1.1.1 foobar.gov +norecurse +nocmd +noquestion +noauthority +nostats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1808
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
Yesterday's #DNS trivia question asked you to identify what was wrong with a dig response. The query was aimed at Cloudflare's resolver 1.1.1.1 asking about foobar.gov. No class or type was specified, by default they are IN and A respectively. This name is non-existant in the gov zone, which you might have guessed, but should be able to verify.
I set a number of options to the query, mostly to limit the display output. The +norecurse option however instructs dig not to set the recursion desired flag (rd=0), which tells the resolver being asked not to go chase down an answer if it is not in the cache.
The output shows only some of the returned header fields and a summary of the EDNS(0) options stuffed into an additional RR. 1/x
Other than the bogus name, there are two things wrong with this response. First, the rd flag was set in the response. The rd flag should echo what the client set, which it clearly does not. Second, is the NOERROR status (aka RCODE) with a single authority section RR, which is unexpected in this scenario.
The NOERROR might be legitimate in certain scenarios.
A local, ISP, or corporate resolver probably doesn't have anything for foobar.gov cached and are likely to provide a referral, which would be an NS RRset in the authority section for .gov (or root if it doesn't know anything about .gov). The number of authority RRs we'd expect are either 4 or 13 respectively, so getting just one is very suspicious.
Public resolvers (e.g., Cloudflare, Google, Quad9) generally refuse (RCODE = REFUSED or SERVFAIL depending on operator) to serve answers when you set rd=0. 2/x
If you replicated the query yourself against a known "good" set of resolvers, you'd be able to see differences in what you got and what I showed, and that should have showed where my result was "wrong".
The next step was to reason about the results I got. If you weren't sure, but if I told you the IPv4 TTL value I received in the DNS response was 64 would have that helped? I didn't tell you that, but that was the case.
There was a middle box at my first hop that intercepted my query and returned a response. That middle box knew there was no answer, but it did not answer as the real 1.1.1.1 would.
@paul_ipv6 @ondrej @goetz @fanf @ahasty all got some or all of the answer, @edmonds gets the overachiever award for the detailed analysis. AWS/Azure, these people may be interested in your money-is-no-object DNS consulting offers. :-) 3/x
theHastyOne