DNS란? (Domain Name System)

DNS 이전의 인터넷 환경

DNS가 없던 시절에는 사용자가 특정 서비스를 IP 주소로 일일이 기억할 수는 없으니 운영체제마다 가지고 있는 호스트 파일에 특정 호스트에 대한 도메인 주소가 저장되어 있었다. 즉, 만약 소비자가 www.dnr2144.com 이라는 이라는 서비스에 접근하고 싶으면 운영체제에서 보관하고 있는 hosts란 파일에서 www.dnr2144.com --> 110.210.212.110 이런 데이터를 보관하고 있었다. 그러나 만약 내가 도메인(www.dnr2144.com)은 그대로 유지하지만 IP 주소를 110.210.212.110 --> 201.212.442.111로 변경할 소요가 생겼다면 www.dnr2144.com 주소를 hosts 파일에 유지하고 있는 전 세계 PC hosts 파일을 바꿔줘야 한다. 현실적으로 불가능하다. 그래서 해당 서비스의 소유자는 Stanford Research Institute(전 세계 host 파일 관리)라는 신뢰할 수 있는 중개업자에게 www.dnr2144.com에 에 대한 IP 주소 변경을 요청하고 변경한다. 그리고 해당 서비스를 이용하려고 하는 소비자는 Stanford Reserach Institute가 관리하는 host 파일을 다운받아서 자신의 host파일에 덮어쓰기 한다. 그러면 소비자는 바뀐 IP 주소로 이상없이 접속할 수 있다. 즉, 개인이 host 파일을 관리하는 것이 아니라 Stanford Research Institute라는 신뢰할 수 있는 기관에서 host 파일을 관리하고 개인을 업데이트가 될 때마다 host 파일을 다운받고 사용받으면 됐다. 그러나 인터넷의 규모가 커짐에 따라 이런 방식은 문제가 생겼다. 예를 들어, 개인은 바뀐 서비스 주소를 SRI로부터 갱신받지 못하면 해당 서비스를 이용할 수 있는 주소를 알지 못했고, SRI 역시 매번 IP 주소나 도메인 주소가 바뀔 때마다 일일이 갱신하는 것은 많은 비용이 발생했다. 또한, 하나의 host 파일에 인터넷에 참여하고 있는 모든 host 주소를 담는 것 역시 곧 한계에 봉착하고 만다.

DNS의 원리

93.184.216.34 라는 주소로 서비스를 제공하는 호스트가 IP주소가 아닌 www.dnr2144.com 이라는 주소로 서비스를 제공하고 싶다. 그래서 서비스 제공자는 Domain Name System Server라는 컴퓨터에 dnr2144.com --> 93.184.216.34 라고 저장해 놓는다.

이제 소비자가 www.dnr2144.com 서비스로 접속을 하려고 하면, 제일 먼저 컴퓨터에 저장되어 있는 host 파일에서 해당 서비스의 도메인 주소와 대응하는 IP 주소를 탐색한다. 만약 host 파일에 해당 서비스의 주소가 없으면 ISP(Internet Service Provider, KT, SKT, LGU ...)가 제공해주는 Domain Name System Server 주소(기본적으로는 ISP의 DNS server를 사용하겠지만 무료 DNS 서비스가 시중에 많다)를 통해서, Domain Name System Server에게 www.dnr2144.com 에 에 대한 IP를 요청한다. Domain Name System Server는 요청받은 서버스의 도메인 주소에 해당한는 IP 주소를 다시 되돌려 준다. 만약 서비스에 대한 IP주소나 도메인 주소가 변경된다면 DNS server에게 요청해서 변경 요청을 하면, 서버에 있는 주소만 바꾸면 되니, 주소 변경에 대한 비용이 비약적으로 낮아졌다.

DNS 이름의 구조

DNS의 역할은 소비자가 이용하고자 하는 서비스의 IP 주소를 모를 때, 요청한 도메인 주소에 해당하는 IP 주소를 알려주는 역할을 한다. 전 세계의 모든 PC 사용자들에게 이런 정보를 제공해야 하기에 DNS 서버는 매우 많은 곳에 분산되어 있다.

dnr2144.tistory.com 이런 주소 형태는 매우 많이 볼 수 있는 형태지만 사실, dnr2144.tistory.com에는 마지막에 '.'이 생략되어 있다. 즉 원래는 dnr2144.tistory.com이 아니라 dnr2144.tistory.com. 이 원래 도메인 주소이다. 도메인의 각각의 영역에는 이름이 있는데 dnr2144.tistory.com. 의 마지막에 있는 .의 이름을 Root 도메인라고 한다. Root 도메인 밑에 있는 .com이 있는데 이 .com을 가장 상위에 있는 도메인이라고 해서 Top-Level이라고 한다. .net, .kr, .com 이러한 도메인들 전부 Top-Level 도메인(TLD)이다.

