Fortigate FQDN 정책과 DNS Snooping(passive-fqdn)

카테고리 없음

Fortigate FQDN 정책과 DNS Snooping(passive-fqdn)

지기(ZIGI) 2026. 4. 22. 07:33

Today Key :FortiGate, FQDN 정책, Wildcard 도메인, DNS Snooping, passive-fqdn-learning, FortiOS 7.6, DNS RTT, Fail-over, CDN 오차단, DNS Proxy

이번 포스팅에서는 FortiGate 방화벽에서 FQDN과 Wildcard 도메인의 IP를 어떻게 질의하고 수집하는지, 그리고 Forti OS 버전별 동작 방식의 차이 등을 알아봅니다.

최근 클라우드와 CDN(Content Delivery Network)의 사용이 보편화되면서, 방화벽 정책의 목적지를 고정된 IP가 아닌 **도메인(FQDN)**으로 설정하는 경우가 많아졌습니다. 하지만 도메인 기반 정책을 운영하다 보면 "정책을 열어두었는데도 통신이 차단되는(False Positive)" 기이한 현상과 자주 마주하게 됩니다.

1. FQDN과 Wildcard 도메인: IP 주소를 알아내는 두 가지 방식

1. FQDN 정책의 전제: 방화벽이 도메인의 IP를 아는 방법

방화벽이 도메인 기반 정책을 수행하려면 결국 해당 도메인의 IP를 알고 있어야 합니다. FortiGate는 이를 위해 두 가지 방식을 사용합니다.

능동적 질의 (Active Query)

방화벽 자체에 설정된 DNS 서버(System DNS)로 직접 쿼리를 보내고, 응답받은 IP를 내부 캐시에 저장합니다.

수동적 스니핑 (Passive Learning / DNS Snooping)

내부 클라이언트가 DNS 쿼리를 수행할 때, 방화벽이 그 트래픽을 중간에서 엿듣고(Snooping) 클라이언트가 응답받은 IP를 자신의 캐시에 동적으로 추가합니다.

일반 FQDN(Ex. img.blog.zigispace.net)은 능동적 질의를 기본으로 사용하며, 한 번에 질의가 불가능한 Wildcard 도메인(*.blog.zigispace.net)은 구조상 수동적 스니핑 방식에만 의존합니다.

2. FortiOS 7.6을 기점으로 바뀐 FQDN 동작 방식

방화벽 자체 쿼리와 클라이언트 쿼리 간의 IP 불일치로 인한 오차단 문제가 반복적으로 제기되면서, Fortinet은 FortiOS 7.6부터 일반 FQDN의 동작 방식을 크게 변경했습니다.

FortiOS 7.6 이전 (7.0 / 7.2 / 7.4)

일반 FQDN

방화벽 자체 DNS 쿼리(Active)만 수행. DNS Snooping이 동작하지 않습니다. 클라이언트가 받은 IP와 방화벽이 캐싱한 IP가 다를 경우 오차단이 발생할 수 있습니다.

Wildcard FQDN

DNS Snooping(Passive)으로만 동작합니다.

FortiOS 7.6 이상

일반 FQDN

방화벽 자체 DNS 쿼리(Active)와 DNS Snooping(Passive)이 기본적으로 병행 동작합니다. 클라이언트가 응답받은 IP도 캐시에 함께 추가되므로 오차단 문제가 크게 줄어듭니다.

Wildcard FQDN

기존과 동일하게 DNS Snooping으로만 동작합니다.

3. passive-fqdn-learning 설정 심층 분석

FortiOS 7.6부터 일반 FQDN에 DNS Snooping이 적용되면서, 관리자가 이 동작을 제어할 수 있도록 passive-fqdn-learning 속성이 추가되었습니다.

기본값: enable (스누핑 활성화 상태로 동작)
주의: 기본값이기 때문에 일반적인 show 명령어로는 표시되지 않습니다. 아래 명령어로 확인해야 합니다.

