"ttl.dnsp.co" shows whether your resolver respects the lifetime we attach to an answer.
Every DNS answer carries a TTL — the number of seconds it may be cached before it must be looked up again. It is how quickly a change to a record can take effect. A resolver that caches for longer than the TTL will keep handing out an address after it has been changed, which is exactly the kind of thing that makes a migration appear to fail for some people and not others.
Ask for "<seconds>.<token>.ttl.dnsp.co", where the seconds value is the TTL you want us to attach and the token is anything you have not used before. The address we return changes every time we are actually asked. Query it repeatedly: if the answer stays the same for longer than the TTL you requested, something in the path is holding it past its expiry.
prompt> dig +noall +answer 5.mytoken.ttl.dnsp.co 5.mytoken.ttl.dnsp.co. 5 IN A 106.168.165.33
prompt> dig +noall +answer 5.mytoken.ttl.dnsp.co 5.mytoken.ttl.dnsp.co. 5 IN A 203.0.113.87 ← changed, so the TTL was honoured