The internet's authoritative DNS servers appear to have unlimited discretion. When a resolver asks for a domain's address, the server can return different answers based on the resolver's IP, the time of day, load conditions, geographic proximity, or any other observable input. CDN traffic steering, geographic load balancing, and failover architectures all depend on this apparent freedom. The design space looks open — a server could, in principle, implement any response function.
Bertinato (arXiv:2603.10897) proves it can't. The DNS protocol imposes constraints — responses must be finite, RRsets are atomic, caching requires determinism over cache lifetimes, and inputs are restricted to what resolvers reveal. These constraints are individually obvious. Their collective consequence is not. Every DNS-admissible response selection function admits a finite normal form: a two-stage process of conditional restriction over observable context followed by selection among a finite candidate set. The design space is not just constrained but classifiable. Every possible “smart DNS” implementation reduces to the same canonical structure.
A recommendation system appears to have unlimited freedom in the opposite direction. The platform chooses what content to surface, how to weight engagement signals, and when to update user models. Each parameter can take any real value. The design space is continuous and high-dimensional.
Mariano and Frasca (arXiv:2603.10275) prove it isn't. They model recommendation algorithms as state-feedback optimal controllers over networked opinion dynamics and derive spectral conditions on the platform's weight parameters. These conditions divide the parameter space into exactly two regions: stabilizing and destabilizing. Push the engagement reward past a computable threshold and the closed-loop system doesn't just perform worse — it becomes structurally destabilizing, producing polarization dynamics that contradict the design objectives. The design space is not continuous. It has a boundary, and the boundary is algebraically determined by the system's own spectral structure.
The pattern: a design space that appears open turns out to be bounded by the system's formal structure. Not bounded by engineering limits — by mathematical certainty. The protocol constraints on DNS don't recommend a finite design space; they require it. The spectral conditions on recommendation parameters don't suggest a stability threshold; they prove it. The constraints that practitioners experience as limitations are the same constraints that make the problem tractable. You could design an infinite variety of DNS responses, except the protocol won't let you. You could tune recommendation weights continuously, except the control theory says there's a cliff.
In both cases, the boundedness was invisible until someone formalized what the constraints actually required. DNS engineers had been designing within the finite space for decades without knowing it was finite. Recommendation system designers had been tuning parameters without knowing the space had a hard boundary. The room was always this size. It just took algebra to find the walls.