EDNS FORMERROR issues from container to resin-dns

[shaunco]

generic-amd64 balenaOS v6.3.18+rev6 with Supervisor v16.20.0

In one customer environment we started having weird server misbehaving errors come back from golang based apps like datadog-agent. The container was originally based on ubuntu:22.04, but while trying to narrow down the issue we switched to balenalib/amd64-debian:bookworm-run-20250401.

After endless poking around, we realized it was only golang based apps that are compiled with cgo, and thus use glibc resolver, and that the hostname must be somewhat long. That is, www.google.com doesn't trigger it, but something like us-east-1.ec2.archive.ubuntu.com does. Since this is only in one customer environment, it appears to be related to an upstream resolver, but we haven't quite made it that far yet.

Here is an example of the EDNS FORMERROR:

dig @10.114.102.1 us-east-1.ec2.archive.ubuntu.com

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @10.114.102.1 us-east-1.ec2.archive.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 19778
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

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

;; QUESTION SECTION:
;us-east-1.ec2.archive.ubuntu.com. IN   A

;; Query time: 0 msec
;; SERVER: 10.114.102.1#53(10.114.102.1) (UDP)
;; WHEN: Tue Apr 15 02:17:04 UTC 2025
;; MSG SIZE  rcvd: 50

and immediately after with +noedns:

dig @10.114.102.1 us-east-1.ec2.archive.ubuntu.com +noedns

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @10.114.102.1 us-east-1.ec2.archive.ubuntu.com +noedns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10955
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;us-east-1.ec2.archive.ubuntu.com. IN   A

;; ANSWER SECTION:
us-east-1.ec2.archive.ubuntu.com. 60 IN A       52.91.65.63
us-east-1.ec2.archive.ubuntu.com. 60 IN A       3.209.10.109
us-east-1.ec2.archive.ubuntu.com. 60 IN A       54.87.19.168
us-east-1.ec2.archive.ubuntu.com. 60 IN A       54.144.148.213
us-east-1.ec2.archive.ubuntu.com. 60 IN A       54.165.17.230
us-east-1.ec2.archive.ubuntu.com. 60 IN A       52.207.133.243
us-east-1.ec2.archive.ubuntu.com. 60 IN A       3.87.126.146
us-east-1.ec2.archive.ubuntu.com. 60 IN A       18.232.150.247
us-east-1.ec2.archive.ubuntu.com. 60 IN A       34.201.250.36
us-east-1.ec2.archive.ubuntu.com. 60 IN A       34.237.137.22

;; Query time: 229 msec
;; SERVER: 10.114.102.1#53(10.114.102.1) (UDP)
;; WHEN: Tue Apr 15 02:17:17 UTC 2025
;; MSG SIZE  rcvd: 210

Given that an upstream DNS server either doesn't support EDNS in this particular environment, or doesn't support fragmented EDNS, my next step will be to test launching the resin-dns instance of dnsmasq on balenaOS --edns-packet-max=1232 to avoid upstream request fragmentation and to try --no-edns so that dnsmasq strips EDNS and sends plain DNS to upstream servers.

[shaunco]

Tracking it down to 1 of the 3 DHCP assigned DNS servers having an old firmware (2020) that didn't support EDNS (regardless of fragmentation). While we were able to fix it in this scenario, I'm leaving this open as it would be great to have a config.json or CONFIG/ENV variable option to disable EDNS on dnsmasq that is handled by balena-net-config to make it easier to deal with these situations.