Amazon Route 53 DNS 모범 사례 - Amazon Route 53

Amazon Route 53 DNS 모범 사례

다음 모범 사례를 따르면 Amazon Route 53 DNS 서비스를 사용할 때 최상의 결과를 얻을 수 있습니다.

DNS 장애 조치 및 앱 복구에 데이터 영역 기능 사용

상태 확인 및 Amazon Application Recovery Controller(ARC) 라우팅 제어를 포함한 Route 53용 데이터 플레인은 전 세계에 분산되고, 심각한 이벤트 중에도 100% 가용성과 기능을 제공하도록 설계되었습니다. 이들은 서로 통합되며 제어 영역 기능에 의존하지 않습니다. 콘솔을 포함한 이러한 서비스의 제어 영역은 일반적으로 매우 안정적이지만, 중앙 집중식으로 설계되어 고가용성 대신에 내구성과 일관성을 우선시합니다. 재해 복구 중 장애 조치와 같은 시나리오의 경우, 데이터 플레인 기능에 의존하는 Route 53 상태 확인 및 ARC 라우팅 제어와 같은 기능을 사용하여 DNS를 업데이트하는 것이 좋습니다. 자세한 정보는 제어 및 데이터 영역 개념 및 블로그: Amazon Route 53을 사용하여 재해 복구 메커니즘 생성을 참조하세요.

DNS 레코드에 대한 TTL 값 선택

DNS TTL은 DNS 해석기가 Route 53에 다른 쿼리를 수행하지 않고 레코드가 캐시될 수 있는 기간을 결정하는 데 사용하는 숫자 값(초)입니다. 모든 DNS 레코드에는 TTL이 지정되어 있어야 합니다. TTL 값의 권장 범위는 60초에서 172,800초입니다.

지연 시간과 안정성, 변화에 대한 응답성 사이의 절충을 위해 TTL을 선택합니다. 레코드의 TTL이 짧을수록 DNS 해석기는 더 자주 쿼리해야 하므로 레코드에 대한 업데이트를 더 빠르게 알립니다. 이렇게 하면 쿼리 볼륨(및 비용)이 증가합니다. TTL을 늘리면 DNS 해석기가 캐시의 쿼리에 더 자주 응답합니다. 이는 일반적으로 더 빠르고 저렴하며 일부 상황에서는 인터넷을 통한 쿼리를 피할 수 있기 때문에 더 안정적입니다. 올바른 값은 없지만 응답성과 신뢰성 중 무엇이 중요한지 생각해 보는 것은 가치가 있습니다.

TTL 값을 설정할 때 고려할 사항은 다음을 포함합니다.

  • 변경 사항이 적용될 때까지 기다릴 수 있는 시간의 길이에 대해 DNS 레코드 TTL을 설정합니다. 이는 특히 위임(NS 레코드 세트) 또는 거의 변경되지 않는 다른 레코드(예: MX 레코드)에 해당됩니다. 이러한 레코드의 경우 긴 TTL을 권장합니다. 한 시간(3600초)과 하루(86,400초) 사이의 값을 일반적으로 선택합니다.

  • 신속한 장애 조치 메커니즘의 일부로 변경해야 하는 레코드(특히 상태 확인된 레코드)의 경우 짧은 TTL이 적합합니다. 이 시나리오에서는 TTL을 60초 또는 120초로 설정하는 것이 일반적입니다.

  • 중요한 DNS 항목을 변경하는 경우 일시적으로 TTL을 줄이는 것이 좋습니다. 그런 다음 변경, 관찰 및 필요한 경우 빠르게 롤백할 수 있습니다. 변경이 완료되고 예상대로 작동하면 TTL을 늘릴 수 있습니다.

자세한 정보는 TTL(초)을 참조하세요.

CNAME 레코드

DNS CNAME 레코드는 한 도메인 이름을 다른 도메인 이름으로 가리키는 방법입니다. DNS 해석기가 domain-1.example.com을 확인하고 domain-2.example.com을 가리키는 CNAME을 찾으면 DNS 해석기는 응답하기 전에 domain-2.example.com을 확인해야 합니다. 이러한 레코드는 웹 사이트에 도메인 이름이 두 개 이상일 때 일관성을 유지하는 것과 같은 여러 상황에서 유용합니다.

그러나 DNS 해석기는 CNAME에 응답하기 위해 더 많은 쿼리를 작성해야 하므로 지연 시간과 비용이 증가합니다. 가능하면 Route 53 별칭 레코드를 사용하는 것이 더 빠르고 저렴한 대안입니다. 별칭 레코드를 통해 Route 53은 AWS 리소스(예: 로드 밸런서) 및 동일한 호스팅 영역 내의 다른 도메인에 대해 직접 답변으로 응답합니다.

자세한 내용은 AWS 리소스로 인터넷 트래픽 라우팅 단원을 참조하십시오.

고급 DNS 라우팅

  • 지리적 위치, 지리적 근접성 또는 지연 시간 기반 라우팅을 사용할 때 일부 클라이언트가 응답 없음 응답을 받기 원하지 않는 한 항상 기본값을 설정하세요.

  • 애플리케이션 지연 시간을 최소화하려면 지연 시간 기반 라우팅을 사용합니다. 이러한 유형의 라우팅 데이터는 자주 변경될 수 있습니다.

  • 라우팅 안정성과 예측 가능성을 제공하려면 지리적 위치 또는 지리적 근접성 라우팅을 사용합니다.

자세한 내용은 지리적 라우팅, 지리 근접 라우팅, 지연 시간 기반 라우팅 단원을 참조하세요.

DNS 변경 전파

Route 53 콘솔 또는 API를 사용하여 레코드 또는 호스트 영역을 생성하거나 업데이트하는 경우 변경 사항이 인터넷에 반영되기까지 약간의 시간이 걸립니다. 이는 변경 전파라고 불립니다. 일반적으로 전파에는 전역적으로 1분 미만이 걸리지만, 예를 들어 한 위치에 동기화하는 문제나 드문 경우 중앙 제어 영역 내의 문제로 인해 가끔 지연될 수 있습니다. 자동화된 프로비저닝 워크플로를 구축하고 있고 다음 워크플로 단계로 진행하기 전에 변경 전파가 완료될 때까지 기다리는 것이 중요한 경우 GetChange API를 사용하여 DNS 변경이 적용되었는지 확인하세요(Status =INSYNC).

DNS 위임

DNS에서 여러 수준의 하위 도메인을 위임하는 경우, 항상 상위 영역에서 위임해야 합니다. 예를 들어 www.dept.example.com을 위임하는 경우 example.com 영역이 아니라 dept.example.com 영역에서 그렇게 해야 합니다. 조부모에서 자식 영역으로 위임하는 것은 전혀 작동하지 않거나 일관성 없이 작동할 수 있습니다. 자세한 내용은 하위 도메인에 대한 트래픽 라우팅 단원을 참조하십시오.

DNS 응답의 크기

대규모 단일 응답을 생성하지 마십시오. 응답이 512바이트를 초과하면 많은 DNS 해석기가 UDP 대신 TCP를 통해 재시도해야 하므로 안정성이 저하되고 응답이 느려질 수 있습니다. 응답을 512바이트 경계 내로 유지하려면 8개의 정상적인 임의 IP 주소를 선택하는 다중 응답 라우팅을 사용하는 것이 좋습니다.

자세한 내용은 다중값 응답 라우팅 및 DNS 응답 크기 테스트 서버를 참조하세요.