DNS에 대해 설명해주세요

[haeyoon1]

DNS를 통해 IP 주소로 이동하는 과정에 대해 설명해주세요!

[sangjun121]

DNS는 도메인 주소(www.google.com)를 컴퓨터가 사용하는 IP주소로 변환해주는 역할을 합니다.

우선 브라우저는 도메인 주소를 기반으로 대응되는 IP주소를 찾기 위해 DNS 조회를 시작하는데요, 이 프로세스에 대해 간단히 알아보겠습니다.

1. 브라우저 -> 운영체제

브라우저는 이전에 조회한 적 있는 자신의 DNS 캐시를 확인하여, IP주소가 있는지 확인합니다. 없다면 운영체제에 DNS 조회를 요청합니다.

2. 운영체제(클라이언트) -> Local DNS 서버로 재귀적 질의

운영체제도 DNS 캐시를 갖고 있기 때문에, IP가 이미 조회되었는지 확인합니다. 없다면 Local DNS서버로 질의를 보냅니다.

• 여기서 Local dns서버는 일반적으로 ISP인 KT,SKT,LG나 Google DNS, Cloudflare DNS가 사용됩니다.

운영체제(클라이언트)는 Local DNS서버에 단순히 재귀 질의만을 보내고, Local DNS 서버가 Root,TLD,Authoritative DNS 서버로 반복질의를 보내기 때문에 운영체제 입장에서는 다른 DNS서버를 모르더라도 IP주소를 얻게 됩니다.

3. Local DNS -> Root ,TLD, Authoritative DNS 서버 조회 (반복 질의)

마찬가지로 Local DNS 서버도 캐시를 먼저 조회합니다. 정보가 없다면, 계층적으로 DNS 서버들을 조회합니다.

1. Root DNS 서버 조회
2. TLD DNS 서버 조회
3. Authoritative DNS 서버 조회

3.1 Root DNS에 먼저 요청

"www.google.com의 IP를 아시나요?"라는 요청을 보낸다면, .com을 관리하는 TLD 서버의 주소를 반환합니다.

3.2 TLD DNS에 요청

TLD서버의 주소를 받은 이후 Local DNS는 TLD 서버에 질의를 보냅니다. 이때 google.com의 Authoritative DNS 서버의 주소를 반환합니다.

3.3 Authoritative(네임서버) DNS에 요청 후, 최종 IP 반환

Authoritative에 질의를 보내 www.google.com의 최종 ip주소를 획득합니다.

4. Local DNS 서버의 캐시 저장

Local DNS 서버는 조회한 결과를 TTL(Time To Live) 동안 캐시에 저장합니다.

5. 브라우저는 얻은 IP 주소를 이용해 해당 서버와 연결합니다.

• HTTP라면 TCP 3-way Handshake 후 요청을 보내고, HTTPS라면 TCP 연결 후 TLS Handshake까지 수행합니다.
• 연결 이후, HTTP Request를 보내고 응답을 받습니다.

추가

DNS 사이의 통신은 기본적으로 UDP 53번 포트를 사용합니다. 빠른 응답을 위해 별도의 Handshake 과정 없는 UDP를 사용하며 응답 데이터가 크거나 Zone Transfer와 같은 경우에는 TCP를 사용합니다.

[softmoca]

DNS는 사용자가 브라우저에 입력한 도메인 이름을 실제 서버가 사용하는 IP 주소로 변환해주는 시스템입니다.
사용자가 도메인을 입력하면 먼저 브라우저나 운영체제의 캐시에 해당 IP가 있는지 확인하고,
없으면 DNS Resolver가 Root DNS, TLD DNS, Authoritative DNS를 순서대로 조회해 최종 IP 주소를 찾습니다.
이후 브라우저는 얻은 IP 주소를 이용해 해당 서버와 TCP 연결을 맺고,
HTTP 요청을 보내 원하는 웹 페이지나 리소스를 받아옵니다.

[koreaioi]

DNS

DNS는 도메인 이름을 IP 주소로 변환하는 역할입니다. (IP주소를 암기하기 힘듦.)

DNS 과정

1. www.naver.com 이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어있는 지 확인
2. 로컬 캐시에 저장되어있지 않으면, 사용자 호스트에 설정된 DNS서버에 질의
3. DNS 서버는 자신의 로컬 캐시와 자체 설정을 확인 후, 없으면 루트 네임 서버에 질의
4. 이때부터 DNS서버는 반복 질의를 시작하고 최종적으로 www.naver.com의 정보를 받아옴. + 자신(DNS)의 로컬 캐시에 저장.
5. 사용자 호스트에게 www.naver.com에 대한 IP 정보를 반환.
6. 사용자 호스트는 자신의 로컬 캐시에 이를 저장.

호스트 -> DNS 서버 질의

재귀적, 반복 질의

[Uechann]

DNS란?

DNS는 사람이 읽는 도메인 이름을 IP 주소로 바꿔주는 분산,계층 데이터베이스이자 그 변환을 수행하는 프로토콜이다.
RFC 1034에 설명 되어 있고, 지금까지 이 계약으로 확장되고 있다고 한다.

트리 구조의 이름 공간을 갖고 여러 주체가 나눠서 관리하고,
각 영역의 권한을 가진 서버가 자기 영역의 정보만 책임진다.

저장되는 단위는 레코드이고, 타입 별로 역할이 다르다.

초기에는 모든 호스트 이름 ↔ 주소 매핑을 하나의 중앙에서 배포하였는데,
확장성, 갱신 부담, 단일 장애점/ 병목의 문제를
DNS는 계층적 위임 + 분산 + 캐싱으로 풀어냈다고 한다.

동작 방식

Stub resolver

브라우저에 내장된 질의기

Recursive resolver 재귀 리졸버

공용 DNS이고 캐시를 들고 있고 계층에 따라 반복적인 질의를 수행한다.

Root / TLD / Authoritative 네임 서버

각 계층을 책임 지는 권한 서버

단계별 순서

1. Stub Resolver가 www.google.com 도메인의 IP를 재귀 리졸버에게 묻는다.
2. 재귀 리졸버는 먼저 자기 캐시를 확인한다.
   TTL이 안지난 답이 있다면 끝
3. 캐시에 존재하지 않는다면 반복 질의를 시작한다.
   Root에게 먼저 묻고,
   Root는 .com 은 저쪽 TLD 서버한테 물어봐라며 위치를 알려준다.
4. TLD(.com) 서버에게 묻고, google.com 의 권한 서버는 여기야라고 NS 정보를 받는다.
5. 권한 네임 서버에게 물어보고 A 레코드(실제 IP)를 받고, 이 답을 TTL과 함께 캐싱한 뒤 Stub Resolver에게 돌려준다.