DNS 패킷 구조

192.168.0.114가 205.152.39.23에게 Query를 던짐(wireshark.org의 IP 주소를 알려줄래?)

205.152.39.23 패킷을 클릭하면 answer가 있음

DNS(Domain Name System)

기본 설정 DNS 서버와 보조 DNS 서버

=> DNS서버는 1개 또는 2개를 셋팅

=> 이 부분은 DNS 클라이언트가 작성

=> 기본과 보조는 무슨 차이일까?

보통 기본을 Master, 보조를 Slave라고 생각하는 경우가 있는데 아님!!!

기본은 사내망에서 운영하는 DNS 서버주소

보조는 ISP(통신사업자)에서 운영하는 DNS 서버주소

=> 사내망 서버가 다운될 경우를 생각해서 2개를 설정

=> 이거 클라이언트가 설정하는 것!

cmd 창에 명령어 입력

> nslookup www.naver.com

=> 집에서는 통신사업자의 DNS 서버를 사용하고 있음을 확인

=> 회사의 경우 회사 DNS 서버를 셋팅해서 사용하는 경우가 많음

DNS 서버의 트리 구조

새로운 도메인명이 많이 생김(com, net, biz...)

DNS 구조 및 프로세스

=> 파란색은 전부 dns 서버라고 생각하면 됨

=> dns구조는 분산되어 있음; 분산계층 데이터베이스

=> Root Level, Top Level Domain(TLD) ...

=> TLD 라는 용어는 자주 사용함

Root-Level은 국가 관련 도메인, 기업/사업적 도메인을 관리해주는 dns server들의 주소를 가지고 있는 server들

TLD는 특정 도메인을 관리하는 DNS 서버 주소를 알고 있음

DNS Name Resolution

DNS Server에게 서비스를 받는 애들을 DNS Client라고 함

DNS Client가 www.idc2000.net의 IP를 모르는데 그걸 알고 싶음

=> IP를 알아내는 과정을 DNS NAME Resolution이라고 함

Client는 Server에게 IP 요청! 이 요청을 Recursive Query 라고 함

=> DNS 클라이언트가 TCP/IP 등록정보에 DNS Server를 등록해 놓음

IP를 알기 위해 DNS Server는 Root Name Server 여러 대 중 한대로 가서 너 www.idc2000.net의 IP를 알아? 라고 질의

=> Root Name Server는 ORG/NET/COM/KR 등을 관리하는 서버들의 주소들을 알고 있음

=> 특정 컴퓨터 즉, www.idc2000.net의 IP를 아는 것이 아니라 net을 관리해주는 DNS Server들의 IP를 알고 있음

=> net을 관리해주는 DNS Server들의 IP를 알려줌

DNS Server는 TLD(Top-Level Domain)로 이동하여 너 www.idc2000.net의 IP를 알아? 라고 TLD에게 질의

=> TLD(Net)의 답변 : 내가 net 관리하는 애들은 아는데 www에 대해서는 잘 몰라. idc2000.net의 ip는 알고 있어

DNS Server는 idc2000.net 도메인을 관리하는 Second-Level Name Server로 가서 너 www.idc2000.net의 IP를 알아? 라고 질의

=> Second-Level Name Server 답변 : 어, 그거 우리 사이트의 호스트명인데 그거 내가 관리해. 자 여기 IP 주소야

DNS Server는 받은 IP를 DNS Client에게 전달

* DNS Client가 사용하는 DNS Server는 Root Name Server의 주소를 가지고 있음

[!!질문!!]

● 질의 응답 과정은 UDP로 운영됨. 왜 TCP가 아닌 UDP일까?

많은 DNS 서버 중에 한대에게 물어봄. 근데 TCP로 운영하는 경우 그 한대가 대답을 안했다면 계속해서 그 한대에게 질문을 하는 것!! UDP의 경우는 한대가 대답을 안했다면 다른 애한테 물어봄. 그래서 UDP로 운영함

