#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
@jtk i'm stuck on +norecurse … but IIRC `rd` == "recursion desired"?
so there's some weird thing in-between?
@jtk You shouldn't get rd or ad with norecurse set. Which I believe should strip the entire authority response from this as well.
And I might not even be right cause I am a bit lacking in this area. But you know...more people should know how DNS works... and certs.. That's my soapbox.. too many people in IT don't know how DNS or certs work.
so thank you for bringing a challenging question that has already raised my level of knowledge!
@jtk hmm, rd=0 in the query ought to be echoed in the response, which is hinky
the lack of cookie and dnssec records suggest that you’re talking to a middlebox not to 1.1.1.1
Hiding dig's version number (+nocmd) while asking what's wrong. At least you didn't use +short.
Querying a recursive DNS service with +norec.
1.1.1.1 is a restrictive recursive DNS service that doesn't allow cache snooping so you should probably not be seeing a NOERROR response. Probably you should see SERVFAIL.
1.1.1.1 supports Extended DNS Errors, which can be sent to any EDNS query. Even old versions of dig will dump the raw bytes of an unknown EDNS option code. But your response doesn't have any EDE options.
The fact that you didn't get a SERVFAIL response with an EDE option stating that a cache snooping query was being rejected ("no local cache to fulfill non recursion (RD=0) request" being the specific EDE text string that the 1.1.1.1 implementation generates) is suspicious and I agree with the other commenters suggesting that this is not the real 1.1.1.1.
@jtk If you added +nsid to the dig and didn't see a Cloudflare-style NSID response (of the form "<X>m<Y>" where X and Y are numbers, e.g. "509m215") I think that would be overwhelming proof that you're not talking to the real Cloudflare 1.1.1.1 service.
On a new enough dig you could also add +https to see either the real response, or how badly the local network admin wants to break off-site DNS resolution.
theHastyOne
niallor
hrbrmstr 🇺🇦 🇬🇱 🇨🇦
Justin
Serge Droz
Tony Finch
Petr MenÅ¡Ãk 
Robert Edmonds