Authoritative DNS가 Recursive DNS까지 한다면? DNS 구성 점검과 대응

사내 DNS 구조를 점검하다가, 외부에 노출된 권위(Authoritative) 네임서버가 재귀(Recursive) 쿼리까지 처리하고 있는 상황을 발견했습니다. 이번 글에서는 왜 이 구조가 위험한지, 어떤 사고로 이어질 수 있는지, 그리고 Windows DNS Server 환경에서 어떻게 진단하고 완화할 수 있는지 정리해봅니다.

배경: 권위 서버와 재귀 리졸버는 다른 역할입니다

DNS 서버는 크게 두 가지 역할로 나뉩니다.

구분	권위 서버 (Authoritative)	재귀 리졸버 (Recursive)
역할	자기 존(zone)에 대한 답만 제공	클라이언트 대신 루트부터 순차 조회
캐시	보통 캐시하지 않음	TTL 동안 응답을 캐시
노출 범위	전세계 공개 (NS 레코드)	보통 특정 클라이언트 그룹 전용

이 둘을 분리해야 한다는 원칙은 새로운 이야기는 아닙니다. 오래전부터 IETF의 DNS 운영 권고 문서들도 "하나의 서버가 권위 응답과 재귀 응답을 동시에 처리하지 말라"는 취지의 가이드를 제시해왔습니다. 이유는 뒤에서 다룰 캐시 포이즈닝과 증폭 공격 리스크 때문입니다.

문제 상황

일반적인 사내 DNS 구조는 다음과 같습니다. 클라이언트는 도메인 컨트롤러(AD)를 1차 DNS로 바라보고, AD DNS는 전달자(Forwarder)로 사내 네임서버(예: ns.aaa.com)를 지정해 재귀 쿼리를 위임합니다.

문제는 이 ns.aaa.com이 회사 도메인의 공인 권위 네임서버, 즉 외부에서 NS 레코드로 조회 가능한 서버라는 점입니다. 확인해보니 이 서버는 내부 재귀 요청뿐 아니라 외부에서 들어오는 재귀 쿼리에도 응답하고 있었습니다. 이런 서버를 업계에서는 흔히 오픈 리졸버(Open Resolver)라고 부릅니다.

지금 오픈 리졸버인지 직접 확인하는 방법

추측만 하지 말고 실제로 검증해보는 게 먼저입니다. 사내망이 아닌 외부 네트워크(집, 모바일 핫스팟, 클라우드 인스턴스 등)에서 다음 명령을 날려봅니다.

# 임의의 외부 도메인을 조회 
 dig @ns.aaa.com google.com 
 # Windows 환경이라면 
 nslookup google.com ns.aaa.com

이 쿼리에 대해 google.com의 실제 IP가 응답으로 돌아온다면, 이 서버는 외부 누구에게나 재귀를 허용하는 오픈 리졸버가 맞습니다. 정상적인 권위 전용 서버라면 이런 질의에는 REFUSED가 돌아와야 합니다.

공개 스캐너로도 확인할 수 있습니다. Shodan에서 자사 공인 IP를 검색해 DNS 서비스 배너가 잡히는지, 혹은 The Open Resolver Project 같은 프로젝트의 리스트에 우리 IP가 포함돼 있는지 주기적으로 체크하는 것도 좋은 습관입니다.

왜 위험한가

1. 오픈 리졸버 → DNS 증폭 공격의 반사체

외부 누구나 이 서버에 재귀 쿼리를 던질 수 있다는 것은, 이 서버가 DNS Amplification / Reflection 공격의 반사체로 악용될 수 있다는 뜻입니다. 공격자가 출발지 IP를 피해자 IP로 위조(UDP 특성상 가능)한 뒤 이 서버에 대량의 쿼리를 보내면, 서버는 그 응답을 위조된 피해자에게 쏟아붓습니다.

