[컴퓨터 네트워크]-Application layer_DNS

 저번 정리글까지는 Application layer의 Web이라는 application과 HTTP라는 application protocol을 살펴 보았다. 이번 글에서는 DNS에 대해서 정리해보려고 한다.

---

1. DNS(=Domain Name System)

 저번 Application layer의 프롤로그 정리글에서, Internet hosts, router들은 IP 주소라는 식별자가 필요하다고 했다. 그리고, host들은 특정 이름 즉, 우리가 검색창에 검색하는 URL 주소를 가지고 있는데, 이를 Domain이라 한다. 그럼 이 URL주소와 IP 주소를 어떻게 Mapping을 해주는 것일까? 이때 Mapping을 도와주는 친구가 바로 이 DNS이다.

 

먼저 DNS의 특징에 대해서 알아보자. DNS 특징은 다음과 같다.

• name server들의 계층적 분산 DB 구조를 가지고 있다.
• application layer protocol: host는 DNS를 통해 name resolution 과정을 거쳐 Domain을 IP주소로 식별한다.

그렇다면 이 DNS가 제공하는 서비스들은 뭐가 있을까?

1. hostname-IP address 번역(=Name Resolution)
2. host aliasing(호스트 별명 붙이기): 진짜 이름과 alias(별칭) 존재
3. mail server aliaising: 한 서버에 여러 sub server 존재(메일 서버, 파일 서버 등) 그 중 메일 서버는 메일서버 메일박스에 존재 ex)mail.naver.com
4. load distribution: 구글같은 유명한 웹서버는 traffic이 엄청 많기 때문에 1대의 기계로 감당이 안된다. 따라서 여러 서버로 만들어 여러 IP 주소가 존재하게 되는데 이를 하나의 이름으로 맵핑되게 만드는 것이다.

 위와 같은 서비스들을 제공한다. 위와 같은 서비스들을 기억하고 DNS의 특징을 한 번 정리해보려고 한다.

---

2. DNS 계층 구조

 DNS는 수많은 name server들이 존재하고, 이를 조금 더 효율적으로 관리 하기 위해, 계층적인 구조를 만들었다. 정확한 계층 구조라고 할 수는 없지만, 즉, 계층별로 수평적인 관계를 가지진 않지만, 관리를 쉽게하기 위해 만든 것임을 알고 넘어가면 된다.

 

DNS 계층 구조

 

 각 계층에 대해 알아보기 전에, 위의 그림을 참고해 다음 상황을 가정해 보자.

 한 클라이언트가 www.amazo.com에 대한  IP address를 원한다. 그럼 다음과 같은 상황이 순차적으로 발생한다.

1. 클라이언트가 root Server에 .com DNS server에 대한 정보를 알기 위해 쿼리를 보낸다
2. .com DNS server에게 amazon.com DNS server에 대한 정보를 얻기 위해 쿼리를 보낸다
3. 클라이언트는 최종적으로 amazon.com DNS server에 www.amazon.com의 IP 주소를 얻기 위해 쿼리를 보낸다.

 위와 같은 상황이 발생하는데, 이는 실제로 작동하는 구조는 아니다. 그 이유는 Root DNS Server는 전 세계에 13군데 밖에 존재하지 않는데, 전 세계적으로 트래픽이 13군대에 몰리게 되면 부하가 발생하기 때문이다. 따라서 이를 해결하기 위한 여러 방법이 존재한다. 그 방법에 대해 알아보기 전에, 먼저 각 계층에 대해서 알아보고 정리해보겠다.

 

-Root DNS servers(=root name servers)

 위 사진을 보면 계층구조 최상단에 위치한 친구이다. 위에서 잠깐 언급했듯이 전 세계에 13군데에 존재하고, 이것의 복제본들이 엄청나게 존재한다. 이 Root DNS server는 Internet 기능에 있어서 엄청나게 중요하다. ICANN이라는 곳에서 root DNS domain을 관리한다.

 

 사실 이 root DNS 서버는 복제본이 존재한다고 해도, 초마다 발생하는 엄청나게 많은 트래픽들을 처리하지 못한다. 따라서 게임에서 보면 최종 보스 느낌으로, 진짜 하위 계층에 존재하는 친구들도 답을 모를 때, 마지막에 쿼리 요청을 보내는 곳이므로 위의 예시처럼 처음부터 클라이언트가 다이렉트하게 root DNS 서버에 쿼리 요청을 보내지는 않는다.

 

-Top-Level Domain(=TLD) servers

 이 TLD는 root DNS server 하위 계층에 존재하는 친구이다. 이 TLD는 .com, .org, .net, .edu와 같은 그 웹사이트의 특징을 나타내는 것들과, .kr, .uk, .jp 등과 같은 특정 나라 사이트임을 나타내는 것들을 책임진다.

 