show full-configuration firewall address "객체이름"

설정 변경은 아래와 같이 합니다.

config firewall address
    edit "FQDN_객체이름"
        set passive-fqdn-learning {enable | disable}
    next
end

언제 어떤 값을 쓸까?

enable (권장/기본값)

AWS, Azure, Akamai 등 클라우드·CDN 도메인을 허용하는 정책에 필수입니다. DNS 응답 IP가 수시로 바뀌는 환경에서도 유연하게 통신을 보장합니다.

disable (엄격한 통제)

내부 클라이언트가 변조된 DNS를 이용해 정책을 우회하는 것을 막아야 할 때 사용합니다. 스누핑을 끄면 오직 "방화벽이 자체적으로 신뢰하는 DNS 서버에서 조회한 IP"만 허용하는 강력한 화이트리스트가 됩니다.

4. 방화벽 자체 DNS 질의 방식: RTT vs Failover

FortiGate가 System DNS로 자체 질의를 할 때, 기본·보조 DNS 서버 중 어느 쪽을 선택할지 결정하는 server-select-method 설정이 있습니다.

least-rtt (기본값)

구성된 DNS 서버 중 RTT(응답 지연 시간)가 가장 짧은 서버를 우선 선택합니다.

failover

RTT에 관계없이 Primary DNS 서버만 사용하며, Primary가 응답하지 않을 때만 Secondary로 넘어갑니다.

⚠️ CDN 도메인 질의 시 least-rtt의 치명적인 함정
CDN은 GSLB(Geo-DNS) 기술을 통해 "질의를 보낸 DNS 서버의 위치"를 기준으로 가장 가까운 IP를 응답합니다. 여기서 least-rtt와의 충돌이 발생합니다.

내부 클라이언트가 사내 DNS(예: 1.1.1.1)로 CDN 도메인을 질의 → IP A 응답
FortiGate는 least-rtt 방식으로 그 순간 더 빠른 Secondary DNS(예: 8.8.8.8)로 질의 → IP B 응답
결과: 클라이언트는 IP A로 접속하지만, 방화벽 캐시에는 IP B만 존재 → 트래픽 차단(Drop)

CDN은 TTL이 몇 초 단위로 매우 짧기 때문에, 이 불일치는 일회성이 아니라 지속적으로 반복됩니다.

🛠️ CDN 오차단 트러블슈팅: 3가지 실무 해결법

① DNS 서버 선택 방식을 Failover로 고정

방화벽이 수시로 다른 DNS 서버로 질의하지 않도록 변경합니다.

config system dns
    set server-select-method failover
end

② FortiGate를 내부 DNS Proxy(Forwarder)로 구성 (가장 확실한 방법)

클라이언트가 외부 DNS를 직접 바라보는 대신, FortiGate 자체(Network > DNS Servers)를 내부 DNS 서버로 설정합니다. 모든 클라이언트의 DNS 응답이 방화벽을 통과하므로, 방화벽과 클라이언트가 항상 동일한 IP를 갖게 됩니다.

③ FQDN 객체의 cache-ttl 연장 (우회 조치)

config firewall address
    edit "FQDN_객체이름"
        set cache-ttl 3600
    next
end

TTL을 인위적으로 길게 설정하면, 방화벽이 기존 IP 목록을 즉시 삭제하지 않고 일정 시간 유지합니다. 근본적인 해결책은 아니지만, ①·②를 적용하기 전 임시 우회 조치로 활용할 수 있습니다.

마치며

FQDN 기반 방화벽 정책은 관리가 편리한 반면, DNS 동작 원리를 정확히 이해하지 못하면 원인을 특정하기 어려운 간헐적 차단 장애로 이어지기 쉽습니다. 운영 중인 FortiOS 버전을 정확히 파악하고, 트래픽 흐름에 맞는 DNS 캐싱 전략을 수립이 필요합니다.

저작자표시 비영리 변경금지 (새창열림)