Post #1864894
2026-04-29 21:42 UTC
Replies (3)
-
@cshishido@infosec.exchange 2026-04-29 22:13
@nicksilkey@hachyderm.io There's a make everything fit in one response packet recommendation to avoid fragmentation. This doc says 1400 for max payload size. There's no quick rule-of-thumb these days since IPv6 and DNSSEC are variable, see section 5 for recommendations. https://www.ietf.org/archive/id/draft-ietf-dnsop-avoid-fragmentation-07.html
-
@rmbolger@mastodon.social 2026-04-29 22:37
@nicksilkey@hachyderm.io I’m pretty sure there’s an RFC stating no less than 2, but not sure what it is. From practical experience, the max is dictated by the TLD. Some ccTLDs I’ve used allow no more than 4.
-
@jtk@infosec.exchange 2026-04-30 13:36
@nicksilkey@hachyderm.io There is no perfect number, it depends. There are "guidelines" and practical limits. The maximum in theory is a lot more than people realize, but there are some 16-bit fields that impose some limits on the wire (nscount, UDP message size, 16-bit length field added in DNS over TCP, etc.) ISC bind imposes an RRset size of 100 records by default (max-records-per-type). Some registrars will impose a minimum of two and might require prefix diversity (i.e., can't be in the same IP4 /24). For any serious zone two is a widely accepted minimum. But is >2 automatically better? I'd rather have two well designed anycast instances than three random non-anycast servers. Other factors are widely recognized as important (e.g., name server address/prefix/route/geoloc) to consider. More might be nice, but that adds complexity. Historically the practical limit was 13 NSes due to message length restrictions. Things have evolved, but unevenly. Original message size limits can be overcome by the EDNS(0) payload option, but do you want bigger messages (i.e., amplification/reflection attacks are no fun). And with IPv6, messages get bigger. I don't know of any RFC or reputable reference that gives you a recommended number without going through a bunch of nuanced considerations like I did.