Linode's Cloudflare DNS Firewall settings
How does Linode have it configured? How does it work?
If I make a change to a DNS record, how long could Cloudflare cache it before the changes fully "propagate"?
In a master zone? A slave zone?
If my TTL is 1 second? 1 minute? 1 hour? 1 day? 1 week?
Okay, that was too many questions, but still.
4 Replies
You can look up the IPs and see.
ns1.linode.com. (unsigned) 300 A 162.159.27.72
ns1.linode.com. (unsigned) 300 AAAA 2400:cb00:2049:1::a29f:1a63
I agree "propagation" still appears to be instant (disregarding the 15 minute thing), but I don't know if that's because my unpopular zones have a poor cache hit rate, or because the cache actually is configured with very short time limits.
CCravens
Linode Staff
Effectively, this works like any DNS TTL, except if you set your TTL to less than 30 seconds, CF acts as if you set it to 30 seconds. If you set your TTL to 2 days, CF acts as if you set it to 15 minutes. But it still passes through the TTL values you set in your records when someone downstream queries CF for your zone. This works the same whether Linode is master or slave for your zone.
My experience watching the difference between our master servers and CloudFlare's servers is that updates happen very quickly, despite our own zone's TTL being much longer than 15 minutes. Generally CF reflects our master nameservers within a minute or two, often much less, once all of our masters are in sync. It may be they pay attention to the NOTIFY signals we send, but I'm not certain of that. But worst-case scenario, you shouldn't see a delay of more than 15 minutes between our master servers being updated and CF reflecting that update. (Keeping in mind that there is a delay between updating in the manager and that update being injected into the DNS system.) Any time I've seen tickets indicating an unexpected delay in DNS updates, it's been a problem on our end (the delay was in getting to our master servers). CloudFlare has been very reliable for us.