DNS

TCP/IP 초기 네트워크 시스템 접근

다른 시스템에 접근할 때 IP주소(숫자 형태)를 이용하여 접근 한다.
다수의 목적지 시스템이 생겨나면서 사용자가 직접 시스템의 주소를 기억하기 힘들어 졌다.
사용자가 쉽게 기억할 수 있는 문자 형태의 값을 사용 한다. -> hostname

hosts 파일

특정 IP주소로 정의되어 있는 도메인 주소에 대한 정보를 보관하는 로컬 파일 -> 이름 해석
사용자가 직접 기억하지 못하는 다수의 hostname과 IP주소의 쌍을 지정하는 시스템 파일
SRI-NIC(Network Information Center)에서 관리하며 ㅈ기적으로 배포했다(현재는 X)

dns1

Linux hosts 설정 파일

/etc/hosts

dns2

hosts 파일 문제점

급격히 증가하는 호스트에 대한 관리 문제가 발생 한다.
파일의 크기가 증가하면서 업데이트 시 트래픽을 증가 시킨다.
호스트의 정보가 갱신될 때 마다 모든 호스트가 파일을 업데이트 해야 한다.
해결책 -> DNS(Domain Name System)

DNS (Domain Name System)

hosts파일을 통한 주소 해석의 한계를 해결하기 위해 1983년에 개발 되고 1984년 도입된 시스템
iIP주소에 해당하는 문자 형태의 주소(도메인 이름)를 해석하기 위한 일련의 시스템 구조 및 동작
Server에서 해석에 관련된 모든 Data를 가지고 있고 Client의 질의가 있을 때 응답 한다.
네트워크 시스템이 복잡해 지면서 주소의 체계적인 구조가 필요하게 됐다. -> 계층적인 Tree 구조 형태
- 상위 도메인은 하위 도메인에 대한 정보만 유지/제공 한다.
- 분산 데이터베이스 시스템 -> 확장성 제공
체계적인 관리를 통해 이름의 중복이 발생하지 않도록 관리 한다. ->유일성 유지
TCP/UDP port 53
- TCP port 53 -> 영역 전송(Zone Transfer)
- UDP port 53 -> 일반 질의

Domain

논리적인 하나의 관리 영역
각 도메인은 해당하는 도메인 이름(Domain Name)을 가진다 -> DNS Zone

Domain 주소 형식

주소의 영역을 옥텟(.)으로 구분한다. -> 라벨(label)
- 하나의 라벨은 최대 63개의 문자(63byte)크기를 가진다
- 대소문자 구분 없이 알파벳, 숫자, - 만 가능 하다 -> ASCII로 표현 한다.
- root는 크기 0인 NULL 문자
전체 도메인 주소의 최대 크기 -> 255 문자(255byte)
오른쪽에서 왼쪽으로 나열 한다. -> 최상위 주소는 항상 .(root)

dns2

Name Space

Domain 주소의 계층적인 구조
확장성과 유연성을 제공할 수 있도록 구조화 되어 있다.
위임 체계를 기반으로 분산 구조를 형성 한다.
표준 관리 기관 -> IANA(Internet Assigned Numbers Authority)
- 각 대륙 별 산하 관리 기관 -> RIR(Regional Internet Registry)
- RIR에서 각 국가별 관리 권한 위임
국내 관리 기관 -> KISA 산하의 KRNIC

dns4

Name Space 구조

Root Domain -> 최상위 도메인 -> 2차 도메인 -> 서브 도메인 -> …

dns5

루트 도메인 (Root Domain)
- NAME Space에서 이름 해석의 출발지 역할을 수행하는 서버
- 최상위 도메인 서버의 정보를 가지고 있다.
- 전 세계에 13개의 원본 root 서버가 존재한다.
최상위 도메인 (Top Level Domain = TLD)
- 지정학적 분류, 기관 유형 분류 등
- 국가 코드 최상위 도메인(country code TLD = ccTLD)
  - .kr, .jp, .cn, .us, .uk
