네트워크

DNS 기본 개념 뿌시기 - (FQDN, domain, sub-domain, A record, CNAME record 등)

quokkalover 2022. 3. 26. 16:58

DNS에 대해 공부하다보면, 나만 그렇게 느낄지 모르겠지만, 명확하게 정리된 내용을 잘 찾지 못했다. 필자는 DNS서버를 개발하려는 목적보다는, DNS가 어떻게 동작하는지, 그리고 어떻게 활용해볼 수 있을지에 대해 궁금했지만, 막상 내용을 찾아보면 너무 국소적으로 설명하거나 이론적 정의에만 치중된 글들이 많았고, 또 사용하는 용어들도 다르다 보니 전반적인 그림이 쉽게 이해가 되지 않았다..

 

따라서 본 글에서는 DNS의 전반적인 그림에 대해 이해하고, DNS에서 필자가 가장 헷갈렸거나, 제대로 이해하지 못했던 내용들을 정리해보려고 한다. 항상 그렇지만 파고파도 끝이 없기 때문에, 관심있는 부분에 대한 키워드를 얻어가는 정도로 이 글을 읽으면 좋을 것 같다.

목차는 다음과 같다.

  1. DNS에 대한 간단한 소개
  2. DNS 기본 용어
  3. DNS의 기본 동작 방식
  4. FAQ: Domain과 Zone의 차이
  5. FAQ: hostname과 domain name의 차이, 그리고 FQDN
  6. FAQ: A record란? CNAME record란?

 

DNS에 대한 간단한 소개

우리가 웹 브라우저를 통해 접근하는 모든 웹 페이지는 실제로 전세계 어딘가에 위치해있는 원격 서버가 호스팅하고 있다. 이렇게 인터넷에 연결되어 있는 장치들은 각각의 장치를 식별할 수 있는 주소를 가지고 있는데 이를 IP주소라고 한다.

 

하지만 우리가 웹 브라우저를 통해 웹사이트를 방문할때는 IP주소가 아니라 사람이 읽을 수 있는 도메인 이름을 입력한다. (예: www.facebook.com). 하지만 앞서 말했듯 실제로 웹사이트를 호스팅하고 있는 서버에 접근하려면 IP주소가 할당돼있어야 하는데, 우리는 어떻게 도메인 주소를 통해서 웹사이트에 데이터를 요청할 수 있을까?

 

답 : DNS!!

위 그림에서 보이듯이 DNS 서버가 IP주소와 특정 도메인 주소를 매핑 시켜두어 저장해두고있다가, 인터넷 사용자들이 도메인 주소를 입력했을 때 DNS서버로부터 도메인 주소와 매핑된 IP주소를 받아 해당 IP주소에서 동작하고 있는 웹사이트에 접근할 수 있는 것이다. (실제로는 여러 종류의 DNS서버가 있고, 자세한 내용은 뒤에서 다루고 있다.)

 

위와 같이 DNS가 필요한 이유는 IPv4 주소나 (e.g. 173.194.121.32) or an IPv6 주소는 (e.g., 2027:0da8:8b73:0000:0000:8a2e:0370:1337) 사람이 쉽게 기억하기 어려워 해당 주소에 어떤 서비스가 동작하고 있는지 파악하기가 매우 어렵기 때문이다.

 

자 이제부터 DNS의 동작방식을 이해하기 위해 필요한 기본 Term들을 익혀보자.

 

DNS 기본 용어

Top-Level Domain

도메인 이름은 아래와 같이 .으로 구분되는 매우 간단한 구조로 나뉘어 있다. (오른쪽에서 왼쪽 순으로 읽어야 한다)

그 중에서 top-level domain은 단어 그대로 최상위 도메인으로, 마지막 점 뒤의 마지막 섹션이다. 즉 도메인 이름 계층 구조내에서 가장 높은 수준이다. 대표적인 TLD의 예시로 “com”, “net”, “org”, “gov”, “edu”, and “io”가 있다.

도메인 이름을 우측부터 순서대로 읽을 때의 의미는 위 그림처럼 TLD란 영역 안에 해당 SLD가 존재한다고 볼 수 있는데, 이렇게 종속 개념이 있는 이유는 관리의 편의성도 있지만 TLD마다 관리하는 기관이 별도로 존재하기 때문이다.