-Authoritative DNS servers

  이 계층은 TLD 계층 밑에 존재하는 친구이다. 특정 조직이 소유한 DNS server들을 묶어 놓은 것으로, IP와 직결적으로 mapping되는 계층이다.

 

이 이외에도 Local DNS name servers가 존재한다. 이 친구는 이름에서 알 수 있듯이, 한 조직 자체에 DNS server를 두는 것이다. 그래서 이 local에 속하는 클라이언트가 특정 도메인에 대한 query를 보내면, local DNS server가 먼저 저장돼 있는 도메인인지 확인하고 저장돼 있으면 바로 응답을 보내준다. 만약 요청 보낸 도메인에 대한 정보가 없다면 이 local DNS server가 쿼리를 보낸다. 이 친구는 위에 보이는 사진에 안나타나 있듯이 계층 구조에 직접적으로 속해있지 않는다.

---

3. DNS name resolution

그럼 이제부터 DNS가 어떻게 요청에 대해서 답을 주는지, 그 과정에 대해서 알아보도록 하겠다. 총 2가지 방법이 있는데 차례대로 알아보고 뭐가 더 많이 쓰이는지, 왜 그 방식이 더 많이 쓰이는지 정리해보겠다.

 

-Iterated Query 방식

다음 그림을 먼저 확인해보자.

iterated query방식

 

 클라이언트가 local DNS server에 먼저 query 요청을 보낸다. 만약, 해당 도메인이 local DNS server 캐시에 저장돼 있지 않다면, local DNS server가 그 도메인에 대한 정보를 찾기 위해 iterated하게 query를 보낸다. 다음과 같은 순서로 보내게 된다.

1. root DNS server에게 engineering.nyu.edu에 대한 쿼리 요청을 보낸다
2. root DNS server는 답을 정확하게 모르니 답을 알고 있을 법한 TLD DNS server에 대한 정보를 응답으로 보낸다
3. local DNS server는 다시 TLD DNS server에  engineering.nyu.edu에 대한 쿼리 요청을 보낸다
4. TLD DNS server도 답을 정확하게 모르니 답을 알고 있을 법한 authoritative DNS server에 대한 저옵를 응답으로 보낸다
5. local DNS server는 다시 authoritative DNS server에  engineering.nyu.edu에 대한 쿼리 요청을 보낸다
6. 답을 알고 있는 authoritaive DNS server는 해당하는 응답을 local DNS server에 보낸다
7. local DNS server는 해당 응답을 본인 cache에 저장함과 동시에 클라이언트에 응답을 보낸다.

-Recursive Query

 이번에는 recursive query에 대해서 알아보자. 다음 그림을 먼저 확인해보자.

Recursive Query 방식

 

 Iterated query 방식과 동일한 상황이라고 가정하면 다음과 같은 순서로 진행된다.

1. local DNS server가 root DNS server에게 한 번의 해당 도메인 정보에 대한 query를 한 번 요청한다
2. 그 뒤로 root DNS server가 답을 모르니 친히 정보를 알고 있을 법한 TLD DNS server에게 query 요청을 한다.
3. TLD DNS server도 답을 모르니 정보를 알고 있을 법한 authoritative DNS server에 query 요청을 보낸다.
4. 답을 알고 있는 authoritative DNS server는 TLD DNS server에 응답을 전달하고,
5. TLD는 그 응답을 root DNS server에 전달하고,
6. root DNS server는 답을 알게 됐으니 local DNS server에 응답을 보낸다.
7. local DNS server는 답을 본인의 cache에 저장함과 동시에 클라이언트에게 응답을 보낸다.

 이 방법은 거의 쓰이지 않는데, 그 이유는 root DNS server가 친히 local DNS server를 위해서 하위계층인 TLD에게 요청을 보낼 필요가 없기 때문이다. 

---

4. DNS Records

 DNS records는 Resource Records(RR)이라고 불리기도 한다. 이 RR은 (name, value, type, ttl)과 같은 format으로 구성되어 있다.

 이 때, name과 value는 type에 따라서 달라진다. TTL은 Time To Leave의 약자로, 특정 유효기간이 지나면 더 이상 도메인에 관해 캐시에 저장하지 않겠다는 것을 나타내는 것이다. 

 

 그럼 Type의 종류에 대해서 알아보자. Type은 A, CNAME, NS, MX 총 4가지 종류가 있는데 A부터 차례대로 알아보자.

 

-type=A

 RR에서 name이 hostname이고, value는 IP address가 된다.

 즉, 사용자가 실제로 query를 보낼 때 원하는 답이 이 타입이다.

 