- 일반 최상위 도메인(generic TLD = gTLD)
  - Generic gTLD -> .net, .com, .org …
  - Sponsored gTLD -> .areo, .asia, .edu, .gov, .int …
  - Generic-Restricted gTLD -> .biz, .name, .pro …
- 국제화된 국가코드 최상위 도메인(internationalized country code TLD = IDN ccTLD)
  - 한글 도메인 등
- ARPA
  - 역방향 도메인을 해석할 때 사용되는 최상위 도메인 -> in-addr.arpa
2차 도메인(Second Lever Domain, Sub Domain)
- TLD 하위에서 관리되는 서브 도메인
- 국가 도메인 하위에 기관 유형별 분류
  - co(일반회사), ac(교육기관), re(연구기관), go(정부기관), nm(네트워크 관리) …
서브 도메인 (Sub Domain)
- 상위 도메인에 소속되는 각 기관 또는 회사별 도메인
- 하위 도메인으로 호스트 또는 내부 조직 도메인이 구성될 수 있다.
  - google, naver, daum …

dns6

리졸버 (Resolver)

도메인 주소 해석을 수행하는 작은 프로그램
- OS에 기본적으로 탑재되어 있는 S/W 라이브러리 형태의 루틴
- Application의 도메인 주소 해석 요청을 처리 한다.
리졸버에 정의되어 있는 순서대로 도메인 주소 해석을 처리한다.
- Client: Hosts 파일 -> DNS Cache -> DNS server에게 질의(또는 해석 실패)
- Server : Zone 파일 -> DNS Cache -> 반복 질의(또는 해석 실패)

dns7

네임 서버(Name Server)

클라이언트의 요청에 대한 이름해석 결과를 전달하는 시스템
- Name Space에 관련된 Resource Record를 저장하고 있는 서버
Domain 정보 Database = Zone File
- 서버가 동작하면서 Zone File에 등록된 RR 정보를 메모리에 데이터베이스 구조로 저장 한다.

dns8

네임 서버(Name Server) 종류

주 네임 서버(Master Name Server, Primary Name Server)
- Zone Database를 직접 구성하는 서버
- Zone Database에 대한 구너한을 가지고 있는 서버
보조 네임 서버(Slave Name Server, Secondary Name Server)
- Master(primary) Name Server의 Zone에 대한 정보만 동기화 받는다.
- 주기적인 동기화과정을 통해 Master 서버와 동일한 정보를 유지한다.
다수의 보조 네임 서버를 운영할 수 있다.
전달자(Forwarder)
- 실제 Zone에 대한 정보를 가지고 있지 않지만 클라이언트의 요청을 대신 해석하는 역할을 수행하는 서버

Zone 저옵 동기화(Zone Transfer) = 영역 전송

마스터 네임서버에서 구성된 Zone 정보를 보조 네임서버가 복사하여 정보를 동일하게 유지하는 과정
- 동기화 크기가 클 경우 압축을 수행 한다.
- 기본적으로 보조 네임 서버가 먼저 동기화 요청을 한다.
TCP port 53 -> 동기화의 신뢰성을 보장한다.
종류 -> AXFR(Authoritative Transfer), IXFR(Incremental Zone transfer)

dns9

AXFR(Authoritative Transfer)
- 기본적인 영역 전송 방법
- 보조 네임서버가 저정된 주기(refresh)에 따라 serial 정보 요청을 전달 한다.
  - serial 값 -> zone 정보의 갱신, 수정, 삭제 등이 일어났을 때 증가 된다.
- 마스터 네임 서버가 zone의 serial 정보를 전달 한다.
- 보조 네임서버에서 설정된 serial 보다 증가되었음을 확인하려면 zone 전체 종기화(AXFR_)를 요청 한다.
- 마스터 네임 서버는 요청받은 zone의 모든 정보를 전달 한다.
- 문제점 -> Refresh의 주기 때문에 동기화 지연 시간이 발생 할 수 있다.
IXFR(Incremental Zone transfer)
Zone에 대한 전체 정보가 아닌 변경된 내용만 전송 받는 동기화 방식
- 동기화 과정에서 발생하는 네트워크 트래픽 부하를 줄인다.
Notify 메시지와 함께 사용된다.
마스터와 보조 네임서버 둘 다 IXFR 방식을 지원해야 한다.
UDP/TCP port 53을 선택적으로 이용할 수 있다.

