도메인 이름 시스템(DNS)이란 무엇인가요?

DNS는 종종 “인터넷의 전화번호부”라고 불리며, 보다 현대적인 비유로는 스마트폰이 연락처를 관리하는 방식처럼 도메인 이름을 관리한다고 볼 수 있습니다. 스마트폰은 쉽게 검색할 수 있는 연락처 목록에 전화번호를 저장하기 때문에 사용자가 개별 전화번호를 기억할 필요가 없습니다.

마찬가지로 DNS는 IP 주소 대신 인터넷 도메인 이름을 사용해 웹사이트에 접속할 수 있도록 합니다. 예를 들어 웹 서버 주소가 ‘192.0.2.1’임을 기억할 필요 없이 사용자는 ‘www.example.com’ 웹페이지로 이동해 원하는 결과를 얻을 수 있습니다.

DNS가 어떻게 작동하는지 이해하려면 먼저 관련 구성 요소를 이해하는 것이 중요합니다.

DNS는 처음부터 빠르게 확장되는 컴퓨터 네트워크에 대응할 수 있도록 보다 유연한 도메인 이름 확인 방식을 지원하는 계층적 분산 데이터베이스 구조로 설계되었습니다. 이 계층 구조는 점(.)으로 표시되는 루트 레벨에서 시작하여 “.com”, “.org”, “.net”과 같은 최상위 도메인(TLD) 및 “.uk”, “.jp”와 같은 국가 코드 최상위 도메인(ccTLD)으로 확장되며, 이어서 2차 도메인으로 이어집니다.

DNS 아키텍처는 두 가지 유형의 DNS 서버로 구성됩니다. 재귀 서버와 권한 있는 서버입니다. 재귀 DNS 서버는 사용자를 웹 사이트에 연결하는 정보를 검색하는 "요청"을 수행하는 서버입니다. 권한 있는 서버는 "답변"을 제공합니다.

재귀 서버(재귀 리졸버 또는 DNS 리졸버라고도 함)는 일반적으로 인터넷 서비스 공급자(internet service providers, ISPs) 또는 타사 DNS 서비스 공급자가 관리합니다. 조직은 자체 리졸버를 호스팅하고 관리할 수도 있습니다.

재귀 확인자는 최종 사용자를 대신하여 도메인 이름을 IP 주소로 확인합니다. 재귀 확인자는 또한 동일한 도메인에 대한 향후 쿼리의 시스템 효율성을 높이기 위해, 특정 기간(생존 시간(time-to-live) 또는 TTL 값으로 정의됨) 동안 요청에 대한 답변을 캐시(최근 DNS 조회 결과를 일시적으로 저장)합니다.

사용자가 웹 브라우저에 웹 주소를 입력하면 브라우저는 요청을 처리하기 위해 재귀 DNS 서버에 연결합니다. 재귀 서버에 응답이 캐시된 경우 사용자를 연결하고 요청을 완료할 수 있습니다. 그렇지 않은 경우 재귀 리졸버는 해당 도메인의 IP 주소를 포함하는 A 레코드(또는 AAAA 레코드)를 찾을 때까지 DNS 계층 구조를 순차적으로 조회합니다.

권한 있는 이름 서버는 도메인에 대한 최종 레코드를 보유하고 해당 영역 내에 저장된 도메인 이름에 대한 요청에 응답합니다(일반적으로 도메인 소유자가 구성한 답변으로 응답). 네임스페이스의 서로 다른 부분을 담당하는 다양한 권한 있는 서버가 존재합니다.

루트 네임 서버는 DNS 계층 구조의 최상위에 위치하며 루트 존(DNS의 중앙 데이터베이스)을 제공하는 역할을 합니다. A부터 M까지의 문자로 식별되는 13개의 루트 네임 서버 “아이덴티티” 또는 “권한”(루트 서버의 논리적 그룹)이 존재하며, 루트 존에 저장된 레코드에 대한 쿼리에 응답하고 적절한 TLD 네임 서버로 요청을 전달합니다.

