DNS

DNS Resolver vs Local DNS Server

Local DNS Server는 DNS Resolver의 일부 기능(특히 캐싱)과 유사한 역할을 하므로, 많은 경우 동일시되기도 합니다. 특히 가정이나 작은 네트워크에서, Local DNS Server가 ISP에서 제공하는 DNS Resolver 역할을 수행하기 때문에 구분이 명확하지 않을 수 있습니다.

DNS Resolver

DNS Resolver는 사용자가 브라우저에 도메인 이름을 입력했을 때 해당 도메인 이름에 대한 IP 주소를 찾아주는 주체입니다.

• 역할: 사용자로부터 도메인 이름을 입력받고, 이를 IP 주소로 변환하는 과정을 주도하는 주체.
• 재귀적 요청 처리: 사용자가 요청한 도메인 이름의 IP 주소가 없다면, 여러 단계(루트 DNS 서버 → TLD 서버 → 권한 있는 네임서버)를 거쳐 재귀적으로 요청을 처리합니다.

예시
사용자가 www.example.com을 요청했을 때:

• 브라우저는 설정된 DNS Resolver에게 해당 도메인 이름의 IP 주소를 물어봅니다.
• DNS Resolver는 루트 서버, TLD 서버, 권한 있는 네임서버를 통해 재귀적으로 IP 주소를 조회하고, 최종적으로 IP 주소를 알아냅니다.
• Resolver는 이 IP 주소를 캐시해 두고, 브라우저에 반환합니다.

Local DNS Server

Local DNS Server는 네트워크 가까운 곳(가정, 회사 또는 ISP의 로컬 네트워크)에 있는 캐싱 DNS 서버입니다. Local DNS Server는 사용자에게 더 빠른 DNS 응답을 제공하기 위해 IP 주소 정보를 저장하고, 자주 요청되는 도메인에 대해 중간 단계에서 응답할 수 있습니다.

• 역할: 사용자가 요청한 도메인 이름의 IP 주소가 캐시에 있으면 바로 응답하고, 없으면 DNS Resolver에게 해당 요청을 넘겨 처리합니다.
• 재귀 요청 처리 없음: Local DNS Server는 재귀적 요청을 처리하는 직접적인 역할을 하지 않으며, 캐시가 없는 경우에만 재귀적인 DNS Resolver로 요청을 전달합니다.

예시
사용자가 www.example.com을 요청했을 때:

• Local DNS Server가 설정된 경우, 먼저 캐시를 확인합니다.
• 캐시에 IP 주소가 있으면 바로 반환합니다.
• 캐시에 없으면 DNS Resolver에게 요청을 넘깁니다.
• DNS Resolver로부터 응답을 받은 후, Local DNS Server는 이를 캐시에 저장하여 향후 같은 요청이 들어오면 빠르게 응답할 수 있습니다.

결론

DNS Resolver

• DNS Resolver는 일반적으로 사용자의 컴퓨터나 모바일 디바이스에 포함되어 있으며, 사용자가 도메인 이름을 입력하면 해당 Resolver는 DNS 쿼리를 생성하고, 이를 인터넷 상의 다른 DNS 서버에 전송한다.

• Resolver는 일반적으로 캐시된 DNS 정보를 사용자의 컴퓨터나 모바일 디바이스에 저장하며, 이를 사용하여 DNS 쿼리를 처리한다.

• 즉, Resolver는 사용자의 컴퓨터와 DNS 서버 사이의 중개자 역할을 한다.

Local DNS Server

• 반면 Local DNS Server는 네트워크에서 사용되며, 일반적으로 기업, 학교, 공공기관 등에서 사용된다.

• Local DNS Server는 네트워크 내에서 DNS 쿼리를 처리하고, 이를 인터넷 상의 다른 DNS 서버에 전달한다.

• 또한 Local DNS Server는 네트워크 내에 캐시된 DNS 정보를 저장하며, 이를 사용하여 네트워크 내 모든 사용자의 DNS 쿼리를 빠르게 처리할 수 있다.

• 성능 측면에서 Local DNS Server는 DNS Resolver 보다 더 높은 처리량을 처리할 수 있으며, 다양한 DNS 정보를 캐시하여 더 빠른 DNS 쿼리 응답을 제공한다.
  

SK, LG 같은 통신사들은 기본적으로 DNS Resolver(Recursive DNS Resolver) 로서 동작하며, 필요할 때 Local DNS Server의 역할(캐싱)을 동시에 수행합니다.
이들은 사용자가 도메인 요청을 보냈을 때, 캐시된 정보가 있으면 Local DNS Server처럼 작동하여 빠르게 응답하고, 캐시가 없을 때는 DNS Resolver처럼 재귀적으로 IP 주소를 찾아 응답합니다.

Root Name Server

Root Name Server는 계층 구조 트리에서 최상위 경로를 담당하고 있습니다.

• 도메인 주소 맨 뒤에는 대부분 dotnaver.com(.)이 생략되어 있고, 생략된 dot이 Root Name Server입니다.
• 사람이 이해할 수 있는 도메인 네임을 IP 주소로 변환하는 첫 번째 단계로 ICANN이 직접 관리하는 절대 존엄 서버입니다.
  • 패킷의 실질적인 크기 제한으로 인해 루트 서버 수를 13개 서버 주소로 제한하도록 결정되었습니다.
  • 갯수가 13가지가 아닌 13가지 유형의 루트 이름 서버가 있으며 전 세계에 각각의 사본이 다수 있습니다.
• 도메인 확장자(.kr, .com) 레이블을 구분해서 TLD Name Server로 안내합니다.

