Route 53 CNAME이 작동하는 데 얼마나 걸립니까?

다른 서버를 가리 키도록 Amazon의 Route 53에 CNAME을 설정했습니다.

기존 도메인 이름을 가리키는 새 하위 도메인의 새 CNAME입니다.

내가 작업 한 다른 DNS 공급자와 함께 새로운 정식 이름 레코드는 다른 정식 도메인 이름으로 즉시 별칭이 지정되었습니다.

Route 53 DNS레코드 변경 사항은 1 분 이내에 전파되지만, TTL시간이 DNS리졸버가 업데이트 된 레코드 를 얼마나 빨리 다시 확인 하는지에 영향을줍니다 .

Q. Amazon Route 53에서 DNS 설정을 변경하면 전 세계에 얼마나 빨리 전파됩니까?

Amazon Route 53은 정상적인 조건에서 60 초 이내에 DNS 레코드에 대한 업데이트를 전 세계 정식 DNS 서버 네트워크에 전파하도록 설계되었습니다. API 호출이 INSYNC 상태 목록을 반환하면 변경 사항이 전 세계에 전파됩니다.

캐싱 DNS 확인자는 Amazon Route 53 서비스의 제어 범위를 벗어나며 TTL (Time to Live)에 따라 리소스 레코드 세트를 캐시합니다. 변경의 INSYNC 또는 PENDING 상태는 Route 53의 권한있는 DNS 서버 상태 만 나타냅니다.

또는 AWS 개발자 포럼을 선호하는 경우 ...

1 분 안에 전세계의 모든 Route 53 서버에 전파 될 것으로 예상 할 수 있습니다. 그러나 TTL은 클라이언트가 업데이트 된 정보를 얼마나 빨리 볼 수 있는지 결정합니다. 레코드의 TTL을 3600 초로 설정하면 DNS 확인자는 해당 데이터를 최대 1 시간 동안 캐시 한 후 Route 53으로 다시 돌아갈 수 있습니다. 업데이트 된 레코드를 최종 사용자에게 가능한 빨리 전파하는 것이 중요하다면 60 초의 TTL을 권장합니다.

TTL이 각 레코드에 대해 구성되므로 다른 값을 사용할 수 있습니다. 가까운 장래에 레코드를 변경하지 않으려는 경우 TTL이 높을수록 쿼리 비용을 절감하고 업무 효율성을 높일 수 있습니다. 예를 들어, MX 레코드를 그렇게 업데이트하지 않아도됩니다. MX 레코드에 대해 TTL을 43200 초 (12 시간)로 설정했다고 가정 해 보겠습니다. 다른 전자 메일 공급자로 전환 한 경우 TTL을 미리 낮추십시오. 원래 TTL이 만료 되 자마자 이동을 진행할 수 있습니다. TTL이 낮아 업데이트 된 레코드가 훨씬 빠르게 전파됩니다. TTL을 원래 값으로 다시 변경하십시오.

CNAME 값에주의를 기울이지 않았습니다. CNAME 사양에 맞지 않습니다. 질문에 대한 대답은 '인스턴트'입니다.

60 초이지만 호스트 운영 체제가 더 이상 DNS 레코드를 캐시하지 않도록하십시오. DNS 조회 도구를 사용하여 이름 서버를 직접 확인하십시오.