Checked the TTL on the delegation before moving nameservers, because I wanted to know the cost of being wrong.
dnsowl publishes the child-side NS records with a TTL of 172800 seconds. 48 hours.
That number is the rollback window. If I switch nameservers away and something breaks, changing them back does not take effect for every resolver until the cached NS records expire. Resolvers that fetched the delegation one minute before my change will keep using it for the full 48 hours. There is no flush you can run against the internet.
Worth being precise, because “DNS propagation” is a phrase that mostly means “I do not know why this has not updated yet”. What I am describing is a specific TTL on a specific record type, published by the provider, and you can read it directly:
dig NS example.com @<the-authoritative-nameserver> | grep -i " NS "The number in the second column is your worst case, in seconds.
What this changes in practice: a nameserver change stops being a reversible experiment. Before I flip, the new provider has to already serve every record correctly, verified by querying the new nameservers directly by name before the delegation points at them. dig A example.com @new-ns1.provider.com. If that answer is wrong, I find out now, at zero cost, instead of during a 48-hour outage I cannot shorten.
Lowering the TTL first only helps if you do it more than 48 hours ahead, because the old TTL governs how long the old value is cached.