본문 바로가기

BackEnd/Backend Developer Road-Map

4. DNA...아 아니 DNS

Domain Name을 공부했다면

바로 그다음은 DNS다

 

이 전에 작성한 글 중 SMTP를 공부했을 때

잠깐 인용만 했었는데 오늘 다시 정리를 해보려 한다

 

https://mutpp.tistory.com/entry/SMTP%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

 

SMTP를 알아보자

서버에서 이메일 전송하는 걸 구현하기 위해 알아보던 중.. SMTP를 사용하게 되었는데 평소에 아웃룩에서 설정할 때나 사내 메일을 설정할 때도 봤던 친구라 간단히 정리해보려고 한다 - SMTP란 무

mutpp.tistory.com

 

Cloudflare에서 DNS에 대해 잘 설명을 해둬서

아래에 첨부한 링크에 있는 사이트를 공부해서 정리하려 한다

 


1. DNS (Domain Name System)

 

DNS는 호스트의 도메인 이름 (Domain Name)을

호스트의 네트워크 주소로 바꾸거나

그 반대의 변환을 수행할 수 있도록 개발된 시스템이다

(도메인 이름은 이전 글을 참고하길 바람)

 

다른 누군가의 컴퓨터나 네트워크 장치의 주소를 찾기 위해서

도메인 이름을 → 숫자 식별 번호 (IP 주소)

로 변환해준다

 

이런 변환 과정 때문에 DNS는 전화번호부에 흔히 비유된다

www.example.com  같은 도메인 이름을

192.123.456.789 같은 IP 주소로 변환해서 라우팅 정보를 제공하기 때문이다

(분산형 데이터베이스 시스템이다)

 


 

2. DNS 동작

 

(1) DNS LookUp

DNS 확인 프로세스에는 HostName을 IP 주소로 변환하는 작업이 포함된다

예를 들어, www.example.com  → 192.123.456.789 이렇겜

 

실생활을 예로 들면,

집을 찾을 때 주소를 알고 있어야 찾아갈 수 있듯이

IP 주소는 인터넷에 접속하는 각 Device의 주소를 찾는데 필요하다

 

집 주소를 찾아가듯이,

사용자가 웹 페이지의 주소를 찾는 과정이 필요하고

웹 브라우저를 로드하려고 할 때 

www.example.com ↔ IP 주소로 바꿔주는 과정이 있다

 

 

그 과정이 바로 DNS Lookup이다

Backend로 동작하며 처음 사용자의 Request 외에는 사용자 컴퓨터와 상호작용은 필요 없다

 

 

(2) DNS Servers

웹 페이지 로드에 필요한 4개의 DNS 서버가 있다

 

DNS Recursor

얘는 도서관의 사서와 같은 역할을 한다

웹 브라우저 등의 애플리케이션을 통해 클라이언트 컴퓨터로부터 DNS Query를 받는 서버이다

그리고 클라이언트의 DNS 쿼리를 잘 처리하기 위해서 추가적인 Request를 수행한다

 

Root Nameserver

아까 위에서 Host Name을 IP 주소로 변환하는 단계가 있다고 했었다

얘는 그 첫 번째 단계이다

도서관 책장의 색인 역할을 한다

 

 

TLD Nameserver

TLD 서버는 도서관 책장 역할을 하는 녀석이다

DNS lookup의 두 번째 단계로 Host Name의 마지막 부분을 Hosting 한다

example.com에서 "com"에 해당된다

 

 

Authoritative Nameserver

가장 마지막 단계에 있는 서버로, 책장의 사전이다

이 서버가 요청한 레코드에 대한 접근 권한이 있다면

Request를 보낸 Host Name의 IP 주소를

첫 번째 단계의 DNS Recursor (사서 선생님)에게 돌려준다

 

(3) Recursive DNS Resolver

 

 

얘는 클라이언트의 요청에 응답하고

DNS Record를 추적하는 데 사용되는 컴퓨터이다

 

😉 DNS Record : URL을 IP 주소에 매핑하는 데 사용되는 Database Record

 

클라이언트의 요청한 Record는

마지막 과정인 Authoritative DNS 서버에 도착할 때까지

재 요청하거나 오류를 반환시켜준다

다시 만약 요청을 할 때는 캐싱을 사용해서 하기도 한다

왜냐? 자원 절약 그리고 빠르니까.

 

 

(4) Authoritative DNS Server 

 

 

얘는 (이름이 너무 길다) 실제 DNS Resource Record를 보유하고 담당하는 서버다

위에서 말한 것처럼 DNS Query의 가장 마지막 단계이다

 

이름에서도 유추할 수 있듯이

웹 브라우저가 웹 사이트/웹 자원 등에 접근할 때

필요한 IP 주소에 도착할 수 있도록 요청할 수 있게 한다

 

얘는 마지막 녀석답게 다른 서버에 Query를 따로 하지 않고

자체 쿼리를 수행할 수 있다

 

 


😂 하위 도메인 Query 동작

 

 

Authoritative 서버에서

하위 도메인의 Record 정보(CNAME Record)를 얻기 위해

추가적인 Nameserver에 쿼리 해서 가져온당

 

 


 

3. DNS 진짜 전체 동작

 

DNS 동작은 아래 그림을 통해 알아보겠다

 

알아보기 전에~~

요 아래 그림의 화살표를 보면 두 가지의 색으로 구성되어있는데

짧게 정리만 하고 다시 설명을 하겠다

 

