pile·
네트워크·cloudflare-blogCloudflare Blog·

Cloudflare Internal DNS 정식 출시 — 사설·공인 DNS 통합 구조

Cloudflare가 사설(내부)·공인 DNS 해석을 하나의 플랫폼으로 통합하는 Internal DNS를 정식 출시했다. 기존에는 공인 DNS·내부 DNS·클라우드별 DNS가 제각기 다른 보안 정책으로 흩어져 공통 컨트롤 플레인이 없었고, split-horizon 구성은 병렬 시스템을 수동 동기화하다 drift로 장애를 냈다. 새 제품은 단일 API·감사 로그·정책 계층으로 이를 합치고, 1.1.1.1 인프라 위에서 하드웨어 없이 동작하며 Enterprise는 Gateway에 무료 포함된다.

핵심 포인트
  • 공인·사설 DNS를 하나의 컨트롤 플레인으로 통합해 단일 API·감사 로그·정책 계층에서 관리한다.
  • Gateway Resolver가 1.1.1.1 기반으로 재귀 해석과 정책 평가를 맡고, Internal Authoritative DNS가 내부 존의 권한 레코드를 서빙한다.
  • Internal Zones·DNS Views·Resolver Policies 세 객체로 split-horizon을 병렬 시스템 없이 구현한다.
  • 변경은 통합 DNS Records API로 들어가 글로벌 네트워크에 전파되며 TTL 만료를 안 기다리고 수 초 내 반영된다.
  • Cloudflare One Client·DoH·DoT·53번 포트·PAC·Cloudflare WAN으로 접근해 Zero Trust를 DNS까지 확장한다.
상세 정리
  • 문제: 공인 DNS는 한 플랫폼, 내부 DNS는 다른 플랫폼, 클라우드 안은 클라우드 네이티브 DNS로 나뉘고 보안 정책이 따로 얹혀 공통 컨트롤 플레인이 없었다.
  • split-horizon 고통: 같은 이름을 내부·외부에 다르게 응답하려면 병렬 시스템을 동기화해야 했고, 시간이 지나며 drift가 생겨 장애로 이어졌다.
  • Gateway Resolver: 재귀 해석과 정책 평가를 담당하고, 표현식 기반 정책 엔진으로 쿼리를 필터링하거나 상위 소스로 리다이렉트한다.
  • Internal Authoritative DNS: 10년 넘은 Cloudflare 권한 DNS 플랫폼으로 내부 존 레코드를 서빙한다.
  • 세 객체 구조: Internal Zones는 사설 리소스의 권한 레코드를 담고, DNS Views는 존을 특정 사용자·디바이스 집합의 해석 컨텍스트로 묶으며, Resolver Policies는 매칭 쿼리를 뷰로 라우팅한다.
  • 존 재사용: 공유 존을 여러 뷰에서 참조로 재사용해 중복과 drift를 막는다.
  • 해석 흐름: 쿼리는 먼저 Gateway Resolver에서 정책 평가를 받고, 매칭되면 Internal Authoritative DNS로, 차단이면 드롭, 미매칭이면 1.1.1.1 공인 경로로 간다. 뷰는 내부에서 못 찾으면 공인 해석으로 폴백할 수 있다.
  • 변경 전파: 대시보드·Terraform·API가 같은 DNS Records API로 들어가 코어 데이터센터에 저장된 뒤 글로벌 네트워크로 복제되고 캐시 무효화까지 처리해 수 초 내 반영된다.
  • 통합 지점: Cloudflare One Client(구 WARP)·DoH·DoT·53번 포트·PAC 배포·Cloudflare WAN을 지원하고, WAN에 연결된 기기는 개별 클라이언트 설치 없이 내부 호스트명을 해석한다.
  • 설정 절차: 내부 존 생성(type internal, 예 corp.internal) → DNS 레코드 추가(예 db.corp.internal → 10.0.1.50, TTL 300) → DNS View 생성으로 존 연결 → Zero Trust 대시보드에서 Gateway Resolver 정책 생성, IaC는 Terraform으로 처리한다.
  • 하드웨어 은퇴: 1.1.1.1 인프라 위에서 돌아 랙에 장비를 넣거나 용량을 프로비저닝할 필요 없이 어플라이언스·레거시 서버를 대체한다.
왜 읽나사내 DNS·split-horizon·Zero Trust 네트워크를 운영하며 어플라이언스 통합을 고민하는 인프라·네트워크·플랫폼 엔지니어에게 유용하다.
cloudflare-blog
Cloudflare Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Cache Response Rules — 오리진 응답 기반 캐시 제어

    Cloudflare가 오리진 응답이 도착한 뒤 캐시에 쓰이기 직전에 개입하는 Cache Response Rules를 내놨다. 기존 Cache Rules는 요청 단계에서만 동작해, 오리진이 붙인 Set-Cookie·no-cache·ETag 때문에 충분히 캐시 가능한 응답이 오리진으로 되돌아가는 문제를 풀지 못했다. 새 규칙은 응답 헤더를 보고 헤더 제거·캐시 태그 관리·Cache-Control 수정을 수행해, 오리진 수정 없이 캐시 적중률을 끌어올린다.

  2. 네트워크·NHN Cloud MeetupNHN Cloud·

    경계가 만든 길, Load Balancer(DSR)

    NHN Cloud가 XDP/eBPF 기반 커널 단 기술로 만든 DSR(Direct Server Return) 방식 로드 밸런서를 소개한다. 기존 프록시 방식 LB는 요청·응답을 모두 종단·중계해 응답 트래픽이 클수록 LB가 병목이 된다. 이를 요청만 LB를 경유하고 응답은 서버가 클라이언트에 직접 보내는 비대칭 구조로 해결한다. 미디어 스트리밍·대용량 다운로드·게임 서버처럼 응답이 큰 L4 워크로드가 대상이다.

  3. 네트워크·cloudflare-blogCloudflare Blog·

    .AL TLD DNSSEC 장애 분석과 EDE 33 투명성 코드 도입

    2026년 7월 3일 알바니아(.AL) TLD의 DNSSEC 키 롤오버 실수로 알바니아 정부, 은행, 미디어 등 모든 .AL 도메인이 약 5시간 동안 다운된 사건을 다룬다. Cloudflare가 Negative Trust Anchor(NTA)로 빠르게 대응했지만, 기존 NTA 응답이 정상 검증 응답과 구분되지 않는 투명성 문제가 있었다. 이를 계기로 NTA 적용 여부를 DNS 응답에 직접 표시하는 EDE 33 코드가 IANA에 공식 등록됐다.

    #network-security#dnssec#dns+2