이 방식이 위험한 이유는 증폭 배율 때문입니다. 짧은 DNS 질의 패킷 하나로 훨씬 큰 응답 패킷을 유도할 수 있어서(질의 대비 응답이 수십 배 커지는 레코드 타입도 있습니다), 소량의 스푸핑 트래픽만으로 피해자에게 대역폭을 마비시킬 정도의 트래픽을 몰아줄 수 있습니다. 2013년 스팸하우스(Spamhaus)를 겨냥한 대규모 DDoS 공격이 바로 이 오픈 리졸버들을 반사체로 악용한 대표적인 사례로 알려져 있습니다. 결과적으로 회사 IP가 이런 공격에 가담자로 찍히면, 서비스 장애는 물론이고 상대 피해 기업이나 보안기관으로부터 어뷰징 신고(Abuse Report)를 받는 상황까지 갈 수 있습니다.

2. 캐시 포이즈닝 확대와 내부 전파

외부에서 임의 쿼리를 계속 던지며 캐시 오염을 시도할 표면이 넓어집니다. 더 큰 문제는 이 서버가 AD DNS의 전달자로도 쓰이고 있다는 점입니다. 여기서 캐시가 오염되면, 그 오염된 응답이 AD를 거쳐 사내 클라이언트 전체로 전파될 수 있습니다. 즉 외부 공격 표면이 그대로 내부망 무결성 문제로 직결되는 구조입니다.

3. 가용성 리스크

외부 재귀 요청이 몰리면 서버 리소스가 소진되고, 이는 곧 사내 DNS 전체의 장애로 이어질 수 있습니다. 외부 공격 하나가 내부망 이름 해석까지 마비시키는 구조인 셈입니다.

4. 감사/컴플라이언스 관점

ISMS-P나 정보보호 관리체계 점검, 금융권 보안 감사 등에서 오픈 리졸버 존재 여부는 흔히 지적되는 항목 중 하나입니다. "외부 노출 서비스의 불필요한 기능 비활성화" 원칙에 정면으로 위배되기 때문에, 실무적으로도 언젠가는 짚고 넘어가야 할 이슈였습니다.

해결 방향: 분리가 원칙, 대역 제한은 즉시 완화책

가장 깨끗한 구조는 역할을 물리적/논리적으로 분리하는 것입니다.

역할	서버	재귀 여부
외부 공인 권위 서버	ns.aaa.com	비활성화 (자기 존만 응답)
내부 캐싱/재귀 리졸버	별도 내부 전용 서버	내부 대역만 허용

다만 서버 분리는 즉시 되는 작업은 아니라서, 당장 리스크부터 차단해야 한다면 Windows DNS Server의 쿼리 처리 정책(Query Resolution Policy)을 이용해 대역 기반으로 재귀를 제한하는 방법을 먼저 적용할 수 있습니다.

Windows DNS Server 대역 제한 설정

Windows Server 2016 이상이면 PowerShell로 DNS 정책을 걸 수 있습니다. 핵심 로직은 다음과 같습니다.

# 내부 대역만 재귀 허용, 나머지는 외부 재귀 차단
Add-DnsServerQueryResolutionPolicy `
    -Name "DenyExternalRecursion" `
    -Action IGNORE `
    -ClientSubnet "ne,10.0.0.0/8,192.168.0.0/16" `
    -FQDN "ne,*.aaa.com"
    -ProcessingOrder 1

각 조건의 의미는 다음과 같습니다.

• ClientSubnet "ne,..." — 지정한 대역이 아닌 클라이언트
• FQDN "ne,*.aaa.com" — 질의 대상이 우리 존(authoritative zone)이 아닌 경우

두 조건이 동시에 참일 때(외부 IP + 우리 도메인 질의도 아닌 경우) 응답 없이 드롭합니다. 결과적으로 외부에서 www.aaa.com 조회는 정상 응답하면서, google.com 같은 재귀성 질의는 차단됩니다. 내부 대역은 기존처럼 전부 재귀 가능합니다.

