

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# VPC Resolver 모범 사례
<a name="best-practices-resolver"></a>

이 섹션에서는 다음 주제를 다루는 Amazon Route 53 VPC Resolver 최적화 모범 사례를 제공합니다.

1. **Resolver 엔드포인트를 사용하여 루프 구성 방지:**
   + 동일한 VPC가 Resolver 규칙 및 인바운드 엔드포인트와 모두 연결되지 않게 하여 라우팅 루프를 방지합니다.
   +  AWS RAM 를 사용하여 계정 간에 VPCs 공유하는 동시에 적절한 라우팅 구성을 유지합니다.

   자세한 내용은 [Resolver 엔드포인트를 사용하여 루프 구성을 방지합니다.](best-practices-resolver-endpoints.md) 섹션을 참조하세요.

1. **Resolver 엔드포인트 크기 조정:**
   + 연결 상태를 기반으로 트래픽을 허용하는 보안 그룹 규칙을 구현하여 연결 추적 오버헤드를 줄입니다.
   + 인바운드 및 아웃바운드 Resolver 엔드포인트에 권장되는 보안 그룹 규칙을 준수하여 쿼리 처리량을 극대화합니다.
   + DNS 트래픽을 생성하는 고유한 IP 주소 및 포트 조합을 모니터링하여 용량 제한을 방지합니다.

   자세한 내용은 [Resolver 엔드포인트 크기 조정](best-practices-resolver-endpoint-scaling.md) 섹션을 참조하세요.

1. **Resolver 엔드포인트의 고가용성:**
   + 중복을 위해 두 개 이상의 가용 영역에 IP 주소를 사용하여 인바운드 엔드포인트를 구성합니다.
   + 추가 네트워크 인터페이스를 프로비저닝하여 유지 관리 또는 트래픽 급증 중에 가용성을 보장합니다.

   자세한 내용은 [Resolver 엔드포인트의 고가용성](best-practices-resolver-endpoint-high-availability.md) 섹션을 참조하세요.

1. **DNS 영역 보행 공격 방지:**
   + 공격자가 DNSSEC 서명 DNS 영역에서 모든 콘텐츠를 검색하려고 시도하는 잠재적 DNS 영역 보행 공격에 유의합니다.
   + 의심스러운 영역 걷기로 인해 엔드포인트가 제한되는 경우 AWS Support에 문의하여 지원을 받으세요.

   자세한 내용은 [DNS zone walking](best-practices-resolver-zone-walking.md) 섹션을 참조하세요.

 이러한 모범 사례를 따르면 VPC Resolver 배포의 성능, 확장성 및 보안을 최적화하여 애플리케이션 및 리소스에 대한 안정적이고 효율적인 DNS 확인을 보장할 수 있습니다.

# Resolver 엔드포인트를 사용하여 루프 구성을 방지합니다.
<a name="best-practices-resolver-endpoints"></a>

동일한 VPC를 (엔드포인트의 직접 대상이든, 온프레미스 DNS 서버를 통해서든) Resolver 규칙 및 인바운드 엔드포인트에 연결하지 마세요. Resolver 규칙의 아웃바운드 엔드포인트가 VPC를 규칙과 공유하는 인바운드 엔드포인트를 가리키면 쿼리가 인바운드 엔드포인트와 아웃바운드 엔드포인트 간에 지속적으로 전달되는 루프가 발생할 수 있습니다.

전달 규칙은 AWS Resource Access Manager ()를 사용하여 다른 VPCs와 계속 연결할 수 있습니다AWS RAM. 허브 또는 중앙 VPC와 연결된 프라이빗 호스팅 영역은 여전히 인바운드 엔드포인트에 대한 쿼리에서 해석됩니다. 해석기 전달 규칙이 이 해석을 변경하지 않기 때문입니다.

# Resolver 엔드포인트 크기 조정
<a name="best-practices-resolver-endpoint-scaling"></a>

Resolver 엔드포인트 보안 그룹은 연결 추적을 사용해 엔드포인트에서 송수신하는 트래픽에 대한 정보를 수집합니다. 각 엔드포인트 인터페이스에는 추적할 수 있는 최대 연결 수가 있으며 많은 양의 DNS 쿼리가 연결 수를 초과하면 제한 및 쿼리 손실이 발생할 수 있습니다. 연결 추적은 보안 그룹(SG)을 통해 흐르는 트래픽의 상태를 모니터링하기 위한 AWS기본 동작입니다.SGs SG에서 연결 추적을 사용하면 트래픽 처리량이 감소하지만 추적하지 않는 연결을 구현하여 오버헤드를 줄이고 성능을 개선할 수 있습니다. 자세한 내용은 [추적하지 않는 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)을 참조하세요.

