Reference :
컴퓨터 네트워킹 하향식 접근 [8판] / 퍼스트 북 / James F. Kurose, Keith W. Ross
건국대학교 컴퓨터 네트워크 수업 / 김기천 교수님
DNS-인터넷의 디렉터리 서비스
사람을 여러가지 방법으로 식별할 수 (이름, 주민번호) 있는 것처럼, 인터넷 호스트도 마찬가지다.
호스트에 대한 하나의 식별자는 호스트 네임이다.
호스트 네임은 가변 길이의 알파뉴메릭(영숫자) 문자로 구성되므로 라우터가 처리하는 데 어려움이 있어서 호스트는 IP주소로도 식별된다
DNS가 제공하는 서비스
사람의 好: 기억하기 쉬운 호스트 네임
라우터의 好: 고정길이의 계층 구조를 가진 IP주소
절충: 호스트 네임을 IP주소로 변환
⇒ DNS
DNS의 간단 개념
- Domain Name System
- DNS 서버들의 계층구조로 구현된 분산 DB
- 호스트가 분산 DB로 질의하도록 허락하는 애플리케이션 계층 프로토콜
- 특징
- BIND 솦웨를 수행하는 유닉스 컴퓨터
- UDP상에서 수행 & 53번 포트 이용
- 클라이언트-서버 구조로 통신하는 종단 사이에서 수행
- 통신하는 종단 시스템 사이에서 DNS 메시지를 전달하기 위해 하위 종단 트랜스포트 프로토콜에 의존함⇒애플리케이션 계층 프로토콜
- 이용
- 다른 애플리케이션 프로토콜들이 HTTP,SMTP,FTP 등 사용자가 제공한 호스트 네임을 IP주소로 변환하기 위해 주로 이용
- 어떤 사용자의 호스트에서 수행되는 브라우저가 URL을 요청할 때 호스트가 HTTP 요청 메시지를 웹 서버로 보낼 수 있게 하기 위해 사용자 호스트는 호스트의 IP주소를 얻어야만 한다.
💡 호스트 네임: `www.naver.com` URL: `www.naver.com/login`
- 과정
- 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다
- 브라우저는 URL로부터 호스트 네임을 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘긴다
- DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다
- DNS 클라이언트는 결국 호스트 네임에 대한 IP주소를 가진 응답을 받게 된다
- 브라우저가 DNS로부터 IP주소를 받으면, 브라우저는 그 IP주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다. 문제 DNS를 사용하는 인터넷 애플리케이션에게 추가 지연을 줌 해결 원하는 IP주소는 가까운 DNS 서버에 캐시되어 있어서 평균 DNS 지연뿐 아니라 DNS 네트워크 트래픽 감소에 도움을 줌
- 기능 (호스트→IP주소 변환 외에)
- 호스트 엘리어싱: 복잡한 별칭 호스트 네임을 간단한 정식 호스트 네임으로 변환
- 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있다
- ex) relay1.west-coast.enterprise.com => enterprise.com / www.enterprise.com
- ex) www.naver.com.nheos.com ⇒ www.naver.com
- 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있다
-
-
- 풀 네임의 호스트 네임: 정식 호스트 네임
- 별명 호스트 네임: 별칭 호스트 네임
- 별칭 호스트 네임은 정식 호스트 네임보다 기억하기 쉽다
-
- **메일 서버** 엘리어싱: 위와 마찬가지로 메일주소는 별명을 가질 수 있고 DNS는 정식 호스트 네임을 알려주는 역할을 한다.
- DNS는 호스트의 IP주소뿐만 아니라 제공된 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 메일 애플리케이션에 의해 수행된다
- *MX 레코드는 기업의 메일 서버와 웹 서버가 같은 호스트 네임을 갖는 것을 허용한다
*MX 레코드: 메일이 수신될 위치를 결정하는 레코드 [[링크]](https://help.worksmobile.com/kr/administrator/registration/mx-record/how-to-set-up-mx-record/)
- 부하 분산: 여러 중복 서버 사이에 부하를 분산
- `cnn.com` 과 같은 인기 있는 사이트는 여러 서버에 중복되어 있어서, **각 서버**가 다른 종단 시스템에서 수행되고 **다른 IP주소** 를 갖는다.
- 중복 웹 서버의 경우, **여러 IP주소가 하나의 정식 호스트 네임과 연관되어** 있다.
DNS 동작 원리 개요
- 변환될 호스트 네임을 명시하여 DNS측의 클라이언트를 호출 gethostbyname()
- 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다
- 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다
- 수 msec~수 sec의 지연 후에 사용자 호스트의 DNS는 요청한 매핑에 해당하는 DNS 응답 메시지를 받는다.
- 이 매핑은 호출한 애플리케이션으로 전달된다
문제
클라이언트가 모든 질의를 단일 네임 서버로 보내고, DNS서버가 질의 클라이언트에게 직접 응답하는 방식에서는 다음과 같은 문제가 발생한다
- 서버의 고장: 이 네임 서버가 고장나면, 전체 인터넷이 작동 X
- 트래픽 양: 단일 DNS 서버가 모든 DNS 질의를 처리해야 한다
- 먼 거리의 중앙 집중 데이터베이스: 단일 DNS서버가 모든 질의 클라이언트로부터 가까울 수는 X
- 유지관리: 단일 DNS서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 함
단일 DNS서버에 있는 중앙 집중 데이터베이스는 확장성이 없다.
💡 **DNS는 분산되도록 설계 됨**
분산 계층 데이터베이스
위의 확장성 문제를 다루기 위해 DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전 세계에 분산시킴
- Root DNS 서버
- 400개 이상 있는데 대부분 북미 지역에 있음
- 13개의 다른 기관에서 관리 됨
- TLD(top-level domain,최상위 레벨 도메인) DNS 서버
- com, org,net,edu와 같은 상위 레벨 도메인
- kr,uk,fr,ca,jp 같은 모든 국가의 상위 레벨 도메인
- Verisign Global Registry Services: com에 대한 서버 담당
- Educause: edu에 대한 서버 담당
- authoritative DNS 서버
- 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 네임을 IP주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다
- 기관의 authoritative DNS 서버는 이 DNS 레코드를 갖고 있다
과정
- 호스트 네임의 IP주소를 알고 싶음
- 클라이언트는 루트 서버 중 하나에 접속함
- 루트 서버는 최상위 레벨 도메인을 갖는 TLD 서버 IP주소를 보낸다
- 클라이언트는 이 TLD 서버 중 하나에 접속하고 서버는 도메인을 가진 authoritative 서버의 IP주소를 보낸다.
- 클라이언트는 도메인의 authoritative 서버 중에서 하나로 접속한다.
- 서버는 호스트 네임의 IP주소를 보낸다.
호스트네임: m.naver.com
도메인네임: naver.com
로컬 DNS 서버
호스트가 DNS 질의를 보내면, 이 질의는 먼저 프록시로 동작하는 로컬 DNS 서버에게 전달되고, 그 로컬 DNS 서버는 이 질의를 DNS 서버 계층으로 전달한다.
재귀적 질의
반복적 질의
DNS 캐싱
질의 사슬에서 DNS 서버가 DNS 응답을 받았을 때 그것은 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.
⇒ authoritative DNS 없이도 원하는 IP주소 제공 가능
2.4.3 DNS 레코드와 메시지
자원 레코드
DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP주소로 매핑하기 위한 자원 레코드를 저장한다.
각 DNS들은 하나 이상의 자원 레코드를 가진 메시지로 응답한다.
- 구성: 4개의 tuple (Name, Value, Type, TTL)
- TTL은 자원 레코드의 생존기간 (자원이 캐시에서 제거되는 시간을 결정) 여기선 생략
if Type=AName=호스트 네임Value=호스트 네임에 대한 IP 주소
if Type = A | Name=호스트 네임 | Value=호스트 네임에 대한 IP 주소 |
if Type=NS | Name=도메인 | Value=authoritative DNS 서버의 호스트 네임 |
if Type=CNAME | Value=별칭 호스트 네임 Name에 대한 정식 호스트 네임 | |
if Type=MX | Value=별칭 호스트 네임 Name을 갖는 메일 서버의 정식 이름 |
한 DNS 서버가 책임 서버이면, Type A 레코드를 포함한다
DNS 메시지
- 12byte-헤더 영역
- 식별자 필드: 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별
- 플래그 필드
- 질의/응답 플래그: 메시지가 질의(0)인지 응답(1)인지 구별
- 책임 플래그: DNS 서버가 질의 이름에 대하여 책임 서버일 때 응답메시지에 설정 됨
- 재귀 요구 플래그: DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정
- 재귀-가능 필드: DNS 서버가 재귀 질의를 지원하면 응답에 설정 됨
- 질문의 수
- 답변 RR의 수
- 책임 RR의 수
- 추가 RR의 수
- 질문 필드(영역): 현재 질의에 대한 정보를 포함
- 이름 필드(질의되는 이름을 포함) + 타입 필드(이름에 대해 문의되는 질문 타입을 나타냄)
- 답변 필드: 원래 질의된 이름에 대한 자원 레코드를 포함
- Type,Value,TTL
- 응답으로 여러 개의 RR을 보낼 수 있음
- 호스트 네임은 여러 개의 IP주소를 가질 수 있기 때문
- 책임 필드: 다른 책임 서버의 레코드를 포함
- 추가 필드: 다른 도움이 되는 레코드를 포함
- ex) Type A 레코드
확인
nslookup
bns1.hananet.net: SK Broadband의 DNS서버
DNS 데이터베이스에 레코드 삽입
- 도메인 네임 networkutopia.com을 등록기관에 등록하려고 함
- 등록기관
- 도메인 네임의 유일성을 확인
- 주책임 서버와 부책임 서버의 이름과 IP주소를 등록기관에 제공해야
- 주 책임 서버 이름: [dns1.networkutopia.com](http://dns1.networkutopia.com) dns2.networkutopia.com
- IP주소: 212.212.212.1 212.212.212.2 (networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A) 이걸 등록함
'컴퓨터 네트워크 > Ch2. 애플리케이션 계층' 카테고리의 다른 글
6. 비디오 스트리밍과 콘텐츠 분배 네트워크 (0) | 2023.03.22 |
---|---|
5. P2P 파일 분배 (0) | 2023.03.22 |
3. 인터넷 전자메일 (0) | 2023.03.22 |
2. 웹과 HTTP (0) | 2023.03.22 |
1. 네트워크 애플리케이션의 원리 (0) | 2023.03.22 |