> On the one hand it's good to prevent these edge cases and keep things deterministic, but on the other it can cause availability issues for customers if Route 53 were to refuse to import a zone that probably loaded and "worked" just fine with the previous or secondary set up. There's all sorts of ways it's possible to write a mis-configured but "valid" zone file, where records and subtrees of records become unreachable. Most customers rely on test queries and traffic monitoring to observe if there are problems.

Since this problem only materializes if you prime your resolver cache correctly, it's really easy for testing/monitoring to miss it.

Route 53 could issue a warning instead of rejecting the zone outright. For example, Google Cloud DNS issues these warnings if you try to add an SPF TXT record without quotes:

"Warning: A record for this domain has whitespace but is not a "quoted string" and therefore is split into separate strings at whitespace. SPF, DKIM, and DMARC join those strings without spaces, which can cause "problems, especially for Sender Policy Framework records. Warning: A record for this domain starts with "v=spf1" but lacks a quoted space following the '1'. This may be a badly formatted Sender Policy Framework record that will be ignored by mail software."

That saved someone I know from publishing a bad SPF record.