Does anyone know what mechanism is used between Route 53 and Google DNS? When I update a record in Route 53, there seems to be 0 delay in the updated records being present in 8.8.8.8, even if I've recently request the old value. I've been imagining that they had set up some sort of "cache invalidate" message that AWS could send Google, but I haven't done any investigation.
which suggests the IP addresses share infrastructure (at least near London!)
You can try this sort of thing with other providers to try and map out their internal infrastructure. (1.1.1.1/cloudflare has around 22 machines near me; quad9 has 16; opendns also has 16; verisign has 31; etc).
One thing I tried was making an ad that recorded the cookie id in the impression tracker so I could record the connecting IP addresses in our DNS server. I could then target users who have a particular network provider (or use a particular DNS provider) which could be useful if I want a large number of users who (effectively) ignore DNS caches.
8.8.8.8 is a bunch of servers, and you may be getting different server to service your request than the one that cached your recently requested old value. Make several requests, and observe the TTL -- you may notice that it jumps around as you get different servers, especially if you space your requests apart a few seconds.
Perhaps Route 53 and Google have setup a system to notify each other when a record changes so they can then request a transfer and have near zero propagation delay.
Note that this notify system is not the same as that proposed in the RFC. This notify system is configured by the admin and is meant to keep secondary servers updated with changes in the primary server, not for general notification of changes to anyone who is interested.
I haven't noticed this with Route 53 (but I also haven't used it for a year). My experience was that even Amazon's resolvers didn't update with my changes immediately. So if I added a record, then immediately did "dig @8.8.8.8 my.new.domain", I would get NXDOMAIN cached for the time on my SOA record. To avoid that wait, I had to be careful to not try resolving it for a couple minutes, so that the NXDOMAIN wouldn't be cached.
Maybe things have changed, which would be nice. Nowadays I'm on DigitalOcean and they don't let you control the TTL on the SOA record, so you have to be even more careful than with Amazon. Very annoying.
You could query your authoritative name server(s) first and only query other resolvers once you see your new record. Shouldn't be to hard to automated that using something like dnspython.
If the authoritative is using Anycast (which they should) then you run into similar problems that you get with Anycast resolvers, which is to say you might get different results depending on distribution of data. Due to this we currently provide an API for checking distribution of zone changes with our authoritative name servers: (https://developer.dnsimple.com/v2/zones/#checkZoneDistributi...).
Thanks for the replies on this. Looks like most of this was luck of the draw and not notifications from AWS to Google. I had a change to make today, and made 100 requests from 8.8.8.8 before, then made the change and it hadn't updated after a couple minutes. In Denver, looks like we have 15 different servers answering the 8.8.8.8 requests. I then hit the "clear cache" URL someone mentioned here, and it updated quickly then. Great discussion, thanks everyone!
