getdnsapi / getdns

A modern asynchronous DNS API https://getdnsapi.net/
Other
465 stars 126 forks source link

status: FORMERR with CoreDNS server #513

Open OfShad0ws opened 3 years ago

OfShad0ws commented 3 years ago

Hello!

I'm using selfhosted CoreDNS as a DoT server and Stubby as a local resolver on Debian 11, amd64. Almost every reply when checking with dig looks like this:

$ LC_TIME=en_US.UTF-8 dig @127.0.0.1 google.com

; <<>> DiG 9.16.15-Debian <<>> @127.0.0.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 27440
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; QUESTION SECTION:
;google.com.            IN  A

;; Query time: 403 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 11 16:29:00 MSK 2021
;; MSG SIZE  rcvd: 28

There is no difference with +noedns option except that it removes the second warning. getdns and stubby are built from source and started with the following command: $ LD_PRELOAD=./*.so ./stubby/stubby -v 7 -C /etc/stubby/stubby.yml The output is:

[13:31:03.302638] STUBBY: Stubby version: Stubby 0.4.0
[13:31:03.305915] STUBBY: Read config from file /etc/stubby/stubby.yml
[13:31:03.306241] STUBBY: DNSSEC Validation is ON
[13:31:03.306252] STUBBY: Transport list is:
[13:31:03.306256] STUBBY:   - TLS
[13:31:03.306260] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[13:31:03.306264] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[13:31:03.306268] STUBBY: Starting DAEMON....

Extra output when making a request with dig:

[13:32:46.601001] STUBBY: <my-server-ip>                          : Conn opened: TLS - Strict Profile

[13:32:46.781738] STUBBY: <my-server-ip>                          : Verify passed : TLS

There are no logs on server when I get status: FORMERR reply. I decided to first submit an issue here and not to CoreDNS because the server works fine when tested with systemd-resolved as a resolver. Could you please look into the issue? Thanks.