2026년 6월 10일 Cloudflare Enterprise가 DNS 레코드 할당량 정책을 바꿨습니다. 지금까지는 존(도메인)별로 몇 만 개 상한이 걸려 있었는데, 이제 계정 전체 레코드 총합으로 제한합니다. 공개 존 총합 1백만, 내부 존 총합 1백만이 기본값.

Enterprise만의 이야기지만, “왜 이런 정책 변화가 필요할까?”의 배경에는 대규모 DNS 운영의 병목이 있습니다. 자체 서버로 DNS를 관리해야 하는 경우에도 같은 이슈를 만나게 되니, 그 병목이 어디서 오고 어떻게 대응하는지 정리합니다.

왜 존별 제한이 문제였나

전통적으로 DNS 서비스는 “존별 최대 레코드 수” 제한이 관행이었습니다.

  • 한 존이 너무 커지면 존 파일 파싱·전송·응답 지연.
  • 관리 UI가 몇 만 개 레코드를 페이지네이션 없이 처리하기 어려움.
  • 한 존 하나 고장 났을 때 blast radius 관리.

그런데 시장의 실제 사용 패턴은 이 가정과 어긋납니다.

  • 하나의 큰 존에 몇 십만 개 레코드가 필요한 사업자가 실제로 있음. SaaS·CDN·이메일 사업자가 대표적.
  • 여러 작은 존에 각 몇 백 개 레코드로 나눈 사업자도 있음. 어카운트 총합은 비슷하지만 관리 부담이 다름.
  • 두 패턴이 자유롭게 섞이는 것을 사업자가 원함.

계정 수준 할당량은 이 유연성을 인정한 결정입니다. 총합만 넘지 않으면 존 하나에 몰든 나누든 자유.

대규모 DNS 운영의 실제 병목

10만 개 이상 레코드를 다룰 때 실무자가 실제로 겪는 문제.

1) API 요청량

레코드 대량 생성·수정을 API로 하다 보면 초당 요청 제한(rate limit)에 걸립니다. Cloudflare Enterprise도 API 초당 1200 요청 정도가 상한. 10만 개 레코드를 새로 만드는 데 1시간 이상.

2) 존 전송(AXFR/IXFR)

Primary → Secondary 존 전송이 큰 존일수록 오래 걸림. 매번 AXFR는 무리라서 IXFR(증분 전송)로 관리하는데, 이때 SOA SERIAL을 정확히 올려야 함.

3) 응답 지연

레코드 조회 시 캐시 미스가 나면 존 파일 전체를 검색해야 하는 구현체가 있음. BIND는 잘 최적화돼 있지만 옛 구현체·자체 개발 서버는 병목.

4) DNSSEC 서명

존 레코드가 많을수록 서명 시간 증가. 롤오버 시 재서명 부담.

5) 감사·롤백

몇 십만 개 레코드에서 어제 누가 뭘 바꿨는지 추적하기 어려움. GUI 히스토리는 대개 최근 100개 수준.

자체 서버로 대규모 DNS를 운영할 때

TCP-80.NET의 일본 전용서버에서 BIND·PowerDNS·Knot를 직접 운영한다면 몇 만 개 이상 레코드에서 아래 실무를 챙겨야 합니다.

1) PowerDNS + SQL 백엔드

BIND의 파일 기반은 몇 만 개까지는 잘 동작하지만, 그 이상은 SQL 백엔드가 낫습니다. PowerDNS + MySQL/PostgreSQL 조합.

# /etc/powerdns/pdns.conf
launch=gmysql
gmysql-host=127.0.0.1
gmysql-user=pdns
gmysql-dbname=pdns

레코드 조회가 인덱스된 SQL 쿼리로 처리돼 응답 지연이 안정적. 스키마 표준.

CREATE TABLE records (
    id INT AUTO_INCREMENT PRIMARY KEY,
    domain_id INT,
    name VARCHAR(255),
    type VARCHAR(10),
    content VARCHAR(64000),
    ttl INT,
    prio INT,
    INDEX name_index(name),
    INDEX nametype_index(name, type)
);

2) 캐싱 프론트엔드로 dnsdist

권위 서버 앞에 캐시 프론트엔드를 두어 응답 부하 분산. dnsdist가 표준.

