HTTP 기초 - DNS

11095 단어 httphttp

지난 포스팅에서는 IP 의 한계점들을 해결해줄 수 있는 TCP UDP 에 대해 살펴보았고,
TCP/IP 4 Layer Model 을 통해 데이터가 애플리케이션부터 인터넷을 거쳐 목적지까지 전송되는 과정을 간단히 알아보았다.

또한, 마지막에는 하나의 IP Address 를 사용하는 각각의 프로그램에 PORT 를 할당하여 이를 통해 내부적으로 프로그램을 구분할 수 있는 원리까지 살펴보았다.

자세한 내용은 아래 링크를 참고바란다.
HTTP 기초 - TCP, UDP

이어서 이번 포스팅에서는 DNS Domain Name System 에 대해 살펴보고자 한다.

DNS

호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하는 분산형 데이터베이스 시스템이다.

위는 DNS 에 대한 위키피디아의 정의이다.

어렵게 설명해놓았지만 결국 DNSIP AddressDomain Name 으로 변환해주는 Service 이면서 관련 정보를 저장해놓은 Server 라고 볼 수 있다.

즉, 각각의 IP Address 에 이름을 부여하여 매핑하고, 부여된 이름을 통해 원하는 IP Address 에 언제든지 접근할 수 있도록 하는 시스템인 것이다.

그렇다면, 왜 우리는 IP Address 에 이름을 부여하여 사용해야 할까?

사실, IP Address 를 사용해서도 충분히 목표 서버 컴퓨터에 접근할 수 있다. 하지만 모든 웹사이트의 주소가 다음과 같은 IP Address 로 이루어져 있다면, 웹사이트를 이동하고 싶을 때마다 번번이 메모장을 켜 미리 작성해둔 IP Address 를 찾아 주소창에 옮겨넣어야 할 것이다.

심지어, IPv6 의 경우에는 주소가 더욱 복잡하다.

과연 이 주소들을 모두 외워버리거나, 메모장에 적어두고 필요할 때마다 꺼내 쓰는 일이 효율적인 방법일까?

문제는 이 뿐만이 아니다.
IP Address 는 수시로 변경될 수 있다.
만약 우리가 열심히 외워놓은 IP Address 들이 변경되었다고 생각해보자. 우리는 더이상 외워놓은 주소를 통해 해당 웹사이트에 접속할 수 없게 될 것이다.

결국, 변경된 새로운 IP Address 를 찾아 다시 외우거나 메모장에 새로 업데이트를 하는 수 밖엔 없다.

생각만해도 암담하고 참담한 상황이다.

하지만 만약, 각각의 IP Address 가 인간이 이해할 수 있는 문자열로 된 이름을 부여받게 된다면?

예를 들어, 200.200.200.2 라는 IP Address 에 'google.com' 이나 'aaa.com' 이라는 문자열로 된 Domain Name 을 부여하는 것이다.

이렇게 되면 우리는 각 웹사이트의 주소를 너무나 쉽게 외우고 사용할 수 있게 될 것이다.

또한, 특정 데이터베이스에 각 IP AddressDomain Name 을 매핑한 정보를 정리하여 저장해놓는다면, IP Address 가 변경되었을 때 데이터베이스 내에서 해당 주소만 손쉽게 변경해주면 될 것이다.

즉, 사용자는 웹사이트의 IP Address 가 변경되었다고 하더라도 이를 인지해야할 이유가 없다. Domain Name 을 사용할 것이기 때문이다.

실제로 우리는 지금껏 특정 웹사이트나 친구 컴퓨터의 IP Address 를 외워본적이 없다. 물론, 구글의 IP Address 가 변경되었다고 당황해본 적도 없을 것이다. 각각의 주소에 부여된 이름인 Domain Name 을 사용해왔기 때문이다.

정리하자면 IP Address 는 외우기도 어렵고 수시로 변경될 수 있어 사용하기 불편하다. 따라서, IP Address 각각에 문자열로 된 Domain Name 을 부여하여 이를 활용해 손쉽게 서버에 접근할 수 있도록 하는 시스템이 DNS 인 것이다.

DNS 의 사용


DNS 는 위와 같은 단계로 사용된다.

