AD/DNS

1) AD가 DNS에 의존하는 이유는?

A. 도메인 컨트롤러(DC)는 부팅/역할 유지 중 Netlogon이 A/SRV 레코드를 DNS에 등록합니다. 클라이언트는 _ldap._tcp.dc._msdcs.<도메인> 등에 질의해 DC 목록을 얻고, 이어 LDAP(UDP) ping으로 응답 가능성을 확인한 뒤 Netlogon 캐시에 보관합니다. 이 전체 DC Locator 절차가 DNS를 전제하기 때문에 DNS가 불안하면 인증·복제·GC 조회가 모두 흔들립니다.

2) DC가 등록하는 레코드와 등록 트리거는?

A. 예: phoenix.contoso.com A, _ldap._tcp.contoso.com SRV, _kerberos._tcp.dc._msdcs.contoso.com SRV 등. 등록은 IP 변경/갱신, 부팅, ipconfig /registerdns, DC 승격 같은 이벤트에 의해 촉발되고, 실제 업데이트 전송은 DHCP Client 서비스가 담당합니다(비DHCP 환경에도 동작).

3) _msdcs 서브도메인의 역할은?

A. 도메인/포리스트 전체에서 DC/GC/PDC/도메인(GUID) 등 역할 기반 탐색을 위한 SRV/CNAME 집합을 보관합니다. 특히 **포리스트 루트의 _msdcs**는 모든 DC가 등록·조회해야 하므로 가용성·복제 범위가 매우 중요합니다.

4) 왜 _msdcs.forest_root_domain을 별도 존으로?

A. 모든 DC가 복제·GC 조회에 필요로 하는 포리스트 전역 레코드를 안정적으로 제공하기 위해서입니다. 권장 구성은 _msdcs.forest_root_domain을 ForestDNSZones 범위로 분리·복제하는 것입니다.

5) DC Locator 단계별 상세

A. (1) 클라이언트가 Netlogon RPC(DsGetDcName) 호출 → (2) DNS에 SRV/A 질의 → (3) 응답 DC들에 LDAP UDP ping → (4) 가장 먼저 응답한 DC를 선택 → (5) 캐싱으로 후속 요청 성능/일관성 확보.

6) “가까운 사이트” 선호는 어떻게 판단?

A. AD 사이트/서브넷 정보로 Closest Site를 계산합니다. 해당 사이트에 DC가 없으면 자동 사이트 커버리지(Automatic Site Coverage) 로 인접 사이트 DC가 해당 사이트의 site-SRV를 등록해 커버합니다(링크 비용 기반).

7) 자동 사이트 커버리지 알고리즘

A. (1) 대상 사이트(DC 없음) 목록 산출 → (2) 후보 사이트(해당 도메인 DC 존재) 목록 → (3) 최저 사이트링크 비용 후보만 남김 → (4) 동률이면 DC 수가 많은 사이트, 그래도 동률이면 알파벳 순 → (5) 선정된 사이트의 DC가 타깃 사이트용 SRV를 등록.

8) “DC 끈적임(Stickiness)” 줄이는 법

A. Netlogon 캐시로 일관성은 좋아지지만, 오래 같은 DC만 쓰는 현상이 생길 수 있습니다. 이때 Force Rediscovery Interval 정책(기본 미구성, 활성 시 12시간(43200초), 최소 1시간)을 통해 재탐색 주기를 강제할 수 있습니다. 필요 시 API 호출에 DS_FORCE_REDISCOVERY 플래그도 사용합니다.

9) DsGetDcName 주요 FLAGS 용도

DS_GC_SERVER_REQUIRED: 반드시 GC 반환(포리스트 이름 필요)
DS_FORCE_REDISCOVERY: 캐시 무시하고 새 탐색
DS_DIRECTORY_SERVICE_REQUIRED/…PREFERRED: AD DS 지원 DC 필수/선호
DS_DIRECTORY_SERVICE_6_REQUIRED: 쓰기 가능한 WS2008 이상 DC만 허용

