논문에서 사용하고 있는 용어에 대한 설명과 내가 나름대로 바꿔서 사용하고 있는 것들은 다음과 같다.

Domain Name 시스템(DNS) 는 인간이 사용하기 편한 도메인 네임을 기계가 식별할 수 있는 숫자형태의 IP 주소로 변환하는 일을 한다.
Client 의 성능(CPU, 메모리)이 좋아짐에 따라, 기존의 DNS 에 대한 연구는 server-side infrastruct 에 초점을 맞춰왔다.
그러나, client-side 의 DNS 실패가 빈번해짐에 따라, DNS 의 성능과 신뢰성에 대한 저하가 발생했다.

앞서 client-side 의 DNS 실패문제를 해결하기 위해서 여기서는 CoDNS 라는 새로운 개념을 소개한다. CoDNS 의 특징으로는 다음과 같다.

1. Lightweight : 가볍다
2. Cooperative DNS lookup service : 기존의 DNS 와 상호 연동 한다
3. Use insurance-like model : Insurance 모델을 사용한다
4. Use locality-enhancement techniques and proximity optizization : 낮은 오버헤드와 짧은 지연시간을 보장한다

DNS 의 실패는 해당 서비스들(WEB, Mail)에 실패나 delay 의 원인이 된다.
server-side infrastructure 의 DNS 는 계층구조로 구성되어 있다. 최상위 단에 있는 root server 는 중심적인 역할을 한다. top-level server 는 root server 밑에 있으며, 각 조직을 대표한다. (ex: .com, .net, .kr)
Planetlab 이라고 하는 testbed 를 이용한 여러가지 실험을 통해 얻은 결과값으로 CoDNS 의 성능을 증명할 것이다.

Planetlab 을 이용한 여러가지 실험을 통해 기존의 DNS 가 어떤 문제점을 가지고 있는지 알아본다.
대부분의 노드들은 실제로 긴 응답시간을 가지고 있지만, DNS cache 를 사용해서 성능을 크게 향상 시키고 있다. 또한 응답시간이 1000ms 이상인 DNS 실패의 경우, 전체 응답시간의 적은 부분을 차지하지만, 전체적으로 DNS 의 성능을 저하시킨다.

응답시간이 1000ms 가 넘는 DNS 실패가 일어나는 요인에 대해서 크게 4가지로 분류하고 있다.

대부분의 DNS 가 UDP 를 사용하기 때문에, 쿼리에 대한 요청이나 응답중에 packet loss 가 발생할 수 있다. LAN 환경에서는 packet 이 hop 을 많이 거칠 수록 packet loss rate 가 증가한다.

네임서버의 특정상황에서 발생할 수 있는데, 예를 들면, 네임서버가 특정시간(8:00 ~ 18:00) 에 DNS 실패율이 높다면, 그것은 업무시간에 부하가 많이 걸려서 이다. 또한 buffer 가 가득차면, 차후에 들어오는 packet 은 버려진다. 그래서 충분한 buffer size 의 확보가 필요하다.

네임서버 내의 다른 프로세스에 의해 매시간 또는 매분 마다 발생할 수 있다. 예를 들면, cron 에 의한 heavy process 때문에 프로세스 간에 충돌이 일어날 수 있다.

예기치 않은 서비스 인터럽트에 의해 발생할 수 있다. 예를 들면, 특정한 시간에 네임서버가 다운 되어 버리는 경우가 그렇다.

CoDNS 의 디자인은 최소한의 오버헤드를 가지면서, 빠르고 신뢰할 수 있는 DNS 서비스를 name lookup 시스템 에 제공하여야 한다.
또한 Insurance-like 모델을 사용한다.

1. 노드는 필요한 시간에 리소스를 공유할 수 있는 pool 에 가입(join)한다.
2. 만일 노드의 성능이 가능하면, 그냥 실행하고 노드에 문제가 있으면, 서비스를 제공한다.
3. 로컬 성능이 떨어지면, 도와주기 위해 다른 노드에 물어볼 수 있다.
4. 가입(joining)하는 것의 장점은 다른 시간에 오버헤드가 걸리더라도, 필요할 때 도와줄 수 있다는 것이다.

관계된(correlation) 노드에서 실패가 일어났을 때, 관계를 끊어서(uncorrelation) 전체적으로 높은 성능을 유지할 수 있다.

CoDNS 의 local name service 의 문제가 발생했을 때, peer node 에 쿼리를 보낸다.
쿼리를 보낼때 고려해야 할 점으로는,

1. 쿼리의 지역성(locality) 와 노드의접근성(proximity) 와 이용가능성(availability)
2. 쿼리를 언제 보내는 것이 적당한가?

있다. 주변에 extra peer node 를 하나 이상 가지고 있으면, 응답시간이 절반 이상으로 줄어든다.