=> Name Resolution 과정은 UDP로 운영

● 매번 이렇게 질의하면 시간이 너무 오래 걸리지 않나??

한번 질의해서 응답해놓은 것을 DNS 캐시에 저장해놓음

나는 gildong.com이라는 회사의 직원인데 www.open.net에 접속하려고 함

내가 지정해놓은 DNS 서버를 Master Name Server라고 함.

=> Master Name Server는 원래 우리 회사의 도메인을 관리하고 있는 서버

=> www.gildong.com(1.1.1.1), dhcp.gildong.com(1.1.1.2), smtp.gildong.com(1.1.1.3), ftp.gildong.com(1.1.1.4) 등을 관리

=> www.open.net(2.2.2.2)는 우리회사 도메인이 아니기 때문에 Master Name Server에서 관리하지 않음

open.net 앞에 있는 Authoritative Name Server도 Master Name Server라고 할 수 있음(open.net 거)

=> 이곳에는 open.net에 대한 정보만 가지고 있음

gildong.com 직원이 www.open.net을 요청한 경우 DNS Resolver는 Root Name Server에 질의

=> Root Name Server의 답변 : www.open.net에 대한 전체 IP는 모르겠고 net을 관리하는 DNS Server를 알려줄게

DNS Resolver는 TLD에게 또 질의

=> TLD의 답변 : 난 open.net를 관리하는 DNS Server를 알아

DNS Resolver는 Second Level Server에 질의

=> Second Level Server 답변 : 내가 관리하는 거야. IP를 알려줄게

우리 회사에서는 Cache Name Server를 따로 관리하고 있음

=> 우리 회사 주소는 아니지만 한번 Name Resolution 했던 것을 기록해놓음

=> 보통 회사에서는 2개의 dns 서버를 구성함

* Master Name Server : 사내 서버들의 IP들을 등록

* Cache Name Server : 외부 사이트들의 주소들을 등록, Name Resolution이 진행된 사이트들의 주소를 기록

Slave Name Server는 Master Name Server에 있는 정보들을 백업시켜놓는 곳

즉, Master Name Server가 다운되었을 경우, Slave Name Server가 Master가 될 수 있도록 해놓는 것

이 둘 사이는 네트워크로 전송되는데 이때 tcp로 진행

!!명칭!!

Local Name Server(= Recursive Name Server = Cache Name Server)

- 사용자 호스트로부터 질의가 들어오면 자신의 캐시에 저장된 정보 또는 반복적 질의를 통해 그 결과를 사용하 호스트에게 응답

- 일반적으로 ISP 업체가 제공 ex) KT

Master Name Server

- 특정 도메인에 대한 정보를 관리하면서 해당 도메인에 대한 질의만 응답하는 네임서버

- 각 회사/사이트 별로 자신의 도메인을 관리하는 DNS 서버

- 네임서버가 관리하는 도메인 영역을 존(zone)이라 함

- zone file : 관리 도메인에 대한 정보를 담고 있는 파일

DNS Server 설치 영역

방화벽을 기준으로 왼쪽은 내부망, 오른쪽 외부망, 아래쪽 DMZ 구간

보통 DNS 서버는 보통 DMZ구간에 설치

그런데 직원용 DNS 서버를 따로 구성할 수 있음!

=> 인트라넷 안에!

=> 로그 분석을 할 때는 사내망에 있는 DNS서버를 분석

DNS 53 UDP/TCP

- DNS는 53번 포트 사용

- 상황에 따라 UDP/TCP 사용

- 응답메시지의 크기가 512보다 작으면 UDP 사용(UDP 패키지의 크기가 최대 512 byte로 제한되기 때문에)

- 응답메시지의 크기가 512보다 크면 TCP 사용

- 대부분의 패킷이 UDP 사용

DNS Header Structure

보통 DNS 헤더가 payload되면 UDP 헤더 부착됨

다음에 IP 헤더가 부착되고 payload됨