대기 시간 기반 리소스 레코드 및 Route 53 관련 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

Route 53에서는 다음과 같은 경우 DNS 쿼리 위치에 따라 대기 시간이 가장 짧은 리전으로 해결합니다.

• AWS 리전 여러 곳에 있는 엔드포인트를 동일한 리소스 레코드에 연결했습니다.
• 대기 시간 기반 라우팅 정책을 사용하고 있습니다.

Route 53에서는 다음을 기준으로 대기 시간 기반 라우팅을 결정합니다.

• Route 53 권한 있는 이름 서버로 쿼리를 보내는 재귀 DNS 해결 프로그램의 소스 IP 주소.
• 클라이언트 IP 주소의 잘린 버전(DNS 해결 프로그램이 확장 edns00-client-subnet을 지원하는 경우).

Route 53 네임 서버는 기본적으로 edns0-client-subnet을 지원합니다. 재귀 DNS 해결 프로그램이 edns0-client-subnet을 지원하는 경우 프로그램은 클라이언트 IP 주소의 잘린 버전을 Route 53으로 보냅니다. 그러면 Route 53에서 이 잘린 IP 주소를 사용해 대기 시간이 가장 짧은 리전을 결정합니다.

대기 시간이 가장 짧은 리전이라고 해서 DNS 해결 프로그램과 물리적으로 가장 가깝다는 뜻은 아닙니다. 클라이언트가 DNS 해결 프로그램과 위치가 다를 경우 원치 않는 라우팅 동작이 발생할 수 있습니다. 해결 프로그램의 IP 주소에 다른 위치 정보가 있는 경우에도 원치 않는 라우팅 동작이 발생할 수 있습니다.

예제 시나리오

한 회사가 버지니아(us-east-1)와 아일랜드(eu-west-1)에 Elastic Load Balancer에 대한 대기 시간 기반 라우팅 레코드를 각각 하나씩 갖고 있습니다. 미국에 있는 사용자는 유럽 기반 기업 DNS 해결 프로그램를 사용하거나 VPN을 통해 유럽에 있는 기업 사무실에 연결합니다.

기업 DNS 해결 프로그램은 권한 있는 네임 서버에 edns0-client-subnet 데이터를 보낼 수 없습니다. 따라서 Route 53은 유럽에 있는 DNS 해결 프로그램 IP 주소를 쿼리 소스로 간주합니다. 그런 다음 대기 시간 데이터베이스를 조회하여 아일랜드의 로드 밸런서가 대기 시간이 가장 낮다고 잘못 판단합니다.

회사 DNS 해결 프로그램이 edns0-client-subnet 데이터를 보낼 수 있는 경우에는 Route 53에서 미국에 있는 잘린 클라이언트 IP 주소를 쿼리 원본으로 간주합니다. 그런 다음 대기 시간 데이터베이스를 조회하여 버지니아에 있는 로드 밸런서가 대기 시간이 가장 짧다고 올바른 판단을 내립니다.

해결 방법

원치 않는 대기 시간 기반 라우팅 동작 문제를 해결하려면 다음 단계를 따르세요.

1. DNS 해결 프로그램이 사용하는 IP 주소 범위를 확인합니다. Linux 및 macOS을 사용하는 경우 dig 명령을 반복해서 실행합니다. Windows에서는 nslookup 명령을 여러 번 실행합니다. 매번 출력을 기록해 두세요.

Linux 또는 macOS을 사용하는 경우 dig 명령을 루프에서 실행합니다.

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

Windows에서는 nslookup 명령을 여러 번 실행합니다. 매번 출력을 기록해 두세요.

nslookup -type=txt o-o.myaddr.l.google.com

2. 이전 명령의 출력을 사용해 DNS 해결 프로그램이 애니캐스트를 지원하는지 확인합니다. 출력에 항상 동일한 단일 IP 주소가 포함되면 DNS 해결 프로그램이 애니캐스트를 지원하지 않는 것입니다. 명령을 여러 번 실행할 때 IP 주소가 변경되면 DNS 해결 프로그램이 애니캐스트를 지원하는 것입니다.

DNS 해결 프로그램이 애니캐스트를 지원하는 경우, DNS 해결 프로그램이 사용할 수 있는 에지 위치가 여럿 있습니다. 사용자의 에지 위치는 최적 대기 시간을 기준으로 선택되므로 해결 프로그램 IP 주소의 위치가 예기치 않게 변경될 수 있습니다.

3. 클라이언트 IP 주소를 찾습니다. 클라이언트 컴퓨터에서 인터넷 브라우저를 연 다음 https://checkip.amazonaws.com/로 이동합니다.

또는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 권한 있는 이름 서버로 보냅니다.

(선택 사항) 호스팅된 영역에서 Route 53 DNS 쿼리 로깅을 사용 설정한 경우 테스트 레코드를 만듭니다. 새 레코드에 대한 DNS 조회를 수행합니다. 쿼리 로그를 확인하여 Route 53 네임 서버에 표시된 해결 프로그램 IP 주소 및 edns0-client-subnet(있는 경우)을 확인합니다.

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

7. Route 53 DNS 검사 도구에 액세스할 수 있는 경우 특정 DNS 해결 프로그램 또는 클라이언트 IP 주소에서 쿼리를 시뮬레이션합니다. 이러한 쿼리를 사용해 Route 53이 반환하는 대기 시간 리소스 레코드 세트를 찾습니다.