10) DsGetDcName의 DomainGuid/SiteName 파라미터

A. DomainGuid로 도메인 찾기(이름 인식 실패 시 GUID로 재탐색), SiteName=NULL이면 로컬 컴퓨터 기준 가까운 사이트 DC를 반환합니다.

11) 존 유형 비교(표준 Primary/Secondary vs AD-통합)

A. Primary는 단일 쓰기 지점(DDNS 수용)이라 SPOF 소지가 있고, Secondary는 읽기 전용이며 Zone Transfer(TCP 53) 로 동기화됩니다. AD-통합 존은 AD 객체로 저장·복제되어 멀티마스터 쓰기가 가능.

12) Zone Transfer 동작

A. Secondary는 Primary(또는 다른 Secondary)에서 전체/증분 전송으로 데이터베이스 파일을 받아 반영하며, 전송은 TCP 53을 사용합니다. 대규모 존의 조회 분산·가용성 향상에 유효합니다.

13) Secondary를 어디에 두면 좋은가?

A. 조회 수요가 높은 지점 근처 또는 WAN 링크 건너에 둬 캐시/백업 역할을 하게 하고, Primary 장애 시 권한 있는 응답을 제공하도록 배치합니다.

14) Background Zone Loading(WS2008) 원리

A. 재시작 시 AD DS에서 존을 백그라운드 스레드로 로드합니다. 서버는 루트힌트·파일존을 먼저 올리고 곧바로 질의에 응답, 아직 메모리에 없는 노드는 AD에서 즉시 읽어 업데이트합니다. 대형 존 환경에서 재가동 공백을 줄입니다.

15) Forwarder의 개념·보안·구성 팁

A. 로컬에서 풀지 못한 질의를 지정 Forwarder로 전송합니다. 방화벽 밖으로 통신하는 DNS 수를 줄여 보안을 강화하고, 체이닝 지양/구성 단순화/비효율 경로 만들지 않기가 팁입니다(루트 존 “.” 존재 시 설정 불가).

16) Conditional Forwarding은 어떻게 동작하나?

A. 도메인별로 다른 포워더를 지정해 오프사이트 내부 도메인·다른 네임스페이스를 효율 해석합니다. 질의의 FQDN 접미사를 기준으로 해당 목록의 서버에 바로 위임하므로 체인 단축·트래픽 감소 효과가 있습니다.

17) Delegation vs Conditional Forwarding 차이와 선택법

Delegation(위임): 부모 존이 자식 존의 권한을 NS(+필요 시 glue A) 로 영구 위임. 권한이 자식 권한 DNS로 넘어가며, 부모에 NS 레코드를 유지/갱신해야 합니다(신규 권한 서버 추가 시 부모 갱신 필요). 권한 경로가 표준 DNS 규칙을 따릅니다.
Conditional Forwarding: 권한을 넘기는 것이 아니라, 질의를 특정 서버로 프록시. 도메인 접미사 기준으로 지정된 서버로만 보내 해석 경로를 강제 단축합니다. 부모 존의 NS 유지/갱신 부담 없음. 다만 해당 서버 가용성/지연에 종속됩니다.
Stub Zone: 부모가 자식의 권한 NS 목록을 자동 최신화(자식 SOA/NS/A만 복제)해 위임의 관리 공백을 줄입니다. 복잡한 다조직 환경에서 Delegation 대용/보완으로 유용.
선택 가이드: 영속적 권한 분리·표준 동작 선호 ⇒ Delegation/Stub. 빠른 상호 신뢰·크로스 네임스페이스·WAN 단축 ⇒ Conditional Forwarder.

18) Stub Zone은 무엇을 해결하나?

A. 위임 후 자식 권한 서버가 늘었지만 부모가 모르는 상황을 해소합니다. 부모 쪽 Stub이 자식에서 최신 NS 목록을 자동 가져와 질의가 최신 권한 서버로 향하게 합니다.

19) Parent vs Child DNS서버 사용 판단 기준

