DNS(Domain Name System)
인터넷상의 모든 컴퓨터는 숫자를 사용하여 서로를 찾고 통신하게 되는데 이를 IP 주소라고 한다. 하지만 숫자로 이루어진 해당 IP 주소는 너무 길어지면 사람이 기억하기 어려워진다.
이때 사람들이 이해하기 쉽게 특정 이름을 부여하게 된다면 숫자보다 기억하기 수월해진다. 이것을 도메인 네임(Domain Name)이라고 부른다.
DNS는 사람이 이해하기 쉬운 이름으로 되어 있는 도메인 네임과 실제 IP 주소 간의 매핑을 관리하게 되는 시스템으로 분산형 DB로 되어 있다.
DNS의 대표적인 예시로 전화번호부를 생각해볼 수 있는데 만약 핸드폰으로 다른 누군가에게 전화를 건다면 전화번호를 외워서 전화하는 것이 아닌 이미 저장되어 있는 이름 혹은 별칭을 통해서 전화를 하게 된다.
실제 DNS 서버는 이름을 IP 주소로 변환하여 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어하게 되는데 이러한 요청을 쿼리라고 부른다.
분산형 DB로 관리되는 이유
도메인 이름으로 요청이 들어오면 한 대의 서버에서 찾으려면 너무 몰리고 느려지고 비효율적이다.
따라서 도메인을 계층적으로 구분하기 위해 도메인에 닷(dot)을 추가하여 계층을 나타내게 된다.
DNS 계층
DNS 서버는 계층적 구조로 되어 있는데 총 4가지로 분류할 수 있다. 하나씩 살펴보면서 각 계층이 어떤 역할을 하는지 알아보자.
- Root Domain
Root DNS라고 불리는 최상위 루트 도메인은 전 세계에 13대로 이루어져 있는데 주로 DNS 해석부터 발생한 DNS 요청에 대해 적절한 TLD 네임 서버 정보를 반환해준다.
(루트 서버가 전 세계에 오직 13대만 있는 것은 아니고 실제로는 더 많지만 다른 루트 서버 네트워크를 쿼리 하는 데 사용되는 IP주소가 13개뿐이라서 그렇다.)
- Top-Level Domain(TLD)
최상위 도메인이라고 불리며 국가명을 나타내는 국가 최상위 도메인과 일반적으로 사용되는 일반 최상위 도메인으로 구분된다.
Authoritative DNS 서버의 주소를 저장하고 이를 반환해주는 역할을 한다.
- Second-Level Domain(SLD)
실제 개인 도메인과 IP 주소의 관계가 기록되는 서버이다.
SLD는 Authoritative DNS 서버라고도 불린다.
- Sub-Domain
호스트의 정보를 저장하는 서버로 서브 도메인은 주로 메인 도메인 앞에 붙여 쓰게 된다.
예를 들면 www.example.com이라는 도메인 이름이 있다고 가정하면 example.com 앞에 붙은 www가 서브 도메인이 되는 것이다.
DNS Resolver
DNS Resolver는 사용자의 컴퓨터나 네트워크에 위치한 DNS 클라이언트이다.
사용자가 도메인 이름을 입력하게 되면 해당 도메인 이름을 IP 주소로 변환하기 위해서 DNS 서버에 요청해야 되는데 해당 역할을 DNS Resolver가 맡아서 해준다.
DNS Resolver는 어떤 도메인 서버에서 찾아야 하는지 혹은 이미 캐시에 저장되어 있는지 등을 파악하여 사용자에게 응답을 전달하는 역할을 하게 된다.
DNS 동작 방식
본격적인 DNS 동작 방식을 살펴보기 전에 2가지의 쿼리에 대해서 알아보자.
- Recursive Query
Recursive Query는 재귀적 질의라고 하며 IT 주소를 돌려주는 작업을 의미한다.
해당 쿼리를 받은 Recursive 서버는 반복적으로 권한 있는 도메인 서버로 Iterative Query를 보내서 목표하는 IP 주소를 찾게 되고 해당 주소를 응답으로 반환하게 된다.
- Iterative Query
Iterative Query는 반복적 질의라고 하며 Recursive 서버가 다른 DNS 서버에게 쿼리를 보내어 응답을 요청하는 작업을 의미한다.
만약 Recursive 서버에 이미 IP 주소가 캐시 되어 있다면 해당 과정은 건너뛴다.
위의 그림에서 파란색 화살표는 Recursive Query, 검은색 화살표는 Iterative Query를 의미한다.
①. 먼저 사용자가 웹 브라우저에 example.com을 입력하게 되면 DNS Resolver가 우선 자신의 캐시에 해당 도메인 이름에 대한 IP 주소가 있는지 확인한다.
만약 캐시에 도메인 이름에 대한 정보가 없다면 Iterative Query를 DNS 서버에 보내서 example.com 도메인에 해당하는 IP 주소를 찾게 된다.
② ~ ③. 앞서 캐시에서 IP 주소를 찾지 못했다면 DNS Resolver가 루트 서버에 쿼리를 보낸다.
루트 서버는 example.com이라는 도메인에 대한 IP 주소를 가지고 있지는 않지만 대신 TLD 서버에 대한 정보를 가지고 있어 TLD 서버의 IP 주소를 다시 DNS Resolver에게 전달해 준다.
④ ~ ⑤. 2 ~ 3번 과정을 통해 루트 서버에서 받은 TLD IP 주소를 가지고 DNS Resolver는 TLD 서버에 쿼리를 보낸다.
사용자가 입력했던 example.com 도메인에서 .com을 TLD 서버에 요청하게 되고 해당 TLD 서버는 .com에 대한 Authoritative 서버의 IP 주소를 DNS Resolver에게 다시 반환해 준다.
⑥ ~ ⑦. 4 ~ 5번 과정을 통해 받았던 Authoritative 서버의 IP 주소를 가지고 DNS Resolver는 Authoritative 서버에 쿼리를 보낸다.
Authoritative 서버는 example.com 도메인에 대한 IP 주소를 가지고 있어 해당 주소를 다시 DNS Resolver에게 반환해 주게 된다.
⑧. DNS Resolver는 Authoritative 서버로부터 전달받은 example.com에 해당하는 IP 주소를 캐시에 저장하고 최종적으로 사용자에게 IP 주소를 응답해 주게 된다.
동작 과정을 쭉 살펴보면 중간에 캐시에 대한 내용이 나오는데 해당 캐시가 필요한 이유는 생각해 보면 도메인 이름을 통해 접속하는 일이 상당히 자주 발생할 것인데 그럴 때마다 DNS 서버에 질의해서 찾게 된다면 그만큼 성능이 느려질 수밖에 없다.
따라서 캐시를 두어 같은 도메인에 대한 요청이 들어오면 바로 IP 주소를 반환할 수 있게 하여 성능 저하 없이 서비스를 제공할 수 있게 된다.
FQDN(Fully Qualified Domain Name)
FQDN은 도메인의 전체 이름을 표기하는 방식으로 Host name + Domain Name으로 DNS 서버 이름을 구하게 된다.
예를 들어 www.naver.com(.)은 www라는 host name과 naver.com이라는 도메인 네임이 합쳐진 풀 네임이다. 참고로 맨 뒤에 .(닷)을 붙이게 되는데 이 과정은 생략해도 된다.
DNS는 언제 사용되는 것일까?
앞서 DNS에 대해서 살펴보고 동작하는 과정도 알아보았다. 그러면 이제는 이러한 과정들이 언제 수행되는지 알아보자.
A라는 PC에서 B라는 PC에 어떤 요청을 보낸다고 가정해 보자.
먼저 TCP/IP 통신 프로토콜을 사용한다고 생각해 보면 Application Layer에서 HTTP 요청을 생성하게 되고 Transport Layer에서 해당 HTTP 요청을 TCP 세그먼트로 분할하게 된다.
그런 다음 Internet Layer에서 A라는 PC의 IP 주소와 목적지인 B라는 PC의 IP 주소를 포함하여 패킷을 만들게 되는데 이때 B라는 PC(즉, 목적지 IP주소)가 www.example.com이라고 생각해 보자.
그러면 해당 부분에서 OS가 DNS서버로 도메인 이름에 대한 IP 주소를 요청하게 된다. 이처럼 OS가 DNS에 요청을 보낼 때는 UDP 프로토콜을 사용한다고 한다.
DNS를 공부해 보면서 간단하게 생각했던 도메인이라는 것이 생각보다 어려웠었다.
특히 동작 과정은 그래도 이해했는데 도대체 언제 이러한 과정이 수행되지? 라는 의문을 많이 가졌었는데 웹 주소를 입력했을 때 발생하는 일을 찾아보게 되면서 어느 정도 이해할 수 있었다.
네트워크 쪽은 전체적인 큰 그림을 그려보면서 공부하는 것이 이해하는데 더 빠를 것 같다고 생각한다.
참고 자료
'CS > 네트워크' 카테고리의 다른 글
네트워크 - REST API, RESTful (0) | 2024.07.17 |
---|---|
네트워크 - 로드 밸런싱(Load Balancing) (0) | 2024.07.14 |
네트워크 - 대역폭 (0) | 2024.07.10 |
네트워크 - HTTP (2) | 2023.10.20 |
네트워크 - IP (0) | 2023.10.14 |