✅ DNS(Domain Name System Servers)란?
: 도메인 이름을 IP 주소로 변환하거나 그 반대의 역할을 해주는 애플리케이션 계층 프로토콜
사용자가 웹사이트에 접근할 때, 기억하기 쉬운 도메인 이름(예: http://www.google.com)을 입력하면 DNS가 이 이름을 해당하는 IP 주소로 변환하여 웹사이트에 연결할 수 있도록 도와준다. DNS는 인터넷의 전화번호부와 같은 역할을 한다.
도메인 이름(Domain Name): 네트워크 상에서 컴퓨터를 식별하는 이름으로, IP 주소에 대응된다.
DNS 질의는 주로 UDP(User Datagram Protocol)를 사용한다.
- 속도: UDP는 연결을 설정하지 않고 데이터를 전송하기 때문에 더 빠르다.
- 간단한 요청: DNS 질의는 일반적으로 짧고 간단한 요청이므로, TCP보다 UDP가 더 효율적이다.
- 재전송 용이: DNS는 자체적으로 캐싱을 활용하여 재전송이 필요할 경우 UDP를 통해 빠르게 처리할 수 있다.
✅ DNS 계층 구조
DNS는 분산 계층 데이터베이스이다.
중앙 집중 데이터베이스는 서버의 고장, 트래픽 양, 먼 거리 등의 문제가 발생할 수 있으므로 DNS는 많은 서버를 이용해 계층 형태로 분산시킨다.
다음과 같이 총 3가지 계층의 DNS 서버로 나눌 수 있다.
📍 루트 DNS 서버
: TLD(Top Level Domain) 서버의 IP 주소 제공
1000개 이상의 루트 서버 인스턴스가 전 세계에 흩어져 있다.
📍 Top-Level Domain(TLD, 최상위 DNS 서버)
: 책임 DNS 서버에 대한 IP 주소 제공
com. org, net와 같은 상위 레벨 도메인과 kr, uk와 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다.
📍 책임 DNS 서버(Second-Level Domain)
: 조직의 자체 DNS 서버
규모가 큰 기관은 대부분 자신의 호스트들에 대한 책임 DNS 서버를 유지한다.
✅ DNS 작동 방식
- 사용자가 웹 브라우저에 URL을 입력한다.
- 브라우저는 URL로부터 호스트 이름(도메인)을 추출한다.
- ex) https://www.example.com/page -> 호스트 이름: www.example.com
- 컴퓨터는 로컬 DNS 서버를 참조하여 해당 도메인의 IP 주소를 검색한다.
- 로컬 DNS에 IP 주소가 없으면, 루트 DNS 서버에 질의한다.
- 로컬 DNS는 결국 도메인에 대한 IP 주소를 가진 응답을 받는다. 그리고 이 정보를 캐싱하여 이후 요청 시 빠르게 응답할 수 있도록 한다.
- 브라우저가 로컬 DNS로부터 IP주소를 받아, 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.
- 루트 서버는 요청된 도메인의 TLD(ex. com) 서버의 IP 주소를 반환한다.
- TLD 서버는 해당 도메인을 관리하는 책임 DNS 서버의 IP 주소를 반환한다.
- 책임 DNS 서버는 요청된 도메인의 IP 주소를 반환하고, 로컬 DNS는 이 정보를 캐싱하여 이후 요청 시 빠르게 응답할 수 있도록 한다.
로컬 DNS 서버의 주소는 일반적으로 ISP에서 할당해 준다.
✅ DNS 질의 종류
ISP(Internet Service Provider)의 DNS 서버가 호스팅 하고 있는 서버의 IP주소를 찾기 위해 DNS query를 날린다.
📍 재귀 질의 (Recursive Query)
: 클라이언트가 DNS 서버에 질의할 때, DNS 서버가 최종 IP 주소를 찾을 때까지 다른 DNS 서버에 추가적으로 질의하는 방식
- 클라이언트가 로컬 DNS 서버에 도메인 이름을 요청한다.
- 로컬 DNS 서버는 다시 루트 DNS 서버에 질의한다.
- 루트 DNS 서버는 다시 TLD 서버에 질의한다.
- 이런 과정을 반복하여 결과를 역순으로 전달받는다.
📍 반복 질의 (Iterative Query)
: 클라이언트가 DNS 서버에 질의할 때, DNS 서버가 자신이 알고 있는 정보만 제공하고, 알지 못하는 정보에 대해서는 다른 DNS 서버의 주소를 반환하는 방식
- 클라이언트가 로컬 DNS 서버에 도메인 이름을 요청한다.
- 로컬 DNS 서버가 해당 도메인의 IP 주소를 알고 있지 않으면, 클라이언트에게 알고 있는 DNS 서버의 주소를 반환한다.
- 클라이언트는 반환된 DNS 서버에 직접 질의하여 필요한 정보를 찾아간다.
✅ DNS 캐싱
DNS 질의는 많은 단계를 거쳐야 하므로 속도와 성능 향상을 위해 DNS 캐싱을 사용한다.
- 로컬 DNS 서버는 클라이언트가 요청한 도메인에 대한 최종 IP 주소를 캐싱한다.
- 이후 동일한 도메인 요청이 들어오면 상위 DNS 서버로 질의하지 않고, 캐시 된 IP를 바로 응답한다.
- 특정 시간(TTL) 이후에 저장된 정보는 제거한다.
- 로컬 DNS 서버에는 TLD 서버의 IP도 저장하여 루트 DNS 서버를 우회할 수 있다.
✅ DNS 레코드
: DNS 서버가 해당 패킷을 받았을 때 어떤 식으로 처리할지를 나타내는 지침
DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드를 저장한다.
각 레코드는 `(Name, Value, Type, TTL)` 4가지 튜플로 이루어진다.
그리고 레코드의 타입에 따라 Name과 Value의 의미가 달라진다.
- A 레코드: 도메인 이름을 IPv4 주소로 변환한다. (Address)
- Name: 도메인 이름
- Value: IPv4 주소
- AAAA 레코드: 도메인 이름을 IPv6 주소로 변환한다.
- Name: 도메인 이름
- Value: IPv6 주소
- CNAME 레코드: 도메인 이름을 다른 도메인 이름으로 매핑한다. (Canonical Name)
- Name: 정식 호스트 이름의 별칭
- Value : 별칭 호스트 이름에 대한 정식 호스트 이름
- MX 레코드: 도메인과 연동된 메일 서버의 주소를 지정한다. (Mail Exchange)
- Value: 해당 도메인의 메일을 처리할 메일 서버의 정식 호스트 이름
- NS 레코드: 도메인의 IP주소를 찾을 수 있는 네임 서버의 주소를 지정한다. (Name Server)
- Name: 도메인
- Value: 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 이름
✅ Web Server & WAS
📍Web Server
: HTTP 프로토콜을 사용하여 클라이언트로부터 받은 요청에 대해 정적 콘텐츠를 제공
- ex) Apache, Nginx
- 정적 콘텐츠: 데이터베이스에서 정보를 가져오거나 등 별도의 서버에서의 처리가 없어도, 사용자들에게 보여줄 수 있는 페이지
- ex) HTML, 이미지, CSS 등
- 항상 동일한 페이지를 반환
- 동적인 콘텐츠 요청을 WAS로 전달하는 역할도 수행
📍Web Application Server (WAS)
: 클라이언트로부터 받은 요청에 대해 동적으로 생성된 콘텐츠 제공
- ex) Tomcat, JBoss 등
- 동적 콘텐츠: 데이터베이스에서 가져온 데이터, 사용자 입력에 따라 생성된 HTML 등
- WAS = Web Server + Web Container
- Web Container: JSP, Servlet을 실행시킬 수 있는 소프트웨어
💡 WAS가 왜 필요?
- 자원의 효율적인 사용을 위해
- Web Server만 사용한다면 동적인 콘텐츠에 대해 미리미리 결괏값을 만들어두고 제공해야 한다. 이렇게 하기에는 자원이 절대적으로 부족하다.
💡 WAS가 Web Server의 기능을 수행하면 안 되나?
- 서버 부하 방지
- 만약 정적 콘텐츠 요청까지 WAS가 처리한다면 부하가 커지게 되고, 동적 콘텐츠의 처리가 지연됨에 따라 수행 속도가 느려짐
- 보안 강화
- Web Server가 외부 요청의 첫 관문이 되어 보안 역할 수행
- WAS는 내부망에 위치시키고 Web Server만 외부에 노출하면 보안 위험 최소화 가능
- 확장성과 유연한 아키텍처
- Web Server는 여러 대의 WAS와 연결 가능 -> 로드밸런서 역할 수행
- Web Server가 로드밸런서 역할을 하여 장애 극복에 쉽게 대응 가능
✅ URL vs. URI vs. URN
- URI(통합 자원 식별자): 인터넷상의 리소스 자원을 식별하는 고유한 문자열. URI의 하위 개념으로 URL과 URN이 존재
- URL(위치): 웹 주소라고도 불리며, 네트워크상에서 리소스의 위치를 찾는 데 사용
- 하지만, 자원의 위치가 변한다면 기존 URL은 유효해지지 않는다.
- URN(이름): 네트워크상에서 리소스의 이름. 위치와 관계없이 리소스를 식별하는 데 사용
- 위치와 무관하게 자원 식별이 가능한 영속적인 식별자
즉, URI가 URL과 URN을 포함하는 개념이다.
URI는 위치를 이용해 자원을 식별할 수도 있고, 이름을 이용해 자원을 식별할 수도 있는 것이다.
http://store.com/dir/page.html?page=1을 기준으로 설명하자면
- http://store.com/dir/page.html?page=1는 URI
- http://store.com/dir/page.html은 URL
- `urn:uuid:123 e4567`와 같이 `urn:`으로 시작하는 것이 URN(위치 정보를 포함 X)
✅ 사용자가 브라우저에 www.github.com을 입력하면?
- 호스트 이름 추출: URL에서 `www.github.com`을 추출
- DNS 질의: 도메인에 대한 IP 주소를 로컬 DNS 서버에 질의
- IP 응답 수신: `www.github.com`의 IP 주소를 응답받음
- TCP 연결: 해당 IP의 443번 포트(https)로 TCP 3-way handshake 수행
- TLS 핸드셰이크: HTTPS 보안을 위한 암호화 연결 설정
- HTTP 요청 전송: 브라우저가 GET 요청 전송
- Web Server 수신: 요청은 먼저 Web Server(ex. Nginx)가 받음
- WAS 전달: 동적 처리가 필요한 경우 Web Application Server로 전달
- 응답 생성: WAS가 처리 후 HTML/JSON 등의 응답 생성
- 응답 반환: Web Server -> 브라우저로 응답 전송
- 페이지 렌더링: 브라우저가 응답 내용을 해석하고 화면에 렌더링
✨ 추가 질문
[ DNS 쿼리 과정에서 손실이 발생한다면, 어떻게 처리하나요? ]
클라이언트/서버는 일정 시간 기다린 뒤 타임아웃이 발생하고, 재전송을 시도한다.
DNS는 UDP 기반 프로토콜이기 때문에 신뢰성을 직접 보장하지 않지만
DNS 클라이언트/서버는 타임아웃 후 자동 재시도(retry)를 통해 손실을 보완한다.
[ 캐싱된 DNS 쿼리가 잘못될 수도 있습니다. 이 경우, 어떻게 에러를 보정할 수 있나요? ]
도메인의 IP 주소가 변경됐는데 TTL이 만료되지 않을 경우, 잘못된 정보를 반환할 수 있다.
이럴 경우 TTL 만료를 기다리거나, 강제로 캐시를 삭제(Flush)하거나, TTL을 더 짧게 조정하여 오류를 보정할 수 있다.
[ hosts 파일은 어떤 역할을 하나요? DNS와 비교하였을 때 어떤 것이 우선순위가 더 높나요? ]
hosts 파일은 DNS가 등장하기 이전 도메인 이름과 IP 주소를 수동으로 매핑하기 위해 사용되던 파일이다.
과거에는 사용자가 인터넷에 연결된 모든 컴퓨터의 이름과 IP 주소를 이 파일에 직접 기록해야 했고,
인터넷 규모가 커지고 네트워크 노드가 급격히 늘어나면서 이를 효율적으로 관리하기 위해 DNS 시스템이 등장하게 되었다.오늘날에도 hosts 파일은 여전히 사용되며, 도메인 이름을 해석할 때 DNS보다 먼저 참조된다.
따라서 hosts 파일에 매핑이 존재하면 DNS 질의 없이 해당 IP로 바로 연결된다.
[ DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있나요? ]
사용자가 입력한 URL의 도메인(=호스트 이름)에 대응되는 서버의 IP 주소를 의미한다.
이 IP는 보통 실제 웹 서버를 가리키며, 그 외에도 로드밸런서나 프록시 장비를 가리킬 수 있다.
'⚙️ CS > 네트워크' 카테고리의 다른 글
| [네트워크] XSS & CSRF & SQL Injection (1) | 2025.03.28 |
|---|---|
| [네트워크] HTTP 상태유지 기술 (2) | 2025.03.28 |
| [네트워크] HTTP 프로토콜 (0) | 2025.03.20 |
| [네트워크] OSI 7계층 vs TCP/IP 모델 (1) | 2025.03.19 |