VPS 네트워크를 위한 프라이빗 DNS: 작동 방식과 필요한 시점

세 번째 서버를 띄우고, 서버들이 IP 대신 이름으로 서로를 찾게 하려고 "private DNS VPS"를 검색합니다. 세 개의 결과가 나오는데 서로 맞지 않습니다. 하나는 휴대폰의 조회를 암호화하는 Android 설정입니다. 하나는 도메인의 네임서버에 브랜드를 입히는 cPanel 가이드입니다. 하나는 프라이빗 호스팅 영역에 대한 AWS 문서입니다. 2026년 7월 20일, Cloudflare가 Internal DNS를 정식 출시했습니다 그리고 이를 "때로는 프라이빗 DNS라고도 불린다"고 설명했습니다. 이제 이 용어 충돌은 인프라 공급업체에서도 비롯됩니다.

이 용어는 과부하 상태입니다. 이 글은 서로 다른 의미를 구분한 다음 VPS 네트워킹 의미에 집중합니다. 즉 서버 간 통신을 위한 내부 DNS 영역입니다. 끝까지 읽으면 어떤 시스템이 필요한지 식별하고, 여러분의 서버군에 프라이빗 DNS가 필요한지 판단하며, 흔한 설계 실수를 피할 수 있습니다.

요약

• "프라이빗 DNS"는 서로 무관한 최소 세 가지 시스템을 가리킵니다. 서버 네트워크를 위한 내부 DNS 영역, Android의 DNS-over-TLS 암호화 기능, 그리고 cPanel의 브랜드 네임서버입니다. 이 글은 첫 번째 의미로 이 용어를 사용합니다. 즉 VPS 네트워크를 위한 내부 DNS 영역입니다.
• VPS 프라이빗 DNS 영역은 네트워크 범위의 내부 네임스페이스로, db.internal.example.com 같은 호스트명을 프라이빗 IP에 매핑합니다. 이 영역의 레코드는 공용 DNS에 공개되지 않습니다.
• IP가 고정된 서버 몇 대뿐이라면 /etc/hosts 정말로 충분합니다. 내부 DNS 서버는 서버군이 커지거나, IP가 자주 바뀌거나, 서비스에 안정적인 이름 확인이 필요해질 때 비로소 값어치를 합니다.
• 대부분의 운영 환경 VPS 네트워크에서는 다음과 같이 직접 소유한 서브도메인을 사용하세요. internal.example.com. .internal 네임스페이스는 네트워크 간 이름 충돌, 사설 CA 기반 인증서 관리, 특수한 DNSSEC 처리를 감수할 수 있는 격리된 환경에서만 사용하세요. mDNS가 예약한 .local은 피하세요.

이 글이 다루지 않는 것

이 글은 프라이빗 DNS의 VPS 네트워킹 의미에만 한정합니다. 관련 없는 소비자용 및 호스팅 브랜드 용도는 다루지 않습니다.

• 휴대폰에서 Android의 프라이빗 DNS 또는 DNS-over-TLS 설정을 구성하는 방법.
• 호스팅 브랜드를 위한 cPanel 프라이빗 네임서버 설정.
• BIND 9, Unbound, dnsmasq, CoreDNS의 전체 설치 과정 안내. 여기서 구현은 단계별 설정이 아니라 참고 수준에 머무릅니다.
• 1.1.1.1이나 NextDNS 같은 암호화 소비자용 리졸버는 네트워킹 의미와 구분하는 선을 넘어서는 다루지 않습니다.

"프라이빗 DNS"는 실제로 무엇을 뜻하는가?

"프라이빗 DNS"는 하나의 시스템이 아닙니다. 이 말은 서로 무관한 최소 세 가지를 가리킵니다. VPS나 VPC 네트워크 내부에서 내부 호스트명을 확인하는 네트워크 제한 DNS 영역, Android의 DNS-over-TLS 암호화 기능, 그리고 cPanel의 맞춤 브랜드 권한 네임서버입니다. 이 글은 첫 번째, 즉 서버들이 서로를 찾기 위해 조회하는 내부 영역을 다룹니다. 네 번째로 느슨한 용법도 있습니다. "프라이빗"으로 마케팅되는 암호화된 공용 리졸버입니다.