DNS 해결 프로그램이 edns0-client-subnet을 지원하지 않는 경우 도구에서 해결 프로그램 IP 주소를 값으로 지정합니다.

DNS 해결 프로그램이 edns0-client-subnet을 지원하는 경우 도구에서 EDNS0 클라이언트 서브넷 IP를 값으로 지정합니다. 추가 구성을 선택한 다음 서브넷 마스크를 지정합니다.

**참고:**Route 53 DNS 검사 도구는 Route 53 대기 시간 측정 데이터베이스를 직접 쿼리합니다. 이 쿼리는 AWS 리전과 인터넷 기반 네트워크 간의 미리 계산된 대기 시간을 결정합니다. 이 도구는 인터넷이나 DNS 해결 프로그램을 통해 DNS 쿼리를 보내지 않습니다. 이 도구는 DNS 해결 프로그램이 edns0-client-subnet을 지원하는지 확인하지 않습니다. 도구에서 나타난 결과와 실제 DNS 쿼리는 다를 수 있습니다.

8. (선택 사항) Route 53 DNS 확인 도구에 액세스할 수 없는 경우 dig를 사용합니다. dig를 사용하여 호스팅된 영역의 Route 53 권한 이름 서버를 edns0-client-subnet으로 쿼리합니다. 출력을 사용하여 소스 IP 주소에서 대기 시간이 가장 짧은 리전을 확인합니다.

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

참고: 인터넷에서 호스트 간의 대기 시간은 네트워크 연결 및 라우팅의 변경으로 인해 시간이 지남에 따라 변경될 수 있습니다. 예를 들어, 이번 주에 오레곤 리전으로 라우팅된 요청이 다음 주에는 오하이오 리전으로 라우팅될 수 있습니다.

9.    edns0-client-subnet을 지원하지 않는 해결 프로그램의 경우: 클라이언트의 DNS 해결 프로그램을 클라이언트와 지리적으로 더 가까운 다른 재귀 DNS 해결 프로그램으로 변경합니다. 해결 프로그램이 edns0-client-subnet을 지원하지 않는 경우 클라이언트 DNS 쿼리에서 클라이언트와 지리적으로 다른 위치에 있는 DNS 해결 프로그램을 사용할 수 있습니다. 이 경우 예기치 않은 라우팅 동작이 발생할 수 있습니다.

DNS 해결 프로그램을 직접 관리하고 있는 경우 전달 구성을 확인하세요. 클라이언트가 지리적으로 위치하는 곳에서 멀리 떨어진 다른 해결 프로그램으로 DNS 쿼리를 전달하고 있지 않은지 확인합니다.

**edns0-client-subnet을 지원하는 해결 프로그램의 경우:**클라이언트 서브넷 IP 주소의 지리적 위치를 확인합니다. 위치를 확인하려면 MaxMind 웹사이트의 GeoIP 데이터베이스 또는 선호하는 GeoIP 데이터베이스를 사용합니다. 클라이언트 서브넷 IP 주소의 위치가 클라이언트와 다른 지리적 위치에 있는 경우 예기치 않은 라우팅 동작이 발생할 수 있습니다.

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) 두 개가 있습니다.

11. (선택 사항) 대기 시간 기반 라우팅 레코드가 Route 53 상태 검사와 연결되어 있는지 확인합니다. 그리고 대상 상태 평가(ETH)가 켜져 있는지 확인합니다(별칭 레코드의 경우). 둘 중 하나 또는 둘 다 참이면 Route 53은 대기 시간이 가장 짧은 정상 엔드포인트를 반환합니다. 상태 확인에 모두 실패하면 라우팅 정책만 고려됩니다.

Route 53 콘솔에서 Route 53 상태 점검 상태를 확인합니다. ETH가 켜져 있는 경우 레코드 엔드포인트의 상태를 확인합니다. Route 53은 하나 이상의 백엔드 인스턴스가 정상인 경우 ETH가 켜져 있는 Classic Load Balancer의 엔드포인트가 정상인 것으로 간주합니다. Application Load Balancer 및 Network Load Balancer의 경우, 정상으로 간주되려면 대상이 있는 모든 대상 그룹에 정상 대상이 하나 이상 포함되어 있어야 합니다. 등록된 대상이 없는 대상 그룹은 정상적이지 않은 것으로 간주됩니다. 대상 그룹에 정상적이지 않은 대상만 포함된 경우 해당 부하 분산 장치는 정상적이지 않은 것으로 간주됩니다.

예외: 애플리케이션 부하 분산 장치에 정상 대상 그룹이 하나 이상 있고 나머지 대상 그룹이 모두 비어 있는 경우 Route 53은 정상으로 간주합니다.

예시

Route 53 상태 검사와 연결된 대기 시간 기반 라우팅 레코드가 두 개 있는데, 하나는 오레곤에 있고 다른 하나는 노스버지니아에 있습니다. 오레곤 엔드포인트의 상태 확인에 실패하면 클라이언트의 위치에 관계없이 모든 요청이 노스 버지니아 엔드포인트로 라우팅됩니다.

관련 정보

Route 53에서 DNS 응답 확인

공용 DNS 해결 프로그램이 EDNS 클라이언트 서브넷 확장을 지원하는지 확인하려면 어떻게 해야 하나요?

Route 53 상태 검사에서 비정상이 나타나는 문제를 해결하려면 어떻게 해야 하나요?

“대상 상태 평가”를 사용할 때 Application Load Balancer를 가리키는 별칭 레코드가 비정상으로 표시되는 이유는 무엇인가요?