Notify

기본적인 AXFR 동기화의 지연 시간 문제점을 해결
Zone의 변화가(serial 값) 발생하면 마스터 네임 서버가 Notify 메시지 전달
- Zone의 변화를 신속하게 동기화 할 수 있다.
Notify 메시지를 전달 받으면 마스터 네임 서버에 SOA를 요청한다.
보조 네임서버에서 설정된 SERIAL 보다 증가되었음을 확인하면 zone 동기화(AXFR/IXFR)를 요청 한다.
마스터 네임 서버는 요청 받은 zone의 정보를 전달(AXFR/IXFR) 한다.

DNS 기본 동작

질의 (Query)
클라이언트에서 정보를 요구하는 과정
응답 (Answer)
서버ㅏ 클라이언트 질의에 해당하는 정보를 전달하는 과정
질의 종류
재귀 질의 (Recursive Queries)
요청한 서버로부터 응답을 직접 받는 질의
밥복 질의 (Iteratice Queries)
하나의 질의에 대해 여러 서버를 순서대로 반복적으로 거쳐서 응답을 받는 질의 방식
응답 종류
- 권한 있는 응답 (Authoritative Answer)
  - Zone 정보를 가지고 있는 서버가 직접 전달하는 응답
- 권한 없는 응답 (Non-authoritative Answer)
  - Cache에 저장되어 있는 data를 이용하여 전달받은 응답
빨리 처리될 수 있는 정보를 우선적으로 사용 한다.
DNS Client의 질의 처리 순서
- Application으로부터 도메인 해석 요청을 받았을 때
- Cache 정보 -> Hosts 파일 -> DNS Server Query -> 해석 실패
DNS Server의 질의 처리 순서
- Client의 Query를 전달 받았을 때
- Cache 정보 -> Zone 파일 -> Root Hint -> 해석 실패

DNS Query

재귀 질의 (Recursive Query)
- 클라이언트가 질의를 전달한 서버가 직접 응답을 전달하는 방식
재귀 질의가 수행되는 경우
- 클라이언트의 질의 -> 네임 서버의 캐시의 정보가 존재 한다. -> 응답
- 클라이언트의 질의 -> 네임 서버의 zone에 정보가 존재 한다. -> 응답
- 클라이언트의 질의 -> 네임 서버에 zone 정보가 없다.
  - Root Hint 설정 -> 반복적 질의 -> 응답
  - Root Hint 설정이 없다 -> 해석 실패 -> 에러 메시지 응답
재귀 질의 메시지
- 재귀 요구
  - DNS 요청 메시지의 필드 중 RD =1
- 재귀 응답
  - DNS 응답 메시지의 필드 중 RA = 1
재귀 질의 (Recursive Query) - 1

dns10

재귀 질의 (Recursive Query) - 2

dns11

재귀 질의 (Recursive Query) - 3

dns12

DNS Query

반복 질의 (Iterative Query)
- 하나의 질의에 대한 해석을 한 번의 질의와 응답으로 완료하지 않고 Root부터 계층적 순서로 반복적으로 최종 응답을 전달하는 방식
- 클라이언트의 요청을 직접 받은 네임서버에서 동작
  - <b style”color:red”>Root Hint 설정</b>이 되어 있어야 한다.
  - Root 네임 서버에 접근하기 위한 정보를 가지고 있어야 한다. -> named.ca
Root Hint
- 내부에서 ㅎ해결하지 못한 질의를 등록된 Root 부터 반복질의를 통해 해결하는 방식
- 반복질의 활성화 가능
반복 질의 (Iterative Query)

dns13