TLD 서버는 일반 최상위 도메인 (gTLD) 을 비롯한 계층 구조의 다음 수준을 관리하는 역할을 합니다. TLD 이름 서버는 해당 TLD 내의 특정 도메인에 대한 권한 있는 이름 서버로 쿼리를 전달합니다. 따라서 “.com” TLD 네임 서버는 “.com”으로 끝나는 도메인을, “.gov” TLD 네임 서버는 “.gov”로 끝나는 도메인을 각각 처리합니다.

2단계 도메인 이름 서버(대부분의 도메인 이름 서버가 여기에 해당함)는 전체 도메인 네임(예: 'ibm.com')에 대한 IP 주소가 포함된 영역 파일을 보유하고 있습니다.

DNS는 주요 서버 유형 외에도 영역 파일과 여러 레코드 유형을 사용하여 확인 프로세스를 지원합니다. 영역 파일은 DNS 영역 내의 특정 도메인에 대한 매핑 및 정보를 포함하는 텍스트 기반 파일입니다.

존 파일의 각 행은 특정 유형 또는 데이터의 특성에 대한 단일 정보를 나타내는 DNS 리소스 레코드를 정의합니다. 리소스 레코드는 사용자가 쿼리를 제출했을 때 DNS가 도메인 이름을 올바른 서버로 요청을 전달하는 실행 가능한 정보로 빠르게 변환하도록 지원합니다.

DNS 영역 파일은 두 가지 필수 레코드로 시작됩니다. 도메인에 대한 권한 있는 이름 서버를 나타내는 이름 서버(NS) 레코드와, 해당 DNS 영역의 주요 권한 이름 서버를 명시하는 권한 시작(SOA) 레코드입니다.

두 가지 주요 레코드 외에도 존 파일에는 여러 다른 유형의 레코드가 포함될 수 있습니다. 여기에는 다음이 포함됩니다.

모든 쿼리(때로는 DNS 요청이라고도 함)는 IP 주소를 확인하기 위해 동일한 논리를 따릅니다. 쿼리는 다양한 방식으로 시작될 수 있으며, 일반적인 예로 웹 브라우저를 사용하는 경우를 살펴볼 수 있습니다.

사용자가 웹 브라우저에 URL을 입력하면 브라우저는 DNS 리졸버로 쿼리를 전송하고, 해당 리졸버는 도메인의 레코드(관련 IP 주소 포함)를 보유한 권한 있는 네임 서버를 찾을 때까지 권한 있는 DNS 서버를 순차적으로 조회합니다. IP 주소가 브라우저로 반환되며 사용자는 해당 웹사이트에 연결됩니다.

보다 구체적으로, DNS의 쿼리 확인에는 몇 가지 주요 프로세스 및 구성 요소가 포함됩니다.

• 쿼리 시작. 사용자가 'ibm.com'과 같은 도메인 이름을 브라우저나 앱에 입력합니다. 해당 사이트의 IP 주소가 브라우저의 캐시에 없는 경우, 요청은 재귀 DNS 확인자로 전송됩니다. 일반적으로 사용자의 기기에는 ISP가 제공한 사전 정의된 DNS 설정이 있으며, 이 설정에 따라 어느 재귀 확인자가 요청을 받을지 결정됩니다.
  
  *많은 현대 브라우저가 HTTPS를 통해 DNS를 조회하는 DoH(DNS over HTTPS)를 지원하며, 많은 서비스 제공업체 또한 이러한 방식의 조회를 처리할 수 있는 서버를 구축해 두어, 이 프로세스는 발전하고 있습니다. 예를 들어, 미국에서 Firefox 브라우저를 사용한다면, 쿼리는 로컬 ISP 제공업체의 확인자 대신 기본적으로 Cloudflare의 DoH 서버로 전송됩니다. DoH는 강화된 개인정보 보호, 더 나은 성능 및 기타 여러 이점을 제공하기 때문에 점점 더 더 인기를 얻고 있습니다.