CoDNS 에 있어서 요청자(requestor) 을 구별하고, 요청에 있어서 올바르게 resolve 하고, 유효한 ip 주소를 제공하는 것이 중요하다.
만일, peer 간에 타협(compromise) 이 이루어지거나, 그렇지 않아서 failure 될 때 turst 나 verification 에 관련한 문제가 발생할 수 있다.
하지만, 현재 이런 문제에 대한 일반적인 해결책은 없는 상태이다.
여기서는 DNSSEC 라는 것에 대해서 소개하고 있다. 이것은 DNS 스푸핑 같은 공격으로 부터 DNS 를 보호하기 위해 만들어졌다. 하지만, 개발된지 10년이 넘은 지금 아직 널리 사용되지 못하고 있다.

Codns 는 stand-alone 으로 동작하며, remote 쿼리에 대해서는 UDP 를, local 쿼리에 대해서는 루프백 TCP를 사용한다. 데몬은 event-driven 이고, 마스터 프로세스와 여러개의 슬레이브 프로세스로 구성되어 있다.

마스터 프로세스는 클라이언트로 부터 오는 요청의 도착시간과 일정한 주기안에 슬레이브로 부터 응답이 오지 않을 때, peer 노드로 UDP name lookup 쿼리를 보내는 시간을 기록한다.

초기 delay 는 첫번째 쿼리를 보내기 전에 네임서버와 peer 의 응답의 최근 성능에 기초로 해서 조정되어 진다.
쿼리가 보내지면, delay 는 '쿼리의 평균 응답시간 + 표준편차' 로 세팅된다.

각 CoDNS 노드는 적당한 지연시간의 바운더리 안에서의 이웃(neighbor)노드로 묶일 수 있고, 관리되어 질 수 있다. CoDNS 가 시작할 때, 다른 CoDNS 노드에 매 초마다, heartbeat 를 보낸다.
이에 대한 응답에는 round trip time(RRT) 와 peer 노드에서의 로컬 네임서버의 평균 응답시간이 포함되어 진다.
만일 서비스가 아직 사용가능하다면, 선택된 이웃노드의 생존성(liveness)은 주기적으로 체크해볼 수 있다. 죽은(dead) 노드들은 다른 노드로 교체된다.

CoDNS 는 네크워크 환경이나 정책에 맞게 inital delay 와 retry 를 적당하게 조정할 수 있다.

CoDNS 는 resolve 하면서 부터 bootstrapping 문제를 가지고 있다. 이 문제를 방지하기 위해서는 시작할 때, resolve 를 백그라운드(background) 에서 실행하는 것이다. 그러면, start time 을 크게 줄일 수 있다.

여기서는 앞에서 설명한 CoDNS 에 대한 장점들을 바탕으로 여러가지 실험을 통해 증명해 보이고 있다.

네임서버가 오버로드가 걸릴때, 각 네임서버에 private nameserver 를 사용할 수 있다.
이것은 몇 가지 이유로 인해 주(primary) 네임서버에 비해 private 네임서버가 백업용도로 좀더 실행될 수 있다.
private 네임서버로 인해 Shared cache 가 좀더 커졌고, cache 의 효과(effectiveness)가 증가했다. 이런 이유로 용량 때문에 강제로 삭제되어야 하는 경우가 줄어들었다.
cache miss 의 증가는 DNS 실패로 이어져 결국, 전체적인 성능과 신뢰성을 저하시킨다.

대부분의 사이트 들이 두대 이상의 네임서버를 운영하고 있고, 각각 다른 설정을 통해 좀더 적극적인(aggressive) 서비스를 제공할 수 있다.
가능한 옵션은 여러대의 네임서버에 쿼리를 보내고, 좀더 빠르고 적극적인(aggressive) Secondary 네임서버를 선택하는 것이다.
Secondary 네임서버는 주(primary) 네임서버의 뒤에 위치함으로서, 사용량이 적은 경향이 있다. H/W 를 업그레이드 함으로서, Secondary 네임서버로 보내지는 쿼리의 수를 증가시킬 수 있다.

이것은 UDP 대신에 TCP 를 사용하여, 로컬 네임서버와 통신하는 것을 말한다.
UDP 버퍼 오버플로우 때문에, packet loss 나 packet drop 이 발생할 수 있다. TCP 는 신뢰성있는 배달(delivery)를 보장한다. 게다가 flow control 을 통해 네임서버가 오버로드 될 때, 클라이언트를 slow down 시킨다.

그러나 TCP 는 모든 쿼리마다 2 개 대신 9 개의 packet 을 필요로 한다. 3 개는 연결을 성립하는데, 2 개는 요청과 응답에, 나머지 4 개는 연결을 분할하는데 쓰인다. 이러한 TCP 의 단점을 극복하기 위한 방법으로 persistent TCP 가 있는데, 이 것은 연결할 때, 매 쿼리마다 오버헤드를 지웠다.
하지만, 1개 또는 2개의 응답(ACK) network packet 이 추가된다.

실험결과, persistent TCP 가 기존의 TCP 보다는 평균 응답 시간이 빨랐지만, CoDNS 보다는 느렸다.

앞에서 실험들을 통해, 여기서는 가볍고 name lookup service 인, CoDNS 의 장점을 알아보았다. CoDNS 는 낮은 오버헤드, 절반 또는 그 이상의 평균 응답 시간, 그리고 DNS 서비스의 사용률을 높이는 데 목적이 있다.