나는 인기 있는 VOIP/WebRtc 프로토콜을 지원하기 위해 실행하는 비 HTTP 서버를 가지고 있습니다.
서버 "A"는 이전 서버입니다. 서버 "B"는 새 서버입니다. 둘 다 독립적으로 실행할 수 있지만 동일한 작업을 수행합니다. 서버 "B"는 "A"를 대체할 준비가 완전히 완료되었습니다. 이틀 전, DNS 항목이 "A" 대신 "B"를 가리키도록 전환되었습니다.
문제는 여전히 "B" 대신 "A"로 이동하는 트래픽이 많다는 것입니다. DNS 항목(Route 53)의 TTL은 단 하루(86400초)였습니다. 따라서 DNS를 다시 쿼리하지 않거나 DNS 캐싱과 관련된 다른 문제가 있는 클라이언트가 여전히 있는 것 같습니다.
나는 오작동하는 고객을 배제하지 않았습니다. 하지만 제가 설명하지 못한 다운스트림 DNS 캐싱에 대한 일반적인 동작이 있어 변경 사항이 Route 53의 기록에 대해 가지고 있는 TTL보다 오래 전파되는 것을 지연시킬 수 있습니까?
답변1
이는 표준 동작이므로 잠시 기다려야 합니다(설명에 언급된 대로 며칠 이상 걸릴 수 있음). 좋은 방법은 TTL을 변경 전 3600일(또는 그 이하)로 변경하고, 0일차에 DNS를 변경한 다음 TTL을 표준 값(예: 86400)으로 되돌리는 것입니다.