In theory… the number of layers of resolvers shouldn’t increase TTL. Any resolver that gets an answer from an authoritative servers gets the full TTL. A downstream resolver that asks for the records from that server’s cache gets the answers with the TTL appropriately decremented. Any additional layers of resolvers also get the TTL counted down since that initial hit on an authoritative server.
But it seems to be common knowledge that layers of resolvers causes things to linger. What is the mechanism? Is it middle caches that are just plain busted and don’t decrement TTL correctly? Something more subtle?
Look at it this way, anywhere that has resolvers forwarding to other resolvers that forward to yet another set of resolvers before the query gets to the root servers (anywhere with a complex network and multiple layers of firewalling) will have
a succession of caches that need to clear .. so might take somewhat longer than whatever TTL you set. The recommendation therefore is to lower the TTL for a few days BEFORE you change your DNS records.
In typical "Google knows best" style they appear to be ignoring SOA and TTL and doing their own thing.
Changed DNS severs and MX records, other public mail services have picked it up no problem.
Gmail however appear to be insisting on continuing to deliver to the old mail servers for god knows how much longer ?
Any ideas how long I can expect this to go on for before they Do The Right Thing (TM) ?