DNS(Domain Name System) 알아보기 (2) : 네임 서버

계층적 네임 서버

 

'IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정'을 흔히 '도메인 네임을 풀이(resolve)한다'라고 표현하며, 영어로는 '리졸빙(resolving)한다'라고도 표현한다.

 

이 과정에서 다양한 네임 서버들이 사용되는데, 중요한 역할을 담당하는 네임 서버의 유형은 크게 네 가지가있다. 각각 '로컬 네임 서버', '루트 네임 서버', 'TLD(최상위 도메인) 네임 서버', '책임 네임 서버'이다. 

 

로컬 네임 서버(Local Name Server)는 클라이언트와 맞닿아 있는 네임서버로, 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게되는 네임 서버다. 클라이언트가 로컬 네임 서버를 찾을 수 있으려면 로컬 네임 서버의 주소를 알고 있어야한다. 이 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당하는 경우가 많다. 하지만 ISP에서 할당 해주는 네임 서버가 아닌, 공개 DNS 서버(Public DNS Server)를 이용할 수도 있다. 공개 DNS 서버의 대표적인 예는 구글의 '8.8.8.8', '8.8.4.4'와 클라우드플레어의 '1.1.1.1'이 있다. 

구글 공개 DNS 서버 안내 페이지. 'developers.google.com/speed/public-dns'

 

이제, 클라이언트가 로컬 네임 서버에게 특정 도메인 네임에 대응되는 IP 주소가 무엇인지 질의했다고 가정해보자. 로컬 네임 서버가 대응되는 IP 주소를 알고 있다면 클라이언트에게 그 IP 주소를 알려주면된다. 하지만 만약 로컬 네임 서버가 IP 주소를 모른다면? 이 경우 루트 네임 서버(Root Name Server)에게 해당 도메인 네임을 질의하게 된다. 루트 네임 서버는 루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환할 수 있다.

루트 네임 서버는 도메인의 TLD를 관리하는 네임 서버의 IP 주소를 알려준다.

 

루트 네임 서버가 루트 도메인을 관장하는 네임 서버인 것처럼, TLD 네임 서버는 TLD를 관리하는 네임 서버다. 그리고 TLD 네임 서버는 다음과 같이 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다. 하위 도메인 네임을 관리하는 네임 서버는 마찬가지로 그보다 하위 도메인을 관리하는 네임 서버 주소를 반환할 수 있다.

루트 하위의 TLD 서버에 질의를 하며 또 다시 하위 네임 서버로 질의를 이어나간다.

 

책임 네임 서버(Authoritative Name Server)는 특정 도메인 영역(zone)을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버다. 쉽게 말해, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버다. 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어낸다. 이처럼 루트 도메인을 관리하는 루트 네임 서버부터 TLD를 관리하는 TLD 네임 서버, 최종 IP 주소를 답해주는 책임 서버에 이르기까지, 네임 서버들은 계층적인 구조를 띄고 있다. 

 

도메인 네임을 리졸빙하는 과정, 즉 IP 주소를 알아내는 과정을 조금 더 자세히 알아보자. 로컬 네임 서버가 네임 서버들에게 질의하는 방법에는 크게 '재귀적 질의'와 '반복적 질의'라는 두 가지 방법이 있다. 아래의 그림을 통해 이 두 방식이 어떻게 동작하는지 알아볼 것이다. 

 

재귀적 질의(recursive query)는 클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게 질의하고, 루트 네임 서버가 TLD 네임 서버에게 질의하고, TLD 네임 서버가 다음 단계에 질의하는 과정을 반복하며 최종 응답 결과를 역순으로 전달받는 방식이다. 

재귀적 질의

 

반복적 질의(iterative query)란 클라이언트가 로컬 네임 서버에게 IP 주소를 알고 싶은 도메인 네임을 질의하면, 로컬 네임 서버는 루트 네임 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답 받고, 다음으로 TLD 네임 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식이다. 

반복적 질의

 

하지만 이 리졸빙 과정에는 약간의 문제가 있다. 예시만 보더라도 루트, TLD, 책임 3가지의 서버만 존재하는데 8단계를 거쳐야하는 것처럼 시간이 오래 걸리고 네트워크상의 메시지 수가 지나치게 늘어날 수 있다는 점이다. 만약 전 세계 모든 호스트가 도메인 네임 리졸빙을 위해 루트 네임 서버에 도메인 네임을 한꺼번에 질의한다면 해당 서버에 과부화가 생길 것이다.

 

그래서 실제로는 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 활용하는 경우가 많다. 이를 DNS 캐시(DNS cache)라고 한다. DNS 캐시를 저장하는 용도로 쓰이는 서버도 있다. DNS 캐시를 활용하면 짧은 시간에 원하는 IP 주소를 얻어낼 수 있다. 하지만 이 캐시도 영원히 남아있는 것은 아니다. 임시 저장된 값은 TTL(Time to Live)이라는 값과 함께 저장되는데, 이 값은 캐시될 수 있는 시간을 뜻한다. 

 