-type=CNAME

 RR에서 name은 alias name이 되고, value는 canonical name(실제 이름)이 된다. =>도메인의 별칭 이름을 정할 때 사용

 ex) www.ibm.com(=alias)=>RR의 name에, srvereast.backup2.ibm.com(=canonical name)=>RR의 type에 들어간다. 

 

-type=NS

 RR의 name에는 domain이, value에는 authoriative name server의 hostname이 들어간다.

 ex) name에는 foo.com, value에는 foo.com에 대한 정보를 알고 있는 authoritavie nanme server의 hostname이 들어간다.

 

-type=MX

 RR의 vlaue에 name과 연관된 SMTP 메일 서버가 들어간다.

 ex) jjj1234@foo.com라는 업무용 메일이 존재한다. Alice는 이 업무용 메일에 메세지를 보내기 위해서는 mail server를 알아야 되고, 그에 해당하는 IP 주소가 필요하다. 이 때, foo.com라는 도메인 안에 존재하는 MX의 IP 주소가 필요하기 때문에 이러한 type의 응답이 필요하다. 즉 순서를 정리하면,

1. foo.com의 메일 서버 도메인을 확인하고,
2. 해당 도메인에 대해 A type을 다시 확인하고,
3. SMTP 서버로 메일을 전송하게 된다.

 그렇다면, 최종적으로 A type의 응답을 기대하며 클라이언트는 쿼리를 보낼 것이다. 다음과 같은 여러가지 상황이 발생할 수 있다.

얻으려는 정보	흐름
host name	NS>A
host name(별칭이 존재하는 경우)	NS>CNAME>A
메일 전송용 주소 조회	NS>MX>A

---

5. DNS protocol messages

 DNS도 message를 통해 qeury를 보내고 reply를 받는다. 이 때, message format은 다음과 같다.

DNS protocol message format

 메세지 헤더는 identification, flags, #questions~#additional RRs까지이다.

• identification: 16비트로 이루어진 쿼리에 대한 식별 번호이다. reply도 동일한 식별 번호로 어떤 쿼리에 대한 답인지 식별한다.
• flags: 또한 16비트 정보로, query인지, reply인지 구분하고, recursion이 필요하거나 가능한지에 대해서 결정한다. 또, 응답이 authoritative한지(유효기간이 지나서 확실하지 않으면 authoritative하다고 하지 않음) 알려준다.
• 그리고 #questions에서 #는 숫자이다. 즉, 질문이 몇개인지, 답의 RRs이 몇개인지 등에 대해서도 헤더에서 명시해준다.

메세지 body는 그 밑의 questions~additional info이다. body는 authoritative 응답일 경우 실제 응답에 대한 답을 실어서 보내주는 부분이다.

---

6. DNS 정보 등록하기

 새로운 도메인 정보를 DNS에 등록하려는 신생 기업 QWER이 있다고 가정해보자.

 

 이 때, qwer.com이라는 이름을 사용하고 싶다면, 다음과 같은 순서로 등록을 해야된다.

1. DNS registrar에 qwer.com을 등록해야 된다. 이 때, 이름,  authoritative name server의 IP 주소를 제공해야된다.
2. registrar가 NS,A type의 RR을 .com TLD server에 삽입한다.
3. (qwer.com, dnsl.qwer.com, NS)==>NS type으로 authoritative 이름 지정       
4. (dnsl.qwer.com, 111.222.333.1, A)==> A type으로 실제 이름과 IP 주소 지정
5. IP주소 111.222.333.1를 가진 server를 만든다.(Mail server, File server 등등)

---

7. DNS security

 DNS의 보안에 대해서 알아보자.

 

-DDoS 공격

 root server로 엄청나게 많은 트래픽을 보내는 공격인데, 현재까지 성공한 적은 없다. traffic filtering을 통해 방지하고, root server 까지 갈 일 없이 보통 local DNS server에서 캐시된 것들로 처리하기 때문에 성공하기 힘들다고 한다.

 

 TLD server로의 공격도 존재하는데, 이것도 아직까지는 성공한 기록이 없다고 한다.

 

-Spoofing 공격

 DNS 쿼리를 가로채고 reply를 조작해서 응답해주는 방식이다. 실제로 정확한 주소를 쳤다해도, 조작된 주소로 접속해 개인정보가 위험해질 수도 있다고 한다.

 

 DNS 캐시 서버를 바꿔채는 방법도 존재하는데, DNS cache poisoning이라고 한다. 모든 쿼리를 가로채서 조작한 응답을 보내는 방법인데 DNSSEC을 통해 방지했다고 한다.