이 네 가지 의미는 이름만 같을 뿐 다른 공통점은 없습니다.

Cloudflare의 Internal DNS 정식 출시 발표는 첫 번째 의미의 현행 관리형 사례이자, 이 용어 충돌이 새삼 눈에 띄게 된 이유 중 하나입니다. 인프라 공급업체가 이제 출시 문구에서 "프라이빗 DNS"를 내부 DNS의 동의어로 쓰고 있기 때문입니다. 그 발표가 설명하는 시스템, 즉 Enterprise 고객을 위한 Gateway Resolver와 Internal Authoritative DNS의 조합은 여러분이 VPS 서버군에 직접 구축하는 것과 같은 범주의 시스템이며, 다만 관리형일 뿐입니다.

이 섹션의 결론: "프라이빗 DNS"라 불리는 주요 시스템들이 공유하는 것은 이름표이지 기능이 아닙니다. 설정 가이드를 따르기 전에 어떤 의미인지부터 확인하세요.

프라이빗 DNS는 VPS 네트워크에서 어떻게 작동하는가?

VPS 프라이빗 DNS 영역은 여러분의 서버가 사용하도록 설정된 리졸버가 제공하는 네트워크 범위 네임스페이스입니다. 이 영역은 db.internal.example.com 같은 내부 호스트명을 여러분이 통제하는 대역의 프라이빗 IP에 매핑합니다. 이 레코드는 공용 DNS에 공개되지 않습니다. 다만 질의 자체는 리졸버에 닿기 전에 사설 터널이나 관리형 DNS 컨트롤 플레인을 거칠 수 있습니다. 바로 이 분리가 프라이빗 DNS와 공용 DNS를 가르는 핵심입니다. 프로토콜은 같지만 영역의 가시성과 접근 범위가 다릅니다.

세 가지 요소가 일을 나눠 맡습니다. 권한 서버 또는 영역 소스가 내부 영역과 그 레코드를 보관합니다. 리졸버가 서버들이 보내는 질의에 응답합니다. 그리고 영역의 A 및 AAAA 레코드가 내부 호스트명을 사설 주소에 매핑하므로, app.internal.example.com 은(는) 애플리케이션 계층으로 확인되고 db.internal.example.com 은(는) 데이터베이스로 확인됩니다. 다른 레코드 유형은 별칭이나 서비스 정보를 제공할 수 있습니다. 영역과 리졸버 경로가 올바르게 설정되어 있으면, 리졸버는 내부 질의를 공용 DNS 루트로 보내지 않고 로컬에서 응답합니다.

클라우드 플랫폼들은 이를 머신이 아니라 네트워크 단위로 한정하는데, 이는 유용한 참고 모델입니다. AWS Route 53 프라이빗 호스팅 영역 은(는) VPC에서 enableDnsHostnames와 enableDnsSupport가 모두 true로 설정된 경우에만 동작하며, 리졸버는 해당 영역에 연결한 모든 VPC에 대해 프라이빗 영역에서 응답합니다. Google Cloud 프라이빗 영역 은(는) 승인된 VPC 네트워크로 범위가 한정되며, 표준 VPC 확인 순서 에서는 아웃바운드 서버 정책이 경로를 바꾸지 않는 한 공용 DNS보다 먼저 확인됩니다. 이를 플랫폼 튜토리얼이 아니라 패턴의 예시로 읽으세요. 직접 운영하는 내부 DNS 서버도 같은 발상이며, 다만 여러분의 VPS 위에서 돌아갈 뿐입니다.

영역을 공용 DNS에서 빼두는 것은 일의 절반일 뿐입니다. DNS 서비스를 사설 인터페이스에 바인딩하거나, UDP 및 TCP 53 포트를 사설 네트워크나 VPN으로 제한하세요. 재귀 서비스를 공개 인터넷에 노출하지 마세요. 개방형 리졸버는 DNS 증폭 공격에 악용될 수 있습니다.

