NET: DNS: 전달자 및 조건부 전달자 확인 시간 제한
이 문서에서는 하나 이상의 DNS 서버 IP가 DNS 서버에서 전달자 또는 조건부 전달자로 구성된 경우 발생하는 대체 및 시간 제한 동작에 대해 설명합니다.
적용 대상: Windows Server 2012 R2
원래 KB 번호: 2834250
요약
DNS 클라이언트 확인 시간 제한에 대한 자세한 내용은 NET: DNS: DNS 클라이언트 확인 시간 제한을 확인합니다.
DNS 클라이언트와 마찬가지로 둘 이상의 전달자 또는 조건부 전달자를 사용하여 DNS 서버를 구성하면 DNS 인프라에 내결함성이 추가됩니다. 여러 DNS 서버를 전달자 또는 조건부 전달자로 추가하면 구성된 유일한 서버, 기본 네트워크 링크 또는 지원 네트워크 인프라가 실패하는 경우 DNS 이름을 계속 확인할 수 있습니다.
그러나 일부 서버가 현재 매달려 있는 복수의 클라이언트를 대신하여 수행하는 전이적 작업이 있을 수 있으므로 서버에 내결함성을 추가하는 것이 훨씬 더 중요합니다. 그런 다음 리소스가 증분적으로 더 긴 시간 동안 소비됩니다.
3개 이상의 전달자/조건부 전달자를 사용하려는 경우 기본 설정이 많은 서버에 최적화되지 않을 수 있으므로 매개 변수를 올바르게 조정해야 합니다.
두 개 이상의 DNS 서버가 전달자로 구성된 경우 DNS 서버의 기본 동작은 무엇인가?
이 작동 방식을 이해하기 위해 주요 변수는 다음과 같습니다.
RecursionTimeout - DNS(도메인 이름 시스템)가 검색을 종료하기 전에 원격 서버가 재귀 클라이언트 쿼리에 응답할 때까지 대기하는 시간입니다.
레지스트리의 , 및 구성 가능한
via dnscmd /config /RecursionTimeout <value>에 저장HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\**RecursionTimeout됩니다.기본값은 다음과 같습니다.
Windows Server 2003에서 15초
Windows Server 2008, 2008 R2 및 2012에서 8초
RecursionTimeout은 DNS 서버 수준에서 정의되며 쿼리된 특정 영역과 독립적입니다.
ForwardingTimeout - DNS(도메인 이름 시스템)가 전달자의 목록에 있는 각 서버가 쿼리에 응답할 때까지 대기하는 시간입니다.
아래의 레지스트리
HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\**ForwardingTimeout에 저장되고 를 통해dnscmd /config /ForwardingTimeout <value>구성할 수 있습니다.기본값은 다음과 같습니다.
Windows Server 2003에서 5초
Windows Server 2008, 2008R2 및 2012에서 3초
ForwardingTimeout은 DNS 서버 수준에서 정의되며 쿼리된 특정 영역과 독립적입니다.
DNS 서버가 신뢰할 수 없는 영역의 레코드에 대한 쿼리를 수신하고 전달자를 사용해야 하는 경우 기본 동작은 다음과 같습니다.
| 시간(시작 후 초) | 작업 |
|---|---|
| 0 | 클라이언트는 DNS 서버를 쿼리합니다. DNS 서버는 쿼리를 첫 번째 전달자에게 즉시 전달합니다. |
| <forwarding_timeout> | forwarding_timeout> 초 후 <첫 번째 전달자가 회신하지 않으면 DNS 서버는 두 번째 전달자를 쿼리합니다. |
| 2 * <forwarding_timeout> +1 | +1을 더 forwarding_timeout> 후 <두 번째 전달자가 회신하지 않으면 DNS 서버는 세 번째 전달자를 쿼리합니다. |
| ... | ... |
| N * <forwarding_timeout> +(N-1) | <forwarding_timeout> + 1초 후 N번째 전달자가 회신하지 않으면 DNS 서버는 (N+1) 전달자를 쿼리합니다. |
참고
구성된 지연 외에도 시스템 오버헤드로 인해 추가 반초 지연이 있을 수 있습니다.
경과된 시간이 RecursionTimeout 값을 초과하면 알고리즘이 중지됩니다.
RecursionTimeout이 만료되면 DNS 서버가 서버 오류로 클라이언트에 다시 회신합니다.
참고
RecursionTimeout 만료 직후에 서버 오류를 보내지 않고 다음 전달자를 시도할 때에만 전송됩니다.
응답 없이 RecursionTimeout이 만료되기 전에 서버가 모든 전달자에게 연결하도록 관리하는 경우 이름 확인에 루트 힌트를 사용하려고 합니다(서버 수준에서 재귀를 사용하지 않도록 설정하지 않은 경우 기본 설정).
즉, 기본 설정을 사용하면 2008R2 서버가 최대 3명의 전달자를 쿼리할 수 있습니다. 네 번째 전달자를 사용하기에 충분한 시간이 없습니다. 실제로 2008R2의 기본 설정으로 서버는 다음을 수행합니다.
- 0초 후 첫 번째 전달자 쿼리
- 3.5초 후 두 번째 전달자 쿼리
- 3.5 + 4 = 7.5초 후 세 번째 전달자 쿼리
8번째 초에 RecursionTimeout 이 만료되므로 네 번째 전달자가 쿼리되는 지점에 도달하지 않습니다(3.5 + 4 + 4 = 11.5초 후에 발생함).
11.5초 후에 서버 오류 응답을 보냅니다.
예:
IP 주소가 192.168.0.1인 DNS 서버는 5개의 전달자(10.0.0.1-10.0.0.5)로 구성됩니다.
클라이언트의 IP 주소가 10.0.0.31이고 를 쿼리하고 있습니다. Microsoft.com
네트워크 캡처에서 다음 네트워크 모니터 출력이 표시됩니다(참고 10.0.0.4 및 10.0.0.5는 쿼리되지 않습니다.).
시간 오프셋 TimeDelta 원본 대상 세부 정보
6:33:51.7507293 0.2731738 0.0000000 10.0.0.31 192.168.0.1 DNS:QueryId = 0xF03, QUERY(표준 쿼리), 클래스 인터넷에서 호스트 추가기 유형 쿼리microsoft.com
6:33:51.7510021 0.2734466 0.0002728 192.168.0.1 10.0.0.1 DNS:QueryId = 0xBD57, QUERY(표준 쿼리), 클래스 인터넷의 호스트 추가기 유형 쿼리microsoft.com
6:33:55.2997074 3.8221519 3.5487053 192.168.0.1 10.0.0.2 DNS:QueryId = 0xBD57, QUERY(표준 쿼리), 클래스 인터넷의 호스트 추가기 유형 쿼리microsoft.com
6:33:59.2931644 7.8156089 3.9934570 192.168.0.1 10.0.0.3 DNS:QueryId = 0xBD57, QUERY(표준 쿼리), 클래스 인터넷의 호스트 추가기 유형 쿼리microsoft.com
6:34:03.3112753 11.8337198 4.0181109 192.168.0.1 1 10.0.0.31 DNS:QueryId = 0xF03, QUERY(표준 쿼리), 응답 - 서버 오류
두 개 이상의 DNS 서버가 조건부 전달자로 구성된 경우 DNS 서버의 기본 동작은 무엇인가?
전달자와 마찬가지로 조건부 전달자에 대한 두 가지 주요 변수가 있습니다. 여전히 RecursionTimeout (서버 수준에서 작동)이 있지만 이 시나리오에서는 ForwardingTimeout 대신 ForwarderTimeout 을 사용합니다. 특히 ForwarderTimeout 은 영역별로 작동하며 기본값이 다릅니다.
RecursionTimeout - DNS(도메인 이름 시스템)가 검색을 종료하기 전에 원격 서버가 재귀 클라이언트 쿼리에 응답할 때까지 대기하는 시간입니다.
아래의 레지스트리에 저장됩니다.
HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\RecursionTimeout를 통해
dnscmd /config /RecursionTimeout <value>구성할 수 있습니다.기본값은 다음과 같습니다.
Windows Server 2003에서 15초
Windows Server 2008 및 2008R2에서 8초
RecursionTimeout은 DNS 서버 수준에서 정의되며 쿼리된 특정 영역과 독립적입니다.
ForwarderTimeout - DNS(도메인 이름 시스템)가 조건부 전달자 목록의 각 서버가 쿼리에 응답할 때까지 대기하는 시간입니다.
조건부 전달자는 특정 영역에 대해 구성되므로 ForwarderTimeout 도 영역에 따라 달라집니다.
아래의 레지스트리
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\ <zone_name>\ForwarderTimeout에 저장됩니다.기본값은 Windows Server 2003, 2008, 2008R2 및 2012에서 5초입니다.
조건부 전달자 GUI에서 볼 수 있는 설정이기도 합니다.
DNS 서버가 신뢰할 수 없는 영역의 레코드에 대한 쿼리를 수신하고 조건부 전달자를 사용하도록 구성된 경우 기본 동작은 다음과 같습니다.
| 시간(시작 후 초) | 작업 |
|---|---|
| 0 | 클라이언트는 DNS 서버를 쿼리합니다. DNS 서버는 쿼리를 첫 번째 조건부 전달자에게 즉시 전달합니다. |
| <forwarder_timeout> | forwarder_timeout> 초 후 <첫 번째 조건부 전달자가 회신하지 않으면 DNS 서버는 두 번째 조건부 전달자를 쿼리합니다. |
| 2 * <forwarder_timeout> +1 | +>1초 forwarder_timeout 후 <두 번째 조건부 전달자가 회신하지 않으면 DNS 서버는 세 번째 조건부 전달자를 쿼리합니다. |
| ... | ... |
| N * <forwarder_timeout> +(N-1) | <+>1초 forwarder_timeout 후 N번째 조건부 전달자가 회신하지 않으면 DNS 서버는 (N+1)th 조건부 전달자를 쿼리합니다. |
참고
구성된 지연 외에도 시스템 오버헤드로 인해 추가 반초 지연이 있을 수 있습니다.
경과된 시간이 RecursionTimeout 값을 초과하면 알고리즘이 중지됩니다.
RecursionTimeout이 만료되면 DNS 서버가 서버 오류로 클라이언트에 다시 회신합니다.
참고
RecursionTimeout 만료 직후에 서버 오류를 보내지 않고 다음 조건부 전달자를 시도할 때에만 전송됩니다.
즉, 기본 설정을 사용하면 2008 R2 서버가 최대 2명의 조건부 전달자를 쿼리할 수 있습니다. 세 번째 조건부 전달자를 사용하기에 충분한 시간이 없습니다. 실제로 2008R2의 기본 설정으로 서버는 다음을 수행합니다.
- 0초 후 첫 번째 전달자 쿼리
- 5.5초 후 두 번째 전달자 쿼리
8번째 초에 RecursionTimeout 이 만료되므로 세 번째 조건부 전달자가 쿼리되는 지점에 도달하지 않습니다(5.5 + 6 = 11.5초 후에 발생함).
11.5초 후에 서버 오류 응답을 보냅니다.
예:
IP 주소가 192.168.0.1인 DNS 서버는 영역에 Microsoft.com대해 5개의 조건부 전달자(10.0.0.1-10.0.0.5)로 구성됩니다.
클라이언트는 IP 주소 10.0.0.31을 가지고 있으며 를 쿼리하고 있습니다 Microsoft.com.
네트워크 캡처에서 다음 네트워크 모니터 출력이 표시됩니다(참고 10.0.0.3, 10.0.0.4 및 10.0.0.5는 쿼리되지 않습니다.).
시간 오프셋 TimeDelta 원본 대상 세부 정보
6:50:32.5481816 0.4306857 0.0000000 10.0.0.33 192.168.0.1 DNS:QueryId = 0x245A, QUERY(표준 쿼리),microsoft.com클래스 인터넷의 호스트 추가기 유형 쿼리
6:50:32.5484341 0.4309382 0.0002525 192.168.0.1 10.0.0.1 DNS:QueryId = 0x252B, QUERY(표준 쿼리), 클래스 인터넷의 호스트 추가기 유형 쿼리microsoft.com
6:50:38.1695163 6.0520204 5.6210822 192.168.0.1 10.0.0.2 DNS:QueryId = 0x252B, QUERY(표준 쿼리), 클래스 인터넷의 호스트 추가기 유형 쿼리microsoft.com
6:50:44.1856567 12.0681608 6.0161404 192.168.0.1 10.0.0.33 DNS:QueryId = 0x245A, QUERY(표준 쿼리), 응답 - 서버 오류
참조
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기