2026년 5월 20일 Cloudflare가 DNS 관리 화면을 재설계해서 공개했습니다. 열 크기 조정, 행 고정, AND/OR 고급 필터, 모바일 최적화가 골자입니다. UI 리뉴얼 자체가 큰 뉴스는 아니지만, “DNS 레코드를 몇백·몇천 개 관리해야 하는 사업자”에게는 실무 개선입니다.

이 소식을 계기로 자체 DNS 서버(BIND·PowerDNS·Knot)를 운영할 때 놓치기 쉬운 관리 실무를 함께 정리합니다. Cloudflare를 안 쓰거나, 부분적으로만 쓰는 경우에 유용합니다.

Cloudflare가 개선한 것

  • 열 크기 조정: 긴 값(SPF·DKIM·긴 TXT)이 잘려 보이지 않도록.
  • 행 고정: 특정 레코드를 스크롤해도 상단에 유지.
  • AND/OR 필터: “타입=A AND 값 포함 ‘192.168’” 같은 복합 조건.
  • 모바일 최적화: 태블릿·폰에서도 편집 가능.

한 도메인에 A·AAAA·MX·TXT·CNAME 수십 개가 붙는 큰 도메인 관리자에게는 실질적 개선입니다. SPF·DKIM·DMARC 같은 긴 TXT 레코드를 다루는 이메일 관리자에게 특히 이득.

왜 대량 DNS 관리가 어려운가

DNS 레코드 수가 100개를 넘어가면 다음 문제들이 발생합니다.

  • 중복·충돌: 같은 서브도메인에 A와 CNAME이 둘 다 있으면 안 됨.
  • TTL 관리: 마이그레이션 전 TTL 낮추기·다시 올리기.
  • 레코드 감사: 옛 서비스로 향하는 orphan 레코드가 남아 있으면 하이재킹 위험(dangling DNS).
  • 일괄 편집: 100개 레코드의 값 일부만 바꿔야 하는 상황.

Cloudflare의 이번 UX 개선은 이 문제를 GUI 관점에서 완화한 것. 그러나 자체 DNS 서버는 여전히 텍스트 파일·SQL·API로 관리합니다.

자체 DNS 서버 운영자를 위한 관리 팁

TCP-80.NET의 일본 전용서버에 BIND·PowerDNS·Knot를 직접 올려 운영하는 경우 (또는 도메인 등록만 자체 관리하는 경우), 아래 실무를 참고하시면 좋습니다.

1) 존 파일을 git으로 버전 관리

# BIND 존 파일
/etc/bind/zones/example.com.zone

# git 초기화
cd /etc/bind/zones
git init
git add . && git commit -m "initial zones"

레코드 하나 바꿀 때마다 diff·되돌리기 가능. 실수로 SPF 지운 사건이 반나절 뒤에 발견되어도 되돌릴 수 있음.

2) octoDNS·dnscontrol로 코드로 관리

큰 도메인은 GUI가 아니라 코드로 관리하는 게 낫습니다. 두 도구가 표준.

  • octoDNS: Python 기반. YAML로 존 정의.
  • dnscontrol: Go 기반. DSL(JavaScript 유사)로 정의.

한 정의 파일에서 여러 프로바이더(Cloudflare, Route53, 자체 BIND)에 동시 배포. 이걸 CI에 연결하면 PR·리뷰·롤백까지 자동화.

// dnscontrol 예시
D("example.com", REG_NONE, DnsProvider(BIND),
  A("@", "203.0.113.10"),
  A("www", "203.0.113.10"),
  MX("@", 10, "mail.example.com."),
  TXT("@", "v=spf1 ip4:203.0.113.10 ~all")
);

3) TTL 마이그레이션 자동화

서버 이전 전 TTL 낮추기, 이전 후 다시 높이기. 매번 손으로 하기 귀찮으니 스크립트.

#!/bin/bash
# lower-ttl.sh
sed -i 's/^\([[:space:]]*\)3600$/\160/g' /etc/bind/zones/example.com.zone
rndc reload example.com
# 며칠 대기 후 다시 3600으로 복원하는 스크립트 별도로