프라이빗 영역과 공용 영역은 동일한 DNS 레코드 및 캐싱 모델을 사용합니다. 레코드에는 TTL이 있고, 캐싱 리졸버는 보통 그 TTL이 만료될 때까지 응답을 재사용합니다. 다만 리졸버별 설정이 실제 캐시 시간을 바꿀 수 있습니다. 이 동작은 도메인을 VPS로 연결하는 가이드에서 다루며, 여기에는 DNS 전파와 TTL 기초가 포함되므로 여기서 다시 설명하지 않습니다.

VPS 네트워크에 프라이빗 DNS가 실제로 필요한 시점은 언제인가?

고정된 서버가 두세 대뿐이라면 /etc/hosts 정말로 충분합니다. 내부 DNS 서버는 서버군이 커지거나, IP가 주기적으로 바뀌거나, 애플리케이션에 안정적인 서비스 디스커버리가 필요할 때 값어치를 합니다. 진짜 기준은 정해진 서버 대수가 아니라 운영 복잡도입니다.

/etc/hosts 은(는) 모든 리눅스 머신에 이미 존재하는, 호스트명과 IP를 잇는 정적 매핑입니다. 데몬도 존 파일도 필요 없지만, 오래되거나 서로 어긋난 사본은 실제 장애 원인이 됩니다. 각 서버의 사설 IP를 이 파일에 추가하고 사본들을 동기화해 두면 머신들이 이름으로 서로를 찾을 수 있습니다. 작고 안정적인 서버군에서는 이것이 정답이며, 대신 BIND 9를 끌어오는 것은 아무 이득 없이 관리할 데몬만 하나 늘리는 일입니다.

이 방식은 세 가지 상황에서 한계에 부딪힙니다. 서버를 자주 추가하고 제거하면, 정적 파일을 모든 호스트에서 일관되게 유지하는 일이 수작업 노동으로 변합니다. 오토스케일링, 재구축, 공급자의 재할당 등으로 IP가 바뀌면 파일은 소리 없이 낡아 갑니다. 그리고 컨테이너나 격리된 런타임이 호스트의 항목을 물려받지 못하면, 그 매핑은 더 이상 보편적이지 않게 됩니다. 이 중 어느 하나라도 해당되면 그것이 진짜 기준입니다. 서버 대수만으로는 거친 어림짐작일 뿐, 실제 신호가 아닙니다.

이 섹션의 결론: 기준은 서버 대수가 아니라 운영상의 변동입니다. 변화가 없는 열 대짜리 서버군은 /etc/hosts만으로 버틸 수 있지만, 매일 밤 재구축되는 세 대짜리 서버군은 아마 그러지 못할 것입니다.

어떤 DNS 서버를 운영해야 하는가: BIND 9, Unbound, dnsmasq, CoreDNS?

서버군의 형태에 따라 고르세요. dnsmasq는 가벼운 DNS와, 필요한 경우 같은 데몬에서 제공하는 DHCP를 원하는 소규모 네트워크에 맞습니다. Unbound는 군더더기 없는 검증형 재귀 리졸버로, 소규모 로컬 영역에도 응답할 수 있습니다. BIND 9는 가장 넓은 설정 표면과 함께 폭넓은 권한 및 재귀 기능을 제공합니다. CoreDNS는 DNS가 서비스 디스커버리의 일부인 컨테이너 및 Kubernetes 환경에 어울립니다.

선택 논리는 간단합니다. hosts 형식 파일에 기반한 작은 리졸버가 필요하거나 이미 DHCP 임대를 나눠 주고 있다면, dnsmasq는 움직이는 부품 하나를 줄여 줍니다. 주로 외부로 전달하면서 소규모 내부 영역에 응답하는 검증형 리졸버가 필요하다면, Unbound가 BIND 9 전체를 배포하지 않고도 그 좁은 기능 집합을 제공합니다. 완전한 권한 제어와 위임, 그리고 새벽 3시에 기댈 수 있는 가장 방대한 문서가 필요하다면, 설정 표면이 넓더라도 BIND 9가 보수적인 선택입니다. DNS가 이미 컨테이너나 Kubernetes 서비스 디스커버리 스택의 일부라면, CoreDNS가 그 자리에 자연스럽게 들어맞습니다. 경험칙은 서버군의 형태를 감당하는 가장 작은 것을 돌리라는 것입니다.

