Physical Address
South Korea
“DNS 서버 CPU 사용률 12%, 메모리 정상, QPS 여유.”
몇 달 전, 회사 모니터링 화면에 서비스 지연 알람이 떴을 때 제가 가장 먼저 확인했던 서버 지표였습니다. 담당자 입장에선 당연히 “DNS 장비는 아주 건강하니 우리 쪽 이슈는 아니다”라고 말하고 싶었죠. 하지만 네트워크 보안팀에서는 정반대의 소리를 했습니다. DMZ 외곽 방화벽이 특정 구간에서 패킷을 감당하지 못해 헐떡이고 있다는 분석이었습니다.
결국 원인을 파고들어 가 보니, ‘서버 성능’과 ‘네트워크 경로상의 병목’은 완전히 다른 차원의 문제였습니다.
오늘은 대기업이나 그룹사 환경에서 흔히 쓰는 Cloudflare + DMZ Authoritative DNS 아키텍처에서 도대체 왜 이런 방화벽 병목이 발생하는지, 그리고 DNS 엔지니어가 타 부서 탓으로 돌리지 않고 스마트하게 문제를 해결할 수 있는 실무 대응법을 공유해 봅니다.
흔한 대기업 DMZ DNS 구성, 트래픽은 어디로 흐를까?
많은 엔지니어링 팀이 외부 인입 트래픽 방어와 글로벌 가속을 위해 Cloudflare를 전면에 세우고, 실제 도메인 원본 존(Zone) 파일은 그룹 내부 보안 정책상 DMZ 구간의 Auth DNS에 직접 둡니다.
Plaintext
[외부 사용자 / 계열사 외부망]
│
▼
[Cloudflare Edge] ── 1차 캐싱 및 Rate Limit 방어
│
▼ (DNS 포워딩 / Zone Transfer 등)
[기업 외곽 방화벽 (FW)] 💥 병목 발생 지점 (UDP/TCP 53)
│
▼
[DMZ 내 외부 DNS 서버] ── 정상 처리 (리소스 여유)
- 외부 사용자가 도메인을 조회하면 1차적으로 Cloudflare Edge로 요청이 들어갑니다.
- Cloudflare에 캐시가 없거나 원본 조회가 필요할 때, 패킷이 우리 회사 외곽 방화벽(UDP/TCP 53번)을 두드립니다.
- 방화벽을 통과한 패킷이 DMZ DNS 서버에 닿아 정당한 IP 응답을 돌려줍니다.
얼핏 보면 앞단에 강력한 CDN/프록시가 버텨주니 안전해 보이지만, 진짜 복병은 방화벽과 UDP 프로토콜의 특성에 있었습니다.
DNS 서버는 멀쩡한데 방화벽만 터지는 진짜 이유
방화벽 장비가 패킷을 드롭(Drop)하기 시작했을 때 확인된 핵심 원인은 두 가지였습니다.
1. UDP 53번 포트와 비연결형 세션의 함정
DNS 조회의 대부분은 UDP를 씁니다. TCP처럼 3-way 핸드셰이크를 거쳐 정상 연결 여부를 따지는 게 아니다 보니, 방화벽 입장에서는 들어오는 요청이 정상 쿼리인지 무작위 서브도메인을 찔러보는 공격(Random Subdomain Attack / NXDOMAIN Flood)인지 즉각 판별하기가 어렵습니다.
결국 쏟아지는 UDP 패킷을 추적하려고 방화벽이 State Table(세션 테이블)을 쥐어짜다 리소스 한계에 도달하는 현상이 벌어집니다. DNS 서버 자체는 들어온 쿼리에 척척 답할 여유가 있어도, 그 앞 문지기인 방화벽이 문을 열어주다 지쳐 쓰러지는 셈입니다.
2. Cloudflare를 지나치게 믿었던 캐시(TTL) 설정 미흡
“앞단에 Cloudflare를 붙여뒀으니 트래픽 대부분을 막아주겠지”라는 건 관리자의 착각일 수 있습니다. 실제로 점검해 보니 레코드의 TTL(Time to Live) 값이 60초~300초 안팎으로 지나치게 짧게 걸려 있었습니다.
Cloudflare Edge 단에서 캐시 유효기간이 금방 만료되니, 캐시 미스(Cache Miss)가 날 때마다 패킷이 곧장 DMZ 방화벽으로 쏟아져 들어오고 있었습니다. 앞단 프록시가 사실상 제 역할을 못 한 채 방화벽을 향한 고속도로만 뚫어준 격이었습니다.
“우리 잘못 아닙니다” 대신 꺼내든 3가지 실무 해결책
이 상황에서 DNS 담당자가 “DNS 서버는 아무 이상 없으니 네트워크팀이 방화벽 장비를 증설하세요”라고만 대응하면 부서 간 감정싸움으로 번지기 십상입니다. 제가 직접 세팅을 변경하고 보안팀과 협업하며 방화벽 인입량을 80% 이상 줄였던 실무 체크리스트입니다.
1. Cloudflare 단에서 캐시 적중률(Hit Ratio) 강제 확보
가장 먼저 DMZ로 들어오는 쿼리 절대량을 억제해야 합니다.
- 주요 A/AAAA 레코드 TTL 상향: 변경이 잦지 않은 메인 서비스 도메인 레코드의 TTL을 최소 1,800초(30분)에서 3,600초(1시간) 이상으로 늘려 Cloudflare Edge에서 질의가 완결되도록 조정했습니다.
- Random Subdomain Protection 활성화: 공격자가
asdf123.yourdomain.com처럼 존재하지 않는 무작위 호스트를 찔러 원본 서버 조회를 강제 유도하는 수법을 Cloudflare Edge 단에서 사전 필터링하도록 룰셋을 걸었습니다.
2. DNS Query Log 뜯어서 보안팀에 ‘타깃 데이터’ 던져주기
보안팀은 53번 포트로 들어오는 방대한 IP/Port 통계만 볼 수 있지, 구체적인 도메인 질의 내용까지는 훤히 보이지 않습니다. DNS 담당자가 로그를 파악해 인사이트를 넘겨주는 순간 해결 속도가 몇 배 빨라집니다.
- NXDOMAIN 응답 비율 체크: 정상 응답(NOERROR) 대비 존재하지 않는 도메인 응답(NXDOMAIN)이 비정상적으로 치솟고 있는지 확인합니다.
- 대용량 Query Type(ANY, TXT) 집중 인입 확인: 반사 공격(Reflection)에 자주 악용되는 특정 타입의 쿼리가 과도하게 들어오는지 확인 후 해당 쿼리 타입의 Rate Limit을 요청합니다.
- Top Source IP 분리: Cloudflare 공인 IP 대역 외에 DMZ 방화벽 53번 포트를 직접 스캔하고 있는 불량 IP 대역을 추려 방화벽 차단 리스트에 올립니다.
3. 계열사/내부 트래픽의 Split-DNS 분리 (중장기 과제)
로그를 상세 분석하다 발견한 또 다른 사실은, 사내 그룹웨어와 계열사 직원들의 접근 트래픽조차 외부 DMZ DNS를 거쳐 다시 내부로 회귀하고 있었다는 점입니다.
이를 해결하기 위해 계열사 전용 내부 DNS(Internal Recursive DNS)에 Zone Forwarding을 적용하는 Split-DNS 구조로 단계적 개편을 진행했습니다. 내부에서 발생한 질의가 굳이 인터넷 망과 외부 방화벽을 타지 않고 다이렉트로 처리되도록 길을 터주니 방화벽 세션 부담이 눈에 띄게 줄었습니다.
부서 간 협업을 부드럽게 만드는 소통 팁
회의 자리에서 엔지니어로서의 전문성을 인정받는 화법은 의외로 간단합니다. 문제의 원인을 구조적으로 짚어주고, 내가 할 수 있는 솔루션을 먼저 제안하는 것입니다.
“현재 방화벽 병목 현상은 DNS 서버 처리량의 문제라기보다는, UDP 세션 폭증과 캐시 미스로 인한 패킷 유입 때문으로 보입니다. 저희 쪽에서 주요 레코드 TTL을 최적화하고 Cloudflare 에지 캐시 정책을 손봐서 방화벽으로 인입되는 트래픽 양을 먼저 대폭 줄여보겠습니다. 아울러 비정상 패턴의 로그 데이터도 뽑아드릴 테니 방화벽 룰셋에 반영해 주시면 감사하겠습니다.”
인프라 장애는 단일 장비의 결함보다 ‘구간과 구간 사이’의 상호작용에서 터지는 경우가 훨씬 많습니다. DNS와 네트워크, 보안이 맞물린 환경이라면 장비 상태 창 너머의 패킷 경로 전체를 한 번쯤 점검해 보시길 권합니다.
전문가의 인사이트 : 함께 읽어 보세요.
오라클 ExaCC를 사내 NFS 스토리지에 백업할 때 엔지니어가 반드시 알아야 할 실전 트러블슈팅
