DNS

DNS

domain name system

Internet host와 router를 식별하기 위한 식별자

• 사람이 IP 주소로 식별하기엔 어려워서 도메인 주소 체계가 만들어짐
• 32 BIT

Distributed Database를 이용

• 많은 name server의 계층 구조로 구현된 분산 데이터 베이스

Application-layer의 protocol로 구현됨

• host, name server는 이름을 확인하기 위해 application layer에서 구현된 기능을 사용
• 모든 network application에 의해 사용되는 application 계층 protocol

 

DNS가 제공하는 기능

host aliasing

• 별명과 실제 이름을 맵핑해줌 ( hostname to IP address translation )

mail server aliasing

load distribution

• 외부에서는 여러 서버를 하나의 이름으로 접속할 수 있도록 지원. IP 주소에 따라 서버 분배

 

 

Centralized DNS

단점  => 이러한 이유로 실제로는 decentralized DNS를 이용

• single point of failure : 하나가 잘못되면 전체가 무너짐
• traffic volume
• distant centralized database : 멀리 있는 사람에게 느리게 도착
• 규모 확장 불가 (계층화로 해결 가능)

장점

• 유지보수
• 한 쪽에서 관리하니까 관리는 쉬움
• 최적의 결과 산출 가능

 

Distributed, hierarchical database

• 가령 client가 www.amazon.com의  IP를 알고싶다면
  • Root DNS server로 쿼리를 전송
  • .com을 담당하는 TLD server를 통하여 
  • amazon.com을 담당하는 Authoritative domain server로 가서 
  • IP 주소를 가져옴

 

+) TLD : TOP LEVEL DOMAIN SERVER

 

 

 

 

한국의 DNS

root > TLD (국가/일반)

Local DNS name server

쿼리문이 들어오면 root dns server로 가지 않고 local dns server로 전송

이곳에 name-to-address가 이미 있다면 여기서 처리하여, 마치 proxy server처럼 작동

• 계층 구조에 엄격하게 속하지 않음
• 각 ISP에 하나씩 가지며, 이를 default name server라고도 부름
• 모든 DNS query는 여기로 옴. proxy처럼 일함

 

Root name server

• local server로부터 받은 쿼리문을 처리 

• 전 세계적으로 13개의 logical root name server가 존재
  • logical이라고 하는 이유는 복제본이 많기 때문

• authoritative name server로부터 맵핑 정보를 알아내어, local name server에게 그 결과로 응답

 

 

TLD server, Authoritative servers

TLD (top-level-domain server)

• 맵핑 정보 자체를 제공 X
• com, org, net 등의 신뢰할만한 상위권 국가 도메인을 담당
  • .com은 Network Solutions 기관이 담당
  • .edu는 Educause가 담당
  • .kr은 KRNIC 한국인터넷정보센터가 담당

 

Authoritative DNS server

• 맵핑 정보를 실제적으로 제공하는 서버
• 해당 기관 자체의 DNS 서버
  • 조직 구성원인 host에게만 hostname-IP 맵핑을 제공
• 기관에서 유지보수 및 서비스 제공

 

+) 덧붙임

DNS server hierarchy에서

가장 아래에 해당하는 server는

authoritative name server이고,

local DNS server는

DNS server hierarchy에 해당하지 않는다.

 

 

---

DNS name resolution example

DNS 이름을 reserve하는 방식

<iterated query>

• 쿼리를 받은 DNS 서버가 맵핑 정보를 알지 못하는 경우에 물어볼 서버를 사용자에게 알려줌
• local DNS 서버가 caching하고 있지 않은 host name에 대한 query가 들어왔을 때,
• local DNS 서버가 root, TLD, authoritative server 순으로 차례로 query를 직접 보내야만
• query resolution이 이루어지는 query 해결 방법

 

• local DNS server에게 해당 도메인의 IP주소에 대해서 물음
• local이 몰라서 root에게 물었는데 모른다고 하면
• local이 TLD server에게 물었는데 모른다고 하면
• local이 authoritative server에게 물어봄
• 답을 찾으면 local이 요청한 host에게 그 답을 전달

 

장점은 local이 바쁘지만, 데이터를 많이 가지고 있어 빠르게 받을 수 있음

 

 

<recursive query>

• 요청받은 server가 맵핑 정보 자체를 구해서 응답
• 누구에게 물어볼지 알려주는 것이 아니라 자신 다음에 누구에게 물어볼지 정해져 있어 후속 서버에게 이후의 쿼리를 맡김

 

• 위쪽 계층일 수록 일이 몰림 (특히 root)

 

 

 

---

DNS caching - updating records

DNS의 name 서버들은 맵핑 정보를 학습하는 대로 한 동안 캐싱을 함

TTL(time to leave) 시간 동안 유지되고 이후에 자동으로 없어짐

local name 서버에 TLD 서버를 캐싱하고 있어 root name server를 방문하는 횟수를 줄임

 

모든 local name server 가 root에게 전달하려면 root에서 넘침

이를 방지하기 위해 각종 TLD 서버가 무엇인지 캐싱

 

DNS의 root name server 로드를 줄이기 위해

local name server에 일반적으로 caching하는 name server

