Dnsmasq is everywhere—in routers, embedded devices, Linux boxes, and network appliances. It's a lightweight DNS forwarder and DHCP server that makes network life easy. But sometimes, a small configuration detail can have huge implications. That's what happened with CVE-2023-28450.

Let’s break it all down to see why this matters.

What's the Vulnerability?

If you run Dnsmasq (versions before 2.90), you might not know that EDNS. UDP packet size defaults to 4096 bytes. But that’s a problem.

Why is this a problem?  
Because, for most of the Internet, DNS over UDP packets bigger than 1232 bytes are likely to be dropped, fragmented, or mangled along the way. This is why DNS Flag Day 202 recommended everyone sets it to 1232 bytes. But old Dnsmasq didn't get the memo.

> The summary:  
> Bad default value in Dnsmasq makes network responses too big, causing issues or helping attackers.

Here’s what goes on inside Dnsmasq’s source code (before 2.90)

/* File: src/dnsmasq.c, before the fix */

#define EDNS_PACKET_MAX    4096   // Way too big after DNS Flag Day 202!

...

if (edns) {
    // Dnsmasq replies with advertised UDP size
    put_short(buf + n, EDNS_PACKET_MAX);
}

After the fix (in 2.90 and later)

#define EDNS_PACKET_MAX    1232   // Safe default matches MTU best practices!

Why 1232 Bytes?

The quick answer:  
- 1232 is safe for IPv6 networks, considering the smallest possible MTU (128) minus IPv6 and UDP headers.

It’s less likely to be fragmented, so responses actually reach their destination.

> DNS Flag Day 202:  
> Coordinated move where big Internet players agreed to reject big UDP DNS packets, limiting them to practical, real-world-safe sizes.

References

- DNS Flag Day 202 (Official site)
- ISC Knowledge Base

Real-World Impact

- Unreliable DNS: If your resolver returns >1232 bytes, clients or other servers may never see the answer.
- Fragmentation: Attackers can manipulate large DNS packets and fragments—leading to possible cache poisoning, spoofing, or just blocking your queries.
- Connectivity Issues: Devices behind strict NAT, firewalls, or broken middleboxes may totally lose DNS.

How Could This Be Exploited?

While CVE-2023-28450 is not a “hack-the-world” type of hole, it’s a door opener. Here’s a basic rundown:

Inject Malicious Fragments:

In some cases, attackers could inject rogue fragments or cause failures, creating opportunity for DNS cache poisoning or denial of service.

A real exploit might look like this (pseudocode)

# NOT A REAL ATTACK, but shows the idea
import dnslib
from scapy.all import send, IP, UDP, fragment

# Craft a massive DNS response
dnsresp = dnslib.DNSRecord(
    header=dnslib.DNSHeader(qr=1, ra=1),
    q=dnslib.DNSQuestion("attack.example.com"),
    a=dnslib.RR("attack.example.com", rtype=dnslib.QTYPE.TXT, rdata=dnslib.TXT("A" * 200))
).pack()

packet = IP(dst="victim.com")/UDP(sport=53, dport=1337)/dnsresp
frags = fragment(packet, fragsize=512)

for frag in frags:
    send(frag)

Takeaway:
Malformed or excessive fragmentation can help an attacker slip in fake DNS data or just break things for users.

How to Fix It

Upgrade Dnsmasq!

Get at least version 2.90:

Download here

Or, if you can’t upgrade, set the EDNS max size manually in your config

# Add this to your /etc/dnsmasq.conf
edns-packet-max=1232

Then restart dnsmasq

sudo systemctl restart dnsmasq

dig +edns= +bufsize=4096 large-dns-record.example.com

`

 If your answer is >1232, you’re at risk.

- Monitor for Fragmented Packets:  
 On your network, keep watch for excessive UDP fragmentation from port 53.

---

## Final Thoughts

CVE-2023-28450 isn’t a headline-grabbing hack, but it’s a classic case of “good defaults matter.” Any sysadmin or developer running Dnsmasq _must_ pay attention to these details—what’s “default” for you might be an open door for someone else.

References:
- CVE-2023-28450 at NIST
- Dnsmasq Changelog (2.90)
- DNS Flag Day 202
- OpenWall Full Disclosure

Good luck, and keep your networks safe!

Timeline

Published on: 03/15/2023 21:15:00 UTC
Last modified on: 04/17/2023 03:15:00 UTC