Samsung Phone - insufficient data for calculated length type
4 years ago I had issues and then with one of the nextDNS upgrades they seemed to be fixed. Now I only see this every time my Samsung S25+ (android) connects to my home EdgeRouter 4. Has been going on for a while. Will repeat 1 to 4 times and stop till I switch back to T-Mobile and then back to home WiFi.
Anyone else seeing this google.com causing this error?
nextdns version 1.47.3
S25+ on Android 16 UI 8.5 kernal version Tues May 12 2026
Phone is using private DNS and set to nextDNS FQDN [using a different ID than the home network, however the same thing happens if I have private DNS OFF on the phone and return to home WiFi]
................. The logging on the ER-4
Jun 10 13:14:12 ER-4 nextdns[6226]: parse additional: Name: insufficient data for calculated length type
Jun 10 13:14:12 ER-4 nextdns[6226]: Query 192.168.13.178:35820 UDP/53 192.168.13.178 A google.com. none (qry=51/res=28) 0ms : parse additional: Name: insufficient data for calculated length type
Jun 10 13:14:15 ER-4 nextdns[6226]: parse question: parsing/packing of this section has completed
Jun 10 13:14:15 ER-4 nextdns[6226]: Query 192.168.13.178:35656 UDP/53 192.168.13.178 0 none (qry=36/res=12) 0ms : parse question: parsing/packing of this section has completed
Jun 10 13:14:15 ER-4 nextdns[6226]: parse question: parsing/packing of this section has completed
Jun 10 13:14:15 ER-4 nextdns[6226]: Query 192.168.13.178:58228 UDP/53 192.168.13.178 0 none (qry=36/res=12) 0ms : parse question: parsing/packing of this section has completed
Jun 10 13:14:25 ER-4 nextdns[6226]: parse question: parsing/packing of this section has completed
Jun 10 13:14:25 ER-4 nextdns[6226]: Query 192.168.13.178:40728 UDP/53 192.168.13.178 0 none (qry=36/res=12) 0ms : parse question: parsing/packing of this section has completed
Jun 10 13:14:25 ER-4 nextdns[6226]: parse question: parsing/packing of this section has completed
Jun 10 13:14:25 ER-4 nextdns[6226]: Query 192.168.13.178:38300 UDP/53 192.168.13.178 0 none (qry=36/res=12) 0ms : parse question: parsing/packing of this section has completed
1 reply
-
Looks like Gemini has a clue to what's going on.
1. The "Malformed" Packet (Android's Fault)
Whenever an Android device connects to a Wi-Fi network (or periodically wakes up), it runs a background check to see if the Wi-Fi has internet access or is trapped behind a captive portal. It does this by blasting out rapid DNS queries for
google.com.To save space and optimize speed, modern Android versions construct highly customized, compressed DNS packets. In doing so, Samsung/Android includes an EDNS0 (Extension Mechanisms for DNS) cookie or metadata block in the "Additional" section of the packet. However, Android packs this additional section with non-standard byte lengths or structural traits that don't strictly adhere to old-school DNS formatting rules.
2. The Parsing Panic (NextDNS's Fault)
The NextDNS CLI utility running on your ER-4 is very strict. When it intercepts the phone's request, its internal packet parser tries to unpack the entire payload to read it.
parse question: parsing/packing of this section has completed— NextDNS successfully read the initial request (e.g., "Where isgoogle.com?").parse additional: Name: insufficient data for calculated length type— NextDNS reached the bottom of the packet (the EDNS0 extensions) and got confused. It read a length header specified by Android, looked at the remaining data, and said: "Wait, the data length doesn't match what the packet header promised. This is garbage data."
Because NextDNS can't parse that extra block, it throws a warning log and often encounters a
HTTP/2.0: doh resolve: error code: 400(Bad Request) upstream, failing to pack/send it cleanly over DNS-over-HTTPS.===================
QUESTION - Can nextDNS team fix this parsing error??
Content aside
- 2 days agoLast active
- 1Replies
- 16Views
-
1
Following