←back to thread

1.1.1.1: Fast, privacy-first consumer DNS service

(blog.cloudflare.com)
1895 points _l4jh | 2 comments | 01 Apr 18 12:14 UTC | HN request time: 0.598s | source
Show context
jlgaddis ◴[01 Apr 18 19:20 UTC] No.16729942[source]▶
Is Cloudflare overriding TTLs on RRs?

If I send a request to 1.0.0.1 for a specific RR that I'm 99.9% certain isn't cached (although I didn't check the query logs on the authoritative DNS servers to verify a request actually came in), the response contains the (expected) TTL of 14400.

If I then send the same request to 1.1.1.1, I get a response that is identical except with a TTL of 3591 seconds.

According to the timestamps in my client, the second request was made nine seconds after the first one (3591+9=3600), hence my question: is Cloudflare "overriding" the TTL I explicitly set on this specific RR (14400s) with a different TTL (i.e., 3600s)?

replies(1): >>16733031 #
1. vavrusa ◴[02 Apr 18 07:55 UTC] No.16733031[source]▶
Yes, there's a cap on both negative and positive cache lifetime. The reason is reducing the blast radius as accidents happen, and it hurts especially on long infrastructure records (mistake during repointing NSs, bad glue, expired DS etc.) We're going to be looking into making the cap more dynamic over time.
replies(1): >>16776761 #
2. LinuxBender ◴[06 Apr 18 19:49 UTC] No.16776761[source]▶
I do this at home as well, using Unbound DNS to set a min and max TTL. It's taboo on public DNS recursors, but totally makes sense. Some folks try to use DNS as real time load balancers and will set crazy low TTL's like 1 second or even 0 (which violates RFC's)