Bunny DNS, 쿼리 과금 없애고 500개 도메인까지 무료로 푼다

• bunny.net이 Bunny DNS의 쿼리 과금을 완전히 없앴음

  • 계정당 최대 500개 도메인까지 무료 DNS 호스팅 제공
  • 쿼리 제한 없음, 요청당 과금 없음, 엔터프라이즈 플랜 뒤에 숨겨둔 핵심 기능도 없음
  • 스마트 레코드와 헬스 모니터링도 무료 범위에 포함됨

• Bunny DNS는 원래 Bunny CDN의 라우팅 엔진으로 시작한 내부 시스템이었음

  • bunny.net은 전 세계 119개 위치에 네트워크를 운영 중이고, 150만 개 이상 웹사이트에 콘텐츠 전송을 제공함
  • Bunny DNS는 현재 30만 개 이상 도메인과 월 2,000억 건 가까운 쿼리를 처리함
  • 단순히 정적 레코드를 반환하는 DNS가 아니라 지연시간 데이터, 헬스 체크, 자바스크립트 기반 로직으로 요청 목적지를 동적으로 정하는 구조임

• 가격 정책은 꽤 공격적임

  • DNS 자체에는 사용량 기반 과금이 붙지 않음
  • 다만 bunny.net 플랫폼의 기본 정책인 월 1달러 최소 사용액은 그대로 적용됨
  • 갑자기 쿼리가 100만 건 튀었을 때 청구서 걱정하는 상황을 없애겠다는 메시지가 강함

• 마이그레이션 경험도 같이 손봤음

  • 자동 존 스캔 기능이 도메인의 흔한 레코드 이름과 타입을 확인해서 기존 DNS 존을 재구성함
  • 처음부터 수동으로 다 입력하지 않고 몇 가지만 수정하면 되는 흐름을 노림
  • 원하면 BIND 파일 업로드 방식도 지원함

• DNS 레코드에서 바로 CDN과 보안을 켤 수 있게 만든 것도 포인트임

  • 1-Click Acceleration을 켜면 DNS 레코드에서 바로 CDN Pull Zone을 만들고 엣지 네트워크로 트래픽을 라우팅함
  • 1-Click Security를 켜면 Bunny Shield가 엣지에서 일반적인 공격을 필터링하고 디도스 공격을 원본 서버에 닿기 전에 흡수함
  • 성능, 보안, 라우팅을 나중에 덧붙이는 게 아니라 DNS 관리 화면 안에서 묶겠다는 방향임

• IPv6 지원은 “옵션”이 아니라 기본값으로 처리함

  • 모바일 네트워크를 포함해 IPv6가 기본인 환경이 늘고 있다는 판단임
  • Bunny DNS의 네임서버 레코드는 이미 IPv4와 IPv6 양쪽에서 동작함
  • 사용자가 따로 설정하거나 마이그레이션할 필요는 없다고 밝힘

• DNSSEC도 켰는데, 전통적인 불편함을 줄였다고 주장함

  • DNSSEC는 DNS 응답 변조를 막는 데 유용하지만 설정 복잡도와 존 정보 노출 문제가 따라붙음
  • Bunny는 NSEC Black Lies를 써서 도메인 구조를 통째로 훑기 어렵게 만들었다고 설명함
  • “보안은 켜고 싶은데 내부 구조가 드러나는 건 싫다”는 팀에게 꽤 현실적인 디테일임

• 최신 DNS 레코드 타입 지원도 늘렸음

  • HTTPS와 SVCB 레코드로 클라이언트가 서비스에 어떻게 접속해야 하는지 힌트를 줄 수 있음
  • TLSA 레코드는 DANE을 쓰는 환경에서 인증서 검증을 더 강하게 통제할 때 필요함
  • CDS와 CDNSKEY는 DNSSEC 키 관리를 자동화해서 수동 회전 부담을 줄이는 쪽임

---

기술 맥락

• Bunny가 고른 선택은 DNS를 단순 레코드 저장소가 아니라 트래픽 제어 지점으로 올리는 거예요. 왜냐면 사용자가 서비스에 닿기 전 제일 먼저 만나는 레이어가 DNS라서, 여기서 CDN과 보안을 붙이면 운영 흐름이 훨씬 짧아지거든요.

• 무료화도 그냥 가격 인하가 아니에요. 월 2,000억 건 가까운 쿼리를 처리하는 DNS에서 사용량 과금을 없애면, 개발팀은 트래픽 스파이크 때 DNS 청구서를 걱정하지 않고 라우팅 정책 자체에 집중할 수 있어요.

• DNSSEC에 NSEC Black Lies를 붙인 것도 중요한 선택이에요. DNSSEC는 변조 방지에는 좋지만 존 열람 문제가 부담인데, Bunny는 이 부분을 줄여야 실제 사용자가 보안 기능을 켤 거라고 본 거예요.

• HTTPS, SVCB, TLSA 같은 레코드는 당장 화려해 보이진 않지만 최신 웹 인프라에선 점점 필요해져요. 클라이언트 연결 방식, 인증서 검증, 키 관리 같은 결정을 DNS 단계에서 표현할 수 있어야 복잡한 서비스 운영이 덜 수동적이거든요.