application layer-4 (DNS)

domain name : 사용자의 편의를 위한 이름

ex) www.yahoo.com

IP address : datagram addressing할때 실제로 사용해야하는 주소

-> 보내기 전에 domain을 IP 주소로 변환한 후 보내야한다.

 

name servers

: mapping 정보 저장해놓은 것

: 하나의 centralized database가 아니라 distributed data base

  -> 이유 : 1) 한 군데로 집중되면 traffic voilume이 주변에 엄청 커질 것 + 2) 서버가 너무 멀면 delay 커지는 문제 생기는데 이를 방지 + 3) single point failure + 4) 서버 업데이트/작업할 때 모든 게 shut down 되는 걸 방지하기 위

 

DNS services

1. hostname(domain name) -> IP address로 translation

2. host aliasing

3. mail server aliasing

4. load distribution

  -> 유명한 웹서버는 복제된 웹서버들이 많은데 얘네들이 각각 분산해서 한 곳에 치우치지 않게 함

 

Root DNS server가 모든 걸 알고 있는 게 아니라 단계적으로 나아가는 hierarchical 구조이다.

Root DNS server : TLD 담당 서버가 누구인지 알고있다

  ->TLD란? ex) .kr, .com, .edu ...

TLD servers : 각 도메인에 속하는 사이트들의 name server 알고있다

Authoritative domain servers : 각 회사들의 DNS 서버

   ->우리가 알아내고자 했던 각자 자기 domain에 속하는 host들에 대해 걔네들의 IP 주소를 얘네들이 기억한다

 

client는 차례대로

1. root DNS server -> 2. TLD server -> 3. Authorative domain server 에 접속한다.

 

Root name servers

: client들이 가장 먼저 contact 한다

: 매우 중요! root가 attack 받으면 인터넷 마비된다.

 : DNSSEC는 보안을 담당

: ICANN -> root DNS 서버를 관리하는 기관

 

Top-level Domain (TLD) servers

: .com, .ent,...

:  각 기관을 담당하는 authorative name server 가 누구인지 알고 있다.

  -> 해당 domain 담당하는 authoritative DNS server 알려준

: TLD마다 TLD server 관리하는 기관이 다르다.

  ex) .com, .net -> Network Solutions / .edu -> Educause / .kr -> KRNIC

 

Authoritative DNS servers

: host name -> IP mapping 정보 가지고 있음

: 각 기관이나 service provider에 의해 관리된다

   (ex) 우리학교의 authoritative dns server를 이용해 여러 host들의 mapping을 관리 하고 있다)

 

+ 

Local DNS name servers

-> hierarchy에 들진 않지만 중요함. proxy 역할한다

: 최근 name-to-address translation pairs 를 cache 하고 있

: host가 어떤 name에대한 IP mapping 알고싶어서 request(DNS query)를 날리면 Local DNS name server에게 가장 먼저 간다 -> 얘가 알고 있으면 얘가 답을 하고 모르면 hierarchy system 쪽으로 query 날림

: 각 ISP (회사,기관)들이 가지고 있다

: TTL시간 동안 mapping 정보 저장해두고 있는다

: TLD server들이 cache 되어있다

: update/modify mechanism존재 (out of date 떄문)

 

 

이제부턴 DNS 쿼리 날렸을 때 DNS 쿼리가 어떻게 resolve되는지 절차를 살펴 볼 것이다

resolve 방식 두가지가있다.

 

1) iterated query

작동 방식 : I don't know this name, but ask this server 

3. 이 도메인에 대해서는 TLD 에게 물어라

5. 해당 도메인 담당하는 authoritative DNS server 알려줌

7에서 얻은 IP주소로 8에서 contact

-> client에 load가 집중된다

 

2) recursive query

iterative 방식의 문제를 해결하기 위해 hierarchy의 상단에 있는 "server쪽"으로 load 집중시킴

query 받은 서버가 책임지고 답해주는 형식

 

< 회사 세워졌을 때 회사가 전세계와 DNS로 어떻게 연결될까?

1. DNS registrar에게 자신의 도메인 네임인 networkuptopia.com을 등록한다. 이때 .com이므로 Network Solutions에 연락함

2. 자신의 authritative server의 name과 IP 주소를 알려주어 연결한다.

3. Registrar가 두 RR ( NS, A) 를 .com TLD server에 넣어둔다. (authoritative name, IP)

authoritative server에 웹서버 이름과 얘의 ip주소, mail server 이름과 그 ip주소 알려주어야함

 

<새 회사가 설립되었을 때의 절차 + 후에 host 가 접속하려하면 어떻게 진행되는지 과정>

1. 새 회사 탄생하면 authoritative DNS server, web server, mail server를 사야한다. 그리고 authritative DNS server에 웹서버의 name과 IP, mail server의 이름과 ip 저장해놓는다.

2. Network Solutions에 신청서 작성. authoritative name server의 이름과 ip를 알려줌. 그러면 Network Solutions는 .com TLD server에다가 NS와 A를 집어넣는다.

3. Alice가 이 웹서버에 접속하려함. 자신의 사이트에 있는 proxy(LDNS)에게 물어봄.

4. proxy에게 정보가 없어서 hierarchy에게 물어봄. LDNS는 .com TLD server를 caching하고 있기에 root한테 안 묻고 얘한테 물어봄

5. .com TLD가 authoritative를 알고 있으므로 얘의 NS와 A를 알려준다.

6. authoritative에 contact해 web server에 mapping되어있는 RR 받아와서 Alice host에게 보내주면 Alice DNS client가 이 정보 받게 된다

7. DNS client가 자신을 구동시킨 HTTP client에게 답해준다. 이로써 드디어 HTTP가 IP주소를 알게 되어 이 IP주소에게 TCP connection맺자고 할 수 있게 됨.