A. 관리 위임 필요, 부하 분산/성능/내결함성, 대량 서브도메인 확장 등이 존 분할·위임의 주된 이유입니다. 조직 구조를 반영해 존을 설계합니다.

20) Child 도메인 DNS 구축 기본 순서

A. (1) 부모 DNS에 delegation 생성 → (2) 자식 서버에 DNS 설치 → (3) 자식에 자식 존 생성 → (4) 클라이언트를 자식 DNS로 지정 → (5) 필요 시 부모를 포워더로 추가 → (6) 클라이언트 ipconfig /registerdns.

21) SRV 질의 검증 방법

A. nslookup → set type=all → _ldap._tcp.dc._msdcs.<도메인> 질의로 DC 목록이 나오는지 확인합니다.

22) 동적 업데이트가 발생하는 시점

A. IP 변경/임대 갱신, 부팅, ipconfig /registerdns, DC 승격 등일 때 DHCP Client 서비스가 DNS에 업데이트를 전송합니다.

23) IPv6 전환기 DNS 질의 동작

A. Vista/WS2008 클라이언트는 연결성 결정을 위해 기본적으로 A와 AAAA를 조회합니다. 단, 링크로컬/Teredo만 있으면 A만 질의합니다. 이는 IPv6 전환 시 접근 성공률과 인프라 검증을 높입니다.

24) AAAA 등록과 Teredo 예외

A. DNS 동적 업데이트 시 IPv4 A/PTR + IPv6 AAAA를 한 패킷에 묶어 등록하고, Teredo 주소는 등록 제외됩니다(트래픽 영향 최소화).

25) 공인 DNS(인터넷)와 동적 업데이트 영향

A. 일반 인터넷 DNS는 동적 업데이트를 지원하지 않으며, 설령 지원하더라도 일반적인 Vista/WS2008 호스트는 글로벌 IPv6 주소가 없어 추가 트래픽 영향이 거의 없습니다.

26) WAN 지사에 Secondary 배치 시 장점

A. 현지 조회를 현지에서 해결해 대역폭·지연을 절감하고, 상위 링크 장애 시에도 일정 수준 권한 응답을 제공합니다. 지사 가까이에 두는 것을 권장합니다.

27) Microsoft DNS와 타 벤더(BIND) 호환성

A. BIND 8.1.2 이상이면 RFC(1034/1035/…/2052 등) 준수로 상호운용 가능하며, AD에는 SRV 지원(동적 업데이트는 선택)이 필수입니다.

28) Single-Label 도메인을 쓰지 말아야 하는 이유

A. 레지스트라 등록 불가, 동적 업데이트/해결 추가 구성 필요, 기본 동적 업데이트 비활성, 일부 서버 앱/도메인 이름 변경 비호환 등 장기 운영 리스크가 큽니다.

29) 위임과 포워더가 섞이면 어떤 일이?

A. 정상적인 위임 기반의 권한 경로가 포워더에 의해 우회될 수 있습니다. 위임을 설계했다면 포워더/조건부 포워더가 의도치 않게 해석 경로를 바꾸지 않는지 검토해야 합니다.

30) 포리스트 전체 가용성을 높이려면?

A. _msdcs.forest_root_domain을 별도 존으로 만들고 복제 범위를 숲 전체(ForestDNSZones) 로 설정하십시오. 신규 DC의 레코드 등록/조회와 도메인 간 복제/GC 탐색의 전제 조건입니다.

A1) nslookup은 실무에서 어떻게 써야 하나요?

A. 레코드 등록/업데이트 검증, 이름해결 문제 분석, 서버 응답 상세 확인에 사용합니다(예: _ldap._tcp.dc._msdcs.<도메인> 질의로 DC 목록 확인). 도구 용도와 문법 참고 경로도 문서에 수록돼 있습니다.

A2) netdiag는 어떤 상황에 유용하죠?