4) 정기 orphan 감사

DNS 레코드 중 실제 서비스로 향하지 않는 orphan을 정기적으로 스캔.

# example.com의 모든 A 레코드 → 실제 응답 확인
for host in $(dig +short example.com any); do
  curl -s -o /dev/null -w "%{http_code}\n" http://$host
done

orphan A/CNAME 레코드가 예전 클라우드 인스턴스 IP를 가리키고 그 IP가 다른 고객에게 재할당되면 하이재킹이 됩니다(dangling DNS 취약점). 옛 이벤트 페이지·마이크로사이트 등이 위험 지점.

5) DNSSEC 서명 자동화

DNSSEC은 좋지만 키 롤오버·서명 갱신 관리가 번거로움. dnssec-tools 또는 PowerDNS의 built-in 자동 서명 활용.

# BIND 자동 서명
dnssec-signzone -A -3 <salt> -N INCREMENT -o example.com \
  -t example.com.zone

키 롤오버 스케줄은 cron에.

6) 이중화

DNS 서버 한 대만으로는 위험. Primary + Secondary 구조.

zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { <secondary IP>; };
    also-notify { <secondary IP>; };
};

Secondary는 지리적으로 분산된 위치에 두는 게 이상적. 도쿄 Primary + 서울 또는 싱가포르 Secondary.

7) 모니터링

dig을 cron으로 돌려 응답·SERIAL·응답 시간을 그래프화. Prometheus의 blackbox_exporter가 실용적.

# blackbox.yml
modules:
  dns_check:
    prober: dns
    dns:
      query_name: "example.com"
      query_type: "A"

Cloudflare + 자체 DNS 하이브리드도 가능

전부 Cloudflare로 몰지 않고, 일부 존은 자체 DNS로 유지하는 하이브리드도 실용적입니다.

  • 프로덕션 도메인 → Cloudflare (전 세계 anycast)
  • 내부 관리 도메인 → 자체 BIND (VPN 안에서만 응답)
  • 개발·스테이징 도메인 → 자체 PowerDNS + API로 CI에서 즉시 갱신

이 하이브리드가 실무에서 상당히 흔한 조합입니다. Cloudflare의 안정성·anycast + 자체 DNS의 제어성·비용 절감을 모두 취함.

언제 자체 DNS를 안 쓰는 게 나은가

  • 도메인 수·레코드 수가 적고 관리 시간이 아까울 때.
  • 지리적 분산이 필요한데 자체 서버가 한 지역에만 있을 때.
  • DNSSEC·DDoS·anycast를 스스로 관리할 여력이 없을 때.

이 경우엔 Cloudflare·Route53 같은 관리형 DNS가 사실상 무료(또는 저렴)에 안정적이라 자체 운영이 낭비입니다.

반대로 내부 도메인·특수 정책·규제 준수·비용 최적화가 필요한 경우 자체 DNS의 가치가 있습니다.

마무리

Cloudflare DNS UX 리뉴얼은 그 자체로는 작은 뉴스지만, 대량 DNS 관리라는 실무를 되돌아보게 하는 계기가 됩니다. 자체 서버로 웹사이트를 운영하시는 분은 이 참에 존 파일 git 관리·orphan 감사·이중화를 점검해보시길 권합니다.

TCP-80.NET의 일본 전용서버에서 자체 DNS를 운영하시는 분은 @tcp80net 텔레그램으로 문의 주시면 BIND·PowerDNS 세팅·마이그레이션을 지원해 드립니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 DNS 서버 운영 팁(BIND·PowerDNS·Knot·octoDNS·dnscontrol·orphan 감사·DNSSEC 자동화·이중화·모니터링)은 원문에 없는 자체 추가 내용입니다.

Cloudflare 제품 옵션명·UI는 시점에 따라 다를 수 있으니 최신 정보는 원문 및 Cloudflare 대시보드에서 확인하시기 바랍니다.