9

I have a question on setting TTLs on NS records. Taking this example:

example.com. 3600  NS ns1.example.com.
example.com. 3600  NS ns2.example.com.
test         14400 A  example.com.

So in this example the name server records are set with a TTL of 1 hour and test.example.com has a TTL of 4 hours.

Does this mean test.example.com will actually have a TTL of 1 hour because the name server lookup is only valid for an hour?

CJD
  • 237
  • 1
  • 3
  • 5

2 Answers2

10

In the DNS context, a TTL defines the duration that a resource record (RR) may be cached by any resolver.

NS RRs are part of what is sometimes called the zone's infrastructure records. Infrastructure RRs (which include SOA, NS and MX RRs) are unique in that they return other names not addresses, as such they should be stable and to minimize DNS access can and should have very long TTLs (days and weeks).

You specify a TTL for a certain RR if you want to override the default value.

Based on your records configuration;

Upon the first recursion of a resolver:

Each NS record will be cached for 1 hour, and test.example.com will be cached for 4 hours.

Say after 30 minutes the same resolver has been asked for test.example.com record, the cached one will be returned without contacting your authoritative NS.

Say after 120 minutes the same resolver has been asked for test.example.com record, the cached one will be returned without contacting your authoritative NS.

But at this point if the resolver is asked about foo.example.com, it will have to do a new recursion to find your NS RR, then find foo.example.com.

Ahmed Ossama
  • 381
  • 2
  • 3
  • I get you, thanks. So if we're trying to name change name servers with minimal downtime - we need to lower the TTLs of ALL records? Not just the NS records? – CJD Jul 11 '16 at 14:48
  • No, the NS RR must be high. However, set the RR of each record low. – Ahmed Ossama Jul 11 '16 at 15:03
  • When migrating the SOA(s) to different NS(s), you maintain copies of the zones on both old an new NS. As the cached records age-out more queries will be hitting the new NS(s). Not all DNS caching implementations are as faithful to the TTL as we'd like them to be, so it's a good idea to monitor queries against the old NS(s) and leave the zones up there until that traffic ceases. If it dosen't cease then you have a configuration error that needs to be tracked down. Changing TTL has the same caching problem; the new TTL values won't propagate any faster than the records they're attached to. – tlum Mar 06 '20 at 17:17
0

I know a little late but I am trying to do the same thing and the approach I am following is I am going to increase the TTL for my important subdomains as the CNAME record for them are not changing, I will decrease the TTL for my NS record and migrate, will verify working with less critical subdomains. This way if anything goes wrong with my NS record, I should be able troubleshoot it before it will impact my critical subdomains.

user1106683
  • 1