기본 DNS 서버는 도메인 이름 시스템(DNS)에서 도메인에 대한 주요 권한 있는 이름 서버입니다. 도메인에 대한 정보를 제공하는 최종 소스로서, 모든 도메인의 DNS 레코드(모든 IP 주소 및 하위 도메인 포함)의 원본을 저장합니다.
DNS 시스템은 사람이 이해하기 쉬운 도메인 이름과 컴퓨터가 이해하는 IP 주소를 연결하여 인터넷 사용자가 원하는 웹사이트에 접근할 수 있도록 합니다.
사용자가 웹 브라우저에 도메인 이름을 입력하면, 사용자의 컴퓨터는 DNS 확인자와 통신하며 DNS 시스템을 탐색하여 요청한 웹사이트의 IP 주소를 가진 권한 있는 이름 서버(주로 기본 서버지만 기본 서버가 다운되었거나 과부하 상태일 경우 보조 서버)에 도달합니다. 해당 IP 주소가 사용자에게 반환되고 사용자는 해당 웹사이트에 연결됩니다.
기본 DNS 서버는 관리자가 도메인의 영역과 DNS 레코드를 구성하는 곳입니다. 보조 서버는 시스템의 복원력을 높이기 위해 설정됩니다. 이들 서버는 기본 서버의 영역에 구성된 레코드의 전체 복사본을 보유하며, 기본 서버를 사용할 수 없을 때 쿼리 해결에 사용됩니다.
기업은 수십 대의 서버를 설정할 수 있으며, 기본 이름 서버의 영역(및 해당 레코드)은 모든 보조 서버로 복사됩니다.
기본 DNS 서버는 도메인의 시작 권한(SOA) 레코드도 보유하며, 이는 일종의 버전 관리 시스템으로서 기본 영역 파일의 업데이트를 보조 서버에 알리고 백업 서버와 복제 프로세스를 추적합니다.
기본 DNS 서버와 보조 DNS 서버 간의 차이는 인터넷 사용자에게는 보이지 않습니다. 이들 서버는 동일한 정보를 가지고 있으며 이 구분은 관리자에게만 의미가 있습니다. 변경 사항은 기본 서버에서 이루어지며, 보조 서버는 기본 서버로부터 복사본을 가져옵니다.
이 시스템은 DNS 트래픽 라우팅과 네트워크 복원력 모두에서 중요한 역할을 합니다.
도메인 이름 시스템(DNS)은 사용자에게 친숙한 도메인 이름을 컴퓨터가 네트워크에서 서로를 식별하는 데 사용하는 인터넷 프로토콜(IP) 주소로 변환하는 인터넷 표준 프로토콜의 구성 요소입니다.
종종 "인터넷용 전화번호부"라고 불리는데, DNS가 스마트폰이 연락처를 관리하는 것과 거의 동일한 방식으로 도메인 이름을 관리하기 때문입니다. 스마트폰은 쉽게 검색할 수 있는 연락처 목록에 전화번호를 저장하기 때문에 사용자가 개별 전화번호를 기억할 필요가 없습니다.
마찬가지로 DNS를 사용하면 사용자가 IP 주소 대신 인터넷 도메인 이름을 사용하여 웹 사이트에 연결할 수 있습니다. 예를 들어 웹 서버가 '93.184.216.34'에 있다는 것을 기억할 필요 없이 사용자는 'www.example.com'이라는 웹페이지로 이동하면 원하는 결과를 얻을 수 있습니다.
기본 DNS 서버는 이름 서버(NS) 레코드, A 레코드, MX 레코드, CNAME 레코드(그 외 다른 유형 포함)를 보유하며, 적절한 데이터와 정보를 사용자에게 반환합니다.
무엇보다도 기본 서버는 도메인의 SOA 레코드도 보유합니다. SOA 레코드는 기본 이름 서버, 관리자 이메일 주소, 새로 고침 타이머(영역 새로 고침 빈도 지정), 도메인 일련번호 등 도메인에 대한 권한 있는 정보를 제공합니다.
도메인이 등록되면 해당 이름 서버(NS) 레코드가 생성되어 일반적으로 호스팅 회사 또는 DNS 서비스 제공업체에서 제공하는 기본 DNS 서버에 저장됩니다. 관리자가 DNS 레코드를 수정하거나 업데이트하려면 기본 DNS 서버에서 작업을 수행해야 합니다. 그러면 변경 사항이 모든 보조 서버로 전파됩니다.
서버 관리자는 어느 DNS 서버든 기본 또는 보조로 지정할 수 있습니다. 실제로 서버는 한 영역에서는 기본 서버로, 다른 영역에서는 보조 서버로 지정될 수 있습니다. 그러나 각 DNS 영역에는 기본 서버가 하나만 존재할 수 있습니다.
사용자가 브라우저나 앱에 도메인 이름을 입력하면 요청은 반복 확인자로 전송됩니다. 일반적으로 사용자의 장치는 인터넷 서비스 공급자(ISP)에서 제공한 사전 정의된 DNS 설정을 가지고 있어 어떤 확인자가 사용될지 결정됩니다.
확인자는 도메인에 해당하는 IP 주소가 DNS 캐시(웹 브라우저 또는 Windows나 Linux 같은 운영 체제 내 임시 저장소)에 저장되어 있는지 확인합니다. DNS 조회 데이터가 캐시되지 않은 경우, 확인자는 권한 있는 DNS 서버에서 해당 정보를 가져오고, DNS 영역 파일을 조회한 후 TTL(수명 시간)에 따라 DNS 레코드를 캐시에 저장하고 적절한 IP 주소를 사용자 장치로 반환합니다.
그런 다음 브라우저나 앱은 해당 IP 주소의 호스트 서버에 연결을 시작하고 요청한 웹사이트나 서비스에 접근할 수 있습니다.
DNS 서버는 역할에 따라 "기본" 및 "보조"로 분류됩니다. 기본 DNS 서버는 도메인의 DNS 레코드에 대한 권한 있는 소스로서 영역 파일의 원본(읽기/쓰기 가능)을 보유하는 반면, 보조 DNS 서버는 로드 밸런싱과 중복성 관리를 위해 영역 파일의 읽기 전용 복제본을 보유합니다. 기본 서버가 다운될 경우 쿼리는 자동으로 보조 서버로 라우팅되어 요청을 처리합니다.
보조 DNS 서버는 필수는 아니며, DNS 시스템은 기본 서버만으로도 동작할 수 있습니다. 그러나 라운드 로빈 DNS(트래픽을 각 서버에 고르게 분산) 구현, 서비스 거부(DoS) 방지, 시스템 복원력 확보를 위해 도메인 등록기관에서는 최소한 하나 이상의 보조 서버 유지를 표준으로 요구하는 경우가 많습니다. 서버 하나 또는 여러 개가 장애가 발생하더라도 백업 서버가 있어 사용자가 원하는 웹사이트에 접속할 수 있습니다.
기본 서버와 보조 서버는 모두 DNS 시스템의 효율성을 유지하는 데 도움이 되며, 이들을 함께 사용하면 사용자 쿼리가 기본 또는 보조 상태에 관계없이 사용 가능한 어느 서버에서나 처리될 수 있습니다. 그러나 기본 DNS 서버와 보조 DNS 서버 간의 차이를 좀 더 자세히 살펴보겠습니다.
기본 DNS 서버는 기본 영역 파일을 저장하는 것 외에도 도메인 관리자의 업데이트 요청에 응답하고 동적 업데이트를 처리합니다. 보조 영역 서버는 기본 서버가 다운되거나 기본 서버에 과부하가 걸렸을 때 DNS 요청을 처리하는 백업 서버입니다.
기본 이름 서버의 기본 영역 파일에는 지정된 도메인에 대한 모든 A 레코드(IPv4의 주소 레코드), AAAA 레코드(IPv6의 주소 레코드), MX 레코드(메일 서버로 연결), CNAME 레코드(별칭을 실제 또는 "표준" 도메인 이름에 매핑), SOA 레코드(도메인의 모든 관리 정보 포함), TXT 레코드(이메일 인증을 위한 발신자 정책 프레임워크 레코드)가 포함되어 있습니다. 관리자가 이 파일을 직접 관리하며, DNS 레코드에 대한 모든 업데이트나 변경이 여기에서 먼저 이루어집니다.
보조 DNS 서버는 기본 서버에서 전송된 영역 파일의 복제본입니다. 보조 서버에서는 영역 파일에 직접 수정이나 편집을 할 수 없으며, 대신 '영역 전송'이라는 프로세스를 통해 주기적으로 기본 서버의 업데이트를 확인합니다.
기본 DNS를 구성할 때는 영역 파일, 리소스 레코드, 액세스 제어를 설정하고, 권한 있는 전체 또는 증분 영역 전송(AXFR 및 IXFR)을 지정된 보조 서버로 설정할 수 있습니다.
보조 DNS 구성을 위해 관리자는 기본 서버와 보조 서버 간 영역 데이터 전송을 위한 통신 프로토콜을 설정하고, 업데이트 확인을 위한 기본 서버 체크인 주기를 지정해야 합니다.
기본 DNS 서버는 필수적이지만 단일 장애 지점이기도 합니다. 충돌이 발생하고 워크로드를 인계받을 지정된 보조 서버가 없는 경우 전체 DNS 확인 프로세스에 문제가 발생할 수 있습니다. 보조 서버는 기본 DNS 서버 없이 존재할 수 없지만, 기본 서버가 다운되면 보조 서버는 기본 서버가 복구될 때까지 DNS를 계속 작동할 수 있습니다.
관리자는 기본 서버를 지원하고 시스템 복원력을 극대화하기 위해 보조 DNS 서버에 의존합니다.
보조 서버는 권한 있는 이름 서버의 모든 레코드의 완전한 복사본을 보유하므로, 기본 서버가 다운되거나 사용할 수 없는 경우 기본 서버를 대신할 수 있습니다. 그러나 시스템 관리자가 수동으로 복사본을 생성하고 관리해야 한다면 기본 서버와 보조 서버 간에 지연이 발생할 것입니다. 그 대신 기본 DNS와 보조 DNS는 복사 프로세스를 자동화합니다.
관리자가 기본 서버에 변경을 가하면 SOA 레코드에 저장된 도메인 일련번호가 다음 숫자로 증가합니다(예를 들어, 기존에 SOA 1이었다면 SOA 2로 변경).
기존 DNS 구성에서는 보조 이름 서버가 미리 설정된 간격으로 기본 서버에 체크인하여 현재 SOA 일련번호를 확인합니다. 기본 서버에서 변경 사항이 감지되면, 보조 서버는 AXFR 또는 IXFR 요청을 보내 복사를 시작합니다. 그 후 기본 서버는 업데이트된 SOA 일련번호와 함께 변경 사항을 보조 서버로 전송합니다.
이러한 DNS 구성은 보조 서버가 기본 서버 변경 여부를 알기 위해 XFR 풀 요청을 수동으로 보내야 하므로 DNS 속도를 다소 저하시킵니다.
하지만 최신 구성에서는 'NOTIFY' 프로토콜을 사용하여 관리자가 변경을 수행할 때마다 기본 이름 서버가 UDP(사용자 데이터그램 프로토콜) 메시지를 백업 서버로 보낼 수 있습니다. 그 후 보조 서버는 SOA 일련번호를 확인하여 변경 사항을 확인하고 업데이트를 위한 풀 요청을 시작합니다.
이러한 기본 DNS와 보조 DNS 접근 방식을 통해 시스템 관리자는 시스템 신뢰성과 복원력을 극대화할 수 있습니다. 또한 서버 간 동기화를 유지하며, 사용자가 최신 정보를 얻기 위해 어느 서버든 이용할 수 있도록 보장합니다.
기본 DNS와 보조 DNS를 사용하는 것은 인터넷에서 중복성을 통해 안정성을 확보하는 가장 일반적인 방법이지만, 이러한 방식에도 몇 가지 과제가 존재합니다. 기본-보조 방식은 종종 글로벌 서버 로드 밸런싱(GSLB)과 같은 고급 기능을 지원하지 못합니다.
GSLB와 같은 트래픽 스티어링 툴은 지리적 근접성을 기준으로 사용자 트래픽을 DNS 서버로 라우팅합니다. DNS 라우터는 자동으로 요청을 가장 가까운 사용 가능한 서버로 보내어 조회 프로세스를 가속화합니다.
그러나 이러한 기능은 종종 독점 기술이며 XFR을 통해 전송할 수 없습니다. 도메인 관리자는 기본 이름 서버에 GSLB를 설정할 수 있지만, 해당 구성을 보조 서버로 전송할 수는 없습니다.
이 문제를 해결하기 위해 기업은 전 세계 여러 서버를 지원할 수 있는 독자적 시스템을 제공하는 공급업체를 선택할 수 있습니다. 예를 들어, Anycast DNS는 관리자가 하나의 IP 주소 또는 IP 주소 집합을 여러 지리적으로 분산된 서버에 할당할 수 있도록 합니다.
기존 DNS의 일대일 통신 방식 대신 Anycast는 일대다 통신을 지원합니다. 따라서 사용자가 요청을 제출하면 요청은 단일 확인자가 아닌 확인자 네트워크로 전송되며, 가장 가까운 사용 가능한 서버에서 처리됩니다.
또는 여러 공급업체를 사용하는 경우 조직은 여러 기본 이름 서버를 구성하고 사용자가 그 사이에서 선택하도록 할 수 있습니다. 보조 DNS와 XFR 전송에 의존하는 대신 관리자는 API를 사용하여 모든 서버를 직접 구성하게 됩니다.
기본 DNS와 보조 DNS는 모두 쿼리 라우팅에 중요하므로 기본 DNS 서버를 유지 관리하고 최적화하면 전체 DNS 시스템의 성능을 향상시킬 수 있습니다. 기업은 다음과 같은 모범 사례를 적용하여 DNS를 최대한 활용할 수 있습니다.
가동 시간이 높고, 종합적인 중복 프로토콜을 제공하며, 접근 가능한 고객 지원을 제공하는 DNS 공급업체를 선택하면 DNS 쿼리가 빠르고 안정적으로 처리될 수 있습니다.
기본 DNS 공급자는 퍼블릭 DNS 서비스부터 프리미엄 관리형 DNS 서버까지 다양한 서비스를 제공합니다. 조직에 가장 적합한 솔루션을 결정하는 것은 조직의 필요1, 예산, 복잡성에 따라 달라집니다. 퍼블릭 DNS를 사용하면 클라이언트에게 개방적이고 무료인 DNS 액세스를 제공하지만, 프리미엄 DNS로 마이그레이션하면 더 세밀한 제어가 가능합니다.
최신 DNS 취약점과 위협(DNS 터널링, DDoS 공격, 캐시 스푸핑 등)에 대한 정보를 지속적으로 파악하고, 방화벽, 도메인 이름 시스템 보안 확장(DNSSEC), 기타 보안 조치를 사용하면 DNS 서버2를 보호하고 위험을 완화할 수 있습니다.
IP 주소, 인프라, 서비스의 변경 사항을 반영하여 DNS 레코드를 신속하고 자주 업데이트하면 일관되고 정확한 도메인 조회가 가능합니다.
기존의 기본/보조 DNS 아키텍처는 최신 관리형 DNS 공급자들 사이에서 더 이상 사용되지 않습니다. 오늘날 대부분의 공급자는 사용할 이름 서버 IP를 제공하며, 이러한 각 IP 뒤에는 애니캐스트(일대다 전송 프로토콜)를 사용하여 요청을 라우팅하는 DNS 서버 풀이 있습니다. 이 접근 방식은 기존 모델보다 더 나은 중복성과 더 높은 가용성을 제공하는 경향이 있습니다.
그러나 고급 DNS 배포에서도 보조 DNS 서비스는 기업에 다음과 같은 도움을 줄 수 있습니다.
보조 DNS를 통해 팀은 조직에서 호스팅되는 이전 DNS 서버를 가리키는 툴, 코드 및 레거시 시스템에 액세스할 수 있습니다. 아키텍처 마이그레이션 중에 보조 서버를 사용하면 관리자는 종속성을 유지하면서 보조 DNS 공급자를 정의할 수 있습니다. 이렇게 하면 모든 기존 프로세스가 동기화된 상태로 유지되지만 사내 서버가 느려지거나 장애가 발생하는 경우 새 DNS 서버가 응답할 수 있습니다.
트래픽이 많은 사이트와 미션 크리티컬 웹 애플리케이션을 운영하는 많은 조직에게 장애는 용납될 수 없습니다. 보조 이름 서버를 사용하면 기본 DNS 서버에서 지연이나 기타 문제가 발생하더라도 관리자가 단일 실패 지점을 방지할 수 있습니다.
관리형 서비스는 일반 관리형 DNS 서비스와는 별도의 네트워크 및 서버에서 실행되는 전용 DNS 배포를 조직에 맞게 구성합니다. 이 접근 방식은 기업이 하나의 공급자와 서비스를 유지하면서도 중복성을 확보할 수 있도록 지원합니다. 또한 전용 배포는 다른 조직과 공유되지 않으므로 서비스의 다른 고객을 대상으로 하는 공격으로부터 격리됩니다.
IBM NS1 Connect는 엔터프라이즈 DNS, DHCP, IP 주소 관리 및 애플리케이션 트래픽 조정을 위한 풀 매니지드 클라우드 서비스입니다.
IBM의 클라우드 네트워킹 솔루션은 앱과 비즈니스를 지원하는 고성능 연결을 제공합니다.
IBM Technology Lifecycle Services와 데이터 센터 지원을 통합하여 클라우드 네트워킹 등을 강화하세요.
1 "Should large enterprises self-host their authoritative DNS?," IBM.com, 2024년 2월 1일
2 "Why DNS protection should be the first step in hybrid cloud security," (TechRadar, 2024년 2월 1일