Command line dig tool doesn't get answer for SOA query, while https://toolbox.googleapps.com/apps/dig/#SOA/ DOES

Question

While running in my windows 10 64bits machine this command: dig gmail-smtp-in.l.google.com ANY

I get this response

; <<>> DiG 9.16.2 <<>> gmail-smtp-in.l.google.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 31969
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 54719e117b6518e0 (echoed)
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      ANY

;; Query time: 163 msec
;; SERVER: 10.8.1.10#53(10.8.1.10)
;; WHEN: Thu May 14 11:10:17 Argentina Standard Time 2020
;; MSG SIZE  rcvd: 67

But if I use google dig toolbox at https://toolbox.googleapps.com/apps/dig/#SOA/ I actually get this:

id 8747
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
gmail-smtp-in.l.google.com. IN SOA
;ANSWER
;AUTHORITY
l.google.com. 59 IN SOA ns1.google.com. dns-admin.google.com. 311303408 900 900 1800 60
;ADDITIONAL

Why the different behavior?

Answer 1

It's hard to know exactly why your resolver 10.8.1.10 responds with the error code FORMERR (although I can speculate somewhat, at the end of the answer).

The query itself is a bit odd as well, there is no expectation that there should be a SOA record at gmail-smtp-in.l.google.com and the successful response you get via the G Suite Toolbox as well as my example below confirm that there is indeed no such record (as you see, in both cases there is a NODATA response).
That said, if you want to run a more directly equivalent dig command that does not rely so much on your local environment being in working order, this would be an example of that (and I expect it will work for you too):

$ dig @8.8.8.8 gmail-smtp-in.l.google.com SOA

; <<>> DiG 9.11.18-RedHat-9.11.18-1.fc32 <<>> @8.8.8.8 gmail-smtp-in.l.google.com SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38855
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      SOA

;; AUTHORITY SECTION:
l.google.com.           59      IN      SOA     ns1.google.com. dns-admin.google.com. 311303408 900 900 1800 60

;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu May 14 16:55:22 UTC 2020
;; MSG SIZE  rcvd: 105

$

As for how to troubleshoot the problem with 10.8.1.10, I would suggest trying these in order to see if it's related to mishandling of edns cookies, mishandling of edns in general or some problem I did not guess.

• dig gmail-smtp-in.l.google.com SOA +nocookie
• dig gmail-smtp-in.l.google.com SOA +noedns

If you are the operator of 10.8.1.10 you then have some input on what problem is, where the solution likely involves upgrading the resolver server software to a fixed version. If you are not the operator, I suppose you can pass on the information about the problem to the operator.