TLD 밑에 있는 .tistory는 Second-Level 도메인(SLD)라고 한다. 예시로 들었던 도메인 dnr2144.tistory.com 에서 SLD인 tistory는 사실상 도메인의 이름이다. SLD는 일반적으로 이 도메인을 등록한 서비스 제공 주체의 아이덴티티를 나타낸다. 실제로 서비스 이름이 티스토리지다. 반드시 그런 것은 아니나 일반적인 도메인에서 SLD가 도메인 이름(identity)일 때를 더 많이 볼 수 있다. 예를 들어, naver.com, google.com, youtube.com 같이 전부 SLD가 도메인 이름(identity)인 것을 알 수 있다. 반면, youtube.co.kr 같은 도메인 경우에는 최상위 도메인(TLD)가 kr, 차상위 도메인(SLD)가 co, 3차 도메인(Third-level domain)이 youtube이다. 즉, 꼭 SLD가 도메인의 이름을 나타낸다고는 할 수 없다. 여기서는 3차 도메인이 도메인의 이름(Identity)을 나타내고 있기 때문이다.

dnr2144.tistory.com 중 SLD 하위에 있는 dnr2144는 Sub 도메인이라고 한다.

1개의 DNS 서버에 모든 레벨의 도메인을 담기에는 그 양이 너무 방대하므로 4개 계층의 도메인을 나눠서 저장한다. 상위 DNS 서버는 하위 DNS 서버들의 목록을 알고 있어야 한다. 4개의 도메인을 담당하고 있는 4개의 DNS 서버의 역할은 동일하다. Root domain DNS 서버는 Top-Level DNS 서버들의 목록과 해당 서버들의 IP 주소를 알고 있어야 하고, Top-Level을 담당하고 DNS 서버는 Second-Level을 담당하는 DNS 서버들의 목록과 해당 서버들의 IP 주소를 알고 있어야 하고, Second-Level을 담당하는 DNS 서버는 Sub 도메인을 담당하는 DNS 서버들의 목록과 서버들의 IP 주소을 알고 있어야 한다. 결과적으로는 Sub DNS 서버가 dnr2144.tistory.com에 해당하는 IP 주소를 가지고 있고 이 IP 주소를 되돌려준다. 즉, 처음부터 dnr2144.tistory.com 의 IP 주소를 보관하고 있는 Sub DNS 서버를 알면 좋겠지만 그것이 불가하기에 Root DNS 서버로부터 해당 Sub DNS 서버를 알기까지의 과정이 필요하다. 이런 과정의 전제 조건은 특정 서비스의 IP 주소를 알고자 하는 모든 PC 사용자들은 Root DNS 서버의 IP 주소는 반드시 알고 있어야 한다는 것이다.

1) 사용자는 dnr2144.tistory.com에 대한 IP 주소를 Root DNS 서버에 요청한다.

2) Top-Level 도메인이 com이므로 Root 도메인 서버는 .com.(Top-Level) 도메인 서버 주소를 사용자에게 알려준다.

3) 사용자는 Top-Level 도메인 서버에게 dnr2144.tistory.com의 IP 주소를 요청한다.

4) dnr2144.tistory.com의 Second-Level 도메인 주소가 tistory이므로 Top-Level 도메인 서버는 .tistory.com.(Second-Level) 도메인 서버 주소를 사용자에게 알려준다.

5) 사용자는 dnr2144.tistory.com에 대한 주소를 Second-Level 도메인 서버에게 요청한다.

6) Second-Level 도메인 서버는 Sub 도메인이 dnr2144인 도메인 서버 주소를 사용자에게 알려준다.

7) 사용자는 Sub 도메인 서버에게 dnr2144.tistory.com에 대한 IP 주소를 요청한다.

8) Sub 도메인 서버는 dnr2144.tistory.com.에 해당하는 IP 주소를 알려준다.

9) 해당 IP는 다음에 사용할 것을 대비해서 로컬 캐시에 캐시를 저장한다.

※ DNS 조회 절차: 로컬 DNS 캐시에서 탐색(DNS Cache) -> hosts 파일 조회 -> DNS 서버 요청

도메인 등록 과정과 원리