운영 환경에서는 하나의 DNS 인스턴스가 모든 내부 이름으로 가는 유일한 경로가 되게 하지 마세요. 최소 두 개의 DNS 인스턴스 영역에 응답할 수 있는 인스턴스를 두 개 이상 운영하고, 가능하다면 서로 다른 장애 도메인에 배치하며, 클라이언트가 둘 다 접근하도록 설정하세요. 그러지 않으면 DNS 장애 한 번으로 멀쩡한 서비스가 죽은 것처럼 보일 수 있습니다.

내부 도메인 이름을 어떻게 정해야 하는가: .internal, .local, 아니면 서브도메인?

대부분의 운영 환경 VPS 네트워크에서는 다음과 같이 직접 소유한 서브도메인을 사용하세요. internal.example.com. .internal 네임스페이스는 네트워크 간 이름 충돌, 사설 CA 기반 인증서 관리, 특수한 DNSSEC 처리를 감수할 수 있는 격리된 환경에서만 사용하세요. mDNS가 예약한 .local은 피하세요.

.local의 문제는 구체적입니다. RFC 6762 은(는) .local로 끝나는 이름에 Multicast DNS를 위한 특별한 처리를 부여합니다. 따라서 같은 접미사를 쓰는 유니캐스트 BIND 9 또는 Unbound 영역은 Apple 기기나 mDNS를 지원하는 다른 시스템의 mDNS 동작과 충돌할 수 있습니다. 클라이언트별 임시방편에 기대기보다 다른 네임스페이스를 사용하세요.

프로 팁: .local 내부 영역을 물려받았다면 기술 부채로 취급하세요. 일부 클라이언트는 .local 질의를 여러분의 유니캐스트 DNS 서버가 아니라 mDNS로 보내는데, 그러면 클라이언트마다 다르거나 간헐적으로 보이는 장애가 생길 수 있습니다.

ICANN 이사회가 .internal을 영구적으로 예약했습니다 . 2024년 7월, 앞선 SSAC 권고에 따라 공용 DNS 루트에서의 위임이 막혔습니다. 그 아래의 이름들은 설계상 전 세계 DNS를 통해 확인되지 않습니다. 여기에는 대가가 따릅니다. .internal 이름은 전 세계적으로 고유하지 않고, 공용 인증 기관이 그에 대한 인증서를 발급하리라 기대할 수 없으며, 전 세계 신뢰 앵커에 의존해 DNSSEC를 검증하는 리졸버는 이를 확인하지 못합니다. .internal에서 HTTPS가 필요하다면 사설 CA 운영을 계획하세요.

여기서 두 가지를 구분해야 합니다. ICANN의 예약은 최종적입니다. 그와 별개로 활성 Internet-Draft인 draft-davies-internal-tld-06이(가) 2026년 5월 6일에 발표되어, 이 네임스페이스를 문서화하고 RFC 1918의 사설 주소 지정과 비교했습니다. 이는 여전히 진행 중인 Internet-Draft일 뿐 발행된 RFC가 아니므로, .internal은 IETF 표준이 아니라 ICANN이 예약한 사설 용도 최상위 도메인으로 설명하세요.

대부분의 VPS 환경에서는 여러분이 통제하는 도메인의 서브도메인이 더 안전한 기본 선택입니다. ISC는 서브도메인 계층 구조를 권장합니다. 예컨대 자기 도메인의 내부 서브도메인을 쓰는 편이, 같은 상위 영역의 내부용과 공개용 사본을 따로, 그것도 불완전하게 유지하는 것보다 낫다는 뜻입니다. 이 선호는 취향의 문제가 아닙니다. 다음 절에서 다루는 장애를 막아 줍니다.