A. 네트워크 바인딩 상태와 핵심 테스트를 일괄 수행해 연결성/네임해결 문제 원인을 좁힙니다. 별도 스위치 없이 실행해 산출물을 바로 분석하기 좋습니다.

A3) dcdiag는 무엇을 점검하나요?

A. 포리스트/사이트/단일 DC 범위를 선택해 DC의 상태를 다각도로 테스트하고 비정상 동작을 리포팅합니다(등록/복제/서비스 등).

A4) ipconfig로 DNS 관련해서 꼭 쓰는 스위치는?

A. /all(구성 덤프), /flushdns(클라이언트 캐시 초기화), /registerdns(A/PTR 재등록) 입니다. IPv4/IPv6 정보를 모두 표시·관리합니다.

A5) ping은 왜 여전히 중요하죠?

A. IP 레벨 도달성 확인의 1차 도구이며, 패킷 크기/횟수/TTL/DF(단편화 금지) 등 옵션으로 경로 특성을 함께 살필 수 있습니다.

A6) Disjoint Namespace 문제가 뭔가요? 어떻게 고치나요?

A. DC 승격 시 기본 DNS 접미사와 도메인 이름이 불일치하면 SRV 동적등록 실패/NETLOGON 5781 등이 발생합니다. 해결은 (1) 접미사 자동변경 체크 후 재승격, 또는 (2) 문서에 언급된 FixDomainSuffix.vbs 스크립트 및 재부팅 절차입니다.

A7) Single-label 도메인(점 없는 이름)이 왜 위험합니까?

A. Windows Server 2003 이후 기본 등록이 제한되고, 다수의 클라이언트/앱 호환 이슈와 레지스트리 예외 설정이 얽힐 수 있어 운영 리스크가 큽니다.

A8) 시간 동기화 기본 원리는?

A. Windows는 도메인 계층 기반 동기화를 기본으로 하며, 정확도는 Stratum 개념으로 표시합니다. 필요 시 수동 소스 지정도 가능하지만, Kerberos 요구사항을 충족하는 도메인 계층 기본값이 권장됩니다.

A9) 누가 최상위(가장 정확) 시간 소스인가요?

A. 포리스트 루트 도메인 PDC 에뮬레이터(스트라텀 1) 가 외부 NTP에 동기화되고, 상위 DC→하위 DC/클라이언트로 내려가며 스트라텀이 증가할수록 오차 가능성이 커집니다.

A10) 방화벽으로 분할된 네트워크에서 DC를 운영할 때?

A. DMZ/분리 세그먼트/상호 분리된 DC 등 시나리오별 인증·복제 트래픽 포트 고려와 IPSec 정책으로 AD 트래픽 보호하는 절차가 제시됩니다(세부 포트는 문서의 MS 문서 링크 참조).

A11) GlobalNames Zone과 DNSSEC은 왜 문서에 등장하나요?

A. 이 모듈은 클라이언트의 DC 찾기 변화점과 함께 GlobalNames Zone/DNSSEC 주제를 소개합니다(상세 구성은 별도 심화 주제). GNZ는 단일 라벨 이름의 포리스트 전역 해석, DNSSEC는 응답 무결성 강화를 다룹니다(개념 소개 수준).

A12) WS2008 DNS의 IPv6/RODC/백그라운드 로딩 포인트는?

A. (1) IPv6 AAAA/역방향 ip6.arpa 지원과 포워더/재귀 질의에서 IPv6 사용, (2) RODC의 읽기 전용 존 복제(도메인/ForestDNSZones/DomainDNSZones), (3) Background Zone Loading으로 재부팅 직후에도 질의 처리 가능

'IT' 카테고리의 다른 글

lsass (2)	2025.08.22
DNS 위임(delegation) 조건부 전달자(conditional forwarders) 차이 (2)	2025.08.18
AD 백업 및 복구 핵심 Q&A 20 (4)	2025.07.18
ADAC(Active Directory 관리 센터)와 휴지통 (1)	2025.07.18
AD DS 복원 옵션 상세 설명 (0)	2025.07.18