정책 확인 및 삭제는 다음과 같습니다.

Get-DnsServerQueryResolutionPolicy Remove-DnsServerQueryResolutionPolicy -Name "DenyExternalRecursion"

정책 적용 후에는 앞서 사용한 dig @ns.aaa.com google.com을 외부망에서 다시 날려, 이번엔 응답이 없거나 REFUSED가 오는지 반드시 재검증합니다.

Split-Horizon(Split-Brain) DNS란

같은 도메인 이름이라도 질의를 보낸 클라이언트가 내부망인지 외부망인지에 따라 서로 다른 IP로 응답하는 구조를 말합니다. 실제로 어떻게 동작하는지 예시로 보면 이해가 빠릅니다.

질의 도메인	외부(인터넷)에서 조회 시	내부(사내망)에서 조회 시
mail.aaa.com	203.0.113.10 (공인 IP, 방화벽 NAT 대상)	10.10.1.20 (내부 실제 서버 IP)
erp.aaa.com	응답 없음 (외부에 노출 안 함)	10.10.2.30

직원이 사내망에서 mail.aaa.com에 접속하면 내부망을 거치지 않고 곧바로 내부 IP로 붙어서 속도도 빠르고 방화벽/NAT 홉도 줄어듭니다. 반면 외부(재택, 거래처 등)에서는 공인 IP로 안내해 정상적으로 외부 경유 접속이 되도록 합니다. 이 구조의 핵심은 재귀를 열어주는 것과는 전혀 다른 접근이라는 점입니다. 즉, 외부 사용자가 우리 도메인에 대해 "다른 답"을 받는 것이지, 우리 서버가 외부 사용자 대신 "구글이 어디 있는지" 찾아주는 게 아닙니다. 그래서 오픈 리졸버 문제와는 별개로 안전하게 운영할 수 있는 기능입니다.

Windows DNS 환경에서 이를 구현하는 방법은 크게 두 가지입니다.

• 서버를 물리적으로 분리: 외부용 권위 서버(재귀 없음, 공개용 레코드만 보유)와 내부용 AD DNS(내부용 레코드를 별도로 보유하거나 조건부 포워딩)를 아예 나누는 방식입니다. 관리 포인트가 명확해서 이해하기 쉽습니다.
• 같은 서버에서 Zone Scope 활용: Windows Server 2016+의 Zone Scope 기능을 쓰면 하나의 존 안에 내부용/외부용 레코드 셋을 각각 두고, 앞서 다룬 Query Resolution Policy로 클라이언트 대역에 따라 다른 Scope를 보여주게 만들 수 있습니다. 서버를 늘리기 어려운 상황에서 고려할 수 있지만, 정책이 하나 더 겹치는 만큼 운영 복잡도는 올라갑니다.

지금 당장 이 구조까지 갈 필요는 없지만, 재귀/권위 분리 작업을 하는 김에 내부·외부 응답 체계를 함께 정리해두면 이후 외부 노출 서비스가 늘어날 때 훨씬 수월해집니다.

서버 분리, 실제로 얼마나 어려울까

앞에서 "분리가 원칙이지만 시간이 걸린다"고 썼지만, 사실 이건 환경에 따라 크게 갈리는 부분이라 단정할 일은 아닙니다. 실제로 얼마나 품이 드는지는 아래 요인들에 달려 있습니다.

쉽게 끝날 수 있는 경우

• 공인 존에 등록된 레코드 수가 적고 (NS, MX, 웹사이트 A/CNAME 정도) 변경이 잦지 않은 경우
• 이미 유휴 서버나 가상머신을 여유롭게 확보할 수 있는 경우 — 신규 VM 하나 세우고 존 파일만 복사하면 됨
• 등록기관(Registrar)에서 NS 레코드나 글루 레코드 변경이 즉시 반영되는 경우 — 실제로는 이 부분이 생각보다 수 시간~하루 내로 끝나기도 합니다
• AD DNS의 전달자 설정 변경 한 줄로 신규 리졸버를 가리키게만 하면 되는 단순 구조인 경우

