스플릿-호라이즌 DNS (내부 vs. 외부)

같은 질문—"mail.company.com은 어디에 있나요?"—이라도 누가 묻느냐에 따라 다른 진실된 답을 받습니다. 회사 네트워크에 있는 직원은 내부 IP 주소를 받습니다. 인터넷 너머의 고객은 공인 IP 주소를 받습니다. 두 답 모두 맞습니다. 하나의 이름이 동시에 두 가지를 의미하는 것입니다.

이것이 스플릿-호라이즌 DNS입니다. 네트워크에 관한 근본적인 진실을 인정하는 방식입니다: 내부와 외부는 서로 다른 세계이며, 같은 호스트명이라도 어느 세계에 서 있느냐에 따라 정당하게 다른 곳을 가리킵니다.

해결하는 문제

회사 웹사이트를 내부 서버에서 호스팅한다고 상상해 보세요. 외부 방문자는 공인 IP 주소를 통해 접속합니다—요청이 인터넷을 거쳐 방화벽에 도달하고, 로드 밸런서를 통과한 뒤 마침내 서버에 닿습니다.

이제 사무실의 직원이 같은 웹사이트를 방문한다고 해봅시다. 동일한 공인 IP를 쓴다면 이상한 일이 벌어집니다: 트래픽이 내부 네트워크를 빠져나가 방화벽의 외부 인터페이스에 도달하고, 검사와 허용 과정을 거친 뒤 다시 내부로 돌아와—코앞에 있던 서버에—접속하게 됩니다. 패킷이 바로 옆에 있는 이웃을 만나러 보안 인프라를 한 바퀴 돌고 온 셈입니다.

스플릿-호라이즌 DNS는 이런 불합리함을 없애줍니다. 내부 사용자는 호스트명을 서버의 내부 주소로 해석하여 직접 연결합니다. 외부 사용자는 공인 주소로 해석하여 적절한 경로를 통해 접속합니다. 같은 호스트명, 다른 답, 그리고 각자의 상황에 맞는 정답입니다.

같은 세계의 두 가지 뷰

스플릿-호라이즌 DNS 서버는 도메인에 대해 내부와 외부, 두 개의 별도 뷰를 유지합니다. 쿼리가 들어오면 서버는 출처를 확인하고 해당 뷰를 참조합니다.

내부 뷰에는 수천 개의 레코드가 있을 수 있습니다: 데이터베이스 서버, 내부 API, 개발 환경, 관리 인터페이스, 백업 시스템. 이 호스트명들은 내부 사용자만을 위해 존재합니다. 외부 쿼리에는 아무 답도 돌아오지 않습니다—"접근 거부"가 아니라, 그냥 침묵입니다. 그 뷰에서는 그 이름 자체가 존재하지 않는 것입니다.

외부 뷰는 그에 비해 단출합니다: 공개 웹사이트, 메일 서버, 아마도 파트너 API 정도. 외부 세계가 접근해야 하는 것들만 담겨 있습니다.

이 분리는 라우팅 최적화 이상의 역할을 합니다. 공격 표면을 줄여줍니다. 공격자가 도메인을 대상으로 DNS 정찰을 수행해도 공개된 서비스만 보입니다. 내부 데이터베이스 서버, 관리자 포털, 개발 환경—이것들은 어디에도 나타나지 않습니다. 공격자가 접근할 수 없는 뷰 안에만 존재할 뿐입니다.

같은 이름, 다른 서비스

때로는 내부와 외부 사용자가 같은 호스트명으로 실제로 다른 서비스에 접근해야 할 때가 있습니다.

api.company.com을 예로 들어보겠습니다. 외부 파트너는 이 엔드포인트를 통해 공개 API에 접속합니다—요청 속도 제한이 있고, 제공 범위가 신중하게 정의되며, 운영 환경에 맞게 견고하게 다듬어진 API입니다. 내부 개발자는 같은 호스트명으로 더 넓은 권한, 상세한 디버깅 출력, 미출시 기능 접근이 가능한 내부 API에 연결해야 합니다.

스플릿-호라이즌 DNS가 없다면 서로 다른 호스트명이 필요합니다: 외부용 api.company.com, 내부용 api-internal.company.com. 개발자는 어느 것을 써야 할지 기억해야 합니다. 문서는 제각각이 됩니다. 누군가는 반드시 잘못된 주소를 하드코딩합니다.

스플릿-호라이즌 DNS를 사용하면 두 그룹 모두 api.company.com을 씁니다. DNS 인프라가 누가 묻느냐에 따라 알아서 라우팅을 처리합니다. 단순함은 유지되고, 분리는 지켜집니다.

구현 방식

가장 널리 배포된 DNS 서버인 BIND는 named views를 통해 이를 구현합니다. 사설 IP 범위에 해당하는 내부 뷰와 나머지 모든 것에 해당하는 외부 뷰를 정의합니다. 각 뷰는 같은 도메인 이름에 대해 서로 다른 레코드를 담은 자체 존 파일을 갖습니다.

