사람들의 신원을 증명하는 identifier에는 이름, 신분증, 여권 등 여러가지가 있다. Internet hosts와 routers는 datagram을 address하기 위해서 하기 위해서 IP address(32 bit)를 사용한다. 그러나 사람들은 www.google.com과 같은 방식으로 접근한다.

Domain Name System (DNS)

  • 많은 네임 서버의 hierarchy로 구현된 분산형 데이터베이스(Distributed Database)이다.
  • Application-layer protocol로, hosts와 DNS server는 name과 address간의 매핑을 위해 통신한다.
    • Application-layer에서 동작한다는 것은 Network core에 있지 않고 edge에 있다는 건데, 사실상 DNS가 오늘날 필수적으로 쓰인다면 왜 더 하위 레이어에서 구현하지 않았을까?
      • Network core는 많은 양의 네트워크 패킷 트래픽을 핸들링하느라 매우 바쁘기 때문이다.
      • 네트워크 개발자들의 철학은 아래와 같다.
        • "Let core leave as simple as possible, and complex(complicated) functionality is implemented in edge side." 코어는 단순하게 가져가자. 왜냐하면 코어는 바쁘고 heavy load를 겪게 되니까. 여기에 복잡한 것을 구현하는 순간 성능이 많이 떨어지게 되고 모두가 불편함을 겪게 된다. 되도록이면 복잡한 연산들은 edge 단에 두자.

 

DNS Service

  • Hostname-to-IP-address translation
  • host aliasing(하나의 서버가 여러 이름을 가질 수 있다.)
    • canonical, alias names
  • load distribution
    • replicated(복제된) Web Servers: 여러 IP address들이 하나의 이름에 대응할 수 있다.

 

Q: 왜 DNS를 중앙화(centralize)하지 않을까?

  • single point of failure
    • 시스템에서 하나의 구성 요소가 동작하지 않으면 시스템 전체가 중단되는 요소를 가리킨다.
  • traffic volume
  • distant centralized database
    • 통합하기엔 DNS를 이용하는 사용자들의 위치가 다양하여 거리에 따른 성능 차이 문제가 있다.
  • maintenance

 

DNS에 대해서 생각해볼 점

  • 엄청난 양의 분산된 데이터베이스
    • billion records
  • 엄청난 양의 쿼리들을 매일 핸들링한다.
    • 쓰기보다 읽기가 훨씬 많이 발생
    • 성능이 중요하다.
      • 거의 매일 인터넷 느랜잭션은 DNS와 상호작용하기 때문이다.
  • 조직적으로, 물리적으로 탈중앙화 되어있다.(organizationally, physically decentralized)
    • 수백만의 서로다른 조직들이 그들의 records에 대해 책임지고 있다.
  • reliability, security를 보장해야 한다.

 

DNS: a distributed, hierarchical database

클라이언트가 www.google.com의 IP address를 요청한다고 가정해보자.

  • 클라이언트는 .com DNS server를 찾기 위해 root server에 쿼리한다.
  • 클라이언트는 google.com DNS server를 찾기 위해 .com DNS server에 쿼리한다.
  • 클라이언트는 www.google.com의 IP address를 찾기 위해 amazon.com DNS server에 쿼리한다.

Q: 왜 이런 트리 구조로 구성하였을까? root DNS server는 name을 resolve하지 못하는데, 만약 한다면 어떻게 될까?

A: Single Point of Failure가 발생할 수 있다.

 

Top-Level Domain (TLD) servers

  • .com, .org, .net, .edu, .aero, .jobs, .museums 그리고 모든 top-level country domains (.cn, .uk, .fr, .ca, .jp)을 담당한다.
  • 실제 우리의 hostname을 등록하는 DNS 서버이다.
    • Authoritative registry for .com, .net TLD

 

Authoritative DNS servers

  • 조직은 자신의 DNS server를 소유하고, organization's named hosts를 위해 권위가 있는(authoritative) hostname을 IP로 매핑하는 기능을 제공한다.
  • 조직이니 서비스 제공자에 의해 유지된다.

 

Local DNS name servers

호스트가 DNS 쿼리를 만들면, 이것은 local DNS server로 보내진다.

  • Local DNS 서버는 응답을 반환하고 답한다.
    • 로컬 캐시에서 최근의 name-to-address 변환 pairs를 찾는다 (아마 최신일 때)
    • 해결을 위해 요청을 DNS hierarchy에 포워딩한다

 

DNS Request order

Iterated Query

로컬 캐시에 데이터가 없다고 가정했을 때, 순서는 아래와 같다.

host -> local DNS server -> root DNS server -> local DNS server -> TLD DNS server -> local DNS server -> authoritative DNS server -> local DNS server -> host

  • 연결된 서버는 다음으로 연결해야할 서버의 이름을 응답한다.
  • "난 이 name을 모르는데 이 server에 물어봐" 방식

Recursive query

로컬 캐시에 데이터가 없다고 가정했을 때, 순서는 아래와 같다.

host -> local DNS server -> root DNS server -> TLD DNS server -> authoritative DNS server -> TLD DNS server-> root DNS server -> local DNS server -> host

  • root에 heavy load가 발생하기 때문에 현실적으로 사용하지 않는다.
  • 연결된 name server에 name resolution에 대한 짐을 지운다.

 

Caching DNS information

  • name server가 mapping을 학습했을 때, 이 mapping을 캐싱하고 해당 쿼리에 댛ㄴ 응답은 즉시 캐싱된 mapping을 반환한다.
    • 캐싱은 응답 시간을 향상시킨다.
    • 일정 시간(TTL: time to leave) 후에 캐시 엔트리는 timeout(disappear)된다.
    • TLD 서버는 보통 local name server에 캐싱된다.
  • 캐싱된 엔트리는 최신(out-of-date)이라면
    • 만약 named host가 IP address를 변경하면, 모든 TTL이 만료되기까지 Internet-wide에 알려지지 않을 것이다.

 

DNS records

DNS는 리소스 레코드들을 저장하는 분산형 데이터베이스다.

  • type=A
    • Name : value = host : IP address
  • type=NS
    • Name : value = domain : hostname of authoritative name server for this domain
  • type=CNAME
    • Name : value = alias name for some canoncial name : canoncial name
  • type=MX
    • value는 name과 연관된 SMTP 메일 서버이다.

 

References

https://datalibrary.tistory.com/207

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기