1) 서비스를 제공하는 주체에서 93.184.216.34 주소에다가 example.com 이라는 주소를 부여하고 싶으면 example.com이라는 도메인을 구입한다.

2) 자신이 구축하거나 등록 대행자(Registrar)가 구축해 놓은 Name Server(a.inna-servers.net)에 example.com A 93.184.216.34를 등록한다. 여기서 말하는 등록은 네임 서버에 example.com이라는 도메인에 대응하는 IP 주소가 93.184.216.34라는 걸 기억하게 했을 뿐 진정한 의미로 등록한 것이 아니다.

3) 등록소(Register)에 example.com을 가지고 있는 Name Server가 a.inna.servers.net 걸 등록소(Registry)의 Top-level Domain Name Server인 a.gtld-servers.net에 등록(약간의 수수료가 필요함)한다. ICANN의 com을 관리하는 Name Server에는 이미 com에 해당하는 Name Server가 a.gtld-servers.net이 등록돼 있으므로 등록할 필요없다.

위 그림에서 레코드 타입이 NS와 A type를 눈여겨 볼 필요가 있다. Root Name Server인 a-root-servers.net에서는 "com NS a.gtld-servers.net" 방식으로 기억하고 있다. NS 타입은 현재 Name Server가 com이라는 도메인을 알아야 할 책임이 없으며, com을 저장해놓은 Name Server만 알고 있다는 의미이다. 반면, example.com A 93.184.216.34의 A 레코드 타입은 example.com 도메인에 해당하는 IP 주소를 현재 Name Server에서 보유하고 있다는 의미로 받아들이면 된다.

※ 위 예에서는 도메인 주소가 example.com이라서 .com TLD와 example Sub Domain밖에 없지만 만약 도메인 주소가 dnr2144.tistory.com이라도 달라지는 것 없다. 위 그림에서는 authoritative name server인 a.iana-servers.net이 dnr2144.tistory.com A 93.184.216.32 이렇게 보관하고 있을 것이다.

* Registrar(등록 대행자): Cafe24, 닷홈, 가비아 ....

* Registry(등록소): .com, .net, .co.kr 같은 Top-level 도메인을 관리하는 네임 서버(기관 혹은 기업에 관리)

* 국제 인터넷 주소관리 기구(Internet Corporation for Assigned Names and Numbers, ICANN): 1998년에 설립된 인터넷의 비즈니스, 기술계, 학계 및 사용자 단체 등으로 구성된 기관으로 인터넷 DNS의 기술적 관리, IP 주소공간 할당, 프로토콜 파라미터 지정, 루티 서버 시스템 관리 등의 업무를 조정하는 역할을 한다. 인터넷 체계의 관리자 역할을 한다. a.root-servers.net, b.root-servers.net ... m-root-servers.net 까지 총 13개의 root 도메인 Name Server를 관리한다. (위키피디아)

CNAME(Canonical Name)

CName이란 Canonical(별칭) Name의 약자로서, A 타입 레코드를 Mapping 할 수 있는 레코드 타입이다. 예를 들어, dnr2144.site A 13.124.249.239 라는 root 도메인이 있다. dnr2144.site 말고도 여러 개의 Sub 도메인을 설정할 수 있는데, api.dnr2144.site A 13.124.249.239 , dev-api.dnr2144.site A 13.124.249.239 같이 작성할 수 있다. 그런데 만약 dnr2144.site의 IP주소가 변경된다면 dnr2144.site A xxx.xxx.xxx.xxx 는 물론, 나머지 2개의 서브 도메인 역시 A 레코드 타입으로 직접 연결했기 때문에 변경을 해줘야 할 것이다. IP 주소를 바꿀일이 많지는 않겠지만, 그래도 불편하다. 그래서 등장한 게 CName 레코드 타입이다. 메인 Address 레코드는 dnr2144.site A xxx.xxx.xxx.xxx로 놔두고, api.dnr2144.site CName dnr2144.site, dev-api.dnr2144.site CName dnr2144.site 같이 도메인의 IP주소에 직접 mapping 하는 게 아닌 루트 도메인 주소랑 메핑하는 방식이다. 이러면 루트 도메인의 IP 주소가 바뀔 소요가 있어도, Address 레코드 타입만 바꾸면 되니 편하다. 하지만 단점도 있다. dnr2144 A xxx.xxx.xxx.xxx는 Name Server 에게 요청하면 바로 해당 IP를 전달해주지만, CName으로 접근하면 Name Server 에게 한 번 더 요청해야 한다는 단점이 있다.