Label : 도메인 이름의 구성요소

도메인 이름은 반드시 하나 이상의 레이블로 구성된다. 그리고 각 레이블 사이에 구분자로 .을 두어 표기한다. 다시 말해서 Domain 이름의 영역을 .로 구분짓고 각각의 영역을 Label이라 한다.

label은 문자열 데이터이고, 사용할 수 있는 문자에 제한은 없다. 하지만 도메인 이름이 호스트이름(hostname)으로 사용되는 경우에는 오직 영문자, 숫자, 하이픈만 사용하여 레이블 문자열을 구성해야 한다.

또한 레이블 갯수는 정해져있지 않다. 참고로 레이블 하나만으로 구성된 도메인도 있다. (e.g. root domain인 “”) 도메인 이름은 우리가 흔히 보는 3개의 label뿐 아니라 여러개의 label을 가질 수 있고 필요에 따라 여러 서브 도메인을 만들 수도 있다. (e.g. cafe.naver.com, game.naver.com)

Name server 네임서버

네임서버란 도메인 이름과 IP의 상호변환을 가능하게 해주는 서버다. 다시 말해 IP주소와 도메인 주소를 연결해주는 역할을 하는 서버를 의미한다. 기능만 보아도 알듯이 DNS 시스템에서 대부분의 일을 도맡아 하는 서버다.

도메인 등록할 때 네임 서버를 지정하고, 대부분의 도메인 주소는 2개의 네임서버를 가지게 되며, 이 두 개의 네임서버가 서로 병렬적으로 동작하면서 네임서비스를 보다 안정적으로 연결되도록 한다.

모든 도메인 주소에 매핑된 IP주소를 한 네임 서버에서 모두 관리하고 있지는 않기 때문에 다른 네임 서버에 redirect하기도 한다. 예를 들어 해외 느린 네임서버의 문제를 해결하기 위해 중간에 네임 서버만 바꾸는 작업도 가능하다.

Zone File 존 파일

존 파일에는 도메인 이름과 IP주소 및 기타 리소스간의 매핑이 포함되고, 리소스 레코드의 텍스트 표현 형식으로 구성된다. 따라서 특정 정보나 서비스를 제공하는 호스트 서버에 접속하기 위해서는 그 영역의 정보, 즉 존 파일을 가지고 있는 네임 서버로 접근해야 한다. 즉 네임서버는 개별 호스트들의 정보를 존 파일을 활용해 관리하고 있고 존파일의 대표적인 내용의 예시는 아래와 같다.

  • 네임서버 및 관리자 정보 : 도메인에 대한 책임자가 누구인지를 규정한다.
  • 호스트 주소 정보 : 호스트 서버의 정보를 의미한다. 대표적으로 Address의 첫 자를 사용하여 A 레코드가 있다. 즉 A레코드란 호스트 IP와 호스트 이름을 말한다.

Records

레코드란 DNS에 받은 요청을 어떻게 처리할 것인지에 대한 매핑 정보를 의미한다. 다르게 말하면 존 파일 내에 도메인에 관한 설정을 하기 위해 사용되는 문자열을 의미한다.

  • 도메인 이름과 IP주소를 매핑하기도 하거나
  • 도메인에 대한 name server를 정의하거나
  • 도메인의 mail 서버를 정의하는 등 다양한 레코드가 존재한다.

 

Root domain과 Sub domain

root domain은 아래 두 가지 문장으로 정리할 수 있다.

  • root domain은 sub domain이 없는 도메인 그 자체를 의미한다.
  • root domain은 sub domain의 부모 도메인이다.

root domain 특징

 

root domain 주소는 TLD이후의 레이블을 .로 나누지 않는다. 일반적으로 도메인 provider를 통해서 도메인을 구입할때, .(dot)이 없는 도메인 이름을 입력하도록 하는 것도 이 때문이다. 예를 들어 설명해보면 mydomain.com은 root domain이지만 my.domain.com은 아니다. my.domain.com는 root domain인 domain.com의 subdomain이 된다.

 

