먼저, DNS가 무엇이고, 무슨 역할을 하기 전에 DNS의 필요성에 대해서 정리해보자.
현재 우리가 사용하고 인터넷에서는 어떻게 주소를 식별하는가?
평소에 우리가 쓰고 있는 것을 보면 naver.com이나 google.com과 같은 문자로 되어 있는 것 같습니다.
하지만 라우터나 종단측 애플리케이션에서는 이러한 문자를 원하지 않습니다. 이러한 문자는 가변 길이의 알파뉴메릭 문자로 라우터가 처리하는데 어려움이 있습니다.
그래서 라우터의 경우 고정 길이를 가지는 IP 주소를 선호합니다.
하지만 반대로 사람들이 IP 주소(십진 표기법)를 기억하기에는 어려움이 있습니다.
그래서 우리는 양쪽의 선호 차이를 절충하기 위해서 DNS를 사용합니다.
DNS
❗ DNS(domain name system)는 DNS 서버들의 계층구조로 구현된 분산 데이터베이스이고, 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜입니다.
DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용합니다.
여기서 간단하게 동작 순서를 보자면 다음과 같습니다.
- 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행합니다.
- 브라우저는 URL로부터 호스트 네임을 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘깁니다.
- DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보냅니다.
- DNS 클라이언트는 결국 호스트 네임에 대한 IP 주소를 가진 응답을 받게 됩니다.
- 브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화합니다.
대략 이런 식으로 작동된다고 보면 됩니다.
물론, 5번의 경우 TCP 연결을 한다고 가정했을 때의 상황입니다.
이러한 작동을 봤을 때 DNS 서버가 멀리 있다면 추가 지연이 발생할 수 있다는 것을 알 수 있습니다.
하지만, 원하는 IP 주소는 "가까운" DNS 서버에 캐시(cache)되어 있어서 평균 DNS 지연뿐 아니라 DNS 네트워크 트래픽 감소에 도움을 줍니다.
DNS가 제공하는 추가적인 서비스에 대해서 정리해 봅시다.
- 호스트 엘리어싱(host aliasing): 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있다. 별칭 호스트 네임은 정식 호스트 네임보다 대체로 기억하기 쉽습니다. DNS는 호스트의 IP 주소 뿐만 아니라 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 이용할 수 있습니다.
- 메일 서버 엘리어싱(main server aliasing): DNS는 호스트의 IP 주소뿐만 아니라 제공된 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 메일 애플리케이션에 의해 수행됩니다.
- 부하 분산(load distribution): DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용되고 합니다. 각 서버는 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖습니다. "중복 웹 서버"의 경우, 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있습니다.
동작 원리
만약 DNS가 중앙 집중 방식으로, 모든 매핑을 포함하는 하나의 인터넷 네임 서버로 되어 있다고 생각해 봅시다. 모든 클라이언트는 모든 질의를 단일 네임 서버로 보내고, DNS 서버는 질의 클라이언트에게 직접 응답합니다.
이 방식에는 수많은 호스틀를 가진 오늘날의 인터넷에서는 적합하지 않습니다. 다음과 같은 문제점이 발생 할 수 있습니다.
- 서버의 고장: 만약 이 네임 서버가 고장나면, 전체 인터넷이 작동하지 않습니다.
- 트래픽의 양: 단일 DNS 서버가 모든 DNS 질의를 처리해야 합니다.
- 먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 "가까울" 수만은 없습니다.
- 유지관리: 단일 네밍 서버는 모든 인터넷 호스트에 대한 레코드를 유지하고 있어야 합니다.
요약하면, 단일 DNS 서버에 있는 중장 집중 데이터베이스는 확장성이 전혀 없다.
그래서 DNS 서버는 계층으로 구성된 세 유형의 DNS 서버로 분산되어 있습니다.
- 루트(root) DNS 서버
- 최상위 도메인 네임(TLD, top-level domain) DNS 서버
- 책임(authoritative) DNS 서버
DNS의 다른 중요한 형태는 로컬 DNS 서버입니다.
로컬 DNS 서버는 서버들의 계층구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있습니다. (대학이나 주거지역 ISP와 같은) ISP들은 로컬 DNS 서버(또는 디폴트 네임 서버)를 갖습니다.
호스트가 ISP에 연결될 때, 그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공합니다.
아래 그림을 봐보자.
호스트 cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 원한다고 해봅시다.
먼저, 호스트 cse.nyu.edu가 프록시 서버로 동작하는 로컬 DNS 서버 dns.nyu.edu에게 DNS 질의 메시지를 보냅니다. 질의에는 변환되어야 하는 호스트 네임, 즉 gaia.cs.umass.edu가 포함되어 있습니다.
로컬 DNS 서버는 그 질의 메시지를 루트 DNS 서버에게 전달합니다. 루트 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 리스트를 로컬 DNS 서버에게 보냅니다.
로컬 DNS 서버는 질의 메시지를 TLD 서버로 보냅니다. 그다음 TLD 서버는 umass.edu를 인식하고 dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소를 응답합니다.
마지막으로 DNS 서버는 직접 dns.umass.eud로 질의 메시지를 다시 보내고, gaia.cs.umass.edu의 IP 주소로 응답합니다.
하나의 호스트 네임 매핑을 얻기 위해 질의 메시지 네 번과 응답 메시지 네 번, 총 8 번 DNS 메시지가 보내졌습니다.
여기서 일반적으로는 TLD 서버에서 한 번 더 나눠집니다.
예를 들어, 한 대학교의 DNS 서버가 있을 때, 거기서 한 학과에서도 자신의 DNS 서버를 갖고 있고 이것을 요청한다고 생각하면 이 상황에서 TLD 서버는 호스트 네임에 대한 책임 DNS를 아는 중간 DNS 서버만 알고 있는 것입니다.
위의 그림의 예는 재귀적 질의(recursive query)와 반복적 질의(iterative query)를 사용합니다.
여기서 로컬 DNS 서버는 DNS 캐싱(chaching) 기능을 수행할 수 있습니다.
Reference
