When configuring reverse DNS, the web interface appears to be using the Fremont recursive servers. In some cases, these may have cached or negative cached an entry, causing delays in applying the update, as the Linode interface requires forward lookups to be in place before reverse lookups are configured.

Are they caching records in excess of the TTL? If not, this is probably not an issue with the reverse DNS verification, but rather with your zone's configuration. Caching is normal and expected (albeit sometimes annoying) behavior for DNS resolution.

_________________

/* TODO: need to add signature to posts */

No.


But can be bypassed if the application calls for it.

are you waiting until 00/15/30/45 past the hour then the DNS manager actually posts updates?

No. I verify the servers have updated empirically:

dig @ns1.linode.com a.b.com A
<correct updated results>
...
dig @ns5.linode.com a.b.com A
<correct updated results>

Then I check resolver1.fremont.linode.com:

dig @resolver1.fremont.linode.com a.b.com A
<previous cached results based>

All of Linode's DNS servers exhibit correct behavior as far as I have seen. It's even possible to tell from the TTL the recursive server gives how long it can keep the cached record. It's just that the cached record happens to be unhelpful for this specific case.