• 재귀 리졸버. 재귀 리졸버는 해당 도메인에 대응하는 IP 주소가 캐시에 있는지 확인합니다. 재귀 확인자의 캐시에 필요한 레코드가 없는 경우 루트 서버에서 시작하여 조회 프로세스를 시작합니다.

• 루트 이름 서버. 재귀 확인자는 루트 이름 서버를 쿼리하고, 루트 이름 서버는 해당 도메인에 대한 적절한 TLD 서버(여기서는 '.com' 도메인을 담당하는 TLD 이름 서버)에 대해 참조로 응답합니다.

• TLD 이름 서버. 리졸버는 “.com” TLD 네임 서버에 쿼리를 보내고, 해당 서버는 “ibm.com”에 대한 권한 있는 네임 서버의 주소로 응답합니다.

• 도메인 네임 서버. 리졸버는 도메인의 네임 서버에 쿼리를 보내고, 해당 서버는 DNS 존 파일을 조회하여 주어진 도메인 이름에 대한 올바른 레코드로 응답합니다.

• 쿼리 확인. 재귀 리졸버는 IP 주소를 사용자 장치에 반환합니다. 이후 브라우저 또는 앱은 해당 IP 주소의 호스트 서버에 연결을 시작하고 요청한 웹사이트나 서비스에 접근할 수 있습니다. 브라우저와 리졸버는 각각의 구성과 TTL에 따라 레코드를 캐시합니다.

DNS는 기본적으로 공개 프로토콜입니다. 퍼블릭 및 프라이빗 DNS는 반드시 정확하거나 전 세계적으로 통용되고 이해되는 용어 및 개념은 아니며, 그 사용처 또한 불명확한 경우가 많습니다.

Public DNS는 일반적으로 “표준” DNS 확인 프로세스 또는 공개 DNS 리졸버를 의미하며, 재귀 리졸버가 공개 DNS 레코드를 보유한 권한 있는 서버를 순차적으로 조회하여 IP 주소를 찾고 최종적으로 사용자를 원하는 웹사이트에 연결하는 방식입니다. 이는 일반적으로 사용자 ISP에서 제공하거나 Google의 “quad 8” Public DNS와 같은 DNS 서비스에서 제공하는 리졸버입니다. 프라이빗 리졸버는 공개 DNS를 조회하도록 구성할 수도 있지만, 일반적으로 제한된 네트워크나 기업 네트워크에서 더 많이 사용됩니다.

이 표준 DNS 조회는 공개적으로 사용 가능한 리졸버와 이러한 권한 있는 서버의 DNS 레코드가 인터넷에 접속할 수 있는 누구에게나 열려 있기 때문에 public DNS라고 불립니다.

“private DNS”라는 용어의 사용은 더욱 모호합니다. 이는 때때로 DNS over TLS(DoT) 또는 DNS over HTTPS(DoH)와 같은 암호화 프로토콜 사용을 설명하는 데 사용됩니다. 그러나 이는 “private DNS”라기보다 “프라이버시 기능” 또는 “프라이버시 프로토콜”로 설명하는 것이 더 정확합니다. 이 경우에도 리졸버가 공개 DNS를 사용해 필요한 정보를 찾는다는 점에서 확인 프로세스 자체는 동일합니다. 다만 이 과정이 암호화된 전송으로 수행될 뿐입니다.

Private DNS는 기업 네트워크나 가상 프라이빗 클라우드와 같은 폐쇄된 내부 네트워크에서 권한이 있는 사용자만 접근할 수 있는 조회 방식을 의미하기도 합니다. 이러한 시스템에서는 로컬에 구성된 프라이빗 리졸버가 내부 네트워크 내의 리소스와 사이트를 찾기 위해 프라이빗 서버를 조회합니다. 이 서버는 프라이빗 존과 내부 IP 주소만 제공하도록 구성되어 있으며, 네트워크는 내부 URL과 IP 주소를 외부 인터넷으로부터 숨깁니다. 이러한 유형의 Private DNS는 조직에 더 높은 수준의 제어와 보안을 제공합니다.

