10. Name Resolution

1. DNS(Domain Name System)

• 문자열을 IP 주소로 해석하는, 분산된 글로벌 네트워크 서비스
  ex) 날씨 웹사이트를 보고 싶을 때 웹 브라우저에 www.weather.com을 입력하면 이 사이트에 대한 IP 주소 중 하나인 184.29.131.121을 입력하는 것보다 쉽다.

2. Domain Name

• DNS로 해석할 수 있는 단어
• domain name에 대한 IP 주소는 여러 이유로 인해 바뀔 수 있지만, domain name 사용자는 바뀐 IP 주소를 몰라도 된다.
• domain name에 대응하는 IP 주소는 현재 위치에 따라 달라질 수 있다. data를 찾는 여정이 더 멀수록, 더 느려지기 때문에 최대한 지리적으로 가까운 곳에서 data를 찾는다.
• 그래서 보통 웹 서버를 한 곳에 모아두지 않고 여러 곳에 분산시킨다. 예를 들어 뉴욕의 누군가가 웹 사이트를 방문하면 뉴욕과 가까운 웹 서버에 접속하고, 서울의 누군가가 웹 사이트를 방문하면 서울과 가까운 웹 서버에 접속한다. 

3. Name Resolution

• DNS를 이용해 domain name을 IP 주소로 바꾸는 과정

4. DNS server

• 네트워크의 한 노드에서 구체적으로 정해야 하는 것들 중 하나이다.
• * 컴퓨터가 현대 네트워크에서 작동하기 위해서는 몇 가지 구성 요소가 필요한데, MAC 주소의 경우 hard coding되어 있고 특정 하드웨어에 대응한다. 이외에도 IP 주소, 서브넷 마스크, 게이트웨이, 그리고 (현대 표준 네트워크에서는) 특별히 DNS 서버를 정해야 한다. 이 네 가지 요소는 호스트가 네트워크를 작동시키기 위해 반드시 정해야 하는 요소들이다. 물론 DNS가 없어도 작동할 수는 있지만, 그 컴퓨터를 사용하기는 쉽지 않을 것이다.
• DNS 서버에는 5개의 주요 유형이 있다.
• 1&2. caching name server & recursive name server
  
  • ISP나 local network가 제공한다.
  • caching name server는 domain name을 일정 시간 동안 저장하여 매번 TCP 연결을 설정할 필요가 없도록 한다.
  • caching name server는 또한 recursive name server이기도 한데, 이는 전체 DNS 해석 요청을 수행하는 서버이다.
  • 대부분의 경우 local name server는 두 서버의 역할을 전부 담당하지만, caching 또는 recursive 중 하나만 담당할 수도 있다.
  • ex) 하나의 네트워크에 두 대의 컴퓨터가 있을 때, 한 컴퓨터가 www.facebook.com을 접속하면 name server는 www.facebook.com의 IP 주소를 모르므로 recursive한 해석을 수행해 올바른 IP를 찾아 cache에 저장된다. 잠시 후 다른 컴퓨터가 www.facebook.com을 웹 브라우저에 입력하면 같은 local name server에서 www.facebook.com의 IP 주소를 찾아 낸다. local name server가 caching server로서 작동한 것이다.
  • 글로벌 DNS 체계의 domain name은 TTL(time to live)을 가지고 있는데, 이는 초 단위의 값을 가지고 name server가 domain name을 버리고 새 해석을 다시 진행하기 전까지 cache에 얼마나 오랫동안 보관할 수 있는지 domain name의 주인이 정한다.
  • 몇 년 전만 해도 TTL이 며칠까지 될 정도로 긴 경우가 많았다. 이는 인터넷이 사용 가능한 대역폭이 훨씬 적어 네트워크 관리자가 full DNS lookup에 의해 대역폭을 낭비하길 원치 않았기 때문이다.
  • 최근 인터넷이 점점 빨라짐에 따라 TTL도 몇 분 내지 몇 시간으로 줄었다. 간혹 매우 긴 TTL을 가지는 domain name이 있는데, 이로 인해 DNS 기록의 변경 사항이 전체 인터넷에 알려지기 위해서는 총 TTL의 길이만큼 걸릴 수 있다. 
• root name server & TLD name server & authoritiative name server
  • local recursive server가 full recursive resolution을 해야 할 때 연결하는 server들이다.
  • root name server는 총 13개가 있고, 적절한 TLD name server에 쿼리를 전달한다. 과거에는 13개의 root server를 구체적인 지리적 영역에 분산했지만, 현재는 anycast를 통해 전 세계에 배포한다. 
  • * anycast란 위치, 혼잡도, 또는 링크 상태와 같은 요인에 따라 트래픽을 다른 목적지로 routing하는데 사용되는 기술이다.
  • anycast를 사용해 컴퓨터는 특정 IP로 datagram을 보낼 수 있지만 몇 가지 요인에 따라 여러 실제 대상 중 하나로 routing할 수도 있다.
  • 13개의 실제 root name server가 더 이상 없고, root name lookup을 서비스로 제공하는 권한 당국이라 할 수 있다.
  • root server는 쿼리해야 하는 TLD name server를 사용해 DNS 조회에 응답한다.
  • TLD는 top level domain으로 계층적 DNS 이름 확인 시스템의 상단, 즉 domain name의 마지막 부분이다. ex) www.facebook.com 에서 .com
  • TLD name server는 root server와 같이 물리적으로 하나의 서버만을 의미하지 않고 anycast의 세계적으로 분산된 형태이다.
  • TLD name server는 리디렉션을 통해 다시 응답하는데, 이번에는 이름 조회를 수행하는 컴퓨터에게 어떤 authoritative name server와 연결할지 알려준다.
  • authoritative name server는 단일 조직에 해당하는 domain name의 마지막 두 부분을 담당한다.
      ex) www.weather.com를 찾는 경우 TLD name server는 사이트를 운영하는 단체인 Weather Channel이 관리하는 weather.com를 authoritative server에서 조회한다. 그리고 DNS 조회는 weather.com를 authoritative server에 리다이렉트하고 authoritative server는 해당 server의 실제 IP를 제공한다.
  • 이러한 엄격한 계층은 Internet의 안정성에 중요하다. 이는 full DNS resolution을 엄격히 규제하고 통제하는 일련의 조회를 거쳐 올바른 응답을 얻도록 해 외부에서 트래픽을 리다이렉트하는 것을 방지한다.
  • 컴퓨터는 트래픽을 어느 IP로든 안 보이게 보내 DNS 조회로의 응답이 정확하게 한다.