우리가 작성한 Domain Name 인 'google.com' 에 접속하기 위해서는 IP Address 로 변환하는 과정이 필요하다.
따라서, 클라이언트는 Domain NameIP Address 의 매핑 정보를 저장하고 있는 DNS Server 에 'google.com' 의 IP Address 를 요청한다.

이후, DNS 는 'google.com' 의 IP Address 를 클라이언트에게 반환해준다.
위 예시에서는 200.200.200.2 의 주소를 반환해줄 것이다.

그리고 우리는 DNS Server 로 부터 받은 IP Address 를 사용하여 'google.com' 의 서버와 연결을 맺을 수 있게 된다.

DNS 의 구조

이제 DNS 의 구조에 대해 더 자세히 알아보고, 어떠한 과정을 통해 IP Address 를 받아오는지 깊게 들여다보자.

DNS 는 거대한 분산 데이터베이스 시스템이며 Domain Name SpaceName Server Resolver 로 구성되어 있다.

각각을 간단히 살펴보면,

Domain Name Space 는 무수히 많은 도메인 주소들을 관리하는 매커니즘으로, 거대한 분산 시스템이다.

최상위에는 dot 으로도 불리는 root 가 존재하고, 그 아래로 최상위 레벨 도메인 TLD , 2 레벨 도메인 SLD , 서브 도메인 Sub Domain 이 계층적 트리 구조로 위치하고 있다.

각 레벨은 . 으로 구분되며, 동일한 레벨에서는 Domain Name 이 유일해야 한다.
즉, TLD 에서 com 이라는 Domain Name 을 가진다면, govkr 을 동시에 사용할 수 없는 것이다.

또한, 최하위 Domain Name 부터 상위층의 Domain Name 으로 이동하면서 왼쪽에서 오른쪽 방향으로 표기한다.
따라서, 최상위 레벨 도메인 TLDDomain Name 의 가장 오른쪽에 위치하며, com edu org kr 등이 이에 속한다.
Sub Domainwww 가 도메인 주소의 가장 왼쪽에 위치하는 이유도 이와 같은 이유에서다.

즉, 모든 도메인 주소들은 정해진 규칙에 따라 분리되는데 이 때 계층화되어 분리된 각 부분들을 Domain Name Space 라는 거대한 트리 구조 시스템으로 관리할 수 있는 것이다.

이제 분리된 각 부분들은 트리 구조 내의 노드들에 나뉘어져 담기게 되고, 각 노드 내의 Name Server 들이 해당 부분들을 관리하게 된다.

위의 그림에서처럼 root 의 하위에는 TLD 가 위치하고 있고, TLDcom 의 하위에 2차 도메인인 google 과 naver 가 위치해있다. 이어서 google 의 하위에는 www 라는 sub domain 이 있고 naver 의 하위에는 다시 wwwblog 라는 sub domain 이 위치해있다.
이렇게 나뉘어진 도메인 주소의 부분들은 노드 내의 Name Sever 들에 의해 관리된다.

마지막으로, ResolverDNS 의 클라이언트로 해석기 라고도 불린다. 말그대로 클라이언트의 요청을 Name Server 로 전달하고, 받은 정보를 클라이언트에게 제공하는 기능을 수행한다. 응용프로그램은 Resolver 를 통해 Domain Name Space 에 접근할 수 있고, 정보를 요청하거나 전달받을 수 있는 것이다.

DNS 동작원리

앞서 DNS 의 구성 요소들인 Domain Name Space Name Server Resolver 에 대해 알아보았다.
간단하게 이들 간 관계를 정리해보면 다음과 같다.

애플리케이션은 Resolver 를 통해 IP Address 에 대한 요청을 보낸다. ResolverName Server 에게 요청을 전달한다. 이 때 Domain Name Space 를 통해 각 도메인 주소들은 분리되어 관리되고 있고 Name Server 는 요청에 대한 IP Address 를 찾아 Resolver 에게 반환한다. Resolver 는 다시 응답 메시지를 애플리케이션에 전달한다.

이 과정에서 Cache 가 참조되기도 한다.

📌 Cache ?

