하마롱크의 블로그
DNS(1) 본문
- 네트워크 프로토콜은 크게 실제로 데이터를 실어나르는 데이터 프로토콜과 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜로 나눌 수 있다.
- 컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 한다.
- TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있다.
- DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 역할을 한다.
- IP 주소보다 도메인 주소를 이용하는 것이 일반 사용자에게 더 익숙하고 서버 IP 변경에 쉽게 대처할 수 있으므로 네트워크 통신에서 DNS의 역할이 매우 중요하다.
- 클라우드 기반 인프라 구성이 많아지면서 인프라가 빈번히 변경되어 DNS 설계가 더 중요해지고 있다.
- MSA(Micro Service Architecture) 기반의 서비스 설계가 많아지면서 다수의 API를 이용하다보니 사용자의 호출뿐만 아니라 서비스 간 API 호출이나 인터페이스가 많아져 DNS의 역할은 더욱 중요해졌다.
1. DNS 소개
1.1. 숫자로 구성된 IP 주소보다 의미 있는 문자열로 구성된 도메인 주소가 우리가 인식하고 기억하기 더 쉽다.
1.2. IP 주소 대신 도메인 주소를 이용하면 하나의 IP 주소를 이용해 여러 개의 웹 서비스를 운영할 수 있고 서비스 중인 IP 주소가 변경되더라도 도메인 주소 그대로 유지해 접속 방법 변경 없이 서비스를 그대로 유지할 수 있다.
1.3. 도메인을 이용하면 지리적으로 여러 위치에서 서비스할 수도 있다.
1.4. 따라서 특별한 경우를 제외하면 대부분의 웹사이트는 도메인 주소 기반으로 운영한다.
1.5. 서비스를 도메인 주소를 사용하더라도 실제로 패킷을 만들어 통신하려면 3계층 IP 주소를 알아야 하고 이를 위해 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 DNS 정보를 네트워크 설정 정보에 입력해야 한다.
1.6. 사용자가 도메인 주소를 사용하여 서비스를 요청하면 네트워크 설정에 입력한 DNS로 해당 도메인에 대한 IP 주소 질의를 보내고 그 결괏값으로 요청한 도메인의 서비스 IP 주소를 받게 된다.
2. DNS 동작 방식
2.1. 클라이언트 관점에서 DNS 질의 과정
2.1.1. 도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 합니다. 하지만 DNS 서버없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있다.
2.1.2. 로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 합니다. hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장된다.
2.1.3. 동일한 도메인을 매번 질의하지 않고 캐시를 통해 성능을 향상시키기 위해서 도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인한다.
2.1.4. DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있다.
2.1.5. DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장한다.
2.1.6. 전에 쿼리를 한 번 수행한 DNS 정보는 캐시부터 조회하므로 DNS 서버에 별도로 쿼리하지 않고 캐시 정보를 사용
2.1.7. 위의 그림은 DNS를 이용해 도메인 이름 쿼리를 하는 예제이다. ‘zigispace.net’이라는 도메인을 쿼리하기 위해 먼저 로컬 캐시를 조회하고 로컬 캐시에 없으면 DNS 서버로 다시 쿼리해 도메인 쿼리를 수행한다.
2.2. DNS 시스템 관점에서 도메인에 대한 결과값을 클라이언트에 보내주는 과정
2.2.1. 대량의 도메인 리스트를 실시간으로 업데이트할 수 없기 때문에 전 세계 도메인 정보를 DNS 서버 하나에 저장할 수 없다.
2.2.2. 그래서 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있다.
2.2.3. DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있다.
- 클라이언트의 쿼리가 자신에게 없는 정보라면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS가 어디인지 응답한다.
2.2.4. 예를 들어 zigispace.net이라는 도메인을 클라이언트가 DNS 서버에 쿼리했다면 DNS 서버는 루트 DNS에 다시 쿼리하고 루트 DNS는 .net에 대한 정보를 관리하는 DNS 주소 정보를 DNS 서버에 응답한다.
- 이 응답을 받은 DNS 서버는 .net을 관리하는 DNS 서버에 zigispace.net에 대해 쿼리한다.
- .net을 관리하는 DNS 서버는 다시 zigispace.net을 관리하는 DNS 관련 정보를 처음 DNS 서버에 응답한다.
- DNS 서버는 마지막으로 zigispace.net을 관리하는 DNS에 쿼리하고 zigispace.net에 대한 최종 결과값을 받게 된다.
- 처음 쿼리를 받은(클라이언트에 DNS 서버로 설정된) DNS 서버는 이 정보를 클라이언트에 응답한다.
2.2.5. 전체 과정을 보면 클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결괏값을 알아낸 후 최종 결과값만 클라이언트에 응답한다.
- 클라이언트는 한 번의 쿼리를 보내지만 이 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 획득한다.
- 호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라 한다.
- DNS 서버가 루트 NS와 TLS NS, zigispace NS에 질의한 방식을 반복적 쿼리(Iterative Query)라고 한다.
1. 사용자 호스트는 ‘zigispace.net’이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
2. ‘zigispace.net’이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 ‘zigispace.net’에 대해 쿼리
3. DNS 서버는 ‘zigispace.net’이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리
4. 루트 DNS는 ‘zigispace.net’의 TLD인 ‘.net’을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답
5. DNS는 TLD 네임 서버에 ‘zigispace.net’에 대한 정보를 다시 쿼리
6. TLD 네임 서버는 ‘zigispace.net’에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답
7. DNS는 zigi 네임 서버에 ‘zigispace.net’에 대한 정보를 쿼리
8. zigi 네임 서버는 ‘zigispace.net’에 대한 정보를 DNS 응답
9. DNS는 ‘zigispace.net’에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 ‘zigi space.net’에 대한 정보를 응답
10. 사용자 호스트는 DNS로부터 받은 ‘zigispace.net’에 대한 IP 정보를 이용해 사이트에 접속
<참고문헌>
IT 엔지니어를 위한 네트워크 입문