💡IP 의 TTL 과는 다른 개념이다. IP의 TTL은 패킷이 살아 있는 시간이며, DNS의 TTL은 도메인 네임을 통해 얻은 IP 주소를 캐시에 저장해두는 시간이다. 

 

정리

네임 서버의 계층적 구조 및 도메인 네임 풀이(resolve) 과정

1. DNS 서버의 계층적 구조 

• DNS는 전 세계적인 분산 데이터베이스 시스템임. 상위 서버가 하위 서버의 IP 주소를 알려주는 트리형 구조로 이루어져있음.
• 루트 네임 서버(Root Name Server) : DNS 트리의 최상위. TLD 서버의 IP 주소를 안내함. 
• TLD 네임 서버(Top-Level Domain Name Server) : '.com', '.kr', '.net' 같은 대분류에 속하는 도메인들을 관리. 
• 책임 네임 서버(Authoritative Name Server) : 특정 도메인 영역(예: 'google.com')의 실제 IP 주소를 가지고 있는 최종 권한을 가진 서버.
• 로컬 네임 서버(Local Name Server) : 사용자의 PC가 가장 먼저 만나는 서버. 직접 주소를 찾아오는 '심부름꾼' 역할을 함. (ISP의 네임 서버나 Google, Claudflare 의 공개 DNS 서버)

2. 도메인 네임 풀이(resolve) 과정

• 가장 중요한건 '누가 누구에게 물어보는가?'임.

① 재귀적 질의(Recursive Query) 

• 특징 : 네임 서버들끼리 질문해가며 답을 찾아옴.
• 질문 주체 : 질문을 받은 각 계층의 네임 서버들 
• 설명 : 질문을 받은 서버가 책임 지고 답을 구해오는 방식. 즉, 로컬이 루트를 통해 답을 구하고 질문을 받은 루트는 다시 TLD, TLD는 책임 서버를 통해 답을 얻어 다시 역순으로 클라이언트에게 알려줌.

② 반복적 질의(Iterative Query)

• 특징 : 로컬 네임 서버가 각 계층의 네임 서버들에게 반복적으로 질문함.
• 질문 주체 : 로컬 네임 서버
• 설명 : 로컬 네임 서버가 주소를 몰라 루트에 물어보면 루트는 "난 모르니 TLD 서버에 물어봐"라고 안내받음. 이런 식으로 로컬 네임 서버가 직접 발품을 팔아가며 답을 찾음.

💡Tip : 이론적으로는 모든 계층에서 재귀적 질의가 가능하나, 실제 인터넷 환경에선 반복적 질의를 통해 답을 얻는 구조가 일반적임. 

3. DNS 캐싱 (DNS Caching) 

• 성능 최적화의 핵심. 알아낸 도메인 정보를 일정 시간 저장해둔 것을 DNS 캐시(DNS Cache)라 함.
• 캐싱 계층 : 브라우저 캐시 → OS 캐시 → Hosts 파일 → 로컬 네임 서버 캐시 순으로 확인함. 
• 도메인 네임으로 접속 시 먼저 캐시를 확인하며, 캐싱된 정보가 없으면 로컬 DNS를 통해 위의 도메인 네임 풀이 과정을 시작함.
• TTL(Time To Live) : 해당 레코드(캐싱한 DNS 정보)가 유효하다고 인정되는 시간
  • Tip : 실무에서 서버 이전으로 인해 IP 주소가 바뀔 때, TTL이 너무 길면 사용자들이 예전 서버로 계속 접속하는 문제가 생김. 그래서 작업전에 TTL을 미리 짧게 줄여둠.

3.1 TTL vs TTL ?

• TTL(DNS) : 알아낸 도메인 정보를 캐시에 얼마나 저장해둘지 정하는 시간. 시간 만료시 저장 값이 지워짐.
• TTL(IP) : 네트워크 패킷이 라우터를 거칠때마다 줄어드는 수명. 해당 값이 0이되면 패킷은 폐기됨.(루프 방지)

4. 추가로 알면 좋은 점 

1. 반복적 질의가 일반적인 이유 : 루트나 TLD 서버는 전 세계의 요청을 받음. 만약 이들이 재귀적 질의를 지원하면 부하가 커지고 보안상 문제가 생김. 따라서 해당 네임 서버들은 "다음 서버 주소"만 알려주는 반복적 질의만 처리함. 
2. DNS 전파의 오해 : 흔히 "DNS 정보가 전 세계로 퍼지는 데 시간이 걸린다"고 하는데, 사실은 전 세계 서버로 퍼지는 것이 아니라 각 서버에 저장된 기존 캐시의 TTL이 만료될 때까지 기다리는 시간임.
3. 재귀, 반복은 두 가지 측면 : 재귀적 질의와 반복적 질의는 보통 하나의 프로세스 안에서 일어나는 두 가지 측면임. '클라이언트-로컬 네임 서버 사이는 재귀적', '로컬 네임 서버-상위 서버 사이는 반복적' 이라 볼 수 있음.