DNS

1. Q. DNS는 무엇이며, AD와 어떤 관계가 있나요?
   A. DNS는 “계층적(hierarchical)·분산(distributed)” 데이터베이스로, 이름을 IP로 바꿔 서비스에 연결해 줍니다. AD는 도메인 조인, 컴퓨터 부팅 시 DC 찾기, 복제 파트너 검색, 패스스루 인증 등 핵심 기능에서 DNS를 사용합니다. 즉 “DNS가 멈추면 AD도 멈춘다”에 가깝습니다.
2. Q. DNS의 ‘논리 개념’과 ‘물리 개념’은 어떻게 다르죠?
   A. 논리 개념은 ‘네임스페이스(예: contoso.com, eu.contoso.com)’ 같은 트리 구조와 위임(Delegation) 관계를 말합니다. 물리 개념은 ‘존(Zone)’—특정 네임스페이스 구간의 리소스 레코드 모음—을 어디에, 어떤 방식으로 저장/복제하느냐(파일 기반/AD-통합)를 말합니다.
3. Q. AD-통합(AD-integrated) 존과 파일 기반 존의 차이와 선택 기준은?
   A. 파일 기반은 한 대(Primary)만 쓰기 가능, 나머지는 Secondary(읽기 전용)로 존 전송 설정이 필요합니다. AD-통합 존은 AD DB에 저장되어 AD 복제로 배포되며, 여러 DC(DNS 서버)가 동시에 쓰기 가능합니다(RODC 제외). 보안 동적 업데이트를 통한 ACL 기반 레코드 제어가 가능하고, 운영·복원력 측면에서 AD-통합 존이 권장됩니다.
4. Q. ‘위임(Delegation)’, ‘조건부 전달자(Conditional Forwarder)’, ‘Stub Zone’은 언제 쓰나요?
   A.

• 위임: 상위 도메인이 하위 도메인 권한을 다른 네임서버에 넘길 때. 클라이언트가 그 하위 도메인의 NS를 직접 질의하게 됩니다.
• 조건부 전달자: 특정 도메인 질의를 지정한 서버로 “항상” 재귀 전달. 내부/파트너 도메인 해석 경로를 명시적으로 고정할 때 좋습니다.
• Stub Zone: 대상 존의 SOA/NS(및 선택적 A)만 부분 복제해 ‘권한 네임서버 위치’를 자동 추적할 때 사용합니다.
  각 방식은 쿼리 흐름과 관리 편의성 측면에서 트레이드오프가 있으므로, 도메인 경계/권한 위임 여부·운영 정책에 맞춰 선택합니다.

1. Q. 재귀(Recursive) vs 반복(Iterative) 질의의 차이는?
   A. 일반적으로 클라이언트→DNS 서버 질의는 “재귀”입니다(최종 답을 요구). 서버는 그 답을 찾기 위해 다른 서버로 “반복(Iterative)” 질의를 하며, 이 과정에서 포워더·루트 힌트 등을 사용합니다.
2. Q. 포워더(Forwarder)와 루트 힌트(Root Hints)는 어떻게 동작하나요?
   A. 로컬 존/캐시에 답이 없을 때, 설정된 포워더로 질의를 “재귀” 전달합니다. 포워더가 없거나 실패하면 서버는 루트 힌트를 사용해 권한 체인을 따라가며 해석합니다. 네임 해석 흐름(인터넷/사내 분리 요구)에 맞춰 포워더를 설계하세요.
3. Q. 동적 업데이트(Dynamic DNS)와 ‘보안’ 동적 업데이트는 무엇이며, 왜 중요하죠?
   A. 클라이언트/서버가 자신의 A/AAAA/PTR 등 레코드를 자동 등록/갱신하는 기능입니다. AD-통합 존이면 ‘보안’ 동적 업데이트로 RR 객체에 ACL이 적용되어, 소유자만 안전하게 갱신합니다. DC의 SRV 레코드, 멤버 서버/클라이언트의 A/AAAA 등록 안정성에 필수입니다.