이러한 종류의 네트워크를 구성하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 로컬 네트워크상에서 확인을 위해 사용되는 .local과 같은 특수 용도 도메인을 이용하는 것입니다. 다른 하나는 인터넷에서 공개적으로 사용할 수 있는 도메인의 프라이빗 하위 도메인을 갖는 것입니다. 이 프라이빗 하위 도메인은 내부 네트워크 내에서 확인자를 사용하는 개인 또는 에이전트만 사용할 수 있습니다.

“public” DNS와 “private” DNS를 결합한 일반적인 기업 환경 구성은 “split-horizon DNS” 또는 “split brain DNS”라고 합니다. 이 구성에서는 내부 요청에 대해 로컬 프라이빗 권한 서버를 조회하는 로컬 리커서가 존재하며, 외부 요청에 대해서는 표준 DNS를 사용합니다. 일반적으로 서버에 내부 서버로 보낼 요청과 공용 인터넷으로 전달할 요청을 구분하는 도메인 이름 목록, 일종의 “허용 목록”이 존재합니다.

관리형 DNS는 조직이 DNS 인프라의 호스팅, 운영 및 관리를 타사에 아웃소싱할 수 있도록 하는 서비스입니다. 관리형 DNS를 사용하면 조직의 도메인에 대한 권한 있는 DNS 레코드가 공급자의 전 세계에 분산된 서버 네트워크에 호스팅됩니다. 많은 경우 관리형 DNS 공급자는 클라이언트가 DNS 레코드 및 기타 설정을 관리하고 자동화할 수 있도록 중앙 제어 플레인, 대시보드 또는 애플리케이션 프로그래밍 인터페이스(application programming interfaces, APIs)를 제공합니다.

관리형 DNS 서비스는 흔히 애니캐스트 라우팅, 로드 밸런싱, 가동 시간 서비스 수준 협약(SLA), 장애 극복 조치 보호, DNSSEC, 그리고 모니터링 및 문제 해결 툴과 같은 기능을 제공합니다. 이러한 기능은 기존의 자체 관리형 DNS 설정보다 더 빠르고, 안정적이며, 보안이 강화된 도메인 확인을 가능하게 합니다.

최상의 DNS 시스템일지라도 사이버 보안 문제에 취약할 수 있습니다. DNS 관련 공격에는 다음이 포함됩니다.

DNS 스푸핑(캐시 포이즈닝이라고도 함)은 공격자가 DNS 리졸버의 캐시에 잘못된 주소 레코드를 삽입하여 리졸버가 잘못된 IP 주소를 반환하게 하고 사용자를 악성 사이트로 리디렉션할 때 발생합니다. 스푸핑은 민감한 데이터를 손상시키고 피싱 공격 및 맬웨어 배포로 이어질 수 있습니다.

DNS 증폭은 공격자가 응답 주소를 피해자의 IP 주소로 위조한 상태로 DNS 서버에 작은 쿼리를 보내는 DDoS 공격의 한 유형입니다. 이러한 공격은 DNS 프로토콜의 상태 비저장 특성을 악용하고 작은 쿼리가 대규모 응답을 생성할 수 있다는 사실을 이용합니다.

증폭 공격의 결과로 DNS 서버는 훨씬 더 큰 응답으로 응답하며, 이로 인해 사용자에게 전달되는 트래픽의 양이 증폭되어 리소스가 과부하됩니다. 이로 인해 DNS가 작동하지 않아 애플리케이션이 다운될 수 있습니다.

DNS 터널링은 DNS 쿼리 및 응답 내에서 HTTP와 같은 비 DNS 트래픽을 캡슐화하여 보안 조치를 우회하는 데 사용되는 기술입니다. 공격자는 DNS 터널을 사용하여 맬웨어 명령을 전달하거나 손상된 네트워크에서 DNS 정보를 유출할 수 있으며, 탐지를 피하기 위해 DNS 쿼리 및 응답 내에 페이로드를 인코딩하는 경우가 많습니다.

