TTL을 24 시간에서 5 분으로 변경했습니다. 기록을 변경하기 전에 24 시간을 기다려야합니까?

37

Rackspace ta 전용 서버의 클라우드 서버에서 앱을 마이그레이션하고 있습니다.

클라우드 서버에서 전용 서버로 데이터를 복사하기 위해 응용 프로그램을 약 5 분 동안 중단하고 싶습니다. 따라서 데이터를 복사 한 후 이전 서버로 요청을 보내고 싶지 않습니다.

새 서버에서 DNS 레코드를 가리키고 싶지만 TTL이 24 시간으로 설정되었습니다. 나는 그것을 300 초로 변경했습니다. 도메인이 데이터를 가리 키거나 복사하는 IP를 업데이트하기 전에 24 시간을 기다려야합니까?

domain-name-system  rackspace  ttl 
— wobbily_col
소스
9
BTW TTL을 기다리더라도 이전 서버의 구성을 편집하여 더 이상 업데이트가 허용되지 않는 것이 좋습니다. 모든 DNS 확인자가 실제로 표준을 따르는 것은 아닙니다.
— 피터 그린
5
한 호스팅 공급자에서 다른 호스팅 공급자로 웹 응용 프로그램을 옮길 때 ssh 포트 전달을 사용하여 여전히 기존 IP를 사용하는 방문자가 새 서버로 연결되도록했습니다.
— kasperd

답변:

58

캐시 된 도메인 레코드 사본을 가진 사람은 24 시간 동안 업데이트하지 않아도되므로 예, 최대 5 분 동안 사용할 수없는 상태를 유지하려는 경우 모든 미해결 캐시가 더 이상 업데이트되지 않을 때까지 기다려야합니다. 5 분 이상.

— 제프 메덴
소스
23
... 24 시간 동안 since they last cached it. 1 초에서 86399 초 사이 일 수 있습니다.
— user9517은 GoFundMonica
6
@Iain 당신은 그들 중 일부 또는 전부가 변경 직전에 캐시 할 수 있기 때문에 최악의 상황을 가정해야합니다.
— Barmar
6
@Barmar 아무 것도 가정하지 마십시오. 많은 ISP가 TTL을 무시합니다.
— user9517은 GoFundMonica 지원
13
@Iain 나는로드 밸런싱을 위해 짧은 TTL (60 초와 같은)을 많이 사용하는 CDN 인 Akamai에서 일했었다. 나는 우리가 연구를했으며 대부분의 ISP가 우리의 TTL을 준수했음을 발견했습니다.
— Barmar
1
나는 웹 호스팅 회사에서 일하고 있으며, 낮은 TTL은 높은 것보다 무시할 가능성이 높습니다.
— Henrik
39

그것보다 (잠재적으로) 훨씬 더 나쁘다. 모든 권위있는 서버가 업데이트 된 후 24 시간을 기다려야한다 . 업데이트가 발생하는 일반적인 방법은 기본 서버의 영역을 변경 한 후 다음에 기본 서버에 체크인 할 때 각 보조 노드가 새 영역 데이터를 전송하는 것입니다. 체크인 빈도는 영역의 SOA 레코드에서 새로 고침 간격에 의해 제어됩니다. 따라서 최악의 경우 영역의 새로 고침 간격 + 레코드의 TTL을 기다려야합니다.

실제 레코드가 변경 될 때까지 기다려야 할 수도 있습니다. 보조 서버가 6 시간마다 새로 고침되는 경우 5 분 TTL은 많은 도움이되지 않습니다. 따라서 빠른 변경을 원하는 기간 동안 영역의 새로 고침 간격을 줄이려고 할 수도 있습니다.

이 설정에 적용되지 않을 수 있습니다. 신뢰할 수있는 모든 서버를 함께 업데이트하는 시스템이있는 경우 이는 문제가되지 않습니다 (Rackspace의 DNS 설정에 익숙하지 않습니다). 그러나 24 시간 카운트 다운을 시작하기 전에 모든 신뢰할 수있는 서버를 개별적으로 쿼리 하여 ( dig server.example.com @secondaryserver.example.com) 새 TTL이 있는지 확인하는 것이 좋습니다 .