시간이 걸릴 수 있는 경우

• 이 서버가 세컨더리 NS와 존 전송(Zone Transfer, AXFR/IXFR) 관계로 얽혀 있어서, 서버를 나누면 전송 설정과 방화벽 룰까지 함께 손봐야 하는 경우
• 다수의 외부 파트너/거래처가 이 서버의 IP를 방화벽 화이트리스트에 고정해둔 경우 — 사전 공지와 조율이 필요합니다
• 공인 IP를 추가로 확보해야 하거나, 클라우드 환경이 아니라 온프레미스라 신규 장비 도입에 결재/구매 절차가 필요한 경우
• 변경 후 전세계 DNS 전파(TTL 만료 및 캐시 갱신)를 기다려야 해서, 완전히 안정화되기까지 며칠의 관찰 기간을 두는 경우
• 감사나 변경관리 프로세스상 사전 승인, 변경 창구(Change Window) 확보가 필요한 조직인 경우

즉 "무조건 오래 걸린다"기보다는, 존 전송 관계, 외부 화이트리스트 의존도, 사내 변경관리 프로세스 이 세 가지만 먼저 확인해보면 이번 분리 작업이 하루 만에 끝날 일인지 몇 주짜리 프로젝트인지 가늠할 수 있습니다. 규모가 작고 위 조건에 걸리는 게 없다면, 대역 제한 정책을 굳이 오래 유지하지 않고 바로 서버 분리로 넘어가는 것도 충분히 현실적인 선택지입니다.

추가로 점검할 것들

서버 자체 재귀 전면 비활성화

이 서버가 순수 외부 공인 NS 역할만 해야 한다면, 아예 재귀 자체를 꺼버리는 것도 방법입니다.

dnscmd /config /norecursion 1

이 경우 내부용 재귀는 AD DNS 서버들이 직접 상위(ISP DNS나 공용 DNS)로 포워딩하도록 구조를 바꾸는 것이 가장 깔끔합니다.

방화벽 레벨 이중 방어

53/UDP, 53/TCP를 외부에 열어두더라도, 알려진 세컨더리 NS(등록기관, 파트너 등) 외의 무차별 오픈은 방화벽에서도 제한하는 것이 좋습니다. Rate limiting(RRL, Response Rate Limiting)을 지원하는 장비라면 초당 응답 수 제한도 함께 걸어두면 증폭 공격의 체감 피해를 줄일 수 있습니다.

서버 분리 시 작업 순서 (참고용)

대역 제한으로 급한 불을 끈 뒤, 서버 분리를 진행한다면 아래 순서를 참고할 만합니다.

• 내부 전용 재귀 리졸버(신규 서버 또는 기존 AD DNS 자체 재귀)를 먼저 구축하고 정상 동작을 검증합니다.
• AD DNS의 전달자(Forwarder) 대상을 기존 ns.aaa.com에서 신규 내부 리졸버로 변경합니다. 여러 대의 AD DNS가 있다면 한 대씩 순차 전환해 다운타임 없이 진행합니다.
• 전환 후 일정 기간 모니터링하며 이름 해석 오류나 지연이 없는지 확인합니다.
• 문제가 없으면 기존 ns.aaa.com에서 재귀 기능을 완전히 비활성화(/norecursion 1)하고 순수 권위 서버로만 남깁니다.
• 전환 완료 후에도 외부망에서 재귀 차단이 유지되는지 주기적으로 재검증합니다.

모니터링, 현실적으로는 어디까지 로그를 남길 것인가