view "internal" {
    match-clients { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    zone "company.com" { file "company.com.internal"; };
};

view "external" {
    match-clients { any; };
    zone "company.com" { file "company.com.external"; };
};

클라우드 DNS 공급자도 설정된 네트워크의 쿼리에만 응답하는 프라이빗 존을 통해 유사한 기능을 제공하며, 공개 존은 인터넷 쿼리를 처리합니다.

일부 조직은 완전히 별도의 DNS 인프라를 운영하기도 합니다: 내부 쿼리에만 응답하는 내부 DNS 서버와, 공개 인터넷을 처리하는 외부 DNS 서버(보통 공급자가 호스팅). 관리해야 할 인프라는 늘어나지만, 격리 수준은 더 강해집니다.

잘못될 수 있는 것들

가장 흔한 오류: 쿼리 출처 오분류. 내부 네트워크가 NAT 게이트웨이나 프록시를 통해 DNS 쿼리를 보냅니다. DNS 서버는 원래 클라이언트가 아닌 게이트웨이의 IP 주소를 봅니다. 그 게이트웨이 IP가 내부 뷰의 매치 목록에 없으면, 내부 사용자가 외부 응답을 받게 됩니다.

해결책은 뷰 정의가 DNS 서버가 실제로 쿼리 출처로 인식하는 모든 IP 주소—게이트웨이, 프록시, 인프라 주소까지—를 포함하도록 하는 것입니다.

또 다른 자주 발생하는 문제: 내부 사용자가 외부 DNS 리졸버를 사용하도록 설정된 경우입니다. 직원의 노트북이 내부 DNS 서버 대신 8.8.8.8을 사용하면, 사무실에 있어도 외부 응답을 받게 됩니다. 스플릿-호라이즌은 쿼리가 스플릿-호라이즌 DNS 인프라에 도달할 때만 작동합니다.

VPN 사용자는 특수한 경우입니다. 직원이 원격으로 연결할 때, DNS 쿼리는 내부 응답을 받아야 합니다—하지만 VPN이 연결된 클라이언트에 내부 DNS 서버 정보를 올바르게 전달하고 DNS 트래픽을 터널을 통해 라우팅할 때만 가능합니다. DNS 쿼리가 로컬 리졸버로 새어나가도록 방치하는 잘못 설정된 VPN은 스플릿-호라이즌 모델을 망가뜨립니다.

하지 못하는 것

스플릿-호라이즌 DNS는 정보를 숨기는 것이지, 접근을 제어하는 것이 아닙니다. 공격자가 DNS를 통해 내부 호스트명을 발견하지 못한다고 해서, 다른 수단으로 네트워크 접근 권한을 얻었을 때 해당 시스템에 접근하지 못하는 건 아닙니다. 네트워크 내부에 들어온 공격자는 다른 내부 사용자와 똑같이 내부 DNS 뷰를 쿼리할 수 있습니다.

적절한 보안을 위해서는 여전히 네트워크 분리, 방화벽, 인증, 권한 부여가 필요합니다. 스플릿-호라이즌 DNS는 정찰 기회를 줄임으로써 이러한 보안 조치들을 보완하지만, 대체하지는 않습니다.

DNS 리바인딩 공격도 스플릿-호라이즌 보호를 우회합니다. 공격자의 악성 웹사이트가 처음에는 외부 IP로 해석되다가(브라우저 보안 검사를 통과하면서), 빠르게 내부 IP 주소로 전환될 수 있습니다. 이 공격은 DNS 인프라가 아닌 브라우저의 동작 방식을 악용합니다. 방어를 위해서는 브라우저 보호 기능과 내부 방화벽 규칙이 필요하며, DNS 설정만으로는 부족합니다.

더 깊은 패턴

스플릿-호라이즌 DNS는 조직이 실제로 작동하는 방식에 관한 진실을 반영합니다: 내부와 외부는 정말로 다릅니다. 신뢰 수준, 접근 패턴, 필요가 모두 다릅니다. 웹사이트든, API든, 메일 서버든—같은 리소스라도 서로 다른 청중에게 정당하게 다른 모습을 보여줍니다.

모든 것이 내부이거나 외부인 하나의 평면 네임스페이스에 이 현실을 억지로 끼워 맞추는 대신, 스플릿-호라이즌 DNS는 이를 그대로 받아들입니다. 같은 이름이 서로 다른 사람에게 다른 것을 의미할 수 있으며, 두 의미 모두 맞습니다.

이것은 꼼수나 임시방편이 아닙니다. 맥락이 중요하다는 인정입니다—DNS 이름 해석이라는 기술적 영역에서도 마찬가지입니다.

스플릿-호라이즌 DNS에 관한 자주 묻는 질문

스플릿-호라이즌 DNS를 사용하려면 클라이언트를 특별히 설정해야 하나요?

아니요. 클라이언트는 여러 뷰가 존재하는지 모른 채 평소처럼 DNS를 쿼리합니다. 어떤 뷰를 사용할지는 쿼리의 출처 IP 주소를 기반으로 DNS 서버가 결정합니다. 이 모든 처리는 서버에서만 이루어지며, 클라이언트 입장에서는 완전히 투명합니다.

클라우드 호스팅 서비스에 스플릿-호라이즌 DNS를 사용할 수 있나요?

네. 대부분의 클라우드 DNS 공급자는 VPC 또는 설정된 네트워크의 쿼리에만 응답하는 프라이빗 존을 지원합니다. AWS Route 53, Google Cloud DNS, Azure DNS 모두 이 기능을 제공하지만, 세부 구현 방식은 각기 다릅니다.

외부 뷰에는 있지만 내부 뷰에 없는 호스트명을 쿼리하면 어떻게 되나요?

외부 사용자는 해당 호스트명을 정상적으로 해석할 수 있지만, 내부 사용자는 NXDOMAIN 응답(도메인이 존재하지 않음)을 받습니다. 특정 공개 서비스를 내부 인프라와 분리하려는 의도적인 경우도 있지만, 대부분은 수정이 필요한 설정 실수입니다.

어떤 뷰를 사용하고 있는지 어떻게 테스트하나요?

DNS 서버에 직접 쿼리를 보내고 응답을 확인하세요. 서로 다른 네트워크 위치에서 dig @your-dns-server hostname.company.com을 실행하고 반환된 IP 주소를 비교하세요. DNS 서버 로그를 확인하면 각 쿼리가 어떤 뷰에서 처리됐는지도 알 수 있습니다.