sub domain 용도

 

subdomain은 도메인 이름의 확장자 역할을 하여 웹사이트의 다양한 섹션을 구성 및 탐색할 수 있도록 지원한다. subdomain의 가장 일반적인 용도는 아래와 같다.

  • 웹사이트의 테스트 또는 준비 버전을 만드는 경우다. 사이트를 인터넷에 게시하기 전에 하위 도메인 준비사이트에서 새로운 플러그인과 업데이트를 테스트할 수 있다.
  • 혹은 모바일 사이트 m.mydomain.com, 위치별 사이트 en.mydomain.com 등과 같이 하위 도메인을 통해 식별 및 구분하고
  • 사이트의 하위 섹션을 만들때도 유용하다. blog.naver.com, news.naver.com

즉 서브도메인이란 도메인 등록 기관에 등록되어 있는 하나의 루트 도메인을 도메인 관리자의 목적에 맞게 여러 개로 쪼개고 싶을 때 사용한다. 예를 들어 www.naver.com을 보면 wwwnaver.com의 subdomain이고 naver.com.com의 서브도메인이다.

이 둘의 차이를 잘 이해해 두어야 나중에 CNAME 레코드와 A레코드 개념에 대해 설명할 때 쉽게 이해할 수 있다.


DNS의 기본 동작 방식

클라이언트에게 도메인 주소와 매핑된 IP address를 전달하기 위해 총 네 종류의 서버가 동작한다.

 

DNS resolver(리졸버)(Local DNS server) : DNS클라이언트와 네임서버 사이의 중개자 역할을 한다. DNS 클라이언트에게 쿼리를 받은 후 캐시된 데이터로 응답하거나 요청을 아래 3개 네임서버에 요청을 전달하고, IP주소를 받아 클라이언트에게 전달한다.

  • 대부분의 인터넷 사용자는 ISP에서 제공하는 DNS resolver를 사용한다.

root nameserver : DNS resolver가 DNS 레코드를 쿼리하는 첫 번째 네임 서버다. 도메인 이름을 포함한 DNS resolver의 쿼리를 받아 적절한 최상위 도메인(TLD)에 대해 권한이 있는 네임 서버 목록을 반환한다.

  • 루트 네임 서버 총 13개가 있고 비영리 단체인 ICANN이 관리한다. (정확히는 13개 유형이고, 전 세계에 각각의 사본이 다수 있다.)
  • 대표적인 최상위 도메인은 .com, .net, .org 등이 있다.
  • DNS서버에 www.naver.com을 질의하면, com도메인을 관리하는 TLD 네임 서버 정보를 전달 받는다.

TLD nameserver : .com, .net또는 URL의 마지막 점 뒤에 오는 일반적인 도메인 확장자를 공유하는 모든 도메인 이름의 정보를 유지한다. 쉽게 말해 .com으로 끝나는 모든 웹사이트의 정보를 가지고 있다.

  • 사용자가 www.naver.com을 질의하면 DNS resolver는 root nameserver로부터 .com TLD 네임서버에 대한 정보를 응답받아 TLD네임서버에 쿼리를 보내고, 요청을 받은 TLD네임서버는 해당 도메인의 권한있는 네임서버를 가리켜 응답한다.
  • TLD 네임서버는 ICANN의 지사인 IANA가 관리한다. IANA는 TLD 네임서버를 두 가지로 구분한다.
    • 일반 최상위 도메인 : 국가별로 고유하지 않은 도메인으로, .com, .org, .net, .edu가 있다.
    • 국가 코드 최상위 도메인 : 국가 또는 주와 관련된 모든 도메인으로, .uk, .us, .ru 등이 있다.

authoritative nameserver : IP주소를 확인하는 마지막 네임 서버다. 실제로 DNS 리소스 레코드(SOA, NS, A, CNAME등)를 관리하고 있는 서버이며 특정 영역에 대해 관리 권한이 위임된 네임 서버다.

  • authoritative nameserver는 도메인 이름에 고유한 정보 (예: google.com)를 포함하며 DNS A 레코드에서 찾은 도메인의 IP주소를 DNS resolver에게 제공하거나 도메인에 CNAME레코드가 있는 경우 DNS resolver에게 별칭 도메인을 제공한다. 이 때 DNS resolver는 authoritative nameserver로부터 레코드를 얻기 위해 새로운 DNS조회를 수행해야 한다.