4. Q. DNS 애플리케이션 파티션(ForestDNSZones/DomainDNSZones)은 왜 쓰나요?
   A. Windows 2000 시절엔 존이 도메인 파티션에 있어 복제 범위가 과했고, 자식 도메인에선 불필요 복제가 생겼습니다. 애플리케이션 파티션을 쓰면 ‘포리스트 전체(ForestDNSZones)’ 또는 ‘도메인 단위(DomainDNSZones)’로 복제 범위를 정확히 조절해 성능/트래픽을 최적화할 수 있습니다.
5. Q. 네임서버(NS) 레코드와 ‘권한(Authoritative)’의 의미는?
   A. 어떤 서버가 해당 존 데이터를 보유하고 있고 “권한 있는 답변”을 줄 수 있는지를 NS 레코드로 정의합니다. 존을 호스팅하는 모든 DNS 서버가 그 존의 네임서버이며, 이 서버들은 권한 응답을 반환할 수 있습니다.
6. Q. DC의 DNS 레코드는 누가, 언제 등록하나요? (netlogon.dns 포함)
   A. DC의 다양한 SRV/CNAME/A 레코드는 “Netlogon 서비스”가 등록/주기적 갱신(기본 60분)합니다(DnsRefreshInterval). 또 DC가 시도한 모든 레코드 목록은 %systemroot%\system32\config\netlogon.dns 파일에 기록되어 진단 시 1차 확인 포인트가 됩니다. 단, Host A/AAAA/PTR은 DNS Client 서비스가 담당합니다(WS2008/2012 기준).
7. Q. _msdcs.<forest/root> 서브도메인은 무엇을 담나요?
   A. AD 서비스 검색용 SRV가 등록되는 특별한 서브도메인입니다. 예)

• _ldap._tcp.dc._msdcs.contoso.com : 도메인의 임의 DC(LDAP)
• _ldap._tcp.pdc._msdcs.contoso.com : 해당 도메인의 PDC
• _ldap._tcp.<Site>._sites.dc._msdcs.corp.contoso.com : 특정 사이트의 DC
  또한 포리스트 루트의 _msdcs에는 GC 관련 SRV와 DC 복제 GUID→호스트명 CNAME이 포함됩니다.

1. Q. AutoSiteCoverage는 무엇이며, 언제 도움이 되나요?
   A. 특정 사이트에 DC/GC/App NC 복제본이 없을 때, 비용(사이트 링크 코스트)·DC 개수·알파벳 순 등의 규칙으로 “커버할 최적의 사이트”를 계산해 그 사이트용 SRV를 등록해 주는 기능입니다. 지점에 DC가 없을 때 “가까운 DC”를 자동으로 노출하는 데 유용합니다. GPO/레지스트리로 끄기(=0)·사이트 강제 지정(DcSiteCoverage/GcSiteCoverage)·DnsAvoidRegisterRecords 등 세밀 제어도 가능합니다.
2. Q. DC Locator(도메인 컨트롤러 찾기) 과정은 어떻게 흘러가나요?
   A.
3. 클라이언트가 DNS에 SRV 질의(사이트 미지정: _ldap._tcp.dc._msdcs.<도메인>, 사이트 지정: _ldap._tcp.<Site>._sites.dc._msdcs.<도메인>)
4. 응답 받은 DC 후보들에게 LDAP Ping(UDP/389) 전송 → 가장 먼저 응답한 DC 선택
5. 해당 DC가 클라이언트 IP에 매칭되는 서브넷을 찾아 “클라이언트 사이트/DSClosestFlag(가까움 여부)”를 알려줌
6. 가장 가까운 DC가 아니면, 그 사이트로 다시 사이트-특정 SRV 질의 후 접속
   이 과정의 결과(사이트명)는 레지스트리 DynamicSiteName에 캐시됩니다.
7. Q. DC Locator가 잘 안 될 때 무엇을 점검하나요? (실전 체크리스트)
   A.

