Why Does Dnsimple Push Record Changes to Eight Points of Presence, as Far as Australia, With Its Own Transfer System and a Low Time to Live Instead of a One-day Default?

DNSimple gets record changes out through its own internal transfer system, and the bar for that system is Australia. The authoritative network has eight points of presence, data has to travel from the primary data center in the US to the furthest one, and default time-to-live values are set fairly low so a caching name server does not sit on a record for a day.

On Hanselminutes, Scott Hanselman said he stuck with DNSimple because a change such as exampleapp.hanselman.com showed up on refresh, and a text record for a certificate was visible when he went back to the command line. People updating a C name at GoDaddy would wait about 12 to 15 minutes for changes to propagate, and the demo never worked.

Anthony Eden said DNSimple does not rely on the usual protocols that synchronize servers. The internal system was built up to move changes to the edge quickly, the team measures the transfer, and when scaling slowed it down they redesigned how data moves. A registrar might default a time to live to a day, and a caching name server with a very long time to live is not going to clear itself.