이 섹션의 결론: 네임스페이스 결정은 오래 갑니다. 여러분이 통제하는 서브도메인은 전 세계적 고유성을 지키고 공용 PKI와도 맞물리기 때문에 대부분의 운영 환경에서 기본값입니다. 격리된 사설 네임스페이스가 더 잘 맞고 DNSSEC, 인증서, 이름 충돌이라는 대가를 감수할 수 있을 때 .internal을 쓰세요.

스플릿 호라이즌 DNS와 그것을 망가뜨리는 실수들

스플릿 호라이즌 DNS는 같은 호스트명에 대해 묻는 쪽에 따라 다른 답을 줍니다. 내부에서는 사설 IP, 외부에서는 공인 IP입니다. 이것이 가장 자주 깨지는 이유는 같은 도메인에서의 NXDOMAIN 함정, 의도한 뷰를 우회하는 대체 리졸버, 그리고 예상한 상위 서버에 닿지 못하는 컨테이너 DNS 경로 때문입니다. 제대로 동작시키려면 한 가지가 아니라 세 가지가 동시에 맞아야 합니다.

NXDOMAIN 함정은 ISC가 직접 경고하는 바로 그 실패입니다. 내부 서버가 상위 도메인에 대해 권한을 갖고 있는데 그 영역 사본에 www 호스트 같은 공개 레코드가 빠져 있다면, 그 이름을 조회한 내부 클라이언트는 공개 영역에 레코드가 있는데도 NXDOMAIN을 받습니다. 내부 영역이 권한을 갖고 있어서, 상위 도메인에 대해 공용 DNS로 넘어가지 않기 때문입니다. 앞의 명명 절에서 다룬 서브도메인 계층 방식이 ISC가 선호하는 설계인 이유가 바로 이것입니다.

프로 팁: 같은 도메인을 쓰는 스플릿 호라이즌 구성으로 서버를 돌리기 전에, 네트워크 안에서 그 도메인의 잘 알려진 공개 이름을 조회해 보세요. 외부에서는 멀쩡히 확인되는 이름에 NXDOMAIN이 돌아온다면 바로 이 함정의 징표입니다.

놓치기 쉬운 함정이 세 가지 더 있습니다. 호스트나 컨테이너에 설정된 대체 리졸버가 이 분리를 우회할 수 있습니다. 리졸버 구현에 따라 타임아웃 후에 조회되기도 하고 병렬로 조회되기도 해서 응답이 달라질 수 있습니다. Docker 기본 브리지의 컨테이너는 시작할 때 호스트의 DNS 설정 사본을 받는 반면, 사용자 정의 네트워크의 컨테이너는 Docker의 내장 리졸버 127.0.0.11에 질의합니다. 그 리졸버는 외부 조회를 호스트나 컨테이너에 설정된 DNS 서버로 전달하므로, split-DNS 동작은 컨테이너 자체의 리졸버 파일만이 아니라 Docker와 호스트 설정에 달려 있습니다. 내부 서비스가 다음과 같은 리버스 프록시 뒤에 있다면, Nginx 프록시 관리자요청한 호스트명을 인증서가 포함하지 않거나 발급 CA를 클라이언트가 신뢰하지 않을 때 인증서 검증이 실패할 수 있습니다. 내부적으로 다른 인증서를 쓰는 것 자체는 잘못이 아닙니다. 이것들은 설정의 빈틈이지 도구의 결함이 아닙니다.

원격 클라이언트도 같은 장애를 겪을 수 있습니다. 자체 호스팅 VPN 이(가) DNS 질의를 의도한 내부 리졸버로 전달하거나 라우팅하지 않을 때입니다.

보안 측면도 있습니다. 내부 호스트명과 사설 IP가 공개 DNS 레코드로 새어 나가면, 내부 명명 및 주소 체계의 일부를 조회하는 누구에게나 드러내는 셈입니다. 스플릿 호라이즌이 존재하는 이유 중 하나가 바로 그 지도를 내부에 두는 것인데, 잘못 설정된 공개 영역은 그것을 조용히 무너뜨립니다.