Name Server 가 애플리케이션의 요청이 있을 때마다 Domain Name Space 에서 IP Address 를 찾아내야 한다면 Name Server 의 부담이 증가될 것이고, 이는 응답에 대한 속도가 저하되는 문제점을 야기할 수 있다. 따라서 Cache 를 활용하여 최근 전달한 정보나 자주 조회하는 정보에 대해 미리 적재해놓고 이를 참조해 빠르게 정보를 찾아낼 수 있다. 하지만 CacheTTL 이라는 시간 관리 기능이 있어 일정 시간 동안만 정보를 적재해놓고, 시간이 초과되면 데이터를 삭제한다.

이제 Name ServerIP Address 를 물어오는 DNS 의 쿼리 처리 과정에 대해 정리해보자.

📌 Local DNS ?

Local DNS 는 단말에 설정되어 있는 DNS 로, IP 를 찾기 위해 가장 먼저 찾게 되는 곳이다.
기본적으로 LAN 선을 통해 인터넷이 연결되면 인터넷을 사용할 수 있게 IP 를 할당해주는 통신사의 DNS 가 등록되는데, Resolver 를 통해 애플리케이션과 소통할 수 있다.
즉, Local DNSName Server 이다.

1) 사용자가 브라우저에 'www.naver.com' 을 입력한다.

2) PC 는 Local DNS 에게 'www.naver.com' 에 대한 IP Address 를 물어본다.

3) PC 로부터 Resolver 를 통해 요청을 전달받은 Local DNS 는 'www.naver.com' 에 대한 IP Address 를 찾아내기 위해 Cache 를 확인한다.

- `Cache` 에서 `IP Address` 를 찾아본다.
- 캐싱되어 있다면 `IP Address` 를 전달하고 끝.

4) CacheIP Address 가 없다면, root 에 물어본다.

- `root` 는 `TLD` 정보만 가지고 있다.
- 즉, 'www.naver.com' 의 `IP Address` 를 모른다.
- 대신 `com DNS` 에 대한 주소를 돌려준다.
- `com DNS` 는 `com` 을 관리하는 서버이다.

5) Local DNScom DNS 에 다시 물어본다.

- 역시 `com DNS` 는 `SLD` 정보만 가지고 있다.
- 즉, 'www.naver.com' 의 `IP Address` 를 모른다.
- 대신 `naver.com DNS` 에 대한 주소를 돌려준다.
- `naver.com DNS` 는 `naver.com` 을 관리하는 서버이다.

6) Local DNSnaver.com DNS 에 다시 물어본다.

- `naver.com DNS` 는 `Sub Domain` 정보를 가지고 있다.
- 즉, 'www.naver.com' 의 `IP Address` 를 알고 있다.
- 따라서, `Local DNS` 에게 `IP Address` 를 전달해준다.

7) Local DNS 는 전달받은 IP AddressCache 에 저장한다.

- 해당 정보에 대한 동일한 요청이 들어올 경우,
  바로 응답하기 위해서 캐싱한다.

8) IP AddressResolver 를 통해 PC 로 전달한다.


이렇듯, Local DNS 가 'www.naver.com' 의 IP Address 를 찾기 위해서는 Cache 부터 시작해서 root DNS com DNS naver.com DNS 등 여러 DNS 를 거쳐야 했다.

앞서 살펴본 Domain Name Space 의 구조 상 root DNSTLD 에 대한 정보만을 가지고 있고, TLDSLD 에 대한 정보만을 가지고 있으며 SLDSub Domain 에 대한 정보를 가지고 있기 때문이다.

따라서, Name ServerLocal DNS 가 요청에 대한 IP Address 를 찾기 위해서는 여러 DNS 를 거쳐야만 했고, 이러한 과정을 Recursive Query 라고 한다.



이번 포스팅에서는 DNS 에 대해 알아보았다.

DNS 를 사용하는 이유와 Domain Name Space Name Server Resolver 등 그 구성요소에 대해서도 살펴보고 조금 더 깊게 들어가 Recursive Query 에 대해서도 다루어 보았다.

이제 우리는 위 그림에서 클라이언트가 어떤 방식으로 'www.google.com' 에 대한 IP Address 를 요청하고 응답받는지 설명할 수 있게 되었다.

다음 포스팅에서는 URI 에 대해서 살펴볼 예정이다.



출처


좋은 웹페이지 즐겨찾기