== TLD server

 

캐시를 사용하면 최신 데이터가 아닐 수 있다는 단점이 있음

이를 방지하기 위해 IETF 의 RFC 2136에서 update/notify 메커니즘을 제안

맵핑 정보 변경이 일어났을 때 무조건 인터넷 entity에게 알리는 것

 

 

DNS records == Resource Record

name value 실질적인 정보

type 어떻게 해석할것인지 지정되는 요소 - 4종류

• A
  • name == hostname
  • value == IP address
• NS
  • name == domain
  • value == 그 domain의 authoritative name server의 hostname
• CNAME 
  • name =alias name(www.ibm.com)
  • value=canonical name(servereast.backup2.ibm.com)
• MX 
  • name = domain
  • value = 그 domain의 mail server의 hostname

ttl 얼마동안 그 entry를 유지할지

 

 

 

 

DNS protocol, messages

DNS protocol은 query와 reply가 동일한 message format을 사용

 

identification 

• 16bit for query
• 쿼리가 실어서 보낸 id를 그대로 실어 줌으로써 어느 쿼리의 응답인지 짝지음

flag

• query인지, reply인지 확인
• recursion을 해주면 좋은지, 
• DNS 서버 측에서 설정하는 bit
  • 서버가 recursion이 가능한지
  • 응답이 available한지
• a. query or reply 
• b. reply is authoritative 
• c. recursion desired 
• d. recursion available 

 

 

(RR : Resource Record)

question : name, type fields for a query

• 쿼리의 경우 여기에 쿼리에 대한 이름과 종류 

answers : RRs in response to query

• 쿼리에 대한 응답을 여기에

authority : records for authoritative servers

• reply 보내는 서버가 authoritative server라면 여기에 실음

additional info : additional “helpful” info that may be used

• 추가적으로 도움이 될 것같은 정보도 담음

 

---

 

Inserting records into DNS

새로운 회사가 어떻게 인터넷에 등장하는지 그 절차 알아보기

 

처음 회사가 만들어졌을 때, 

 

회사의 웹서버를 인터넷에서 볼 수 있도록 하고 

 

외부에서 회사로 이메일을 보낼 수 있도록 하기 위해서는

회사에 authoritative name server를 두고 

거기에 회사 웹서버에 대한 type A RR와 

회사의 mail server의 domain name에 대한 MX type의 RR 및

 메일서버에 대한 type A RR를 저장하고, 

 

DNS registrar 역할을 하는 등록 기관에는 

회사의 authoritative name server의 name과 IP 주소만을 등록하면 된다.

 

새로운 회사의 등록을 받은 DNS registrar 등록 기관은 

회사가 DNS에 등장하도록 하기 위해 

 

회사 domain을 담당하는 authoritative name server 이름을 저장한 type NS RR과 

authoritative name server에 대한 type A RR를 

TLD 서버에 저장한다.

 

 

-----

 

네트워크 유토피아라는 회사가 탄생했다면

먼저 회사의 도메인 이름을 정함 (networkutopia.com)

회사라서 .com을 담당하는 기관인 Network Solutions에 등록 (DNS registrar)

이 기관은 그 도메인이 사용가능한지 판별

 

또한 authoritative name server(primary와 secondary 모두)의 ip 주소와 도메인 이름을 등록

 등록기관은 .com TLD server에 RR 두개를 추가

 A type record for www.networkutopia.com(웹/메일) 와

MX type record for networkutopia.com(메일 서버의 도메인이름)를

authoritative server에 생성

 

 

 

회사의 네트워크 내에 서버 설치

 

회사의 웹 서버 host의 IP 주소를 묻는 쿼리가 들어오면

회사 도메인을 담당하는 authoritative server가 응답할 수 있도록

그 웹서버의 IP 주소를 저장하는 타입 A를

자신의 authoritative auth server에 저장

 

외부로부터 내부 구성원에게 메일이 올 수 있도록

메일 서버를 묻는 쿼리를 발생시켰을 때 응답하기 위해

MX타입의 이름도 저장되어 있어야 함

 

회사 내에 최소한

authoritative name server, 웹 서버, 메일 서버를 배치해야 하며

웹 서버용 IP 주소를 저장한 타입 A record,

메일 서버를 알려주는 MX record,

그리고 authoritative name server에 자신의 도메인에 존재하는 여러 서버들을 등록

 

 

Accessing Web Page of Network Utopia

 

1. authoritative DNS server에 각 서버에 대한 RR 준비

• type A RR - web server
• type MX RR for mail server
• type A RR for mail server

2. 회사의 authoritative name server와 DNS server를 위해

Network Solution (.com DNS registrar)에 NS RR과 A RR을 등록

 

3. DNS client가 회사 URL로 접속 시도

4. Local Name server로 해당 Domain에 대한 IP 주소를 물어봄   

5. 거기서 추천한 .com TLD DNS server로 감   (cache으로 root 안 거치고도 .com을 바로 알았나 봄)

6.  이후에 어디로 갈 지 응답

7. authoritative DNS server로 가봄 

8. IP주소 찾았음

9. client에게 알려줌

10. 회사 web server에 찾은 IP 주소로 접근