• Sites & Services 서브넷 누락/오매칭 여부
• _msdcs 및 사이트별 SRV 등록 상태(Resolve-DnsName/nslookup)
• 클라이언트의 DynamicSiteName 캐시 불일치
• nltest /dsgetdc:<도메인> 결과와 플래그(WS, KDC, GC 등)
• Netlogon 로깅(nltest /dbflag)과 시스템/ DNS 이벤트
• 방화벽(UDP 389 LDAP Ping)
  위 항목을 순서대로 확인하면 대다수 사이트 배치/등록 문제를 빠르게 좁힐 수 있습니다.

1. Q. DNS/AD 트러블슈팅에 어떤 도구가 유용하죠?
   A.

• Resolve-DnsName: 풍부한 결과 포맷(예: | fl *)
• nslookup: SRV/A 질의 기본 도구(캐시 우회)
• ipconfig: /registerdns, /displaydns, /flushdns
• dcdiag /test:DNS: DC의 DNS 등록/구성/포워더·루트 힌트/기본 설정 검사
• nltest: /dsgetdc, /dclist, /dsgetdns, /dsderegdns
• 이벤트 로그/DNS 디버그 로깅/네트워크 캡처
  핑은 ICMP 차단 환경이 흔해 진단 신뢰도가 낮을 수 있습니다.

1. Q. Netlogon 로깅은 어떻게 켜고, 무엇을 봐야 하나요?
   A. nltest /dbflag:2080ffff(DCDiscovery & Secure Channel) 또는 nltest /dbflag:2fffffff(DNS 등록)로 상세 로그를 남깁니다. DNS 등록 실패, 사이트 판별, DC 후보 비교 등 DC Locator의 내부 결정을 텍스트로 확인할 수 있어 근본 원인에 빨리 도달합니다.
2. Q. AD 설계 관점에서 DNS ‘모범 설계’는?
   A. “단순하고 회복력 있는” 구성이 정석입니다.

• 다수의 DNS 서버(가능하면 쓰기 가능한 DC)
• AD-통합 존 + 보안 동적 업데이트
• 애플리케이션 파티션으로 복제 범위 최적화
• 방화벽에서 DNS 트래픽 허용(내/외부 경계 전략 명확화)
• 단일 장애 지점(SPOF) 회피
  운영/보안/성능의 균형을 위해 위 원칙을 일관되게 적용하세요.

1. Q. Kerberos 인증의 핵심 흐름(TGT/TGS/SPN)은?
   A. 클라이언트는 KDC(DC의 Kerberos 서비스)에서 TGT를 받고, 특정 서비스(SPN)에 접근할 때 TGS를 요청합니다. KDC는 AD에서 해당 SPN 소유 계정(서버/서비스 계정)을 찾고, 그 계정의 비밀키(패스워드 해시)로 티켓을 암호화해 발급합니다. 서버는 자신의 키로 티켓을 복호화하면 사용자 인증이 성립합니다.
2. Q. SPN과 서비스 계정은 실제로 어떻게 매핑되나요? (LocalSystem 포함)
   A. 예를 들어 CIFS에 접속하면 SPN cifs/서버이름을 대상으로 TGS를 요청합니다. 대상 서비스가 LocalSystem으로 동작하면 “해당 컴퓨터 계정(서버이름$)”이 그 SPN의 소유자이며, KDC는 그 계정의 키로 티켓을 암호화합니다. 서버는 자신의 계정 키로 티켓을 풀어 사용자 인증을 완료합니다(AP_REQ/REP 교환).
3. Q. “부팅→DNS 등록→DC Locator→Kerberos→자원 접근”까지, 어디서 문제가 자주 나고 어떻게 확인하나요?
   A.

• DNS 등록 실패: netlogon.dns/이벤트와 dcdiag /test:DNS, Resolve-DnsName으로 SRV/A 확인
• 사이트 판별 오류: 서브넷 누락, DSClosestFlag 경고, DynamicSiteName 캐시 확인
• DC 접근 실패: UDP 389(ldap ping)·TCP 389/445/88 방화벽·네트워크 경로 점검
• Kerberos 실패: 잘못된 SPN(중복/미등록), KDC 조회 실패, 계정 비밀번호 불일치
  각 단계의 로그/도구를 이용해 상향식으로 좁혀가면 MTTR을 크게 줄일 수 있습니다.