Amazon Route 53의 지연 시간 기반 라우팅이 클라이언트로부터 멀리 떨어진 AWS 리전에 있는 서버를 반환합니다. 예를 들어, 미국에 있는 사용자가 내 웹 사이트에 액세스하려고 하면 Route 53은 유럽에 있는 서버의 IP 주소를 반환합니다. 클라이언트가 먼 곳의 AWS 리전으로 라우팅되지 않게 하려면 어떻게 해야 합니까?

다음 조건이 충족될 경우, Route 53은 DNS 쿼리 위치를 기준으로 지연 시간이 가장 짧은 AWS 리전을 선택합니다.

Route 53는 다음을 기준으로 지연 시간을 계산합니다.

  • 쿼리를 Route 53 권한 이름 서버에 전송하는 재귀 DNS 확인자의 소스 IP
  • DNS 확인자가 EDNS0-Client-Subnet 확장을 지원하는 경우, 재귀 쿼리를 수행하는 클라이언트의 소스 IP.

Route 53 네임 서버는 기본적으로 EDNS0-Client-Subnet을 지원합니다. EDNS0-Client-Subnet을 지원하는 재귀 DNS 확인자는 잘린 버전의 클라이언트 IP 주소를 Route 53으로 보냅니다. 그러면 Route 53은 그 잘린 IP 주소를 사용하여 지연 시간이 가장 짧은 AWS 리전을 결정합니다.

지연 시간이 가장 짧은 AWS 리전이 DNS 확인자와 물리적으로 가장 가까운 리전이 아닐 수 있습니다. 클라이언트가 DNS 확인자와 동일한 위치에 있지 않거나 확인자의 IP 주소에 다른 위치 정보가 있으면 원치 않는 라우팅 동작이 발생할 수 있습니다.

다음 단계에 따라 원치 않는 지연 시간 기반의 라우팅 동작 문제를 해결하십시오.

1. 특정 AWS 리전에서 DNS 확인자가 사용하는 IP 주소 범위를 점검합니다. 다음 명령을 11초 기간 동안 5 ~ 6회 실행합니다. 매번 출력을 기록해 둡니다.

Linux 또는 macOS에서는 dig를 사용합니다.

for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;

Windows에서는 nslookup을 사용합니다.

nslookup resolver-identity.cloudfront.net

2. DNS 확인자가 애니캐스트를 지원하는지 출력을 통해 확인합니다. 출력에 항상 동일한 단일 IP 주소가 포함되는 경우 DNS 확인자는 애니캐스트를 지원하지 않습니다. 명령을 여러 번 실행할 때 IP 주소가 변경되는 경우 DNS 확인자는 애니캐스트를 지원합니다.

DNS 확인자가 애니캐스트를 지원할 때는 DNS 확인자에 대해 여러 개의 엣지 로케이션이 있으며 최적의 지연 시간을 기준으로 사용자의 엣지 로케이션이 선택되므로 확인자 IP 주소에 대해 예상치 못한 위치가 나타날 수 있습니다.

