Why does my DNS lookup work without EDNS but not with?

Question

I'm trying to build a custom DNS server to return programmatic results. Right now, I'm just having it return part of the query it was given, in an SPF format, which works fine when I specify my server's exact IP:

$ dig @54.183.223.221 127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. TXT

; <<>> DiG 9.8.3-P1 <<>> @54.183.223.221 127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62640
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. IN TXT

;; ANSWER SECTION:
foo.com.        600 IN  TXT "v=spf1 include:test.com -all"

;; Query time: 19 msec
;; SERVER: 54.183.223.221#53(54.183.223.221)
;; WHEN: Fri Jan  6 18:05:55 2017
;; MSG SIZE  rcvd: 118

However, running the same command without specifying the IP doesn't find anything. By looking at my DNS server logs, I know it's hitting my server with the same question (and presumably responding the same way), but dig doesn't seem to get a response back:

$ dig 127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. TXT

; <<>> DiG 9.8.3-P1 <<>> 127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8929
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. IN TXT

;; Query time: 254 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Fri Jan  6 18:10:00 2017
;; MSG SIZE  rcvd: 70

It turns out that these two dig queries create two slightly different DNS queries. With the IP, I get:

;; opcode: QUERY, status: NOERROR, id: 53947
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;127.0.0.20._ip.test.com._ehlo.foo.com._spf.moat.email. IN   TXT

Without the IP, I get:

;; opcode: QUERY, status: NOERROR, id: 34502
;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;127.0.0.10._ip.test.com._ehlo.foo.com._spf.moat.email. IN   TXT

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 4096

What is it about this additional EDNS section that could be causing issues? When I simulate EDNS against my local development server by adding +bufsize=4096 +dnssec, it works properly. What's a good place to start looking for why I get no response with EDNS?

Answer 1

The trick was in the answer section:

;; QUESTION SECTION:
;127.0.0.5._ip.test.com._ehlo.foo.com._spf.moat.email. IN TXT

;; ANSWER SECTION:
foo.com.        600 IN  TXT "v=spf1 include:test.com -all"

The answer isn't the full string 127.0.0.5..., but just foo.com. Once I changed the answer section to be the full string, it worked great. Hooray for red herrings!

Answer 2

Without being able to run the query myself but looking at the behavior your describe, I wonder if it's a dnssec validation issue. Your configured recursor is used when not specifying the dns server and it may be a dnssec validating recursor. One way to see if this is true or not is to make the query using +CD with dig (this sets the Checking Disabled flag). This will allow the result to be returned even if it fails dnssec. Unfortunately, SERVFAIL is a bit overloaded and this is one of its meanings.

Answer 3

When you say +trace to dig, you ask it to do its own recursion and print the results. When you don't, it will just ask your system-configured recursing resolver to do the work, and print the result that comes back.

The lines in your example above that you want to pay special attention to are the ones starting with ;; Received and the one starting with SERVER:. You also probably want to read the manual page for dig in order to find out how to specify which server you want it to send its query to.