[네트워크] DNS(Domain Name System) 동작 흐름

 

1. DNS(Domain Name System)

DNS(Domain Name System)은 사람이 읽을 수 있는 도메인 주소를 기계가 이해할 수 있는 IP 주소로 변환하는 역할을 한다. 예를 들면, www.example.com으로 입력한 도메인 주소를 xx.xxx.xx.x IP 주소로 변환한다.

 

2. DNS 동작 흐름

DNS 쿼리란 DNS 서버에 IP 주소를 묻는 행위이다. 사용자가 입력한 도메인 주소에 대한 실제 IP 주소를 찾는 행위이다. DNS 조회 과정은 클라이언트가 DNS 쿼리를 발생시키면 시작된다.

 

 

사용자가 DNS 쿼리를 발생시키면 도메인 주소에 해당하는 실제 IP 주소를 찾는다. 먼저, DNS 리졸버에 접근하여 캐시되어 있는 데이터가 존재하는지 확인한다. DNS 리졸버는 DNS 쿼리를 ISP(Internet Service Provider)가 관리하는 로컬 DNS 서버로 라우팅한다.

DNS 리졸버

 

로컬 DNS 서버는 레코드(도메인 주소, IP 주소)가 캐시되어 있는지 확인한다. 캐시되어 있다면 클라이언트에게 IP 주소를 반환하고, 캐시되어 있지 않다면 루트 네임 서버(Root Name Server)에 요청한다.

로컬 DNS 서버는 ISP가 관리하는 DNS 서버로서, 사용자의 인터넷 회선에 따라 사용하는 DNS 서버가 다르다.

ISP(Internet Service Provider)

 

루트 네임 서버(Root Name Server)는 도메인을 IP 주소로 변환하는 첫 단계이다. 루트 네임 서버는 도메인 확장자에 따라 다른 TLD(Top Level Domain) 서버를 전달한다. 예를 들어, google.com 도메인 주소를 사용한다면 루트 네임 서버는 .com 도메인을 관리하는 TLD 서버를 응답한다.

DNS Root Name Server

 

TLD 서버는 확장자에 속한 서브 도메인을 관리한다. 예를 들어, google.com의 경우 .com으로 끝나는 도메인 주소를 모두 TLD 서버에서 관리하게 된다. TLD 서버는 Authorative 네임 서버의 주소를 알고 있기 때문에, DNS 쿼리를 Authorative 네임 서버에 전달한다.

DNS TLD Server

 

Authorative 네임 서버는 호스팅 업체가 관리하는 네임 서버이다. 호스팅 업체가 도메인 주소를 발급하기 때문에 Authorative 네임 서버에 레코드가 저장된다. Authorative 네임 서버는 도메인 주소에 해당하는 실제 IP 주소를 DNS 리졸버에 반환한다. 예를 들어, google.com 도메인에 해당하는 실제 IP 주소인 142.250.207.100 주소가 DNS 리졸버에 반환된다.

Authorative Name Server

 

DNS 리졸버는 반환받은 IP 주소를 로컬 DNS 서버에 캐싱한 후, 클라이언트에게 전달한다. 사용자는 google.com에 해당하는 페이지를 볼 수 있게 된다.

 

3. Authorative vs Non-Authorative

Authorative vs Non-Authorative

• Authorative(권한 있는) : 도메인을 직접 관리하는 네임 서버로부터 반환된 응답이다.
• Non-authorative(권한 없는) : DNS 서버가 다른 DNS 서버에서 받은 정보를 캐시하여 응답하는 경우이다.
  • 빠른 응답을 위해 캐시해 둔 데이터를 반환한다.

 

아래 사진의 경우 Non-authorative answer를 반환한다. 이는 로컬 DNS 서버(192.168.0.1)가 구글 네임 서버가 아니기 때문이다. 따라서 로컬 DNS 서버에 캐시되어 있는 IP 주소를 반환한다. 이는 이전에 google.com 도메인에 접속한 적이 있기 때문에 로컬 DNS 서버에 레코드가 캐시되어 있는 것이다.

→ 매 번 Authorative 네임 서버에 DNS 쿼리를 질의하는 것은 비효율적이기 때문에, 이전에 조회해 둔 레코드를 로컬 DNS 서버에 캐시 해두고 빠르게 응답하는 것이다.

Non-Authorative Answer

 

Authorative 네임 서버로부터 응답받기 위해서는 도메인을 직접 관리하는 Authorative 네임 서버를 조회해야 한다. 명령어 옵션으로 -type=NS를 추가하면 도메인을 직접 관리하는 Authorative 네임 서버가 조회된다. 아래 사진에서 ns1.google.com, ns2.google.com 등은 google.com 도메인의 실제 Authorative 네임 서버이다.

google.com 도메인의 Authorative Server

 

google.com 도메인을 관리하는 Authorative 네임 서버의 주소가 ns1.google.com 임을 확인했다. nslookup google.com ns1.google.com을 입력하면 Authorative 네임 서버로부터 직접 응답을 받을 수 있다.

Authorative Answer

 

참고로 내 노트북의 게이트웨이 IP 주소는 192.168.0.1이다. 이는 위 사진에 나오는 로컬 DNS 서버의 IP 주소와 동일한 것을 알 수 있다. 라우터가 DNS 요청을 처리하는 로컬 DNS 서버로 동작하고 있는 듯하다.

입력:
$ netstat -nr | grep default                

출력: 
default            192.168.0.1        UGScg                 en0

 

4. 로컬 DNS 서버의 TTL(Time To Live)

로컬 DNS 서버에 캐시 된 레코드는 TTL(Time To Live)이 설정되어 있다. TTL이란 캐시된 데이터를 얼마나 유지시킬 것인지 결정하는 요소이다.

Non-authorative answer의 경우 로컬 DNS 서버에 캐시된 레코드를 응답하는 것이다. 이 레코드 또한 TTL이 설정되어 있기 때문에, TTL이 만료된 레코드의 경우 DNS 서버는 Authorative 네임 서버에게 DNS 쿼리를 질의해야 한다.

 

아래 사진의 경우, Non-Authorative answer 응답이 왔기 때문에 로컬 DNS 서버에 캐시된 레코드가 반환되었음을 알 수 있다.

 

로컬 DNS 서버에 캐시된 레코드

 

dig google.com 명령어를 통해 로컬 DNS 서버에 캐시된 레코드의 TTL을 확인할 수 있다. 아래 사진의 경우 로컬 DNS 서버에 캐시된 데이터의 TTL이 72초 남았다는 의미이다.

로컬 DNS 서버에 캐시된 레코드의 TTL

 

다시 한 번 TTL을 조회해보니 72 → 67초로 줄은 것은 확인할 수 있다.

로컬 DNS 서버에 캐시된 레코드의 TTL

 

 

---

참고

https://namu.wiki/w/DNS

https://kghworks.tistory.com/126

https://aws.amazon.com/ko/route53/what-is-dns/

https://velog.io/@bonjugi/nslookup