3. 클라이언트의 IP 주소를 찾습니다. 클라이언트 장비의 브라우저에서 이 URL(https://checkip.amazonaws.com/)을 방문하여 클라이언트 IP 주소를 확인합니다.

아니면 curl을 사용합니다.

curl https://checkip.amazonaws.com/

4. 아래 명령 중 하나를 사용하여 DNS 확인자가 EDNS0-Client-Subnet을 지원하는지 점검합니다. 출력을 기록해 둡니다.

Linux 또는 macOS에서는 dig를 사용합니다.

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

Windows에서는 nslookup을 사용합니다.

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5. 출력의 Answer 섹션에 반환된 첫 번째 TXT 레코드를 점검합니다. 이 값이 애니캐스트를 광고하는 가장 가까운 DNS 서버입니다. 두 번째 TXT 레코드가 없는 경우 DNS 확인자는 EDNS0-Client-Subnet을 지원하지 않습니다. 두 번째 TXT 레코드가 있는 경우 DNS 확인자는 EDNS0-Client-Subnet도 지원합니다. 확인자는 잘린 클라이언트 서브넷(/24 또는 /32)을 제공한 다음 Route 53 권한 이름 서버로 전송합니다.

6. 응답의 TTL 값이 60초인지 확인합니다. TTL이 60초가 아닌 경우 응답은 캐시된 응답입니다. 응답 TTL 값이 60초가 될 때까지 dig 또는 nslookup 명령을 반복합니다.

7. Route 53 DNS 확인 도구를 사용할 수 있다면 특정 DNS 확인자 또는 클라이언트 IP 주소에서 오는 쿼리를 시뮬레이션합니다. 이러한 쿼리를 사용하여 Route 53이 반환하는 지연 시간 리소스 레코드 세트를 찾아 냅니다.

DNS 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우 도구에서 Resolver IP address(확인자 IP 주소)를 값으로 지정합니다.

DNS 확인자가 EDNS0-Client-Subnet을 지원하는 경우 도구에서 EDNS0 client subnet IP(EDNS0 클라이언트 서브넷 IP)를 값으로 지정합니다. 추가 옵션을 선택한 다음 서브넷 마스크도 지정합니다. Resolver IP address(확인자 IP 주소)를 지정하지 마십시오.

참고: 이 도구는 Route 53 지연 시간 측정 데이터베이스를 직접 쿼리하여 AWS 리전과 인터넷 네트워크 간에 미리 계산된 지연 시간을 확인합니다. 사실 이 도구는 인터넷을 통해 또는 DNS 확인자에 DNS 쿼리를 실제로 전송하지 않습니다. 시뮬레이션 도구는 DNS 확인자가 EDNS0-Client-Subnet을 지원하는지 여부를 확인하지 않습니다. 시뮬레이션과 실제 DNS 쿼리의 결과가 다를 수 있습니다.

8. (선택 사항) Route 53 DNS 확인 도구에 대한 액세스 권한이 없는 경우, dig를 사용하여 Route 53 권한 이름 서버에서 EDNS0-Client-Subnet이 있는 호스팅 영역을 쿼리합니다. 이제 그 출력을 사용하여 소스 IP에서 지연 시간이 가장 짧은 AWS 리전을 결정합니다.

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

참고: 인터넷에서 호스트 간의 지연 시간은 네트워크 연결 및 라우팅 변경으로 인해 시간이 지나면 바뀔 수 있습니다.

9. EDNS0-Client-Subnet을 지원하는 클라이언트라면 해당 클라이언트의 DNS 쿼리 종료 지점을 클라이언트와 지리적으로 가까운 위치로 변경하십시오. 확인자가 EDNS0-Client-Subnet을 지원하는 경우 클라이언트 DNS 쿼리는 클라이언트 위치와 다른 위치에서 종료될 수 있으며 결과적으로 예상치 못한 라우팅 동작이 나타날 수 있습니다.

EDNS0-Client-Subnet을 지원하지 않는 클라이언트라면 클라이언트가 사용하는 DNS 확인자를 클라이언트와 지리적으로 더 가까운 다른 재귀 DNS 확인자로 변경합니다. 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우 클라이언트 DNS 쿼리는 클라이언트와 다른 지리적 위치의 DNS 확인자를 사용할 수 있으며 결과적으로 예상치 못한 라우팅 동작이 나타날 수 있습니다.

10. (선택 사항) DNS 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우, EDNS0-Client-Subnet을 지원하는 퍼블릭 재귀 DNS 확인자로 변경하십시오. 그런 다음, Route 53의 기존 지연 시간 라우팅 응답 결과를 새로운 결과와 비교합니다. 예를 들어 현재 EDNS0-Client-Subnet을 지원하는 두 가지 퍼블릭 DNS 확인자는 GoogleDNS(8.8.8.8 및 8.8.4.4)와 OpenDNS(208.67.222.222 및 208.67.220.220)입니다.

문제 해결 예제

한 회사가 버지니아(us-east-1) 및 아일랜드(eu-west-1)에 있는 두 개의 Elastic Load Balancer에 대한 지연 시간 기반 라우팅 레코드를 가지고 있습니다. 미국에 있는 사용자는 유럽에 있는 회사 DNS 확인자를 사용하거나, VPN을 통해 유럽에 있는 회사 사무실에 연결합니다.

회사 DNS 확인자가 EDNS0-Client-Subnet 데이터(잘린 클라이언트 IP 주소 정보)를 권한 이름 서버에 전송할 수 없는 경우 Route 53는 유럽에 있는 DNS 확인자 IP 주소를 쿼리 소스로 간주합니다. 그런 다음 Route 53는 지연 시간 데이터베이스에서 조회를 수행하고 아일랜드에 있는 로드 밸런서의 지연 시간이 가장 짧다고 잘못 결정합니다.

하지만 회사 DNS 확인자가 EDNS0-Client-Subnet 데이터를 전송할 수 있는 경우 Route 53은 미국에서 잘린 클라이언트 IP를 DNS 쿼리의 소스로 간주합니다. Route 53는 지연 시간 데이터베이스에서 조회를 수행하고 버지니아에 있는 로드 밸런서의 지연 시간이 가장 짧다고 올바르게 결정합니다.


페이지 내용이 도움이 되었습니까? | 아니요

AWS 지원 지식 센터로 돌아가기

도움이 필요하십니까? AWS 지원 센터를 방문하십시오.

게시 날짜: 2017-09-06

업데이트됨: 2018-11-20