5. DNS와 UDP

• DNS는 transport layer에 대해 TCP 대신 UDP를 사용하는 application layer 서비스의 대표적인 예시이다.
• 이는 UDP의 connectionless 특성으로 인해 훨씬 적은 트래픽이 필요하다는 점에서 기인한다.

6. TCP를 통해 full DNS 조회를 하는 경우

1. DNS 조회 요청을 하는 호스트는 SYN packet을 local name server에 port 53(DNS가 수신 대기 중인 port)으로 보낸다. local name server는 SYN ACK packet으로 응답하고, host는 ACK으로 응답해 three-way handshake를 완성한다. 그래서 총 3개의 packet이 필요하다.
2. 이제 연결이 시작됐으니 host는 실제 요청을 보낸다. food accomplice의 IP 주소를 얻고 싶은 경우가 그 예시가 될 수 있다. name server는 그 요청을 받고 food.com에 대한 요청을 받았다는 또 다른 ACK를 응답한다. 그래서 지금까지 5개의 packet이 필요하다.
3. 이제 local name server는 root name server에게 누가 .com TLD를 담당하는지 찾아야 한다고 전달해야 한다. 이때 three-way handshack, 실제 요청, 요청에 대한 ACK, 응답, 응답에 대한 ACK, 그리고 four-way handshake를 통한 연결 종료까지 총 11개의 packet이 필요하다. 지금까지 총 16개의 packet이 필요하다
4. 이제 recursive name server는 맞는 TLD name server를 가지고 위의 과정을 반복해 적절한 authoritative name server를 찾아야 한다. 여기서 11개의 packet이 추가로 필요해 총 27개의 packet이 필요하다.
5. 마지막으로 recursive name server는 authoritative name server에게 food.com의 IP를 얻기 위해 위의 과정을 한 번 더 반복해 총 38개의 packet이 필요하게 된다.
6. 이제 local name server는 food.com의 IP를 얻어 처음의 요청에 응답한다. 그리고 요청을 했던 컴퓨터는 응답을 받았다는 ACK를 name server에 보낸다. 이로써 총 40개의 packet이 필요하다.
7. 이제 TCP 연결을 종료하기 위해 four-way handshake가 필요하고 그래서 총 44개의 packet이 필요하다.
   이처럼 DNS 조회가 TCP를 통해 이루어지는 경우 많은 packet이 필요함을 알 수 있다. 게다가 DNS 트래픽은 실제 트래픽의 시작으로, 추가 데이터를 보내기 위해 항상 domain name의 IP를 알아야 하기 때문에 거의 항상 DNS 조회를 수행한다. 그래서 이러한 방법은 비효율적일 수 있다.

7. UDP를 통해 full DNS 조회를 하는 경우

1. 컴퓨터는 food.com의 IP를 요청하는 UDP packet을 local name server에 port 53으로 보낸다.
2. local name server는 recursive server로서 root server로 UDP packet을 보내고 root server는 적절한 TLD name server를 포함한 응답을 보낸다. 여기서 2개의 packet이 필요하다.
3. recursive name server는 TLD server에게 packet을 보내고 authoritative server를 포함한 응답을 받는다. 여기서도 역시 2개의 packet이 필요하다.
4. 마지막 요청을 authoritative name server에 보내 food.com의 IP를 포함한 응답을 받는다. 여기서도 역시 2개의 packet이 필요하다.
5. 마지막으로 local name server는 food.com의 IP를 포함한 packet을 요청했던 컴퓨터에게 응답한다. 여기까지 총 8개의 packet이 필요하다.
   이처럼 UDP를 이용해 DNS 조회를 하면 훨씬 적은 packet을 소비한다. 이는 UDP와 같은 protocol이 존재하는 이유에 대한 예시 중 하나이다. 만약 오류가 발생할 경우, 즉 DNS resolver가 응답을 받지 않았을 때 다시 요청함으로써 오류를 해결한다.
   TCP가 transport layer에서 제공하는 기능을 application layer에서 DNS가 가장 간단한 방식으로 제공한다. DNS 서버는 조회 요청에 대한 응답 외에는 신경쓰지 않아도 되고, 실패할 경우 조회를 계속 반복한다.
   하지만 TCP에서 DNS는 존재하고 실제로도 쓰이고 있다. 이는 웹이 점점 복잡해짐에 따라 DNS 조회 응답이 하나의 UDP datagram에 맞는 경우가 없어, DNS name server가 응답이 너무 크다는 packet으로 응답하는 경우 DNS 클라이언트가 TCP 연결을 시작해 조회를 수행한다.