DNS 쿼리는 트래픽이 많은 서버라면 초당 수백~수천 건씩 발생하기도 해서, 모든 쿼리를 무기한 전량 로깅하는 건 현실적으로 스토리지 비용과 검색 성능 모두에서 부담이 큽니다. 실제로는 다 모으는 대신 목적에 맞게 범위를 좁히는 것이 맞는 접근입니다.

• 전체 쿼리 로그가 아니라 요약 지표(카운터) 위주로 수집: 개별 쿼리 내용을 다 남기기보다, Windows DNS Server의 성능 카운터(QPS, 응답 실패율 등)나 이벤트 로그 건수를 주기적으로 집계해 시계열로만 보관합니다. 원본 쿼리 로그보다 용량이 훨씬 작습니다.
• 디버그 로깅은 상시가 아니라 필요한 시점에만 짧게: Windows DNS의 Debug Logging(Set-DnsServerDiagnostics)은 성능 영향도 있고 용량도 빠르게 커지므로, 상시 켜두기보다는 이상 징후가 보일 때 며칠만 켜서 원인 분석용으로 쓰는 편이 현실적입니다.
• 정책에 의해 드롭(IGNORE)된 쿼리만 선별 로깅: 이번에 적용한 대역 제한 정책에 걸려 차단된 쿼리처럼 "예외적으로 의미 있는" 이벤트만 골라서 남기면, 전체 트래픽 대비 로그량이 훨씬 적으면서도 어뷰징 시도를 추적하는 목적은 충분히 달성됩니다.
• 표본 추출(Sampling): 전체를 다 볼 필요가 없다면 일정 비율만 샘플링해서 로깅하는 것도 트렌드 파악용으로는 충분한 경우가 많습니다.
• 보관 주기 짧게, 필요 시 아카이빙: 최근 며칠~몇 주 분량만 상세 로그로 즉시 조회 가능하게 두고, 그 이전 데이터는 요약된 형태로만 남기거나 폐기하는 식으로 보관 주기를 정책화합니다.

즉 "모니터링한다"는 것이 곧 "전체 쿼리를 다 저장한다"는 뜻은 아닙니다. 이번 케이스처럼 목적이 명확할 때는(오픈 리졸버 악용 여부 확인, 대역 제한 정상 동작 확인) 그 목적에 맞는 지표와 이벤트만 선별해서 가볍게 수집하는 것이 현실적인 선택입니다.

정책 적용 이후 실제로 지켜볼 만한 항목은 다음과 같습니다.

• 초당 쿼리 수(QPS) 추이: 대역 제한 적용 직후 외부발 쿼리량이 얼마나 줄었는지로 기존 악용 규모를 가늠할 수 있습니다.
• NXDOMAIN / REFUSED 비율: 급격한 증가는 스캐닝이나 어뷰징 시도의 신호일 수 있습니다.
• 정책에 의해 드롭된 쿼리 건수(선별 로깅 대상): 이 항목만 별도로 카운트해두면 전체 로그 없이도 악용 시도 추이를 파악할 수 있습니다.
• 내부 클라이언트의 이름 해석 실패율: 정책 적용으로 내부 업무에 영향이 없는지 함께 확인해야 합니다.

Datadog 같은 모니터링 도구를 쓰고 있다면, 개별 쿼리 로그 대신 위 지표들만 뽑아서 시계열로 넣고 임계치 기반 알림을 거는 정도로도 충분한 가시성을 확보할 수 있습니다.

 

정리하면, 권위 서버와 재귀 리졸버를 분리하는 것이 근본적인 해법이지만 조직 상황에 따라 그 난이도는 크게 다릅니다. 대역 기반 재귀 제한으로 먼저 리스크를 차단해두고, 존 전송 관계나 외부 화이트리스트 의존도 같은 걸림돌이 없다면 생각보다 빠르게 서버 분리까지 진행할 수 있습니다. 모니터링도 전량 수집이 아니라 목적에 맞는 지표만 가볍게 가져가는 것이 현실적인 접근입니다.