newServer({address="127.0.0.1:5300", pool="powerdns"})
setLocal("0.0.0.0:53")
pc = newPacketCache(100000, {maxTTL=86400})
getPool(""):setCache(pc)

캐시 히트 응답이 마이크로초, 미스 응답도 밀리초로 안정.

3) 지역 분산

권위 서버를 여러 대륙에 배포. anycast로 라우팅.

Tokyo (Primary)
  ├── Secondary 1: Seoul
  ├── Secondary 2: Singapore
  └── Secondary 3: Frankfurt

같은 IP를 여러 서버가 anycast로 광고하면 사용자 가장 가까운 서버가 응답. Cloudflare가 하는 일이 이거고, 자체로도 BGP 세션 있으면 가능.

4) 증분 존 전송(IXFR)만 사용

큰 존에서 AXFR로 매번 전체 전송하면 부하 큼. IXFR로 변경분만.

# BIND에 IXFR 강제
options {
    request-ixfr yes;
    provide-ixfr yes;
};

SOA SERIAL을 매 변경마다 정확히 올려야 IXFR 정확도가 유지됨.

5) 코드 기반 관리 (dnscontrol·octoDNS)

GUI로 몇 만 개 레코드를 관리하는 건 무리. 코드로 정의하고 CI에 태워야 함.

// dnscontrol
var IPS = require_glob("./ips/*.json");
D("example.com", REG_NONE, DnsProvider(BIND),
  IPS.map(function(ip) {
    return A(ip.hostname, ip.address);
  })
);

파일이 git에 있으니 diff·리뷰·롤백 표준 워크플로우.

6) 감사 로그

레코드 변경마다 이벤트를 로그에.

CREATE TABLE dns_audit (
    id INT AUTO_INCREMENT PRIMARY KEY,
    changed_at TIMESTAMP,
    changed_by VARCHAR(64),
    action VARCHAR(20),
    domain VARCHAR(255),
    old_value TEXT,
    new_value TEXT
);

PowerDNS는 hook 스크립트로, 자체 API 앞단에 audit middleware를 두는 것도 방법.

7) DNSSEC 자동 서명

대규모 존에서 수동 서명은 불가능. PowerDNS는 built-in 자동 서명 매우 편함.

pdnsutil secure-zone example.com
pdnsutil rectify-all-zones

키 롤오버도 built-in.

언제 관리형 DNS로 옮기는 게 나은가

자체 관리의 반대 방향. 아래 조건이면 Cloudflare·Route53 같은 관리형이 실용적.

  • 존이 한두 개, 레코드가 몇 백 이하.
  • 지역 분산·anycast를 스스로 하기 부담.
  • DNSSEC·DDoS를 관리형에 위임하고 싶음.
  • 팀 규모가 작아 인프라 운영 리소스 최소화.

관리형은 무료 티어도 매우 넉넉해서 소규모엔 자체 운영이 오히려 낭비입니다.

하이브리드 접근

가장 실용적인 구조는 종종 하이브리드.

  • 공개 프로덕션 도메인: 관리형(anycast·DDoS·DNSSEC 자동)
  • 내부·인프라 도메인: 자체(비용·제어·통제)
  • 개발·CI 도메인: 자체 + API로 즉시 갱신

Cloudflare가 이번에 계정 수준 할당량을 나눈 이유도 이 하이브리드 사용 패턴 반영. 공개와 내부를 다른 카테고리로 카운트합니다.

마무리

DNS는 규모가 커지면 다른 문제 세트가 등장합니다. Cloudflare의 이번 정책 변화는 그 큰 규모 사업자의 실무를 GUI·API 정책에 반영한 것.

자체 서버로 대규모 DNS를 다뤄야 하는 분은 위 실무를 참고하시면 됩니다. TCP-80.NET의 일본 전용서버에서 PowerDNS·dnsdist·BIND 세팅이 필요하신 경우 @tcp80net 텔레그램으로 문의 주시면 됩니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 DNS 서버 운영 실무(PowerDNS SQL 백엔드·dnsdist 캐싱·anycast·IXFR·dnscontrol·감사 로그·DNSSEC 자동 서명·하이브리드)는 원문에 없는 자체 추가 내용입니다.

Cloudflare Enterprise 정책·할당량·UI는 시점에 따라 다를 수 있으니 최신 정보는 원문 및 Cloudflare Enterprise 담당자를 통해 확인하시기 바랍니다.