Reference :
컴퓨터 네트워킹 하향식 접근 [8판] / 퍼스트 북 / James F. Kurose, Keith W. Ross
건국대학교 컴퓨터 네트워크 수업 / 김기천 교수님
DNS-인터넷의 디렉터리 서비스

사람을 여러가지 방법으로 식별할 수 (이름, 주민번호) 있는 것처럼, 인터넷 호스트도 마찬가지다.

호스트에 대한 하나의 식별자는 호스트 네임이다.

호스트 네임은 가변 길이의 알파뉴메릭(영숫자) 문자로 구성되므로 라우터가 처리하는 데 어려움이 있어서 호스트는 IP주소로도 식별된다

DNS가 제공하는 서비스

https://namu.wiki/w/DNS

 

DNS - 나무위키

DNS 서버가 질의 받은 도메인 또는 IP 주소의 레코드를 Forward Zone, Reverse Zone 중 하나 이상 가지고 있지 않을 경우에 하는 응답이다. 도메인의 네임 서버에 해당 도메인을 구성하지 않은 호스트, 즉

namu.wiki

사람의 好: 기억하기 쉬운 호스트 네임

라우터의 好: 고정길이의 계층 구조를 가진 IP주소

절충: 호스트 네임을 IP주소로 변환

⇒ DNS

 

DNS의 간단 개념

  1. Domain Name System
  2. DNS 서버들의 계층구조로 구현된 분산 DB
  3. 호스트가 분산 DB로 질의하도록 허락하는 애플리케이션 계층 프로토콜
  • 특징
    • BIND 솦웨를 수행하는 유닉스 컴퓨터
    • UDP상에서 수행 & 53번 포트 이용
    • 클라이언트-서버 구조로 통신하는 종단 사이에서 수행
    • 통신하는 종단 시스템 사이에서 DNS 메시지를 전달하기 위해 하위 종단 트랜스포트 프로토콜에 의존함⇒애플리케이션 계층 프로토콜
  • 이용
    • 다른 애플리케이션 프로토콜들이 HTTP,SMTP,FTP 등 사용자가 제공한 호스트 네임을 IP주소로 변환하기 위해 주로 이용
    • 어떤 사용자의 호스트에서 수행되는 브라우저가 URL을 요청할 때 호스트가 HTTP 요청 메시지를 웹 서버로 보낼 수 있게 하기 위해 사용자 호스트는 호스트의 IP주소를 얻어야만 한다.

💡 호스트 네임: `www.naver.com` URL: `www.naver.com/login`

  • 과정
    1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다
    2. 브라우저는 URL로부터 호스트 네임을 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘긴다
    3. DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다
    4. DNS 클라이언트는 결국 호스트 네임에 대한 IP주소를 가진 응답을 받게 된다
    5. 브라우저가 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 동작 원리 개요
  1. 변환될 호스트 네임을 명시하여 DNS측의 클라이언트를 호출 gethostbyname()
  2. 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다
  3. 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다
  4. 수 msec~수 sec의 지연 후에 사용자 호스트의 DNS는 요청한 매핑에 해당하는 DNS 응답 메시지를 받는다.
  5. 이 매핑은 호출한 애플리케이션으로 전달된다

문제

클라이언트가 모든 질의를 단일 네임 서버로 보내고, DNS서버가 질의 클라이언트에게 직접 응답하는 방식에서는 다음과 같은 문제가 발생한다

  1. 서버의 고장: 이 네임 서버가 고장나면, 전체 인터넷이 작동 X
  2. 트래픽 양: 단일 DNS 서버가 모든 DNS 질의를 처리해야 한다
  3. 먼 거리의 중앙 집중 데이터베이스: 단일 DNS서버가 모든 질의 클라이언트로부터 가까울 수는 X
  4. 유지관리: 단일 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 레코드를 갖고 있다

과정

  1. 호스트 네임의 IP주소를 알고 싶음
  2. 클라이언트는 루트 서버 중 하나에 접속함
  3. 루트 서버는 최상위 레벨 도메인을 갖는 TLD 서버 IP주소를 보낸다
  4. 클라이언트는 이 TLD 서버 중 하나에 접속하고 서버는 도메인을 가진 authoritative 서버의 IP주소를 보낸다.
  5. 클라이언트는 도메인의 authoritative 서버 중에서 하나로 접속한다.
  6. 서버는 호스트 네임의 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 데이터베이스에 레코드 삽입

  1. 도메인 네임 networkutopia.com을 등록기관에 등록하려고 함
  2. 등록기관
    1. 도메인 네임의 유일성을 확인
    2. 주책임 서버와 부책임 서버의 이름과 IP주소를 등록기관에 제공해야
      1. 주 책임 서버 이름: [dns1.networkutopia.com](http://dns1.networkutopia.com) dns2.networkutopia.com
      2. 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. 인터넷 전자메일  (1) 2023.03.22
2. 웹과 HTTP  (0) 2023.03.22
1. 네트워크 애플리케이션의 원리  (0) 2023.03.22

티스토리툴바