게시일: 2024년 4월 19일
기고자: Chrystal R. China, Michael Goodwin
도메인 이름 시스템(DNS)은 사용자에게 친숙한 도메인 이름을 컴퓨터가 네트워크에서 서로를 식별하는 데 사용하는 인터넷 프로토콜(IP) 주소로 변환하는 인터넷 표준 프로토콜의 구성 요소입니다.
종종 "인터넷용 전화번호부"라고 불리는데, DNS가 스마트폰이 연락처를 관리하는 것과 거의 동일한 방식으로 도메인 이름을 관리하기 때문입니다. 스마트폰은 쉽게 검색할 수 있는 연락처 목록에 전화번호를 저장하기 때문에 사용자가 개별 전화번호를 기억할 필요가 없습니다.
마찬가지로 DNS를 사용하면 사용자가 IP 주소 대신 인터넷 도메인 이름을 사용하여 웹 사이트에 연결할 수 있습니다. 예를 들어 웹 서버가 '93.184.216.34'에 있다는 것을 기억할 필요 없이 사용자는 'www.example.com'이라는 웹페이지로 이동하기만 하면 원하는 결과를 얻기 위해서요
서비스형 데스크톱(DaaS)을 통해 기업이 온프레미스에 애플리케이션을 배포하는 것과 동일한 수준의 성능과 보안을 달성할 수 있는 방법을 알아보세요.
DNS 이전에 인터넷은 주로 학술 및 연구 기관에서 사용하는 컴퓨터 네트워크였습니다. 개발자는 HOSTS.TXT라는 간단한 텍스트 파일을 사용하여 호스트 이름을 IP 주소에 수동으로 매핑했습니다. SRI International은 이러한 텍스트 파일을 유지 관리하여 인터넷의 모든 컴퓨터에 배포했습니다. 그러나 네트워크가 확장됨에 따라 이러한 접근 방식은 점점 더 어려워졌습니다.
HOSTS.TXT의 한계를 극복하고 보다 확장 가능한 시스템을 만들기 위해 University of Southern California 컴퓨터 과학자 Paul Mockapetris는 1983년에 도메인 이름 시스템을 발명했습니다. 인터넷 선구자 집단은 DNS 생성을 도왔고 새로운 시스템 사양인 RFC 882 및 RFC 883을 자세히 설명하는 첫 번째 의견 요청(RFC)을 작성했습니다. RFC 1034와 RFC 1035는 이후 이전의 RFC를 대체했습니다.
결국 DNS가 확장됨에 따라 DNS 관리는 인터넷주소관리기관(IANA)의 책임이 되었고, 결국 1998년 비영리 단체인 인터넷주소관리기구(ICANN)의 관리 하에 놓이게 되었습니다.
하이브리드 클라우드 가이드 등록
처음부터 개발자들은 빠르게 확장되는 컴퓨터 네트워크에 보조를 맞출 수 있는 도메인 이름 확인에 대한 보다 동적인 접근 방식을 용이하게 하기 위해 계층적 분산 데이터베이스 구조로 DNS를 설계했습니다. 계층 구조는 점(.)으로 표시된 루트 수준에서 시작하여 '.com', '.org', '.net'과 같은 최상위 도메인(TLD) 또는 '.uk' 및 '.jp'와 같은 국가 코드 TLD(ccTLD) 및 두 번째 수준 도메인으로 나뉩니다.
DNS 아키텍처는 두 가지 유형의 DNS 서버, 즉 재귀 서버와 권한 있는 서버로 구성됩니다. 재귀 DNS 서버는 사용자를 웹 사이트에 연결하는 정보를 검색하는 "요청"을 수행하는 서버입니다.
재귀 확인자 또는 DNS 확인자라고도 하는 재귀 서버는 일반적으로 인터넷 서비스 공급자(ISP), 대기업 또는 기타 타사 DNS 서비스 공급자가 관리합니다. 이들은 최종 사용자를 대신하여 도메인 이름을 IP 주소로 확인합니다. 또한 재귀 해석기는 특정 기간(TTL(Time-to-Live) 값으로 정의됨) 동안 요청에 대한 응답을 캐시하여 향후 동일한 도메인에 대한 쿼리를 위해 시스템 효율성을 개선합니다.
사용자가 검색 브라우저에 웹 주소를 입력하면 브라우저는 재귀 DNS 서버에 연결하여 요청을 확인합니다. 재귀 서버에 응답이 캐시된 경우 사용자를 연결하고 요청을 완료할 수 있습니다. 그렇지 않으면 재귀 확인자는 일련의 권한 있는 DNS 서버를 쿼리하여 IP 주소를 찾고 사용자를 원하는 웹 사이트에 연결합니다.
권한 있는 서버는 "답변"을 제공합니다. 권한 있는 이름 서버는 도메인에 대한 최종 레코드를 보유하고 해당 영역 내에 저장된 도메인 이름에 대한 요청에 응답합니다(일반적으로 도메인 소유자가 구성한 답변으로 응답). 권한 있는 이름 서버에는 여러 유형이 있으며, 각 유형은 DNS 계층 구조 내에서 특정 기능을 수행합니다.
권한 있는 DNS 이름 서버에는 다음이 포함됩니다.
루트 이름 서버는 DNS 계층 구조의 최상위에 위치하며 루트 영역(DNS의 중앙 데이터베이스) 관리를 담당합니다. 루트 영역 내에 저장된 레코드에 대한 쿼리에 응답하고 적절한 TLD 이름 서버로 요청을 참조합니다.
TLD에 대한 요청을 처리하고 쿼리를 적절한 TLD 이름 서버로 전달하는 13개의 서로 다른 루트 서버 네트워크(A~M으로 식별)를 쿼리하는 데 사용되는 13개의 IP 주소가 있습니다. 이러한 루트 서버 네트워크는 인터넷주소자원관리기구(ICANN)에서 운영합니다.
TLD 서버는 일반 최상위 도메인 (gTLD) 을 비롯한 계층 구조의 다음 수준을 관리하는 역할을 합니다. TLD 이름 서버는 해당 TLD 내의 특정 도메인에 대한 권한 있는 이름 서버로 쿼리를 전달합니다. 따라서 ".com"에 대한 TLD 이름 서버는 ".com"으로 끝나는 도메인을 디렉션하고, ".gov"에 대한 TLD 이름 서버는 ".gov"로 끝나는 도메인을 디렉션합니다.
도메인 이름 서버(2단계 도메인 이름 서버라고도 함)는 "ibm.com"과 같이 전체 도메인 이름의 IP 주소가 포함된 영역 파일을 보유합니다.
DNS의 모든 쿼리(DNS 요청이라고도 함)는 동일한 논리에 따라 IP 주소를 확인합니다. 사용자가 URL을 입력하면 컴퓨터는 DNS 서버를 점진적으로 쿼리하여 사용자의 요청을 처리하는 데 적합한 정보 및 리소스 레코드를 찾습니다. 이 프로세스는 DNS가 해당 도메인과 연결된 권한 있는 DNS 서버에서 올바른 응답을 찾을 때까지 계속됩니다.
보다 구체적으로 DNS의 쿼리 확인에는 몇 가지 주요 프로세스 및 구성 요소가 포함됩니다.
사용자가 "ibm.com"과 같은 도메인 이름을 브라우저나 앱에 입력하면 요청이 재귀 DNS 확인자로 전송됩니다. 일반적으로 사용자의 디바이스에는 인터넷 서비스 공급자(ISP)가 제공하는 사전 정의된 DNS 설정이 있으며, 이를 통해 클라이언트가 쿼리하는 재귀 확인자를 결정합니다.
재귀 확인자는 이전 DNS 조회를 보관하는 웹 브라우저 또는 운영 체제(예: macOS, Windows 또는 Linux) 내의 임시 스토리지인 캐시에서 도메인의 해당 IP 주소를 확인합니다. 재귀 확인자의 캐시에 DNS 조회 데이터가 없는 경우 확인자는 루트 서버부터 시작하여 권한 있는 DNS 서버에서 데이터를 검색하는 프로세스를 시작합니다. 재귀 확인자는 최종 IP 주소를 찾을 때까지 DNS 계층 구조를 쿼리합니다.
재귀 확인자는 루트 이름 서버를 쿼리하고, 루트 이름 서버는 해당 도메인에 대한 적절한 TLD 서버(여기서는 ".com" 도메인을 담당하는 TLD 이름 서버)에 대해 참조로 응답합니다.
확인자는 ".com" TLD 이름 서버를 쿼리하고, 이 서버는 "ibm.com"에 대한 권한 있는 이름 서버의 주소로 응답합니다. 이 서버를 2단계 도메인 이름 서버라고도 합니다.
확인자는 도메인의 이름 서버를 쿼리하고, 이름 서버는 DNS 영역 파일을 조회하고 제공된 도메인 이름에 대한 올바른 레코드로 응답합니다.
재귀 확인자는 레코드의 TTL에 지정된 시간 동안 DNS 레코드를 캐시하고 IP 주소를 사용자의 디바이스로 반환합니다. 그런 다음 브라우저 또는 앱은 요청된 웹 사이트 또는 서비스에 액세스하기 위해 해당 IP 주소에서 호스트 서버에 대한 연결을 시작할 수 있습니다.
DNS는 주요 서버 유형 외에도 영역 파일과 여러 레코드 유형을 사용하여 확인 프로세스를 지원합니다. 영역 파일은 DNS 영역 내의 도메인에 대한 매핑 및 정보를 포함하는 텍스트 기반 파일입니다.
영역 파일의 각 줄은 DNS 리소스 레코드(특정 유형 또는 데이터의 특성에 대한 단일 정보)를 지정합니다. 리소스 레코드는 사용자가 쿼리를 제출할 때 DNS가 도메인 이름을 실행 가능한 정보로 신속하게 변환하여 사용자를 올바른 서버로 안내할 수 있도록 합니다.
DNS 영역 파일은 두 개의 필수 레코드, 즉 로컬 DNS 캐시에 레코드를 저장하는 방법을 나타내는 TTL(글로벌 타임 투 라이브)과 DNS 영역의 기본 권한 이름 서버를 지정하는 SOA 레코드(권한 시작)로 시작됩니다.
두 개의 기본 레코드 다음에 영역 파일에는 다음과 같은 여러 가지 다른 레코드 유형이 포함될 수 있습니다.
A 레코드는 IPv4 주소에 매핑되고 AAAA 레코드는 IPv6 주소에 매핑됩니다.
MX 레코드는 도메인의 SMTP 이메일 서버를 지정합니다.
CNAME 레코드는 별칭에서 다른 도메인('표준 도메인')으로 호스트 이름을 리디렉션합니다.
NS 레코드는 도메인에 대한 권한 있는 이름 서버를 나타냅니다.
PTR 레코드는 역방향 DNS 조회를 지정하여 IP 주소를 도메인 이름에 다시 매핑합니다.
TXT 레코드는 이메일 인증을 위한 발신자 정책 프레임워크 레코드를 나타냅니다.
DNS 조회에는 일반적으로 세 가지 유형의 쿼리가 포함됩니다. 재귀 서버와 DNS 클라이언트를 연결하는 재귀 쿼리는 도메인 이름을 완전히 확인하거나 사용자에게 도메인을 찾을 수 없음을 알리는 오류 메시지를 반환합니다.
재귀 확인자(로컬 DNS 서버)와 비로컬 DNS 서버(예: 루트, TLD 또는 도메인 이름 서버)를 연결하는 반복 쿼리에는 도메인 확인이 필요하지 않습니다. 대신 서버는 조회로 응답할 수 있으며, 여기서 루트 서버는 재귀 확인자를 TLD로 참조하고, TLD는 확인자를 응답을 제공하는 권한 있는 서버로 참조합니다(응답을 사용할 수 있는 경우). 따라서 반복 쿼리는 답변 또는 참조로 해결됩니다.
비재귀적 쿼리의 경우 재귀 확인자는 쿼리에 대한 응답을 찾을 위치를 이미 알고 있으므로 이러한 쿼리는 항상 응답으로 확인됩니다. 확인자는 재귀 서버에 캐시된 응답을 찾거나 DNS 루트 및 TLD 이름 서버를 건너뛰고 적절한 권한 있는 서버로 직접 이동하여 시간을 절약합니다. 예를 들어 재귀 확인자가 이전 세션에서 캐시된 IP 주소를 제공하는 경우 해당 요청은 비재귀 쿼리에 해당합니다.
조직에서는 DNS를 사용할 때 퍼블릭 및 프라이빗 DNS 또는 이 둘의 조합을 포함하여 다양한 옵션을 사용할 수 있습니다. 퍼블릭 DNS와 프라이빗 DNS는 완전히 다른 두 가지입니다. 조직의 요구 사항을 충족하기 위해 DNS를 가장 잘 사용하는 방법을 이해하려면 각 유형의 작동 방식을 이해하는 것이 중요합니다.
퍼블릭 DNS는 일반적으로 DNS의 확인자 측과 권한 있는 이름 서버를 쿼리하고 사용자를 웹사이트에 연결하는 데 사용되는 재귀 서버를 의미합니다.
이러한 서버는 인터넷의 모든 사용자 및 Cloudflare(1.1.1.1)와 같은 회사에서 액세스할 수 있으며 Quad9 및 OpenDNS는 일반적으로 이를 무료로 제공합니다. 퍼블릭 DNS 서버는 이를 실행하는 조직에서 유지 관리합니다. 사용자와 클라이언트는 자신의 운영, 정책 또는 구성을 제어할 수 없습니다.
프라이빗 DNS는 일반적으로 DNS의 권한 있는 부분을 의미합니다. 조직은 사설망 내에 프라이빗 DNS 서버를 설정하며, 이러한 서버는 권한 있는 DNS 서버 역할을 하여 내부 리소스에 대한 DNS 조회를 제공합니다. 프라이빗 DNS 서버는 방화벽 뒤에 위치하며 내부 사이트의 레코드만 보관하므로 권한이 있는 사용자, 장치 및 네트워크로만 액세스가 제한됩니다.
퍼블릭 DNS 구성과 달리 프라이빗 DNS는 조직이 DNS 서버를 제어할 수 있도록 하여 DNS 레코드를 사용자 지정하고, 내부 명명 체계를 적용하고, 특정 보안 정책을 시행할 수 있도록 합니다. 이는 또한 조직이 온프레미스 데이터 센터에서 호스팅되든 클라우드 서비스를 통해 호스팅되든 관계없이 인프라를 유지 관리할 책임이 있음을 의미합니다.
관리형 DNS 솔루션은 기본적으로 서버 관리 및 오케스트레이션 프로세스를 아웃소싱합니다. 관리형 시스템을 사용하면 DNS 공급자가 조직의 DNS 서버에 대한 모든 구성, 유지 관리 및 보안 프로토콜을 처리하고 클라이언트는 공급자 인프라를 사용하여 도메인 이름을 관리합니다. 이 경우 사용자가 비즈니스의 URL을 입력하면 회사 도메인 이름 서버에서 공급자의 서버로 리디렉션되어 모든 리소스를 가져오고 사용자에게 응답합니다.
또한 관리형 DNS는 전용 DNS, 글로벌 서버 로드 밸런싱, 가동 시간 보장, API 우선 아키텍처, DNSSEC 지원, 글로벌 애니캐스트 네트워크, 전파 시간 단축 , 모니터링 및 상태 확인 도구, DDoS 보호 등과 같은 서비스와 이점을 제공 할 수 있습니다.
대부분의 최신 DNS 서버는 퍼블릭 DNS의 경우에도 매우 안전합니다. 그러나 최고의 DNS 시스템도 여전히 사이버 보안 문제에 취약할 수 있습니다. 특정 유형의 공격은 DNS의 권한 측면을 대상으로 하는 반면, 다른 유형의 공격은 재귀적 측면을 대상으로 합니다. 이러한 공격에는 다음이 포함됩니다.
캐시 포이즈닝이라고도 하는 DNS 스푸핑은 공격자가 DNS 확인자의 캐시에 잘못된 주소 레코드를 삽입하여 확인자가 잘못된 IP 주소를 반환하고 사용자를 악성 사이트로 리디렉션할 때 발생합니다. 스푸핑은 민감한 데이터를 손상시키고 피싱 공격 및 맬웨어 배포로 이어질 수 있습니다.
DNS 증폭은 공격자가 피해자의 IP 주소로 스푸핑된 반환 주소를 사용하여 DNS 서버에 작은 쿼리를 보내는 분산 서비스 거부(DDoS) 공격의 한 유형입니다. 이러한 공격은 DNS 프로토콜의 상태 비저장 특성을 악용하고 작은 쿼리가 대규모 응답을 생성할 수 있다는 사실을 이용합니다.
증폭 공격의 결과로 DNS 서버는 훨씬 더 큰 응답으로 응답하며, 이로 인해 사용자에게 전달되는 트래픽의 양이 증폭되어 리소스가 과부하됩니다. 이로 인해 DNS가 작동하지 않아 애플리케이션이 다운될 수 있습니다.
DNS 터널링은 DNS 쿼리 및 응답 내에서 HTTP와 같은 비 DNS 트래픽을 캡슐화하여 보안 조치를 우회하는 데 사용되는 기술입니다. 공격자는 DNS 터널을 사용하여 맬웨어 명령을 전달하거나 손상된 네트워크에서 데이터를 유출할 수 있으며, 탐지를 피하기 위해 DNS 쿼리 및 응답 내에 페이로드를 인코딩하는 경우가 많습니다.
도메인 하이재킹은 공격자가 도메인 등록 기관 계정에 무단으로 액세스하여 도메인의 등록 세부 정보를 변경할 때 발생합니다. 하이재킹을 통해 악의적인 행위자는 트래픽을 악성 서버로 리디렉션하고, 이메일을 가로채고, 사용자의 온라인 ID를 제어할 수 있습니다.
사용 중지된 서비스를 가리키는 하위 도메인의 방치된 DNS 항목은 공격자의 주요 표적이 됩니다. 클라우드 호스트와 같은 서비스가 사용 중지되었지만 DNS 항목이 남아 있는 경우 공격자는 잠재적으로 하위 도메인을 요청하고 그 자리에 악성 사이트나 서비스를 설정할 수 있습니다.
조직에서 어떤 DNS 서비스를 선택하든 보안 프로토콜을 구현하여 DNS 공격 표면을 최소화하고 잠재적인 보안 문제를 완화하며 네트워킹 프로세스에서 DNS를 최적화하는 것이 좋습니다. DNS 보안을 강화하기 위한 몇 가지 유용한 방법은 다음과 같습니다.
- DNS 보안 확장(DNSSEC) 및 가상 사설망(VPN) 배포: DNSSEC는 DNS 응답에 디지털 서명을 요구하여 DNS 조회에 보안 계층을 추가합니다. 특히 DNSSEC는 요청의 출처를 인증하고 DNS 데이터의 무결성을 확인하여 DNS 스푸핑 공격으로부터 보호할 수 있습니다.
VPN은 위치 및 (무엇보다도) 검색 기록 데이터를 추적할 수 없도록 암호화를 사용하여 IP 주소를 숨겨 기밀성을 제공합니다.
- 속도 제한 방식 채택: DNS 서버의 속도 제한은 지정된 기간 동안 단일 요청자에 대한 응답 수(또는 서버가 응답을 보내는 속도)를 제한하여 DDoS 공격을 완화할 수 있습니다.
- 도메인 등록 기관에 2단계 인증(2FA) 요구: 도메인 등록 기관 계정에 2단계 인증을 설정하면 공격자가 서버에 무단으로 액세스하는 것을 더 어렵게 만들고 도메인 하이재킹의 위험을 줄일 수 있습니다.
- 중복 사용: 지리적으로 분산된 여러 서버에 중복 구성으로 DNS를 배포하면 공격이나 중단이 발생할 경우 네트워크 가용성을 보장하는 데 도움이 됩니다. 기본 서버가 다운되면 보조 서버가 DNS 확인 서비스를 대신할 수 있습니다.
- DNS 플러시 구현: DNS 캐시를 정기적으로 지우면 로컬 시스템에서 모든 항목이 제거되므로 사용자를 악성 사이트로 안내할 수 있는 유효하지 않거나 손상된 DNS 레코드를 삭제하는 데 유용할 수 있습니다.
- DNS 위협에 대한 최신 정보를 습득하세요. 공격자와 보안 위협은 그들이 손상시키는 시스템과 거의 동일한 방식으로 진화합니다. 최신 DNS 취약점과 위협을 파악하면 악의적인 공격자들보다 한발 앞서 대응할 수 있습니다.
IBM NS1 Connect는 프리미엄 DNS 및 사용자 정의 가능한 고급 트래픽 조정을 통해 전 세계 어디서나 사용자에게 빠르고 안전한 연결을 제공합니다. 상시 가동되는 API 우선 아키텍처를 통해 IT 팀은 네트워크를 보다 효율적으로 모니터링하고, 변경 사항을 배포하고, 일상적인 유지 관리를 수행할 수 있습니다.
IBM NS1 Connect DNS Insights의 DNS 관측 가능성 데이터를 기반으로 하는 맞춤형 실시간 보고서에서 구성 오류와 보안 문제를 신속하게 파악할 수 있습니다.
IBM Cloud DNS Services는 신속한 응답 시간, 최고의 중복성 및 고급 보안을 갖춘 퍼블릭 및 프라이빗 권한 DNS 서비스를 제공합니다. 이 서비스는 IBM Cloud 웹 인터페이스 또는 API를 통해 관리됩니다.