A fintech platform providing tenant subdomains should choose a platform-owned DNS zone for predictable activation. Conversely, a customer-owned zone is preferable when delegated control is a contractual or security necessity. It's crucial to explicitly define DNS readiness as a distinct state rather than assuming successful lookups signify completion. The TTL of DNS records plays a significant role, as lowering it does not retroactively alter existing cached entries by resolvers.In a platform-owned zone, the platform manages both TTL and records, facilitating automatic tenant subdomain creation and simplifying diagnostics by clearly distinguishing authoritative states from resolver states. A customer-owned zone grants the customer control over parent-side changes, essential for delegated ownership requirements, but complicates diagnostics due to potential staleness across administrative boundaries. The core issue with DNS changes is multiple observation points: authoritative servers versus recursive resolvers and client caches.A single successful lookup is insufficient proof; one must first query the authoritative path and several recursive resolvers separately. Patience is key; if an old, long TTL is cached, the effective action is to measure its remaining lifetime and wait, not to reconfigure the record. Tenant onboarding should model "record created" and "safe to activate" as separate states, as a control plane write can be quick while resolvers might still hold old, cached data.Customer-owned zones are suitable when namespace control is paramount, but this necessitates evidence-driven activation across administrative boundaries. Platform-owned zones are ideal for automatic per-tenant subdomain issuance when the platform can own the namespace. Ultimately, design for disagreement, observing DNS change completion rather than relying on declarations. Store evidence, expose pending states, and clearly delineate ownership boundaries to reduce blind retries and identify faults faster.