Application: DNS

ㅎㅎ·2023년 9월 6일

목록 보기

6/6

각각의 호스트의 IP주소는 기억하기 어려우므로, IP주소를 대신하는 Domain Name을 두어 쉽게 접속할 수 있도록 하는 체계
한 서버를 두고, 해당 서버에 각 도메인의 IP주소를 질의할 수 있겠지만, 실제로 이렇게 구현하지는 않는다. 도메인 목록의 크기가 크며, 검색하는 시간도 오래 걸리고, 한 서버가 다운되면 모두 서비스를 이용하지 못한다. 따라서 루트 - com, net, org - … 를 통한 계층화가 되어 있다.

Root Name Server: IP주소 질의를 할 때 가장 먼저 접근할 Server, 전 세계 12~13개정도 존재하며, 바로 밑에 있는 top level domain(net, com..)을 관리함.
가장 하위에는 authoritative DNS server가 있음, 인터넷에 속한 모든 기관들은 이 서버를 가지고 있어야 하며, 이 서버가 각자 자기 기관이 보유하고 있는 머신들의 호스트 네임에 대한 ip주소 매핑을 책임진다. 각 서버들은 각자의 이름을 가진다. 예를 들어 한양대학교에는 가장 유명한 www.hanyang.co.kr라는 이름을 가진 서버가 존재하며, 이들은 고유의 IP 주소를 가지고 있을 것이다. Authoritative Name Servers는 이 도메인 네임과 IP주소를 매핑하는 자료구조를 가지고 있다. 각 기관이 이 자료구조를 가지고 있다

IP주소가 아닌 컴퓨터의 Name을 사용하게 되면, name 자체에 의미를 가질 수 있다. www.hanyang.co.kr이라고 하면, 한양대와 관련한 서버구나라는 것을 알 수 있다. 또한 IP주소는 물리적인 위치와 관련이 깊어서 서버의 위치가 변경되면 IP주소도 변경될 것이다. 하지만 Domain name은 그대로 유지할 수 있다. 네이버는 www.naver.com으로 접속하지만, 해당 서버는 네이버 회사의 위치에 따라 여러번 위치 이동을 겪었을 것이다.

각 기관은 내부적으로 local name server를 가지고 있다. 각 네트워크 내 사용자들은 먼저 해당 name server에 요청하는 도메인에 대한 IP주소를 질의해서 가져온다. 만약 로컬 server가 가지고 있지 않다면 외부 망으로 빠져나와 또 질의를 하는 방식으로, 마치 캐시처럼 동작한다.
local name server가 user가 요청한 도메인에 대한 ip주소를 가지고 있지 않다면, 상위 DNS server에 질의를 하게 된다. 만약 요청된 도메인 주소가 .com이라면 .com을 관리하는 서버에 질의를 하게 된다. 즉 알고 있는 최하위 단계 서버(local name server)에서 시작하여 찾을 수 있는 다음 하위 서버로 질의를 하게 된다. 따라서 실제로 ROOT 부터 IP주소를 찾는 요청은 드물다. 가령 .kr(co.kr에 대한 ip주소 보유) → co.kr(hanyang.co.kr에 대한 ip주소 보유) → hanyang.co.kr(한양대 authroative server)로 이동한다.
주의할 점은 Domain Name의 IP주소는 언제든 변경될 수 있기 때문에, 정보를 최신화해야 한다. 따라서 각 Name Server는 TTL이라는 필드를 두어 정해진 시간을 초과하면 해당 domain에 대한 매핑 정보를 자동적으로 삭제하도록 되어 있다.

DNS는 아래 4가지 정보를 가진 구조로 구성된다.

Name
Value(IP 주소)
TTL
TYPE: 어떤 값을 가지냐에 따라 각 record(테이블의 행)의 의미가 달라진다.
- type A: name은 hostname, value는 ip address를 가리킨다.
- type NS: name은 domain, value는 host name

hostname과 domain name은 다르다. hostname은 특정 컴퓨터(머신)을 지칭하며, domain name은 네트워크를 지칭한다. 가령 Root Server는 top level domain을 관장한다. 따라서 Root Server의 NAME에 ‘.com’, Value에 DNS.a.com이 Type NS로저장되어 있다면, ‘.com’이라는 도메인은 DNS.a.com이라는 host가 관리한다는 뜻이다. 하지만 이 DNS.a.com만 알아서는 우리는 해당 도메인에 접근할 수 없기 때문에 해당 도메인의 IP address에 대한 정보도 알아야 한다. 따라서 NAME이 DNS.a.com고, Value가 7.7.7.7이며 Type이 A인 IP주소에 대한 정보도 항상 함께 가지고 있다가, 요청한 서버에 IP 주소를 알려주어 해당 IP주소로 요청을 할 수 있도록 한다. 요청한 USER는 상위부터 타고 타고 내려가서 요청한 주소의 최하위 authroative server가 return 해준 Type A의 IP address를 최종적으로 응답받게 된다.

HYS.com이라는 도메인을 얻었다.
우선 Authorative Name Server를 구성한다. 이 서버의 host name은 DNS.hys.com, ip 주소는 8.8.8.8이다.
위 그림과 같이 자신의 네트워크 내의 호스트들의 record를 저장하고 관리한다. www.hys.com, 8.8.8.9, Type A라는 서버가 존재한다.
자신의 authroative server에 대한 record를 상위 Domain Server인 .com에 제공해야 한다. (HYS.com, DNS.hys.com, NS / DNS.hys.com , 8.8.8.8, A)

DNS도 Application layer에서 구동되는데 HTTP와 달 전송계층의 프로토콜로 UDP를 이용한다. 신뢰성도 보장해야 할 거 같고 꽤 중요한 네트워크 요청인데 왜 UDP를 사용할까? TCP는 신뢰성이 있는 대신, connection을 맺기 위한 handshake 과정 및 저장공간 준비가 필요하다. 하지만 우리가 DNS를 사용하는 목적은 요청한 HOST에 DATA를 직접 받아오는 요청이 아니라, 해당 호스트를 우선 찾는 과정일 뿐이다. 따라서 지나친 준비동작을 통해 overhead가 발생하는 TCP를 사용할 필요가 없다. 그럼 신뢰성 보장이 되지 않는 것은 어떤 관점에서 바라봐야 할까? 실제 현실 상황에서 packet이 유실될 확률은 굉장히 낮다. HTTP 요청과 같이 여러 media data를 포함한 큰 요청도 유실이 적다. DNS의 요청은 Domain name과 ip주소, type, ttl 필드만 가진 아주 작은 정보이다. 따라서 유실될 확률이 더 적으며, 유실되면 다시 요청하면 그만이다. 따라서 TCP를 이용하지 않는다.

Hello World

네트워크