Dusan Pohl
asked on
DNS TTL
Hello,
Hello All,
During the Team Center migration we had an issue where the DNS cache on all Domain.com forest DNS servers needed to be cleared as some were responding with the old IP address of the server that was moved (and is in the domain2.com domain). After testing it appears that the default TTL is set to one day. I am asking for opinions on what this should be set to going forward. Should we make it a global change or do it on a record by record basis depending on use case? Should we make it a low default until we get through are IP address reconfigurations?
If I look at the ad.Domain.com domain it looks as though the default TTL for the DNS record is one hour.
I fear this will be an issue for us going forward with the DC 2.0 migrations.
Hello All,
During the Team Center migration we had an issue where the DNS cache on all Domain.com forest DNS servers needed to be cleared as some were responding with the old IP address of the server that was moved (and is in the domain2.com domain). After testing it appears that the default TTL is set to one day. I am asking for opinions on what this should be set to going forward. Should we make it a global change or do it on a record by record basis depending on use case? Should we make it a low default until we get through are IP address reconfigurations?
If I look at the ad.Domain.com domain it looks as though the default TTL for the DNS record is one hour.
I fear this will be an issue for us going forward with the DC 2.0 migrations.
A good TTL is usually 10 minutes for normal production work.
Then drop to 1 minute during migrations, if you must do fallbacks quickly in case of any site failures.
In days of yore/old... when connections were slow... the mythos was to keep DNS TTLs high to reduce DNS traffic.
This is myth, because every Apache request will be orders of magnitude higher than DNS lookups.
So the shorter the TTL, means the shorter time required to recover/migrate a site to a new IP.
Then drop to 1 minute during migrations, if you must do fallbacks quickly in case of any site failures.
In days of yore/old... when connections were slow... the mythos was to keep DNS TTLs high to reduce DNS traffic.
This is myth, because every Apache request will be orders of magnitude higher than DNS lookups.
So the shorter the TTL, means the shorter time required to recover/migrate a site to a new IP.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
The asker of the DNS-Q can use the obtained info the the TTL time in seconds without any need to verify.
So if you are building a Rocksolid server that will never go down and will never change address TTL can be huge.
For a server that has a redundant setup and you want to use each server then the TTL might be 1 minute. (or even shorter).
If TTL is set very short (1 sec?) then almost all requests for a hostname will be asked at the source. Which would be similar to a DDOS attack on the DNS server.
So there is some tradeoff to be made. What is a required acceptable time without causing to much overhead.
When you want to cutover a service that has TTL 1 day, you could set it to say 5 minutes at least 1 day ahead of cutover time.
Then during cutover the TTL's would only live for 5 minutes. after the cutover is final you can set original TTL again.