이 섹션의 결론: 스플릿 호라이즌의 실패는 설정의 함정이지 도구의 결함이 아닙니다. 올바름은 명명 규율, 각 클라이언트가 실제로 어떤 리졸버에 질의하는지 아는 것, 그리고 영역 범위를 제대로 잡는 것에 달려 있지 어느 한 가지 설정에 달려 있지 않습니다.

읽기

도메인을 VPS에 연결하는 방법: 빠른 가이드

결론: 알맞은 프라이빗 DNS 설계 고르기

이제 여러분이 말하는 "프라이빗 DNS"가 어떤 시스템인지 가려낼 수 있습니다. VPS 네트워킹에서는 Android의 DNS-over-TLS 설정이나 브랜드 권한 네임서버가 아니라 내부 DNS 영역을 뜻합니다. 서버군이 작고 안정적이라면 /etc/hosts 은(는) 충분히 방어할 수 있는 선택입니다. 그렇지 않다면 직접 소유한 서브도메인을 기본 네임스페이스로 쓰고, 서버군에 맞는 가장 작은 DNS 서버를 고르며, 접근 권한과 이중화, 내부 대 공개 영역 범위를 명시적으로 유지하세요. .internal은 격리된 네임스페이스가 더 잘 맞고 인증서, DNSSEC, 이름 충돌이라는 대가를 감수할 때만 쓰세요.

자주 묻는 질문

Android의 프라이빗 DNS는 VPS의 프라이빗 DNS 서버와 같은 것인가요?

아닙니다. Android 프라이빗 DNS는 기기의 조회를 전송 구간에서 보호하는 DNS-over-TLS 기능입니다(853 포트에서의 쿼리 암호화, Android 9에서 추가). VPS의 프라이빗 DNS 서버는 네트워크 전반에서 내부 호스트명을 사설 IP로 확인해 줍니다. 하나는 쿼리를 암호화하고, 다른 하나는 내부 네임스페이스를 만듭니다. 서로 무관한 문제를 해결합니다.

프라이빗 DNS와 공용 DNS의 차이는 무엇인가요?

프라이빗 DNS는 특정 네트워크, VPN, 클라우드 환경의 인가된 클라이언트에게만 영역을 공개합니다. 공용 DNS는 인터넷의 리졸버가 조회할 수 있도록 레코드를 게시합니다. 둘 다 같은 DNS 레코드 유형과 캐싱 모델을 씁니다. 차이는 누가 그 영역에 닿을 수 있고 레코드가 어디에서 보이느냐입니다.

프라이빗 DNS와 암호화 DNS의 차이는 무엇인가요?

DoT나 DoH 같은 암호화 DNS 프로토콜은 전송 중인 DNS 질의를 보호합니다. 네트워킹 의미의 프라이빗 DNS는 내부 이름을 위한 네트워크 범위 네임스페이스를 만듭니다. 암호화는 질의가 어떻게 이동하는지를 바꾸고, 프라이빗 영역은 어떤 이름이 존재하며 누가 그것을 확인할 수 있는지를 바꿉니다.

내부 호스트명에 .internal을 써도 안전한가요?

네, 다만 단서가 있습니다. ICANN이 2024년 7월에 .internal을 공용 위임에서 영구히 제외했으므로 사설 리졸버에서 서비스할 수 있습니다. 그러나 전 세계적으로 고유하지 않고, 공용 인증 기관이 이에 대한 인증서를 발급하리라 기대할 수 없으며, 전 세계 신뢰 앵커에 의존하는 DNSSEC 검증기는 이를 확인하지 못합니다. 대부분의 운영 환경 VPS 네트워크에서는 직접 소유한 서브도메인이 더 안전한 기본 선택입니다.

프라이빗 DNS 레코드는 공용 DNS와 같은 TTL과 캐싱을 사용하나요?

네. 프라이빗 영역과 공용 영역은 동일한 TTL 기반 캐싱 모델을 사용합니다. 레코드에는 TTL이 있고, 캐싱 리졸버는 보통 그 값이 만료될 때까지 응답을 재사용합니다. 물론 리졸버별 설정이 실제 캐시 시간을 바꿀 수 있습니다. 자세한 원리는 DNS 전파와 TTL 동작 에서 확인하세요.