Imagine your DNS server had this behaviour when queried using dig:
$ dig drjohnstechtalk.com @184.108.40.206
; <<>> DiG 9.9.2-P2 <<>> drjohnstechtalk.com @10.201.145.30 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 48905 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;drjohnstechtalk.com. IN A ;; Query time: 1 msec ;; SERVER: 10.201.145.30#53(220.127.116.11) ;; WHEN: Fri Feb 24 12:16:42 2017 ;; MSG SIZE rcvd: 48
That would be pretty disturbing, right? The only way to get dig to behave is to turn off edns like this:
$ dig +noedns drjohnstechtalk.com @18.104.22.168
; <<>> DiG 9.9.2-P2 <<>> +noedns drjohnstechtalk.com @10.201.145.30 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31299 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;drjohnstechtalk.com. IN A ;; ANSWER SECTION: drjohnstechtalk.com. 3277 IN A 22.214.171.124 ;; Query time: 3 msec ;; SERVER: 10.201.145.30#53(126.96.36.199) ;; WHEN: Fri Feb 24 12:17:00 2017 ;; MSG SIZE rcvd: 53
Nslookup works. But who uses nslookup anyway?
Furthermore, imagine that DNS client and server are on the same subnet, so there is no firewall intermediating their traffic. so we know we can’t blame firewall cutting off large DNS packets, unlike the suggestions made in the references section.
Well, this is exactly the situation in a large company where I consult. The DNS server is unusual: a Bluecoat ProxySG, which can conveniently combine replies from nameservers from two different namespaces.
There does not seem to be an option to handle edns queries correctly on a Bluecoat device.
The client is running SLES version 11. The real question is how will applications behave? Which type of query will they make?
Bluecoat does not support eDNS and gives a response permitted by RFC2671. RFC2671 also encourages clients to account for error responses and drop the use of eDNS in a retry.
References and related
EDNS: What is it all about? is a really good explanation of edns and how it came about, how it’s supposed to work, etc.
This post suggests some scenarios where edns may not work, though it does not address the Bluecoat issue: http://blog.fpweb.net/strange-dns-issues-better-check-out-edns/#.WLBmw3dvDkk