Windows Server 2025 / DNS 레코드와 정방향·역방향 조회 영역 이해하기

DNS(Domain Name System)는 이름에 해당하는 IP 주소나 서비스 위치를 찾는 체계입니다. Windows Server에서는 영역에 레코드를 저장해 내부 이름을 관리하고, Active Directory에서는 도메인 컨트롤러와 서비스를 찾는 데도 DNS를 사용합니다.

이름 조회는 서버에 질문하는 과정입니다

클라이언트는 설정된 DNS 서버에 특정 이름과 레코드 종류를 질의합니다. DNS 서버가 담당 영역의 정보를 갖고 있으면 그 데이터를 바탕으로 답하고, 외부 이름은 캐시·전달자·재귀 조회 등의 경로로 처리할 수 있습니다. 이름과 주소가 한 번 대응되었다고 영구히 고정되는 구조는 아닙니다.

예를 들어 fs1.lab.example.test를 172.24.50.20으로 관리하면 사용자는 서버 IP를 외우지 않고 이름으로 접근할 수 있습니다. 하지만 DNS에 이름을 등록하는 것만으로 공유·웹·인증 서비스가 설치되거나 접속 권한이 생기는 것은 아닙니다. 이름 조회 성공과 실제 서비스 접속을 따로 확인해야 합니다.

영역은 DNS 정보를 관리하는 범위입니다

Windows Server의 DNS 영역 설명에서 영역의 저장 방식과 종류를 확인할 수 있습니다. 이 강좌는 AD 설치 전 연습용 lab.example.test 영역과 AD 구성용 ad.example.test 영역을 구분합니다. 둘은 이 실습에서 예약된 예시 네임스페이스를 사용한 별도 영역입니다.

AD 통합은 모든 DNS 서버에서 선택 가능한 저장 방식이 아닙니다. AD DS 도메인 컨트롤러에 DNS 역할이 있어야 합니다. 아직 독립 서버인 DC1에서 연습할 때는 파일 기반 주 영역을 사용하고, AD 영역은 도메인 설치 과정에서 별도로 구성합니다.

레코드 종류에 따라 담는 값이 다릅니다

별칭을 만들 때는 대상 이름이 실제로 조회되는지 확인하세요. 웹 사이트의 별칭은 웹 서버 바인딩과 인증서도 맞아야 하고, SMB 공유 별칭도 서비스 측의 추가 조건이 있을 수 있습니다. CNAME 하나로 모든 서비스 이름 변경이 끝난다고 생각하면 안 됩니다.

PTR이 없어서 nslookup에 DNS 서버 이름이 Unknown으로 표시되는 경우도 있습니다. 이는 질의한 A 레코드가 정상인지와 따로 판단합니다. 역방향 조회 성공을 모든 응용 프로그램 동작의 필수 조건으로 일반화하지 않습니다.

캐시와 TTL 때문에 변경이 바로 보이지 않을 수 있습니다

TTL(Time to Live)은 DNS 응답을 캐시에 얼마나 보관할 수 있는지 나타냅니다. 레코드를 바꿔도 다른 DNS 서버나 클라이언트가 이전 응답을 유지할 수 있습니다. 변경 전후 비교에서는 어느 서버에 어떤 종류로 질문했는지와 캐시 여부를 함께 봅니다.

Resolve-DnsName -Name 'fs1.lab.example.test' -Type A -Server 172.24.50.10
nslookup fs1.lab.example.test 172.24.50.10

위 명령은 해당 영역과 레코드를 구성한 뒤 CLIENT1에서 실행하는 확인 예시입니다. 구성 전에는 실패할 수 있습니다. 기대 결과는 A 응답에 172.24.50.20이 포함되는 것입니다. 이름이 없다는 응답과 서버가 응답하지 않는 시간 초과는 원인이 다릅니다.

도메인 환경에서는 내부 DNS를 사용합니다

도메인에 가입한 컴퓨터는 도메인 컨트롤러 위치를 DNS로 찾습니다. 인터넷 사이트가 잘 열린다는 사실만으로 도메인 DNS가 정상이라고 판단할 수 없습니다. 공용 DNS가 사설 AD 영역의 SRV 레코드를 알 수 없기 때문입니다.

내부 도메인 조회는 내부 DNS가 담당하고 외부 이름은 내부 서버의 전달 정책으로 처리하도록 설계합니다. AD DNS에 필요한 레코드를 수동으로 임의 변경하기 전에 역할과 자동 등록 방식을 확인하세요. 연습 영역에서 A·CNAME·PTR을 익힌 뒤 도메인 영역에 적용되는 차이를 구분하면 DNS 장애를 더 정확하게 좁힐 수 있습니다.