제한적인 보안 그룹 규칙을 사용하여 연결 추적을 적용하거나 Network Load Balancer 통해 쿼리를 라우팅하는 경우([자동으로 추적하는 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking) 참조) 엔드포인트에 대한 IP 주소별 초당 전체 최대 쿼리는 최소 1,500개가 될 수 있습니다.

**인바운드 Resolver 엔드포인트에 대한 수신 및 송신 보안 그룹 규칙 권장 사항**


****  

| 
| 
| **수신 규칙** | 
| --- |
| 프로토콜 유형 | 포트 번호 | 소스 IP | 
| TCP  | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 
| **송신 규칙** | 
| --- |
| 프로토콜 유형 | 포트 번호 | 목적지 IP | 
| TCP | All | 0.0.0.0/0 | 
| UDP | All | 0.0.0.0/0 | 

**아웃바운드 Resolver 엔드포인트에 대한 수신 및 송신 보안 그룹 규칙 권장 사항**


****  

| 
| 
| **수신 규칙** | 
| --- |
| 프로토콜 유형 | 포트 번호 | 소스 IP | 
| TCP  | All | 0.0.0.0/0 | 
| UDP | All | 0.0.0.0/0 | 
| **송신 규칙** | 
| --- |
| 프로토콜 유형 | 포트 번호 | 목적지 IP | 
| TCP | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 

**참고**  
**보안 그룹 포트 요구 사항:**  
**인바운드 엔드포인트**에는 포트 53의 TCP 및 UDP가 네트워크에서 DNS 쿼리를 수신하도록 허용하는 수신 규칙이 필요합니다. 송신 규칙의 경우 엔드포인트가 다양한 소스 포트의 쿼리에 응답해야 할 수 있으므로 모든 포트를 허용할 수 있습니다.
**아웃바운드 규칙**에는 네트워크에서 DNS 쿼리에 사용하는 포트에 대해 TCP 및 UDP 액세스를 허용하는 송신 규칙이 필요합니다. 포트 53는 가장 일반적인 DNS 포트여서 위 예제에 제시되었지만 각 네트워크는 다른 포트를 사용할 수도 있습니다. 수신 규칙은 모든 포트가 DNS 서버의 응답을 수용하도록 허용할 수 있습니다.

**인바운드 Resolver 엔드포인트**

인바운드 Resolver 엔드포인트를 사용하는 클라이언트의 경우 DNS 트래픽을 생성하는 40,000개 이상의 고유 IP 주소 및 포트 조합이 있는 경우 탄력적 네트워크 인터페이스 용량에 영향을 미칩니다.

# Resolver 엔드포인트의 고가용성
<a name="best-practices-resolver-endpoint-high-availability"></a>

VPC Resolver 인바운드 엔드포인트를 생성할 때 Route 53에서는 네트워크의 DNS 해석기가 쿼리를 전달할 IP 주소를 두 개 이상 생성해야 합니다. 또한 중복성을 위해 가용 영역 2개 이상에서 IP 주소를 지정해야 합니다.

항상 둘 이상의 탄력적 네트워크 인터페이스 엔드포인트를 사용할 수 있어야 하는 경우 네트워크 인터페이스를 필요한 수보다 하나 더 생성하여 트래픽 급증 가능성에 대비할 수 있는 추가 용량을 확보하는 것이 좋습니다. 또한 추가 네트워크 인터페이스는 유지 관리 또는 업그레이드와 같은 서비스 운영 중에도 가용성을 보장합니다.

자세한 내용은이 자세한 블로그 문서인 [Resolver 엔드포인트 및를 사용하여 DNS 고가용성을 달성하는 방법을 참조하세요](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/)[인바운드 엔드포인트를 생성 또는 편집할 때 지정하는 값](resolver-forwarding-inbound-queries-values.md).

# DNS zone walking
<a name="best-practices-resolver-zone-walking"></a>

DNS zone walking 공격은 DNSSEC 서명 DNS 영역에서 모든 콘텐츠를 가져오려고 시도합니다. VPC Resolver 팀이 엔드포인트에서 DNS 영역이 확인될 때 생성된 트래픽 패턴과 일치하는 트래픽 패턴을 감지하면 서비스 팀은 엔드포인트의 트래픽을 제한합니다. 따라서 DNS 쿼리 시간 초과의 비율이 높아질 수 있습니다.

엔드포인트의 용량 감소를 목격하고 엔드포인트 제한이 잘못되었다고 생각하면 https://console.aws.amazon.com/support/home\$1/으로 이동하여 지원 사례를 만듭니다.