— 고든 데이비스 슨
소스
1
이것이 정답입니다.
— dotancohen
4
마스터가 업데이트 된 직후 슬레이브 서버에 새로 고침을 지시하는 DNS 알림 프로토콜을 무시하는 것 같습니다. 대부분의 DNS 서버는이 기능을 사용합니다.
— Barmar
@Barmar : 사실이지만 마스터 는 공급자에 따라 업데이트하는 데 시간 이 걸릴 수 있습니다. (예를 들어, 일부 공급자는 5 분 또는 15 분마다 데이터베이스에서 영역을 다시 작성하지만 현대는 즉시 수행합니다.)
— grawity
1
내 의견은 새로 고침 간격을 기다리는 문제 만 다루고 있었지만 요즘 대부분은 더 이상 사용되지 않습니다. 자신의 마스터를 운영하지 않는 한 마스터가 업데이트되기를 기다리는 것은 사실입니다. 하지만 모든 것이 안전하게 업데이트되는 정확한 시간을 다룰 필요는 없을 것 같습니다. 5 ~ 15 분 정도 차이가 나지 않아야합니다. 원래 질문의 요점은 하루 종일 기다려야하는지 여부입니다.
— Barmar
1
@GordonDavisson : 신뢰할 수없는 경우 – 확인하십시오. dig +nssearch example.com모든 서버에서 SOA를 빠르게 비교하는 데 유용한 도구입니다. nsdiff 는 실제 차이점을 보여줍니다.
— grawity
23

예, 기다려야합니다. 그럼에도 불구하고 모든 사람이 TTL을 존중한다고 보장하지는 않습니다.

— 스벤
소스
6
모든 사람이 TTL을 준수하지 않는 경우 +1, DNS 변경 후 일주일 만에 스트로 글러가 등장했습니다. 과거에 처리 한 한 가지 방법은 새 사이트에서 별칭으로 새 고유 이름을 설정하고 이전 사이트에서 리디렉션을 사용하여 이전 도메인의 사용자를 www.mycompany 와 같이 새 도메인으로 리디렉션하는 것입니다. .COM -> newsite.mycompany.com
— 조니
그렇습니다. 그러나 많은 사람들이 새로운 이름을 사용해야한다는 생각을 멸시 할 것입니다. 이름은 브랜드입니다. 또한 이것은 HTTP 및 다른 거의 작동하지 않습니다.
— Sven
8
다른 옵션은 기존 서버를 새 서버에 대한 리버스 프록시로 구성하는 것입니다. 그런 다음 스위치 후 일주일 정도 그대로 두어 트래픽이없는 경우 끄십시오.
— bdsl
1
TTL을 준수하는 DNS 서버가 올바르게 작동하는 사람은 새 도메인을 볼 수 없습니다. HTTP (S)에서만 "작동"하지만 HTTP는 인터넷에서 상당히 일반적인 프로토콜이라는 것을 알게 될 것입니다. bdsl의 리버스 프록시 설정 제안은 더 좋지만 더 많은 작업입니다.
— Johnny
@Johnny 새 도메인의 문제는 사람들이 해당 도메인을 북마크에 추가 할 위험이 있다는 것입니다. 위에서 언급 한 새 도메인을 영원히 액세스 할 수 있도록 두지 않는 한.
— Bob
5

다양한 의견과 답변을 종합하면 전체 절차는 다음과 같습니다.

  1. 권한있는 서버를 적시에 업데이트 할 수 있는지 확인하십시오.
  2. TTL을 줄이십시오.
  3. 모든 권위있는 서버가 새로운 ttl을 가지고 있는지 확인하십시오.
  4. 이전 TTL이있는 캐시 된 값이 캐시에서 제거되도록 이전 TTL을 기다리십시오 (일부 캐시는 표준을 무시할 수 있기 때문에 모든 캐시에서 사라지는 것을 보장 할 수 없습니다).
  5. 이전 서버의 사이트를 읽기 전용 모드로 설정하십시오 (그렇지 않으면 "유지 관리를 위해 다운되었습니다"페이지로 대체하십시오).
  6. 이전 서버에서 새 서버로 최종 복사를 수행합니다 (새 서버의 읽기 전용 사이트에 있음).
  7. DNS 레코드를 변경하십시오.
  8. 모든 권한있는 서버에 새로운 DNS 레코드가 있는지 확인하십시오.
  9. 새 ttl을 기다립니다 (일부 사용자가 사이트에 참여할 수없고 다른 사용자가 해당 기여의 결과를 보지 못하는 경우에는이 단계를 건너 뛸 수 있습니다).
  10. 새 서버의 사이트를 읽기 / 쓰기 모드로 전환하십시오.
  11. 오래된 서버에서 오래된 읽기 전용 복사본이며 사용자가 DNS를 손상했을 가능성이 있음을 통지하십시오.
  12. 비 호환 DNS 캐시에서 레코드가 제거 될 때까지 잠시 기다리십시오.
  13. 이전 서버를 해제하십시오.
— 피터 그린
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.