DNS를 GD에서 Route 53으로 이동하려고 하는데 두 위치 모두에 동일한 영역 파일이 있어도 가동 중지 시간을 피하는 것이 불가능해 보입니다. 내 실험에 따르면 GoDaddy에서 '사용자 정의' 네임서버로 변경하자마자 DNS 요청에 대한 응답이 중지되고 Route 53도 응답하지 않습니다(응답하기 전에 권한이 있는지 확인하기 위해 기다리고 있습니까?). 나는/dig로 테스트했습니다. 그리고 이것이 내가 본 것입니다. AWS에서 내부 테스트 도구를 사용하면 괜찮지만, Route 53 네임서버 중 하나의 @와 함께 dig를 사용하려고 하면 결과가 반환되지 않습니다.
내 생각은 네임 서버 레코드에 낮은 ttl을 설정하고 다른 모든 것에는 긴 ttl을 설정하는 것입니다. 문제를 해결하는 데 도움이 되는 경험이 있는 사람이 있습니까?
나는 이것이 최근에 특정 확인 네임서버가 레코드에 대해 쿼리한 경우에만 효과가 있을 것이라는 것을 이해합니다. 그러나 실제로는 전파 기간 동안 확인 네임서버가 권위 있는 네임서버를 필요로 할 가능성이 더 커지게 하는 모든 것에 대한 낮은 TTL보다 더 나은 것처럼 보입니다.
답변1
전환하기 전에 새 네임서버가 레코드를 제공하는지 확인하세요. 아직 권한이 없는 서버에 DNS를 구성하는 것은 허용됩니다. 올바른 데이터를 제공하고 있다고 판단되면 도메인 구성의 네임서버 목록에 추가하세요. 그런 다음 원래 이름 서버를 제거할 수 있습니다.
모든 호스트에 대해 이미 긴 TTL이 있어야 합니다. 이렇게 하면 네임서버 변경에 문제가 있는 경우 위험이 줄어듭니다. 조회 실패가 장기간 캐시되지 않도록 도메인의 음수 TTL을 줄이는 것이 좋습니다. NS 레코드의 TTL을 줄이면 변경이 더 간단해집니다. 원래 네임서버가 자신을 가리키는 NS 레코드가 만료되기 전에 레코드 제공을 중단하면 부정적인 응답 제공이 시작될 수 있습니다.
GD에 대한 내 경험으로 볼 때 GD 측의 외관상 중단을 피할 수 없을 수도 있습니다. 도메인 구성의 NS 레코드에 짧은 TTL을 설정하면 영향이 줄어듭니다.
답변2
나는 이것이 최근에 특정 확인 네임서버가 레코드에 대해 쿼리한 경우에만 효과가 있을 것이라는 것을 이해합니다. 그러나 실제로는 전파 기간 동안 확인 네임서버가 권위 있는 네임서버를 필요로 할 가능성이 더 커지게 하는 모든 것에 대한 낮은 TTL보다 더 나은 것처럼 보입니다.
DNS 확인자(DNS 서버 또는 해당 DNS 서버의 클라이언트)가 이전에 DNS 레코드를 조회한 경우 해당 레코드는 당시 유효한 TTL에 따라 캐시됩니다. 해당 시나리오에서는 실제로 TTL을 늘리거나 줄여도 아무런 효과가 없습니다. 새로운 TTL은 다음에 대해 적용됩니다.새로운조회.