← 전체 목록
📖

DNS

주소/이름도메인 이름을 IP 주소로 변환하는 분산 시스템

아키텍처 다이어그램

example.com?① .com 어디?② TLD 서버③ 권한 서버④ IP 응답💻Client🔍Resolver🌍Root DNS📂TLD DNS📖Auth DNS📍93.184.1.1

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

서버에 접속하려면 IP 주소가 필요한데, `93.184.216.34` 같은 숫자를 기억하기는 어렵습니다. 더 큰 문제는 서버를 이전하면 IP가 바뀌는데, 그때마다 모든 사용자에게 새 주소를 알려야 합니다. 호스트 수가 수십 만 대를 넘어서면 중앙 파일 하나로 관리하는 것도 불가능합니다.

안에서 어떻게 동작하나요?

브라우저가 `example.com`을 입력하면 재귀 리졸버가 루트 네임서버 → TLD 네임서버(.com) → 권한 네임서버 순으로 물어가며 IP를 찾습니다. 결과는 TTL 동안 캐시되어 다음 요청을 빠르게 처리하고, TTL이 만료되면 다시 조회합니다. 도메인을 바꾸지 않고 IP만 바꾸면 TTL 이후 자동으로 새 주소로 연결됩니다.

무엇과 헷갈리나요?

DNS와 CDN은 둘 다 사용자 요청 경로에 관여하지만 역할이 다릅니다. DNS는 도메인을 IP로 변환하는 첫 번째 단계이고, CDN은 그 이후 실제 콘텐츠를 사용자와 가까운 엣지에서 전달하는 계층입니다. DNS가 없으면 CDN 엣지 주소 자체를 찾을 수 없습니다.

왜 이런 방식이 등장했나요?

초기 인터넷에서는 `HOSTS.TXT` 파일 하나로 모든 호스트 이름을 관리했습니다. 연결된 장치가 수백 대일 때는 괜찮았지만, 수천 대로 늘어나자 파일 갱신과 배포가 불가능해졌습니다. 이 확장성 문제를 해결하기 위해 1983년 계층적 분산 구조를 가진 DNS가 설계됐고, 지금은 수십억 개 도메인을 처리합니다.

언제 쓰나요?

웹사이트 접속, 이메일 전달, 서비스 디스커버리, 클라우드 로드 밸런서 연결에 필수입니다. TTL을 짧게 설정하면 IP 변경이 빠르게 반영되지만 DNS 쿼리 부하가 늘어납니다. 장애 조치가 중요한 서비스라면 TTL을 낮게 유지하는 것이 좋습니다.

웹사이트 접속이메일 전달서비스 디스커버리CDN 라우팅