📚 Network
ㄴ 📒 Chap.2 Application Layer
ㄴ 📄 The Domain Name System DNS
📌 DNS : Domain Name System
Internet hosts, router는 IP 주소로 식별이 가능하지만 IP 주소의 길이는 32bit로 사람들이 서버의 IP주소를 기억하는 것은 어려운 일이다. 따라서, google.com과 같은 서버의 '호스트 이름'을 기억한다.
그렇다면, IP주소와 호스트 이름을 어떻게 mapping할 수 있을까? 🤷♀️
DNS(Domain Name System)
- DNS 서버들의 계층 구조로 구현된 분산 데이터베이스
- 호스트가 분산 데이터베이스를 질의하도록 허락하는 어플리케이션 계층 프로토콜
- 응용 계층 프로토콜로 구현된 핵심 인터넷 기능
• complexity at network’s “edge”
클라이언트의 웹 브라우저에서 웹 서버의 호스트 이름을
입력하여 웹 서버의 IP 주소를 얻는 절차는 다음과 같다.
-
DNS 애플리케이션의 클라이언트을 실행 (자체적으로 실행된다)
-
브라우저는 URL로부터 호스트 이름을 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트에 전달
-
DNS 클라이언트는 호스트 이름이 포함하는 질의를 DNS 서버로 보냄
-
DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 포함된 응답을 받음
-
브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 해당 IP 주소와 그
주소의 80번 포트에 있는 HTTP 서버 프로세스로 TCP 연결을 시작함
📌 DNS : services, structure
DNS service
-
호스트 이름을 IP 주소로 변환
-
호스트 엘리어싱 (host aliasing)
복잡한 정식 호스트 이름 대신 사용하는 별칭 호스트 이름을 정식 호스트 이름으로 변환해주는 기능ex) 정식 호스트 이름 : relay1.west-coast.enterprise.com
별칭 호스트 이름 : enterprise.com , www.enterprise.com -
메일 서버 엘리어싱
간단한 메일 서버 이름을 복잡한 메일 서버 이름으로 변환해주는 기능 -
부하 분산
중복 웹 서버 : 여러 개의 IP 주소가 하나의 호스트 이름과 매핑 -> 호스트 이름 : IP 주소 = 1 : N
DNS가 중앙 집중 방식이 아닌 이유는 무엇일까?
1. 서버의 고장
2. 트래픽 양
3. 먼 거리의 데이터베이스
4. 유지 관리
=> 확장성이 없다! DNS는 하루에 엄청난 단위의 서비스를 처리한다.
📌 DNS : 분산 계층 데이터베이스
Root - Top Level Doamin - authoritative 으로 연결되어 있다.
DNS client가 www.amazon.com의 IP주소를 처음 접근하여 요구한다고 가정하자.
-
클라이언트는 루트 서버에 질의하여 .com DNS 서버 (TLD 서버)를 찾는다.
-
클라이언트는 .com DNS 서버를 질의하여 amazon.com DNS 서버 (책임 서버)를 찾는다.
-
클라이언트는 www.amazon.com의 IP 주소를 얻기 위해 amazon.com DNS 서버에 질의한다.
📌 Root DNS 서버
- 로컬 DNS 서버가 호스트 이름을 확인하기 위해 접속한다.
- TLD 서버의 IP 주소 제공한다.
- 전 세계에 1,000개 이상의 루트 서버가 흩어져 있음
- ICANN (Internet Corporation for Assigned Names and Numbers)에서 루트 DNS 도메인을 관리
📌 TLD & 책임 DNS 서버
TLD : .com, .org, .net, .edu, .jobs, .museums, 혹은 국가 domain .kr, .cn, .uk, .fr, .ca, .jp들을 관리한다.
책임 DNS : 기관의 책임 DNS 서버는 기관의 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 서비스를 제공한다. 기관 또는 서비스 제공업체에 의해 유지 관리된다.
📌 로컬 DNS 서버
호스트의 DNS 질의는 기본적으로 로컬 DNS 서버로 전달된다. Web Cache와 비슷한 동작을 한다고 생각하면 된다. Root, TLD, 책임 DNS를 거치지 않고 같은 기관, ISP에서 로컬 DNS 서버가 응답을 해준다. (단, 최신이 아닐 수 있다)
-
프록시 역할을 수행하여, 질의를 DNS 서버 계층으로 전달한다. -> 로컬 DNS에 cache 안되어 있는 경우 전달
-
각 ISP에는 로컬 DNS 서버가 존재한다 :
- MacOS: % scutil --dns
- Windows: >ipconfig /all
로컬 DNS 서버는 엄격하게 계층적 구조에 속하지 않는다.
📌 DNS 반복적 호스트 이름 확인
Iterated query (반복적 질의)
임의의 host에서 google.com의 IP 주소를 요구하고 로컬 DNS 서버는 google.com이 cache 되어 있지 않다고 가정하자.
1) host는 로컬 DNS 서버에게 google.com의 IP 주소를 질의한다.
2, 3) 로컬 DNS 서버는 root DNS 서버에게 google.com을 질의하고 root DNS 서버는 TDL DNS 서버 주소를 알려준다.
4, 5) 로컬 DNS 서버는 다시 TLD DNS 서버에게 goole.com을 질의하고 TLD DNS 서버는 google.com의 책임 DNS 서버의 주소를 알려준다.
6, 7) 로컬 DNS 서버는 책임 DNS 서버에게 goole.com을 질의하고 책임 DNS 서버는 google.com의 IP 주소를 알려준다
8) 로컬 DNS 서버가 host에게 google.com의 IP 주소를 알려준다
아무런 정보가 없다면 root DNS 서버에 질의하지만 실제로는 TLD DNS 서버가 .com을 cache하고 있어 root DNS 서버에 질의하는 경우는 많이 없다.
📌 DNS 재귀적 호스트 이름 확인
Recursive query (재귀적 TLD DNS 서버 질의):
반복적 질의와는 달리 재귀적 구조를 가지고 로컬 -> root -> TLD -> 책임 -> TLD -> root -> 로컬과 같은 순서로 질의가 이루어진다. 이러한 구조에서는, 질의를 하고 응답이 올 때까지 대기를 해야하기에 root DNS 서버에 많은 부하가 걸리게 된다. 따라서, 실제로는 반복적 질의 방식을 많이 사용한다.
📌 DNS 캐싱
DNS 서버는 호스트 이름과 IP주소의 짝을 캐싱하여, 같은 질의에 대한 응답으로 캐시된 IP 주소를 즉시 전달한다.
-
응답 시간을 줄일 수 있다
-
특정 시간이 지나면 캐시가 삭제된다
-
TLD 서버는 기본적으로 캐시되어 있기 때문에 root DNS 까지 질의되지 않는다.
캐시된 DNS 확인 (Windows): >ipconfig /displaydns -
IP 주소가 변경된다면 캐시가 그대로 이므로 이전의 주소로 알려주게되어 캐시가 만료되어야 한다. 따라서, IP 주소가 진짜라는 보장은 없다.
📌DNS security
DNS가 마비되면 인터넷이 안된다. 따라서, DNS는 공격의 대상이 된다.
-
DDoS attacks : root , TLD sever에 대한 공격
-
Spoofing attacks : DNS 질의를 가로채 가짜 응답을 반환하도록 한다. 가짜 응답으로 DNS 서버에 가짜 DNS 레코드를 캐싱하도록 유도한다.
-
exploit DNS for DDos : 다수의 좀비 컴퓨터에게 책임 서버에 target IP에 대한 질의를 한다.
🔎 [참고 문헌]
Computer Networking A Top-Down Approach 7-th Edition / Kurose, Ross / Pearson
