I applied the suggested fix:
C:\Users\administrator>dnscmd /config /enableednsprobes 0
Registry property enableednsprobes successfully reset.
Command completed successfully.
C:\Users\administrator>net stop dns && net start dns
The DNS Server service is stopping.
The DNS Server service was stopped successfully.
The DNS Server service is starting.
The DNS Server service was started successfully.
C:\Users\administrator>
No change...
I notice my udp is 4096 on the failed queries now:
root@pihole-a:~# dig -t txt versions.pi-hole.net
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> -t txt versions.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 57771
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: afb772d6ce2ad19d (echoed)
;; QUESTION SECTION:
;versions.pi-hole.net. IN TXT
;; Query time: 0 msec
;; SERVER: 192.168.33.205#53(192.168.33.205)
;; WHEN: Sat Jul 18 16:02:20 EDT 2020
;; MSG SIZE rcvd: 61
root@pihole-a:~#
No drops in the FW logs... 
FYI, Ubuntu with +edns and +cookie (though I don't see a cookie).... note the UDP size and it succeeds:
root@pphost236:~# dig -t txt +edns +cookie versions.pi-hole.net
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> -t txt +edns +cookie versions.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8348
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;versions.pi-hole.net. IN TXT
;; ANSWER SECTION:
versions.pi-hole.net. 0 IN TXT "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Jul 18 20:35:26 UTC 2020
;; MSG SIZE rcvd: 127
root@pphost236:~#
DIG requested kevinlocke.name and received FORMERR. After some trial and error, I determined that the issue results from DIG 9.11 sending the DNS COOKIE option. This option was enabled by default in BIND 9.11. Unfortunately, adding this option causes DNS Server to treat the request as malformed. This behavior appears to violate “Any OPTION-CODE values not understood by a responder or requestor MUST be ignored.” from Section 6.1.2 of RFC 6891, but that is of small consolation for a non-working system.
As a workaround, pass the +nocookie option (or +noedns to disable all EDNS options) as in dig +nocookie kevinlocke.name.
After testing, it's only the cookie that is causing the requests to fail
root@pihole-a:~# dig -t txt +nocookie versions.pi-hole.net
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> -t txt +nocookie versions.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25524
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;versions.pi-hole.net. IN TXT
;; ANSWER SECTION:
versions.pi-hole.net. 59 IN TXT "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"
;; Query time: 55 msec
;; SERVER: 192.168.33.205#53(192.168.33.205)
;; WHEN: Sat Jul 18 16:59:44 EDT 2020
;; MSG SIZE rcvd: 127
root@pihole-a:~#
My workaround was to download the script and add the +nocookie option to the dig command contained therein.
Would it make sense to add the +nocookie option to the installer by default?
I don't think so, it's not a problem with Pi-hole or the installer.
I do understand that implementing a workaround is time and effort for a flawed DNS implementation that, while in very large circulation, is not likely to appear all that often upstream of pihole setups. If that is the case then I would ask that it be noted in the prerequisites or faq and maybe some sort of info when the script ends abruptly.
I do have a question regarding whether updates will be affected by this logic as well, as pihole -up isn't a script I can modify easily.
I think it would be better to fix the local DNS server so it responds to all DNS queries properly.
Suggested error checking:
Replace line 190:
IFS=" " read -r -a supportedOS < <(dig +short -t txt ${remote_os_domain} | tr -d '"')
with the following:
dig_result=$(dig +short -t txt ${remote_os_domain} | tr -d '"')
if [ "${#dig_result}" == 0 ]; then
printf "Upstream DNS Error: Possible upstream Microsoft DNS or firewall blocking error\\n"
printf " Check the result of: dig -t txt %s\\n\\n" "${remote_os_domain}"
exit 1
fi
IFS=" " read -r -a supportedOS <<< "${dig_result}"
It checks that the result of the dig +short isn't 0 characters in length and errors out if it is.
We can improve the installer output but I think you're going to have problems in the future with that client if it can't do a plain dig successfully.
Oh, definitely understood. I'm working to replace the MS DNS infrastructure. Especially since 2008R2 is no longer supported. Unfortunately I don't currently have anything newer to test it through.
I don't like abrupt failures that drop you back at the prompt without warning or explanation so I understand the idea concern. There are a few other places that silent failures happen.
This particular set of circumstances are so unique and edge case that you may be the only one ever seeing it, Raspbian 10 uses the same dig package and version so it's not specific to dig v 9.11.
Do you have a GitHub account? Can you go to GitHub - pi-hole/pi-hole: A black hole for Internet advertisements and open an Issue for a bug and reference this thread? I'll assign myself to it to track it.
Can do. While I've hacked scripts in the past, I haven't done much with git other than open issues. One of these days I should learn how to contribute other than code snippets in comments. 
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.