FAQ: 도메인과 Zone의 차이

 

도메인과 존은 혼동하기 쉬운 용어다. 특정 네임 서버가 자신의 하위에 위치한 도메인을 전적으로 관리하면 존과 도메인이 동일하지만, 하부에 새로운 도메인이 추가되면 두 영역이 일치하지 않게 되기 때문이다. 즉 미리 힌트를 주자면 도메인 단위로 볼지(도메인), 네임 서버가 관리하는 단위로 볼지(Zone)에 따라 달라진다.

 

아래 그림을 보면서 차이를 이해해보자.

 

 

도메인은 .으로 구분된 영역으로 최상위 도메인에서 부터 시작해 단계적으로 하위에 위임된 이름의 명칭이다. 다시 말해 도메인은 하나의 노드가 관리하는 영역을 의미한다. 위 그림에서 보이듯, com 도메인은 .com으로 등록된 모든 도메인을 포함하는 단어가 된다. 또 다른 도메인인 naver.com은 naver를 포함한 그 하위 영역(초록색 영역)에 해당 한다.

 

이와 달리 Zone은 하나의 네임 서버가 관리하는 영역을 의미한다. 위 그림을 보면 naver가 네임 서버의 역할을 한다고 하면 naver네임서버 하위의 노드들의 정보는 naver.com의 네임서버가 관리하는 동시에 해당 영역이 하나의 존으로 형성된다.


FAQ: hostname과 domain name의 차이, 그리고 FQDN

인터넷에서 호스트란 IP주소를 설정함으로써 인터넷 망에 연결된 통신가능한 요소를 의미한다. 즉 쉽게 말하면 IP주소를 사용하여 통신할 수 있는 ‘무언가'를 의미한다.

 

호스트의 기준은 IP주소다. 서버, 개인용 PC, 라우터 모두 인터넷 망의 호스트다. 모두 IP주소를 사용해 통신할 수 있기 때문이다.

 

따라서 hostname(호스트 이름)은 이런 host에 부여된 이름을 의미한다. IP주소를 갖고 있는 ‘무언가'에 이름을 부여한 것이다. 로컬 네트워크에서 네트워크에 연결된 특정 device를 식별하기 위해 사용되기도 하고, 인터넷에서 특정 디바이스를 식별하기 위해 우리가 사용하는 도메인 주소인 FQDN의 한 부분으로서 사용되기도 한다. (FQDN 자체를 hostname으로 부르기도 함 (짜증..))이렇게 이름을 부여하는 이유는 IP주소만으로는 사람이 ‘무언가'가 누구인지 기억하기 어렵기 때문에 기억하기 쉬운 이름을 부여하여 통신에 사용한다.

얘기만 들었을때는 hostname과 도메인 이름(domain name)의 의미가 차이가 없게 느껴진다. 하지만 조금 더 디테일하게 들어가보자. 우리가 인터넷에서 웹페이지를 방문할때는 [호스트 이름]. [도메인]. [tld] 순으로 작성된 도메인 이름을 사용하고, 이를 FQDN(Fully Qualified Domain Name)라고 부른다. 그리고 이 FQDN을 구성하는 요소가 호스트 이름과 도메인 이름이다. 이를 다시 말하면 호스트 이름은 도메인 전체 이름의 한 부분이다.

 

원래 도메인 이름에는 사용할 수 있는 문자에 제한이 없다. 하지만 우리가 A레코드나 AAAA레코드를 설정할 때는 한글로 된 도메인인을 사용할 수 없다. 한글로된 도메인 이름은 도메인 이름이기는 하지만 호스트 이름이 아니기 때문이다.

 

hostname의 예를 들어보겠다.

  • www.naver.com: www
  • m.naver.com: m
  • products.office.com: products
  • www.microsoft.com: www

