DNS란?
인터넷에 연결된 장치에는 다른 컴퓨터가 장치를 찾는데 사용하는 고유한 IP(Internet Protocol) 주소가 있다. 그리고 웹 브라우저는 IP 주소를 이용해 상호 작용한다. 하지만 192.168.1.1(IPv4), 2400:cb00:2048:1::c629:d7a2(IPv6)같은 IP주소는 외우기가 어렵다.
그래서 우리들은 웹사이트에 접속할 때 google.com, daum.net 등 도메인 주소(이름)을 통해 온라인에 접근한다. 여기서 DNS(Domain Name Systme)는 도메인 이름을 IP 주소로 변환하고 브라우저가 인터넷의 리소스를 로드할 수 있도록 한다.
도서관에서 책의 위치를 찾을 때 청구기호를 기억하고 찾는게 아니라 책 이름으로 청구기호를 검색하는 것과 비슷하다고 볼 수 있겠다.
DNS의 동작 과정
특정 도메인에 해당하는 IP 주소를 DNS에 요청할 때, 해당 요청이 거치는 하드웨어 구성 요소들을 연관지어 이해하면 좋다.
- DNS 리졸버:사용자가 입력한 도메인 이름을 IP 주소로 바꾸는 과정을 시작하는 서버다. 일반적으로 인터넷 서비스 제공자(ISP)에서 제공하며, 사용자의 요청을 받아 다른 DNS 서버에 질의한다. 또한 매번 다른 DNS 서버에 요청하는 것이 아니라 캐싱을 통해 바로 적절한 IP 주소를 반환할 수도 있다.
- www.example.com에 접속하려고 할 때, 사용자의 컴퓨터는 가장 먼저 DNS 리졸버에게 이 도메인의 IP 주소를 요청한다.
- Root 네임 서버: 전 세계에 13개의 클러스터가 있으며, 도메인 이름의 최상위 수준에 대한 정보를 가지고 있다. 이 서버는 TLD 네임 서버의 주소를 반환한다.
- DNS 리졸버가 www.example.com의 IP 주소를 찾으려면, 루트 네임 서버에 “.com 도메인에 대한 정보를 가지고 있는 서버는 어디에 있나요?“라고 묻는다. 그럼 루트 네임 서버는 .com 도메인을 담당하는 TLD 네임 서버의 위치를 알려줍니다.
- TLD(Top Level Domain) 네임 서버:TLD 네임 서버는 특정 최상위 도메인(TLD)의 정보를 관리한다. 예를 들어, .com, .org, .net 같은 도메인에 대한 정보를 가지고 있다.
- 루트 네임 서버가 알려준 TLD 네임 서버에 DNS 리졸버가 접속하여 example.com에 대한 정보를 요청한다. TLD 네임 서버는 이 도메인을 관리하는 (Authoritative 네임서버의 주소를 반환한다.
- Authoritative 네임 서버:네임 서버는 특정 도메인에 대한 최종 정보를 가지고 있는 서버다. 이 서버는 도메인 이름에 해당하는 IP 주소를 정확히 알고 있으며, 이 정보를 반환한다.
- DNS 리졸버가 example.com의 Authoritative 네임 서버에 접속하여, www.example.com의 IP 주소를 묻는다. 그러면 해당 네임 서버는 정확한 IP 주소를 DNS 리졸버에게 전달한다. 이제 DNS 리졸버는 이 IP 주소를 사용자에게 반환하며, 사용자는 원하는 웹사이트에 접속할 수 있게 된다.
DNS 쿼리 유형
일반적인 DNS 조회에서는 세 가지 유형의 쿼리가 발생한다. 이러한 쿼리를 조합하여 DNS 확인을 위한 최적화된 프로세스를 끌어낼 수 있다.
재귀 쿼리
재귀 쿼리에서 클라이언트는 DNS 리졸버에게 도메인 이름의 정확한 IP 주소를 요청한다. 이때 클라이언트는 최종적인 답변(즉, 도메인 이름에 해당하는 IP 주소)을 받을 때까지 기다리며, DNS 리졸버는 다른 DNS 서버들과 통신하면서 필요한 모든 단계를 수행한다.
예를 들어, 사용자가 www.example.com에 접속하려고 할 때, 브라우저는 DNS 리졸버에게 “이 도메인의 IP 주소를 주세요.“라고 요청한다. DNS 리졸버는 루트 네임 서버, TLD 네임 서버, Authoritative 네임 서버 등을 차례로 거치며 최종적으로 www.example.com의 IP 주소를 찾아 클라이언트에게 전달하게 된다. 이 과정에서 클라이언트는 중간 단계를 알지 못하고, 최종 결과만 받게 된다.
반복 쿼리
반복 쿼리에서는 DNS 리졸버가 요청을 받으면 즉시 가지고 있는 정보를 반환한다. 이때 해당 정보가 없으면, 가장 가까운 DNS 서버의 주소를 알려준다. 클라이언트는 이 주소를 바탕으로 다시 DNS 서버에 쿼리를 보내어 정보를 계속해서 찾게 된다.
만약 사용자가 www.example.com의 IP 주소를 찾기 위해 반복 쿼리를 사용한다면, DNS 리졸버는 “저는 이 도메인에 대한 정보는 없지만, 루트 네임 서버의 주소는 알려줄 수 있습니다.“라고 응답한다. 클라이언트는 다시 루트 네임 서버에 접속하여 .com TLD 네임 서버의 주소를 얻고, 다시 그 서버에 접속하여 Authoritative 네임 서버의 주소를 얻어내어 최종적으로 IP 주소를 찾는다.
비재귀 쿼리
비재귀 쿼리에서는 DNS 리졸버가 이미 가지고 있는 캐시된 정보를 클라이언트에게 바로 전달한다. 이 쿼리는 클라이언트가 이미 자주 요청된 도메인 이름의 IP 주소를 빠르게 찾을 수 있도록 한다.
만약 사용자가 자주 방문하는 www.example.com에 접속하려고 한다면, DNS 리졸버가 이전에 이 도메인의 IP 주소를 요청받은 적이 있어 이를 캐시에 저장해 두었을 수 있다. 따라서 DNS 리졸버는 클라이언트의 요청을 받자마자 캐시에 저장된 IP 주소를 바로 전달하여 빠르게 응답한다. 새로운 쿼리나 다른 DNS 서버와의 통신은 필요하지 않다.
DNS 캐싱
위에서 언급했듯이 DNS 캐싱은 DNS 쿼리 결과를 저장해 두었다가, 동일한 도메인에 대한 요청이 다시 들어올 때 빠르게 응답할 수 있도록 하는 메커니즘이다. 캐싱 덕분에 매번 DNS 서버에 쿼리를 보내는 대신, 로컬에 저장된 정보를 재사용할 수 있어 네트워크 성능을 향상시키고 응답 시간을 줄일 수 있다.
DNS 캐싱은 주로 브러우저와 운영 체제 레벨에서 이루어진다.
브라우저 DNS 캐싱
웹 브라우저는 사용자가 웹사이트에 접속할 때, 해당 도메인의 IP 주소를 캐시한다. 이렇게 하면 동일한 도메인에 대한 반복적인 요청이 있을 때, DNS 리졸버나 OS에 다시 요청을 보내지 않고, 브라우저 내에서 바로 캐시된 IP 주소를 사용할 수 있다.
• 작동 방식:
- 사용자가 브라우저에서 www.example.com을 처음 방문하면, 브라우저는 DNS 리졸버에 쿼리를 보내고 IP 주소를 받는다.
- 이 IP 주소는 브라우저의 DNS 캐시에 일정 기간(일반적으로 TTL(Time to Live) 값으로 지정된 시간) 동안 저장된다.
- 사용자가 동일한 www.example.com을 다시 방문할 때, 브라우저는 캐시를 먼저 확인하고, 캐시에 IP 주소가 있다면 이를 사용해 즉시 웹사이트에 접속한다.
- TTL이 만료되면 캐시된 항목이 삭제되고, 다시 DNS 쿼리가 발생한다.
해당 캐싱 방법은 DNS 요청 횟수를 줄여 네트워크 트래픽을 감소시키고, 웹사이트 로딩 시간을 단축할 수 있다.
운영체제(OS) 레벨 DNS 캐싱
운영체제는 DNS 쿼리 결과를 시스템 전역에서 사용할 수 있도록 캐시해 둔다. 이는 브라우저뿐만 아니라 시스템에서 발생하는 모든 네트워크 요청에 대해 캐시된 정보를 제공할 수 있다.
• 작동 방식:
- 사용자가 브라우저 또는 애플리케이션을 통해 www.example.com에 접속할 때, 해당 도메인의 IP 주소를 DNS 리졸버에 요청한다.
- 운영체제의 DNS 캐시가 응답받은 IP 주소와 캐시된 항목의 TTL을 저장한다.
- 동일한 도메인에 대한 요청이 발생하면, 운영체제는 먼저 자신의 DNS 캐시를 확인한다. 만약 캐시에 IP 주소가 있다면, 브라우저나 애플리케이션에 바로 해당 IP 주소를 반환한다.
- 만약 캐시에 정보가 없거나 TTL이 만료되었다면, 운영체제는 다시 DNS 리졸버에 쿼리를 보내 새로운 IP 주소를 요청하고, 그 결과를 캐시에 저장한다.
해당 캐싱 방법은 브라우저뿐만 아니라 다른 애플리케이션에서도 동일한 DNS 정보를 재사용할 수 있어 시스템 전체의 효율성을 높일 수 있다.
'스터디 > 프론트엔드' 카테고리의 다른 글
CSS 참고 키워드 - 반응형 웹사이트 (1) | 2024.09.25 |
---|---|
CSS 참고 키워드 - CSS 요소 (0) | 2024.09.24 |
[JS, React]이벤트 버블링과 실제 개념 활용 사례 (1) | 2024.08.29 |
[Internet] 브라우저의 동작 방식 (0) | 2024.08.27 |
프론트엔드 첫 글 (0) | 2024.08.25 |
댓글