Why DNS Zone IDs Should Never Be Primary Keys in App Infrastructure

A technical analysis argues that applications should maintain their own stable zone keys rather than relying on provider-issued DNS zone IDs as primary identifiers. The recommended model uses three distinct identities: an application-owned zone key, the human-readable domain name, and the provider-issued zone ID treated as replaceable cached data. This separation becomes critical during account migrations, zone recreation events, or provider switches, where using a provider ID as a primary key can cause silent identity failures. The piece draws on real-world logistics contexts, where operational mail like dispatch notices depends on correct DNS routing across provider changes. It concludes that MX cutovers should be treated as reconciliation loops verified against published DNS, not one-shot record updates.