우리가 흔히들 사용하는 www는 main 웹서버를 지칭하는 conventional한 이름이다. 쉽게 말해서 www.google.com이라고 표현하면 google.com의 main 웹서버임을 의미한다. www외에도 mail, products 등과 같은 hostname이 있듯이 hostname/FQDN들은 웹서버 뿐 아니라 다른 서버에도 사용된다.

 

근데 이 개념을 이해하면서 필자는 hostname과 subdomain의 차이가 궁금했다. 느낌상 hostname이 subdomain인 것처럼 느껴졌기 때문이다. 그럼 m.naver.com의 경우에는 m이라고 지칭된 특정 노드가 있는 것처럼 해석되는데, 좀 혼란스러웠다. 찾아본 결과 hostname부분을 실제로 인터넷에 연결된 node를 지칭하기 위해 사용할지, 아니면 subdomain으로 사용할지는 사실 해당 domain 관리자가 결정할 영역이라고 한다. (즉 사용하기 나름이라는 것) 예를 들어 mail.google.com만 하더라도 이 도메인에 붙은 무수하게 많은 mail server들이 같이 동작하고 있을꺼기 때문에 mail이라는 hostname을 가진 특정 노드는 없다.

 

자 이제 hostname의 뜻을 정리해보자

  • FQDN을 구성하는 한 부분으로서의 hostname으로, 특정 node를 지칭
  • 특정 node가 아닌 subdomain으로서의 역할을 하지만, hostname으로 사용
  • FQDN자체를 hostname으로 부르는 경우도 있긴함.

 

URL 구조 분석

여태까지 이해한 내용을 토대로 URL structure를 정리하면 아래와 같다.

URL : http://subdomain.domain.com:1234/

  • Protocol : HTTP
  • Hostname : subdomain
  • Domain name : domain.com
  • FQDN : subdomain.domain.com
  • Port : 1234
  • Top Level Domain : com
  • Scheme : HTTP
  • Host : FQDN(subdomain.domain.com) 도메인이 없는 경우에는 IP 주소가 Host가 됨

FAQ: A record란? CNAME record란?

A record

DNS의 주 목적은 사람이 기억하기 어려운 IP주소를 human-readable하게 만들어주는 것이다. 그런 의미에서 A record는 DNS record의서 가장 핵심적인 record 타입이다. 서버의 IP address와 domain 이름(예: richet.com)이 매핑된 레코드이기 때문이다. 즉 A record란 서버의 주소를 찾아가기 위한 가장 기본적인 방법이다. 참고로 A record는 IPv4 address와 동작한다. (IPv6 address는 AAAA record사용해야함)

아래와 같은 예의 경우에는 blog.richetdns.com이라는 도메인 이름이 211.31.17.218에 호스팅하고 있는 서버와 매핑된 A record다.

NAME                   TYPE       VALUE
blog.richetdns.com.     A        211.31.17.218
mail.richetdns.com.     A        169.31.17.218

실제로 도메인과 매핑된 IP를 확인하려면 nslookup 명령어를 사용하면 되는데, 우리가 흔히 사용하는 www.naver.com에 대해 실행해보면 223.130.200.107라는 IP에 매핑돼있는 것을 볼 수 있다.

~ nslookup www.naver.com
Server:        168.126.63.1
Address:    168.126.63.1#53

Non-authoritative answer:
www.naver.com    canonical name = www.naver.com.nheos.com.
Name:    www.naver.com.nheos.com
Address: 223.130.195.200
Name:    www.naver.com.nheos.com
Address: 223.130.200.107

CNAME record (Canonical)

cname record는 하나의 도메인 네임을 다른 이름으로 매핑 시키는 방법이다. A 레코드는 도메인 이름과 IP가 매핑됐다면, cname 레코드는 도메인 이름과 도메인 이름을 매핑시킨다.

cname 레코드는 alias도메인이나 subdomain을 만들 때 사용한다.

예를 들어 보겠다.

blog.richetdns.com.      CNAME   richet.github.io.
richet.github.io.      CNAME   github.map.fastly.net.
github.map.fastly.net.  A       185.31.17.133

위의 경우엔 나의 richet.github.io의 CNAME으로 blog.richetdns.com을 사용하고, github.map.fastly.net의 CNAME으로 richet.github.io를 사용하는 예시다.