⛳ Recursive Query

말 그대로 재귀 방식으로,

쿼리 요청이 실제 도메인 이름을 가지고 있는 서버까지

쿼리가 이동하면서 IP 주소를 얻는 방법이다

 

⛓ Iterative Query

얘는 말 그대로 쿼리를 반복하는 방식인데, 서버의 IP 주소를 얻어오기 위해

요청-응답, 요청-응답을 여러 서버에 요청하면서 얻어오는 방식이다

 

 

1) 사용자 → DNS Resolver

사용자가 웹 브라우저에 example.com 이란 주소를 입력함

그러면 Recursive Query에 의해 인터넷으로 이동함

DNS Resolver에 수신된다

 

2) DNS Resolver → Root Server

그러면 DNS Resolver에서 DNS 루트 이름 서버를 쿼리 한다

여기서 Root Name은 

 

 

그림에서 가장 오른쪽에 있는 저 Root를 의미한다

 

3) Root Server →  DNS Resolver 

그러면 다시 응답을 주는데

이때 TLD (. com이나. net 같은) DNS 서버의 주소를

응답에 담아서 준다

 

4) DNS Resolver →  TLD Server

그러면 Root Server가 준 주소의 TLD 서버에게 다시 요청한다

 

5) TLD Server →  DNS Resolver

TLD 서버는 Domain Name 서버의 IP 주소로 응답을 다시 내려준다

이때 내려주는 주소가  example.com에 해당되는 것이다

 

6) DNS Resolver →  DNS (Domain Name Server)

마지막으로 DNS에 쿼리를 보낸다

 

7) DNS →  DNS Resolver

그러면 DNS에서 무엇을 주느냐

example.com에 해당하는 IP 주소가 반환되게 된다

 

8) DNS Resolver →  웹 브라우저

웹 브라우저에서 요청한 도메인의 IP 주소로 응답을 내려준다

그러면 웹 브라우저는 IP 주소를 알게 됐고

원하는 웹 페이지에 요청을 할 수 있다

 

9) 웹 브라우저 →  Server

IP 주소에 HTTP 요청을 보낸다

 

10) Server →  웹 브라우저

IP 주소에 해당하는 서버는 브라우저에서 렌더링 할 웹페이지를 반환을 해준다

 


4. DNS Queries

 

아까 그림 설명하기 전에 잠깐 짚었던 쿼리 종류가 있는데

다시 한번 정리하고 지나가겠다 한 가지 그리고 더 있음

 

1) Recursive Query

 

Local Host가 example.com에 대한 쿼리를 보내면

local DNS Server → Root DNS 서버 →  TLD 서버까지

쿼리를 보내서 요청하는 방식이다

Root DNS 서버는 자신의 서버에 등록되어 있는지 검사하고

다음이 없으면 TLD 서버에 요청을 한다

실제 Domain Name을 가지고 있는 서버까지 쿼리가 이동하면서

IP 주소를 얻는 방식이어서 재귀 쿼리라고 한다

 

 

2) Iterative Query

 

 

local Host에서 example.com에 대해 쿼리를 보내면

local DNS Server → Root DNS Server

local DNS Server → TLD DNS Server

요런 식으로 최종 IP 주소를 받을 때까지

요청-응답을 locam DNS Server가 반복하는 방법이다

 

📌 실제 DNS Server 동작 방식은 전체 동작에서 설명했던 그림처럼 Recursive, Iterative Query를 함께 사용하면서 효율성을 높이는 방식을 사용하고 있다
웹 브라우저에서 Local Name Server에 쿼리를 요청할 때 Recursive 하게 하면 요청한 클라이언트 Host의 자원을 덜 쓰게 될 수 있다

 

3) Non-Recursive Query

얘는 일반적으로 DNS Resolver 클라이언트가

Record에 대한 권한이 있거나, 해당 Record가 캐시에 이미 있어서

바로~~ 액세스 권한이 있는 DNS 서버를 쿼리 할 때이다

 

일반적으로 DNS 서버는 서버의 부하를 줄이고, 자원을 잘 관리하기 위해

DNS Record를 캐시 해서 사용한다

 

 


5. DNS Caching

 

 

 

캐싱 자체의 목적은 데이터 요청에 대해 성능↑ 안전성향상하기 위해

데이터를 임시로 저장해서 사용하는 것이다

 

따라서 DNS 캐싱은 클라이언트의 요청 정보 데이터를 저장하면서

이전에 수행한 DNS 쿼리에 대해서 또 요청했을 때

더 일찍 수행이 가능하도록 하는 것을 목적으로 한다

 

그러면 로드 시간이 향상되고~

대역폭/CPU 소비가 줄어들고~ 너무 좋고~

 

DNS 데이터는 다양한 위치에서 캐시가 가능하고

정해진 시간 동안 DNS Record가 저장된다

 

근데 DNS 캐싱을 악용해서 해킹할 수도 있기 때문에

일부러 잘못된 쿼리를 캐싱해두기도 한다고 한다 (Negative Caching)

우리가 이해한 방식은 Positive Caching이라고 한다

 

 


참고 링크

https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/


 

집에 있는데 집에 가고 싶다

 

'BackEnd > Backend Developer Road-Map' 카테고리의 다른 글

3. Domain Name 돔넴  (0) 2022.04.20
2. 브라우니 말고 브라우저  (0) 2022.04.09
1. Internet 동작 원리  (0) 2022.03.24