사용 중지된 서비스를 가리키는 하위 도메인의 방치된 DNS 항목은 공격자의 주요 표적이 됩니다. 클라우드 호스트와 같은 서비스가 사용 중지되었지만 DNS 항목이 남아 있는 경우 공격자는 잠재적으로 하위 도메인을 요청하고 그 자리에 악성 사이트나 서비스를 설정할 수 있습니다.

조직이 어떤 DNS 서비스를 선택하든 보안 프로토콜을 구현하여 DNS 공격 표면을 최소화하고 잠재적인 보안 문제를 완화하며 네트워크 프로세스에서 DNS를 최적화하는 것이 중요합니다. DNS 보안을 강화하기 위한 몇 가지 유용한 방법은 다음과 같습니다.

• DNS 보안 확장(DNSSEC) 배포.DNSSEC는 DNS 응답에 디지털 서명을 요구함으로써 DNS 조회에 보안 계층을 추가합니다. DNSSEC는 요청의 출처를 인증하고 DNS 데이터의 무결성을 검증하여 DNS 스푸핑 공격을 방지할 수 있습니다.

• 속도 제한 적용 DNS 서버에서 속도 제한을 적용하면 일정 시간 동안 단일 요청자에게 제공되는 응답 수 또는 서버가 응답을 전송하는 속도를 제한하여 DDoS 공격을 완화할 수 있습니다.

• 도메인 등록기관에 대해 이중 인증(two-factor authentication, 2FA) 요구도메인 등록기관 계정에 2FA를 설정하면 공격자가 서버에 무단 접근하기 어려워지고 도메인 탈취 위험을 줄일 수 있습니다.

• 중복성 활용. 지리적으로 분산된 여러 서버에 중복 구성으로 DNS를 배포하면, 공격이나 중단이 발생할 경우 네트워크 가용성을 보장하는 데 도움이 됩니다. 기본 서버가 다운되면 보조 서버가 DNS 확인 서비스를 대신할 수 있습니다.

• DNS 플러싱 구현. DNS 캐시를 지우면 로컬 네트워크의 모든 항목이 제거되므로 사용자를 악성 사이트로 유도할 수 있는 유효하지 않거나 침해된 DNS 레코드를 삭제하는 데 유용할 수 있습니다. 일반적으로 이는 확인자 운영자가 제공하는 요청 기반 서비스입니다. 그렇지 않으면 TTL이 만료될 때 캐시가 지워집니다.
  
  
• DNS 위협에 대한 최신 정보 습득. 공격자와 보안 위협은 침해 대상인 시스템과 거의 동일한 방식으로 진화합니다. 최신 DNS 취약점과 위협을 파악하면 악의적인 공격자보다 한발 앞서 대응할 수 있습니다.

DNS가 등장하기 이전에 인터넷은 주로 학술 및 연구 기관에서 사용하던 성장 단계의 컴퓨터 네트워크였습니다. 개발자들은 SRI International에서 관리하고 인터넷상의 모든 컴퓨터로 배포되던 HOSTS.TXT라는 단순 텍스트 파일을 사용하여, 호스트 이름을 IP 주소에 수동으로 매핑했습니다. 그러나 네트워크가 확장됨에 따라 이러한 접근 방식은 점점 더 어려워졌습니다.

HOSTS.TXT의 한계를 극복하고 보다 확장 가능한 시스템을 만들기 위해 University of Southern California 컴퓨터 과학자 Paul Mockapetris는 1983년에 도메인 이름 시스템을 발명했습니다. DNS를 개발한 인터넷 선구자들은 새로운 시스템 사양을 설명하는 최초의 RFC(request for comments) 문서인 RFC 882와 RFC 883도 작성했습니다. RFC 1034와 RFC 1035는 이후 이전의 RFC를 대체했습니다.

결국 DNS가 확장됨에 따라 DNS 관리는 인터넷할당번호관리기관(IANA)의 책임이 되었고, 결국 1998년 비영리 단체인 국제인터넷주소관리기구(ICANN)의 관리 하에 놓이게 되었습니다.