즉, 위처럼 CNAME을 설정할 경우 blog.richetdns.com으로 접근하면 github.map.fastly.net으로 연결되고, A record로 입력된 185.31.17.133으로 연결된다. 여기서 확인할 수 있는 것은 CNAME은 아예 다른 domain이름에 대해서도 만들 수 있다는 점이다.

 

CNAME을 사용하는 예시로 개인 도메인을 티스토리 블로그와 연동시키는 경우를 들 수 있다. host.tistory.com에 대한 CNAME레코드를 만들고, tistory에 해당 개인 도메인을 등록하면 된다. (물론 티스토리 블로그의 IP주소를 가져다가 A레코드로 만들 수도 있지만, IP주소가 바뀌거나 하면 404가 발생하기 때문에 CNAME 사용을 추천한다)

A record vs CNAME record

그렇다면 DNS에 도메인을 등록할 때 A record를 사용할까, CNAME record를 사용해야 할까? 예시를 들어보며 각각의 장점을 알아보자

A record의 장점은 한 번의 요청으로 찾아갈 서버의 IP주소를 한번에 알 수 있다는 점이다. 반면 단점은 IP주소가 자주 바뀌는 환경에서는 번거로울 수 있다.

richet.com       - A Record  - 211.219.31.2 (Production Server IP)
test.richet.com  - A Record  - 172.39.12.31 (Test Server IP)
blog.richet.com  - CNAME     - 211.219.31.2 (Production Server IP)
dev.richet.com   - CNAME     - 172.39.12.31 (Test Server IP)
beta.richet.com  - CNAME     - 172.39.12.31 (Test Server IP)
haha.richet.com  - CNAME     - 211.219.31.2 (Production Server IP)

예를 들어 하나의 IP주소에서 blog.richet.com, haha.richet.com과 같은 여러개의 서브 도메인들을 처리하고 있다고 해보자. 만약 Production Server 나 Test Server의 IP가 변경됐을 때 위처럼 각 서브도메인들을 A 레코드로만 매핑 시킨다면, 모든 A레코드를 찾아서 변경해야 한다.

CNAME레코드는 IP주소가 자주 변경되는 환경에서 유연하게 대응할 수 있다는 점이다.

richet.com       - A Record  - 211.219.31.2 (Production Server IP)
test.richet.com  - A Record  - 172.39.12.31 (Test Server IP)
blog.richet.com  - CNAME     - richet.com
dev.richet.com   - CNAME     - test.richet.com
beta.richet.com  - CNAME     - test.richet.com
haha.richet.com  - CNAME     - richet.com

위의 예를 보면 blog.richet.com, haha.richet.com 과 같은 도메인 정보를 richet.com이라는 주소로 매핑시키는 CNAME레코드로 저장하고, richet.com을 특정 IP주소로 매핑시키는 A레코드로 저장한다면 Production Server의 IP주소가 바뀌었을 때 richet.com의 A레코드 정보만 변경시키면 된다.

 

다만 CNAME레코드를 사용하면 실제 IP주소를 얻을 때까지 여러번 DNS정보를 요청해야 한다. (e.g. beta.richet.comtest.richet.com에 매핑되는 정보 1번, test.richet.com이 Test Server IP와 매핑된 정보 얻는데 1번, 총 두번) 따라서 성능저하를 유발할 수 있다.

 

 

끝!!

 

참고자료

https://onlywis.tistory.com/14

https://mypage.domainclub.kr/faq_view.htm?category2=faq&no=95

https://ssungkang.tistory.com/entry/네트워크-서브도메인과-A-Record-CNAME

https://dnssec.tistory.com/26

https://serverfault.com/questions/269838/what-is-the-difference-between-a-hostname-and-a-fully-qualified-domain-name

https://www.ionos.com/digitalguide/domains/domain-administration/fqdn-fully-qualified-domain-name/

http://www.differencebetween.net/technology/difference-between-hostname-and-domain-name/

https://medium.com/basic-command-ls-linux/how-dns-works-b49c7395c91e

http://www.terms.co.kr/FQDN.htm