이 포스팅은 '성공과 실패를 결정하는 1%의 네트워크 원리' 책을 기반으로 작성되었습니다.
1장 세번째. 전 세계의 DNS 서버가 연대한다
1. DNS 서버의 기본 동작
리졸버로부터 DNS서버가 받는 조회 메시지에는 다음과 같은 내용이 포함되어 있다.
이름 : 서버 or 메일 배송 목적지와 같은 이름
클래스 : 초창기 때는 인터넷 이외에도 네트워크를 이용하는 경우가 많았다. 따라서 이들을 구분해주기 위해 클래스라는 것을 이용했다. 그러나 지금은 인터넷 이외의 네트워크는 소멸되었으므로 클래스는 항상 인터넷을 나타내는 ‘IN’이라는 값이 된다.
타입 : 타입에 따라 클라이언트에 회답하는 정보의 내용이 달라진다.
IP주소를 조회할 때는 A라는 타입(Address)을 이용하며, 메일 배송 목적지를 조회할 때는 MX라는 타입을 사용한다. 이 외에도 여러 가지 타입들이 존재한다. 이렇게 타입을 구분해서 사용해야 하므로 다양한 정보를 취급할 수 있다.
DNS 서버에는 이 세 가지 정보에 대응하여 클라이언트에 회답하는 항목들을 테이블 형식으로 등록해두었다. 이러한 항목들을 리소스 레코드라고 한다. 조회 항목의 이름과 클래스와 타입을 비교하여 세 항목 모두 일치하는 경우의 리소스 레코드를 응답 메시지 안에 기입하게 된다.
위의 경우에는 기존에 등록되어 있던 DNS 서버에 요청한 항목이 존재하는 경우이다. 하지만 인터넷 상에는 막대한 수의 서버가 존재하고, 수많은 값들이 각 서버에 퍼져있다. 만약 기존에 등록되어 있던 DNS 서버에 요청한 항목이 존재하지 않은 경우에는 어떻게 해야 하는가?
당연히 여러 대의 DNS 서버들이 서로 연대하여 요청한 정보를 찾는 구조일 것이다. 이 구조, 원리를 살펴보자.
2. DNS 서버의 구조
DNS 서버에 등록된 정보들은 계층적 구조(트리 형태)를 갖고 있다. 한 가지 예를 들어보자.
www.codeschool.co.kr 이라고 하면, kr 도메인 명으로된 서버(DNS)가 있고, 그 아래 co 라는 DNS 서버가 있고, codeschool 이라는 회사가 할당받은 DNS 서버가 있고, 그 아래 www DNS 서버가 있는 구조다. 각 도메인에 한 대의 DNS 서버가 할당되어 있다. kr로 끝나지 않고 .com 으로 끝나는 주소도 있는데 이 또한 kr 과 동등한 depth(?) level(?)의 DNS 서버로 그 아래 많은 DNS 서버들과 연결되어 있는 것이다. kr과 com 도메인을 최상위 도메인이라고 한다. 이름은 최상위지만 이들을 연결하는 루트 도메인이 존재한다. 이 루트 도메인에는 전세계를 통틀어서 13개의 DNS 서버가 연결되어 있으며 이 루트 도메인을 통해 인터넷이 하나로 연결될 수 있는 것이다.
http://webdir.tistory.com/161
이제 구조는 이해가 됬다. 그렇다면 어떠한 방식으로 찾아가는가?
클라이언트로부터 받은 메시지에서 웹 서버에 관한 정보를 조회한다고 한다면, 일단 가장 가까운 DNS 서버에 조회를 한다. 존재하지 않으면 루트 도메인에 조회 메시지를 전송한다. (가장 가까운 DNS 서버에는 루트 도메인의 DNS 서버가 등록되어 있다.)
Q. 모든 DNS 서버에서 바로 루트 도메인 DNS 서버가 등록되어 있어서 루트 도메인으로 조회메시지를 전송할 수 있는가?
루트 도메인은 조회 메시지로 부터 하위 DNS 중 어느 DNS로 조회 메시지를 보내야 할 지에 대한 정보를 반송해준다. 아까 첫 조회를 했던 가장 가까운 DNS 서버는 루트 도메인으로부터 받은 반송 메시지를 통해 다음 조회할 DNS 서버로 다시 조회 메시지를 전송한다. 이러한 과정을 반복하다보면 원하는 DNS 서버에 도달하게 되고, 해당 IP 주소를 알 수 있게 된다. 그리고 이 주소를 클라이언트에 회답한다. (프로토콜 스택이 되겠지!)
3. DNS 서버의 캐시 기능
사실 현실에서는 각 도메인 마다 한 대의 DNS 서버가 할당되어 있지 않고, 복수개의 도메인이 할당되어 있다. 상위와 하위의 도메인을 같은 DNS 서버에 등록하는 경우도 존재한다.
또 DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있다. 조회한 이름에 해당하는 정보가 캐시에 존재하면 그 정보를 회답할 수 있게 되는 것이다. 존재하지 않은 경우도 캐시에 저장하여 빠르게 회답할 수 있다.(Caching)
하지만 이 캐시 원리에서 주의해야할 점이 있다.
캐시에 정보를 저장한 후 등록 정보가 변경되는 경우이다. 이 경우에는 캐시에 저장된 정보가 올바른 정보라고 할 수 없다. 때문에 DNS 서버에서는 캐시에 저장할 때 유효 기간(TTL : Time To Live)을 설정하고, 그 기간에 따라 캐시를 삭제한다. 또한 조회에 회답할 때 회답되는 정보가 캐시에 저장된 정보인지 아니면 DNS 서버로부터 조회한 정보인지를 알려준다.
1장 세번째 end
'Dev.Basic > 네트워크' 카테고리의 다른 글
[2장] 1. TCP/IP - 소켓을 작성하고 서버에 접속한다. (0) | 2016.11.10 |
---|---|
[1장] 4. 프로토콜 스택에 메시지 송신을 의뢰한다. (0) | 2016.11.09 |
[1장] 2. 웹 서버의 IP 주소를 DNS 서버에 조회한다. (0) | 2016.11.06 |
[1장] 웹 브라우저 - 1. HTTP Request 메시지를 작성한다. (0) | 2016.11.05 |
[Intro] 브라우저부터 서버까지 네트워크의 큰 흐름 (2) | 2016.10.08 |