TLD(Top-Level Domain) Name Server

Authoritative DNS 서버의 주소를 저장하고 안내하는 역할을 합니다.

• 만약 naver.com 으로 DNS에 요청을 보내게 된다면 Root Name Server를 통해 .com 도메인 확장자를 반환 받아서 .com 을 관리하는 기관에 naver.com 도메인 주소가 존재하는지 확인하여 Authoritative DNS로 안내합니다.
• TLD Name Server는 ICANN의 지사인 IANA(Internet Assigned Numbers Authority)가 관리하며, 두가지 서버로 구분합니다.
  일반 최상위 도메인: 가별로 고유하지 않은 도메인입니다. (.com, .net)
  국가 코드 최상위 도메인: 국가 또는 주와 관련된 모든 도메인이 포함됩니다. (.kr, .us)

Authoritative Name Server(SLD Name Server)

일반적으로 DNS 서버에서 가장 마지막 단계로 실제로 DNS 리소스 레코드를 보유하고 담당하는 서버입니다.

• 쿼리의 종착지입니다. 요청한 리졸버에게 도메인의 IP주소를 반환합니다.
• 일반적으로 도메인 (호스팅) 업체들의 네임서버입니다. 개인이나 회사가 별도의 DNS를 구축했다면 그 서버 또한 여기에 해당합니다.
• IP를 응답받은 리졸버는 Local DNS Server 데이터를 캐싱해 두고 클라이언트에게 전달합니다.

Web Server vs Web Application Server

Web Server

HTTP 프로토콜을 사용하여 클라이언트로부터 받은 요청에 대해 정적 콘텐츠(HTML, CSS, 이미지, JavaScript 파일 등)를 제공한다.

• 예: Apache, Nginx, IIS(windows 전용 웹 서버)

Web Application Server (WAS)

동적인 웹 애플리케이션을 실행하는 데 사용된다. 이 서버는 클라이언트로부터 받은 요청에 대해 동적으로 생성된 콘텐츠(데이터베이스에서 가져온 데이터, 사용자 입력에 따라 생성된 HTML 등)를 제공한다.

• 예: Tomcat, JBoss, Jeus, Web Sphere

Web Server와 Web Application Server 비교

	Web Server (웹 서버)	Web Application Server (WAS 서버)
정의	정적인 컨텐츠(HTML, CSS, 이미지 등)을 제공하는 서버	동적인 컨텐츠(웹 애플리케이션)을 처리하고 제공하는 서버
기능	HTTP 프로토콜을 이용해 클라이언트에게 웹 페이지 제공	웹 애플리케이션 실행 및 데이터 처리, 웹 서버와 클라이언트 간의 중계 역할
소프트웨어	Apache, Nginx, IIS	Tomcat, JBoss, Jeus, Web Sphere
예시	회사 홈페이지, 블로그, 뉴스 사이트 등	온라인 쇼핑몰, 은행 인터넷 뱅킹, SNS 등

URL / URI / URN 차이점

URI (Uniform Resource Identifier)

• 통합 자원 식별자(Uniform Resource Identifier)는 인터넷에 있는 자원을 어디에 있는지 자원 자체를 식별하는 방법이다.

  • Uniform : 리소스를 식별하는 통일된 방식
  • Resource : 자원, URI로 식별할 수 있는 모든 것여기서 자원은 웹 브라우저의 파일만 뜻하는 게 아니라, 실시간 교통정보 등 우리가 구분할 수 있는 것은 모든 게 리소스가 된다.
  • Identifier : 다른 항목과 구분하는데 필요한 정보

• URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다.
• URI의 하위개념으로 URL, URN 이 있다

URL (Uniform Resource Locator)

• 파일식별자(Uniform Resource Locator)는 네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약이다.
• 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다.
• 흔히 우리는 URL을 웹 사이트 주소로만 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타내는 표기법이다.
• 그리고 해당 주소에 접속하려면 URL에 맞는 프로토콜(http, sftp, smp ..등)을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다.

예를들어 다음과 같은 홈페이지 링크가 있다고 하자.
http://www.naver.com/index.html?page=1232950&id=776

• http://www.naver.com/ 서버에 위치한 index.html 페이지는 query string인 page의 값에 따라 여러가지 화면 결과를 나타나게 된다.
• 이때 여기서 URL은 index.html의 위치를 표기한 http://www.naver.com/index.html 까지이다.
• 하지만 사용자가 원하는 정보에 도달 하기위해서는 ?page=1232950&id=776라는 식별자(Identifier)가 필요한 것이다.
• 따라서 엄격히 구분하자면 위의 http://www.naver.com/index.html?page=1232950&id=776 주소는 URI이고, 식별자가 빠진 http://www.naver.com/index.html를 URL이라고 하는 것이다. 

URN (Uniform Resource Name)

• 통합 자원 이름(Uniform Resource Name)은 urn:scheme 을 사용하는 자원의 고유한 이름을 식별하는 문자열이다.
• URN은 영속적이고, 위치에 독립적인 자원을 위한 지시자로 사용하기 위해 1997년도 RFC 2141 문서에서 정의되었다.
• URN은 자원의 위치가 변경되어도 고유한 이름으로 식별할 수 있다는 장점이 있지만,
  실제 자원에 접근하기 까다롭다는 단점이 있어서 거의 사용하지 않는다.
  

출처

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC
https://kghworks.tistory.com/126
https://velog.io/@zinukk/9kpyzbdt
https://velog.io/@park-moen/devcourse-study01
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-URL-URI-%EC%B0%A8%EC%9D%B4