일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- MSCS on VMWare
- Nested VM
- nonpaged pool
- failover cluster
- 안철수
- dsquery
- Xperf
- ftp7.5 장애조치 클러스터
- FTP7.5
- paged pool
- LiveKD
- Windows Server 2008
- windbg
- windows debugging tool
- SQL Server 2008
- Session space
- 클러스터
- Local TempDB
- windows update
- iSCSI target
- Windows Server 2016 Hyper-v Cluster
- 작업관리자
- 프로세스 CPU 사용량
- 인문고전
- SQL Server 2012R2 FCI
- 터키여행
- windows media service
- Hyper-V
- Windows Server 2016
- cluster node as Domain controller
- Today
- Total
류짱:Beyond MySelf
DNS 클라이언트 쿼리 요청 소요 시간 및 실행 과정 본문
Windows Server( Client 포함)의 경우 이미 알고 계신 것처럼 해당 서버에 설치 된 네트워크 카드의 TCP / IP 등록 정보를 통해 설정 된 Preferred DNS server와 Alternate DNS server 를 통해 네임 쿼리를 실행 합니다.
Preferred DNS server에 네임 쿼리를 시도하고 서버가 응답이 없을 경우 Alternate DNS server통해 네임 쿼리를 시도 하며, 시도 간격은 1초 입니다.
DNS Client service가 Name Query를 하는 순서는 아래와 같습니다.
1 . The DNS Client service sends the name query to the first DNS server on the preferred adapter’s list of DNSservers and waits one second for a response.
DNS Client 서비스가 네트워크 어뎁터로 설정 된 첫 번째 DNS server 로 Name Query를 보내고 1초 간 기다립니다.
2. If the DNS Client service does not receive a response from the first DNS server within one second, it sends the name query to the first DNS servers on all adapters that are still under consideration and waits two seconds for a response.DNS client
서비스가 첫 번 째 dns 서버로부터 1초 이내에 응답을 받지 못하면 다른 모든 네트워크 아답터에 설정 된 첫 번째 DNS server로 부터의 응답을 2초간 기다립니다.
3. If the DNS Client service does not receive a response from any DNS server within two seconds, the DNS Client service sends the query to all DNS servers on all adapters that are still under consideration and waits another two seconds for a response.
네트워크 아답터에 설정 된 또 다른 DNS server로부터 응답을 2초 이내에 받지 못하면 다른 DNS server로부터 응답을 기다립니다.
DNS 클라이언트는 프로그램에 사용된 이름을 조회할 때 DNS 서버에 쿼리하여 이름을 확인합니다. 클라이언트가 전송하는 각 쿼리 메시지에는 서버에게 응답을 요구하는 아래와 같은 세 가지 정보가 포함되어 있습니다.
- FQDN(정규화된 도메인 이름)으로 표시되는 지정된 DNS 도메인 이름
- 형식별로 또는 쿼리 동작의 특정 형식별로 리소스 레코드를 지정할 수 있는 지정된 쿼리 형식
- DNS 도메인 이름에 지정된 클래스
Windows DNS 서버에서 이 클래스는 항상 인터넷(IN) 클래스로 지정되어야 합니다.
예를 들어, 지정된 이름은 "host-a.example.microsoft.com"과 같이 컴퓨터의 FQDN일 수 있으며 쿼리 형식은 그 이름으로 A(주소) 리소스 레코드를 찾도록 지정될 수 있습니다. DNS 쿼리는 클라이언트가 서버에게 "이름이 'hostname.example.microsoft.com'인 컴퓨터의 A 리소스 레코드가 있습니까?"와 같은 두 부분으로 이루어진 질문을 하는 것과 같습니다. 클라이언트는 서버에서 응답을 받으면 반환된 A 리소스 레코드를 읽고 해석하여, 이름을 사용하여 물어본 컴퓨터의 IP 주소를 확인합니다.
DNS 쿼리에서 이름을 확인하는 방법은 다양합니다. 때때로 클라이언트는 이전 쿼리에서 얻어 캐시에 보관한 정보를 사용하여 로컬에서 쿼리에 응답할 수 있습니다. DNS 서버는 자신의 리소스 레코드 정보 캐시를 사용하여 쿼리에 응답할 수 있습니다. 또한 DNS 서버는 요청 클라이언트를 대신하여 다른 DNS 서버에 쿼리하거나 연결하고 이름을 완전히 확인한 다음 클라이언트에 응답을 반환할 수 있습니다. 이 프로세스를 재귀라고 합니다.
또한 이름 확인을 위해 클라이언트 자신이 추가로 다른 DNS 서버에 연결을 시도할 수 있습니다. 이 때 클라이언트는 서버가 보낸 조회 응답에 기반하여 별도의 추가 쿼리를 사용합니다. 이 프로세스를 반복이라고 합니다.
일반적으로 DNS 쿼리 프로세스는 아래와 같은 두 부분으로 수행됩니다.
- 이름 쿼리는 클라이언트 컴퓨터에서 시작되고 이름 확인을 위해 확인자인 DNS 클라이언트 서비스로 전달됩니다.
- 쿼리가 로컬에서 확인되지 않으면 필요에 따라 이름 확인을 위해 DNS 서버로 쿼리를 보낼 수 있습니다.
이 두 프로세스를 아래 절에서 자세히 설명합니다.
1절: 로컬 확인자
쿼리 프로세스의 초기 단계에 나온 것처럼 로컬 컴퓨터의 프로그램(hosts file)에서 DNS 도메인 이름을 사용합니다.
다음에는 로컬 캐시(DNS Resolver cache)에 저장된 정보를 사용하여 이름을 확인하기 위해 DNS 클라이언트 서비스로 요청이 전달됩니다. 쿼리된 이름이 확인되면 쿼리가 해결되고 프로세스가 완료됩니다.
로컬 확인자 캐시에는 아래와 같은 소스로부터 얻은 이름 정보가 포함될 수 있습니다.
- Hosts 파일이 로컬로 구성되어 있으면 DNS 클라이언트 서비스가 시작될 때 그 파일의 호스트 이름 대 주소 매핑이 캐시로 미리 로드됩니다.
- 이전 DNS 쿼리에서 반환된 응답에서 얻은 리소스 레코드는 캐시에 추가되어 일정 기간 보존됩니다.
쿼리가 캐시에 있는 항목에 일치하지 않으면 클라이언트가 이름 확인을 위해 DNS 서버로 쿼리를 보내어 이름 확인 프로세스가 계속됩니다.
2절: DNS 서버 조회
위 그림에서와 같이 클라이언트는 기본 설정 DNS 서버에 쿼리합니다. 이 프로세스에서 초기의 클라이언트/서버 쿼리 동안 사용되는 실제 서버는 글로벌 목록에서 선택됩니다. 이 글로벌 목록이 컴파일되고 업데이트되는 방법에 대한 자세한 내용은 클라이언트 기능을 참조하십시오.
쿼리를 받은 후 DNS 서버는 먼저 서버에 로컬로 구성된 영역에 포함되어 있는 리소스 레코드 정보에 기반하여 쿼리에 신뢰할 수 있게 응답할 수 있는지의 여부를 확인합니다. 쿼리된 이름이 로컬 영역 정보에 있는 해당 리소스 레코드와 일치하면 서버는 이 정보를 사용하여 쿼리된 이름을 확인하는 방법으로 신뢰할 수 있게 응답합니다.
쿼리된 이름에 대한 영역 정보가 없으면 서버는 이전 쿼리에서 얻어 로컬 캐시에 저장한 정보를 사용하여 이름을 확인할 수 있는지 검사합니다. 일치하는 정보가 있으면 이 정보를 사용하여 응답합니다. 마찬가지로 기본 설정 서버가 자신의 캐시를 사용하여 일치하는 긍정 응답을 요청 클라이언트에 반환할 수 있으면 쿼리가 완료됩니다.
쿼리된 이름에 대해 기본 설정 서버의 캐시 또는 영역 정보에서 일치하는 응답을 찾지 못하면 이름을 완전히 확인하기 위해 재귀를 사용하여 쿼리 프로세스가 계속될 수 있습니다. 이 때 다른 DNS 서버가 이름 확인을 돕습니다.
기본적으로 DNS 클라이언트 서비스는 응답을 반환하기 전에 클라이언트를 대신하여 이름을 완전히 확인하는 재귀 프로세스를 사용하도록 서버에 요청합니다. 아래 그림과 같이, 대부분의 경우 DNS 서버는 기본적으로 재귀 프로세스를 지원하도록 구성됩니다
DNS 서버가 제대로 재귀를 수행하기 위해서는 먼저 DNS 도메인 네임스페이스에 있는 다른 DNS 서버에 대한 유용한 연결 정보가 필요합니다. 이 정보는 루트 힌트 형태로 제공됩니다. 루트 힌트란 DNS 서비스가 DNS 도메인 네임스페이스 트리의 루트에 대해 권한을 가진 다른 DNS 서버를 찾을 때 사용할 수 있는 예비 리소스 레코드 목록입니다.
루트 서버는 DNS 도메인 네임스페이스 트리의 도메인 루트 및 최상위 도메인에 대해 권한을 갖습니다. 자세한 내용은 루트 힌트 업데이트를 참조하십시오.
DNS 서버는 루트 힌트를 사용하여 루트 서버를 찾은 다음 재귀 사용을 완료할 수 있습니다. 이론적으로 DNS 서버는 이 프로세스를 통해 네임스페이스 트리의 모든 수준에서 사용되는 다른 DNS 도메인 이름에 대한 권한을 가진 서버를 찾을 수 있습니다.
예를 들어, 클라이언트가 단일 DNS 서버로 쿼리할 때 "host-b.example.microsoft.com"이라는 이름을 찾기 위해 재귀 프로세스를 사용하는 경우를 가정합니다. DNS 서버와 클라이언트가 처음 시작되었고 로컬 캐시에 이름 쿼리를 확인에 사용할 수 있는 정보가 없으면 이 프로세스가 수행됩니다. 이 프로세스에서는 서버에 구성되어 있는 영역에 기반하여 서버 자신이 로컬 정보를 갖고 있지 않은 도메인 이름을 클라이언트가 쿼리했다고 가정합니다.
먼저, 기본 설정 서버는 전체 이름을 분석하고 최상위 도메인인 "com"에 대한 권한을 가진 서버를 찾아야 한다고 결정합니다. 그런 다음 "com" DNS 서버에 대한 반복 쿼리를 사용하여 "microsoft.com" 서버에 대한 조회를 얻습니다. 그 다음에 "microsoft.com" 서버에서 "example.microsoft.com"의 DNS 서버로 조회 응답이 전달됩니다.
마지막으로 "example.microsoft.com" 서버에 연결됩니다. 이 서버에 구성된 영역에는 쿼리된 이름이 포함되어 있으므로 이 서버는 재귀를 시작한 원래 서버에게 신뢰할 수 있는 응답을 보냅니다. 요청한 쿼리에 대해 신뢰할 수 있는 결과를 얻었다는 응답을 받은 후, 원래 서버가 이 응답을 요청 클라이언트로 전달하면 재귀 쿼리 프로세스가 완료됩니다.
재귀 쿼리 프로세스는 위에서 설명한 대로 수행될 때 리소스를 많이 소비하지만 반면에 DNS 서버 성능을 높이는 이점이 있습니다. 예를 들어, 재귀 조회를 수행하는 DNS 서버는 재귀 프로세스 중에 DNS 도메인 네임스페이스에 대한 정보를 얻습니다. 서버는 이 정보를 캐시에 보관하여 이후로 이 정보와 일치하는 쿼리나 이 정보를 사용하는 쿼리의 응답 속도를 높일 수 있습니다. 이렇게 캐시에 보관되는 정보는 DNS 서비스가 설정되고 해제될 때마다 지워지기는 하지만 시간이 지남에 따라 서버 메모리 리소스의 상당 부분을 차지할 장도로 커질 수 있습니다.
DNS 서버는 재귀나 반복을 사용하여 클라이언트 쿼리를 처리하기 때문에 DNS 네임스페이스 정보를 포함한 저장을 상당수 발견하고 가져옵니다. 그리고 나면 서버가 이 정보를 캐시합니다.
캐시를 사용하면 자주 사용되는 이름의 다음 쿼리에 대한 DNS 확인 속도를 높이면서 네트워크의 DNS 관련 쿼리 트래픽을 상당량 줄일 수 있습니다.
DNS 서버는 클라이언트를 대신하여 재귀 쿼리를 수행할 때 캐시 RR(리소스 레코드)을 임시로 캐시합니다. 캐싱된 RR에는 클라이언트 대신 수행한 재귀 쿼리를 검색하고 이 쿼리에 완전히 응답하기 위해 반복 쿼리를 수행하는 중에 확인한 DNS 도메인 이름에 대한 권한이 있는 DNS 서버에서 가져온 정보가 포함됩니다. 다음에 다른 클라이언트가 캐싱된 RR에 일치하는 RR 정보를 요청하는 새 쿼리를 수행하면 DNS 서버는 캐싱된 RR 정보를 사용하여 여기에 응답할 수 있습니다.
정보가 캐시되면 모든 캐싱된 RR에 TTL(Time-To-Live) 값이 적용됩니다. 캐싱된 RR의 TTL이 만료되지 않은 한 이 RR에 일치하는 클라이언트의 쿼리에 응답할 때 DNS 서버는 계속 RR을 캐시하여 다시 사용할 수 있습니다. 대부분의 영역 구성에서 RR이 사용하는 캐시 TTL 값에는 영역의 SOA(권한 시작) 리소스 레코드에서 사용되도록 설정된 최소(기본) TTL이 지정됩니다. 기본적으로 최소 TTL은 3,600초(1시간)지만 조정이 가능하며 필요하면 각 RR에 개별 캐시 TTL을 설정할 수 있습니다.
참고
- DNS 서버를 캐시 전용 서버로 설치할 수 있습니다. 자세한 내용은 캐싱 전용 서버 사용을 참조하십시오.
- 기본적으로 DNS 서버는 서버 컴퓨터의 systemroot\System32\Dns 폴더에 저장되어 있는 Cache.dns라는 루트 힌트 파일을 사용합니다. 이 파일의 내용은 서비스가 시작될 때 서버 메모리로 미리 로드되며 DNS 서버가 작동되는 DNS 네임스페이스의 루트 서버에 대한 포인터 정보를 포함합니다. 이 파일 또는 이 파일 사용 방법에 대한 자세한 내용은 DNS 관련 파일을 참조하십시오.
[ DNS 쿼리 실행 방법 ]