[Network] DNS 서버 동작 방법

DNS 서버의 기본 동작

 

DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회 내용에 응답하는 형태로 정보를 응답하는 일이다. 클라이언트의 조회 메시지에는 다음의 세 가지 정보가 포함된다.

 

1. 이름

서버나 메일 전송 목적지와 같은 이름이다. gray1234@google.com이라고 하면 google.com을 의미한다.

 

2. 클래스

클래스는 항상 인터넷을 나타내는 'IN' 값을 사용한다.

 

3. 타입

이름에 어떤 타입의 정보가 지원되는지 나타낸다. 예를 들어 타입이 A(주소)이면 이름에 IP 주소가 지원되는 것을 나타낸다.

예를 들어 이름이 www.lab.google.com인 서버의 IP 주소를 조사할 때 클라이언트는 이름 = www.lab.google.com  , 클래스 = IN, 타입 = A 과 같은 정보를 포함한 조회 메시지를 DNS 서버로 보낸다. 그러면 DNS 서버는 리소스 레코드를 참고해서 등록된 정보가 있는지 탐색한다. 위 그림과 같이 등록된 정보가 있는 경우 192.124.0.226이라는 IP 주소를 응답으로 전송한다.

 

만약 이름 = google.com, 클래스 = IN, 타입 = MX와 같이 요청을 보낸다면 DNS 서버는 10과 mail.google.com이라는 두 개의 항목과 IP 주소를 응답으로 전송한다. 타입이 MX(메일)인 경우에는 메일 서버의 우선순위와 메일 서버의 이름이라는 두 항목으로 저장되어 있기 때문에 두 개의 항목을 전송하고, 추가적으로 mail.google.com의 주소인 192.124.0.124까지 더해서 최종 응답으로 전송한다.

 

이처럼 이름과 타입에 따라 조사하는 정보를 저장하고, 그것에 따라 해당하는 데이터를 찾아 클라이언트에 전송하는 것이 DNS 서버의 기본 동작이다.

 

도메인의 계층

DNS의 기본 동작을 설명하는 과정에서는 DNS 서버에 이름과 IP 주소가 등록되어 있는 경우만 생각했다. 하지만 인터넷에는 막대한 수의 서버가 있으므로 이 정보들을 모두 1대의 DNS 서버에 등록하는 것은 불가능하다. 그렇다면 DNS 서버에 IP 주소가 등록되어 있지 않는 경우에는 어떻게 동작할까?

 

우선 DNS 서버에 등록한 정보에는 모든 도메인 명이라는 계층적인 구조를 가지고 있다. DNS에서 취급되는 이름은 www.lab.google.com  처럼 점(.)으로 구분되어 있는데, 이 점이 계층을 구분한다. 즉 .을 기준으로 계층이 나눠진다고 할 수 있고, 주소를 기준으로 오른쪽에 위치한 것이 상위 계층이다. www.lab.google.com에서는 com, google, lab, www의 순서로 높은 계층부터 낮은 계층으로 구성된다는 것을 알 수 있다. 여기서 계층 하나 하나씩을 도메인이라고 한다.

 

 

담당 DNS 서버를 찾아 IP 주소 가져오기

인터넷에는 DNS 서버가 수만 대나 있으므로 모든 DNS를 하나씩 뒤져서 찾을 수는 없다. 여기서 가장 중요한 것은 액세스 대상의 웹 서버가 어떤 DNS 서버에 등록되어 있는지를 찾아내는 것이다.

 

먼저 하위의 도메인을 담당하는 DNS 서버의 IP 주소를 그 상위의 DNS 서버에 등록한다. 

 

그리고 상위의 DNS 서버를 또 그 상위의 DNS 서버에 등록하는 식으로 차례대로 등록한다. 즉 lab.google.com이라는 도메인을 담당하는 DNS 서버를 google.com의 DNS 서버에 등록하고, google.com의 DNS 서버를 com 도메인의 DNS 서버에 등록한다. 이렇게 하면 상위의 DNS 서버에 가면 하위의 DNS 서버의 IP 주소를 알 수 있고, 거기서 응답 메시지를 보낼 수 있다.

 

그렇다면 com과 같이 최상위 계층의 도메인은 어떤 DNS 서버에 등록되어 있을까? 인터넷의 도메인은 com이나 kr의 상위에 또 하나의 루트 도메인이 존재한다. 루트 도메인에는 com이나 kr, jp와 같은 도메인명이 없으므로 보통 도메인을 쓸 때는 생략한다. 만약 명시적으로 작성해야할 때는 lab.google.com.과 같이 마지막에 .을 표시한다. 이렇게해서 하위의 DNS 서버를 상위의 DNS 서버에 등록하여 루트 도메이에서 차례로 아래쪽으로 거슬러 갈 수 있다.

 

