답변:
Slicehost의 기본값 인 86,400 초 (1 일)로 유지하는 경향이 있습니다. 이동이 보류 중이고 하루나 이틀 정도 기다리면 10 분으로 줄어 듭니다.
편집 : 요즘 (2016) 나는 ~ 5 분 낮게 유지하는 경향이 있습니다.
1987 년 오래 전에 작성된 표준 에서는 최소 기본 TTL로 86,400 초 (1 일)를 제안합니다.
TTL을 적절한 값으로 설정해야합니다. TTL은 리졸버가 서버에 다시 요청하기 전에 서버에서 얻은 데이터를 사용하는 시간 (초)입니다. 값을 너무 낮게 설정하면 많은 반복 요청으로 서버가로드됩니다. 너무 높게 설정하면 변경 한 정보가 적절한 시간 내에 분배되지 않습니다. TTL 필드를 비워두면 영역의 SOA 레코드에 지정된 값으로 기본 설정됩니다.
대부분의 호스트 정보는 오랫동안 변경되지 않습니다. TTL을 설정하는 좋은 방법은 TTL을 높은 값으로 설정 한 다음 변경이 곧 올 것이라는 것을 알고 있으면 값을 낮추는 것입니다. 대부분의 TTL을 하루 (86400)와 일주일 (604800) 사이의 어느 곳에 나 설정할 수 있습니다. 그런 다음 가까운 미래에 일부 데이터가 변경 될 것임을 알고 있으면 변경이 발생할 때까지 해당 RR의 TTL을 더 낮은 값 (1 시간에서 하루)으로 설정 한 다음 이전 값으로 되돌려 놓으십시오.
또한 이름, 클래스 및 유형이 동일한 모든 RR은 동일한 TTL 값을 가져야합니다.
RFC 1033 참조 : http://tools.ietf.org/html/rfc1033
RFC 1912 (1996 년)는 3 일이 SOA기록에 더 적합 할 수 있다고 제안 합니다.
긴급 상황 (특히 HA DNS 환경 내)에서 더 빠르게 대응할 수 있도록 짧은 TTL을 갖는 것이 더욱 유행하고 있음을 알았습니다.
4 시간이면 괜찮을 것입니다. 그것이 대부분의 영역에서 사용하는 것입니다.
RFC 1912 외에도 유럽의 사용자는 RIPE-203 "DNS SOA 값 권장 사항"을 확인해야 하는데 이틀을 최소 TTL 값으로 권장합니다.
(참고 :이 게시물은 개별 A / AAAA 레코드의 TTL에 적용되며, 일부 다른 레코드 유형은 동일한 방식으로 단일 실패 지점을 나타내지 않기 때문에 더 긴 TTL을 가질 수 있습니다).
재난 복구 계획과 관련하여이 문제를 고려해야합니다. 사이트를 이동하려는 시점이 아닙니다 (의도적 인 이동의 경우 런업에서 TTL을 이동으로 줄일 수 있음). 호스트가 인터넷에서 사라지거나 TOS 위반으로 당신을 쫓아 내거나 그들이 당신의 길로 온 DDOS를 처리 할 수 없기 때문에 당신을 쫓아내는시기입니다.
이러한 상황에서 하루 동안 사이트가 다운되는 것을 신경 쓰지 않으면 TTL을 하루 기본값으로 두십시오. 여러 공급 업체의 여러 위치에 PI 주소 공간과 BGP 전송이 있고 BGP 수준에서 재해 복구를 처리하려는 경우 하루 기본값으로 그대로 두십시오. 반면에 DNS를 장애 조치 사이트와의 연계를 감지하는 메커니즘으로 DNS를 사용하는 경우 훨씬 짧은 TTL을 원한다면 5 분이 일반적입니다.