루트 도메인의 DNS 서버를 인터넷에 존재하는 DNS 서버에 전부 등록한다. 이렇게 해서 어느 DNS 서버에서도 루트 도메인에 접근할 수 있게 된다. 그 결과 클라이언트에서 어딘가의 DNS 서버에 액세스하면, 이 지점에서 루트 도메인을 경유하여 도메인의 계층 아래로 찾아가서 최종적으로 원하는 DNS 서버에 도착한다. 루트 도메인의 DNS 서버에 할당된 IP 주소는 전 세계에 13개 밖에 존재하지 않으므로 이 정보를 각 DNS 서버에 등록하는 것은 어렵지 않다. 실제로 루트 도메인의 DNS 서버에 관한 정보는 DNS 서버 소프트웨어 설치와 함께 설정 파일로 배포되어 있으므로 DNS 서버 소프트웨어를 설치하면 자동으로 등록이 완료된다.

 

lab.google.com 이라는 웹 서버에 관한 정보를 조회한다고 하자. 가장 가까운 DNS 서버에는 lab.google.com이라는 이름이 등록되어 있지 않으므로 루트 도메인으로 이동한다. 이 과정에서 모든 DNS 서버에는 루트 도메인의 DNS 서버가 등록되어 있으므로 거기에 클라이언트로 받은 요청 메시지를 전송한다. 여기서 가장 가까운 DNS 서버란 사용자에게 물리적으로 가까운 위치를 의미한다.

 

루트 도메인에는 lab.google.com이라는 이름이 등록되어 있지 않지만 com이라는 이름을 보면 com 도메인의 아래에 있다는 것을 알 수 있다. 그래서 루트 도메인은 가장 가까운 DNS 서버에게 com한테 물어봐! 라고 하면 가장 가까운 DNS 서버는 com 도메인의 DNS 서버에 조회 메시지를 보낸다. lab.google.com이라는 이름이 com 도메인의 DNS 서버에도 등록되어 있지 않으므로 아래 계층인 google 도메인의 DNS 서버로 넘어간다. 이와 같은 과정이 반복되면 이 중에서 원하는 DNS 서버에 도달하게 된다.

 

최종적으로 lab 도메인의 DNS 서버에 접근하게 되면 lab.google.com 이라는 이름을 찾을 수 있고 거기서 IP 주소를 알 수 있다. 클라이언트에서 조회 메시지를 받은 DNS 서버는 이렇게 해서 IP 주소를 조사하고 이 결과를 클라이언트에 응답한다.

 

DNS 캐시

웹 브라우저에 URL이 입력되면 매번 DNS 서버에 요청을 보내 IP 주소를 받아오지 않는다. 사용자가 webtoon.naver.com이라는 사이트에 50번 접속한다고 하면, 50번 만큼의 DNS 서버에 요청을 보내는 것은 비효율적이다. 아무리 public DNS 서버가 많다고 하더라도 네트워크를 타는 비용이 OS 내부에서 처리하는 비용보다 클 것이다.

 

그래서 DNS 캐시는 요청이 인터넷으로 전송되기 전, 최근 방문한 주소의 이름을 확인해 처리 속도를 높인다. 브라우저가 네트워크에 요청을 보내기 전에 컴퓨터(클라이언트의 PC)는 각 요청을 먼저 가로채, DNS 캐시 테이블에서 도메인 이름을 조회한다. 캐시 테이블에는 최근에 액세스한 모든 도메인 이름 목록과 주소가 포함되어 있다.

 

또한 컴퓨터(클라이언트의 PC)에서 뿐만 아니라 DNS 서버에서도 캐시를 사용한다. DNS 서버는 요청받은 도메인 이름에 대한 IP 주소를 찾기 위해 다른 DNS 서버를 쿼리하며, 이 과정에서 캐시를 사용하여 응답 속도를 높일 수 있다. DNS 서버에서 캐시는 보통 메모리에 저장되며, TTL(Time-To-Live) 값이 만료되면 캐시에서 제거된다.

 

 

여기서 취약점이 발생할 수 있는데, 공격자는 DNS를 가장하여 DNS에 요청을 보낸 후, DNS 확인자가 쿼리할 때 응답을 위조하여 DNS 캐시를 감염시킬 수 있다. 왜냐하면 DNS 서버가 TCP 대신 UDP를 사용하고, 현재 DNS 정보에 대한 확인이 없기 때문에 가능하다. UDP는 TCP와 달리 연결이 필요한 것이 아니고, 송신측에서 받을 준비가 되었다는 것도 확인하지 않기 때문이다.