DNS(Domain Name System)란

네트워크 프로토콜에는 실제 데이터를 실어 나르는 데이터 프로토콜과 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜이 존재한다.

컨트롤 프로토콜에는 ARP, ICMP, DNS가 있다. 이 중 DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 역할을 한다. 

도메인 주소가 IP 주소보다 일반 사용자에게 더 익숙하고 서버 IP 변경에 쉽게 대처할 수 있어 네트워크에서 DNS 역할이 매우 중요하다.

---

DNS 소개

웹사이트의 주소는 IP 주소보다 도메인 주소 기반을 자주 사용하는데 이는 사용자가 쉽게 인식하고 기억하기에는 도메인 주소가 적합하기 때문이다. 

물론 도메인 주소를 이용하더라도 3계층 IP 주소를 알아야 하고 이를 위해 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 DNS 정보를 알아야 한다.

사용자가 도메인 주소를 이용하여 서비스를 요청하면 네트워크 설정에 입력한 DNS로 해당 도메인에 대한 IP 주소 질의를 보내고 그 결괏값으로 요청한 도메인 서비스 IP 주소를 받게 된다.

naver.com 접속 절차

1. 사용자가 naver.com을 입력하면 DNS 서버에 naver.com 주소가 무엇인지 질의
2. DNS 서버는 naver.com의 IP 주소가 202.179.177.21이라는 주소를 이용해 실제 naver.com에 접속

<참고>
사용자가 서비스를 찾아갈 때뿐만 아니라 내부 시스템의 서비스 간 연결에도 DNS를 사용한다.
서비스 간 연결을 IP로 한다면 IP 변경이 필요할 경우, 여러 가지 설정을 변경하거나 프로그램을 재배포해야 한다.
이때 도메인 주소로 연결하면 DNS 서버에서 간단한 설정 변경만으로 복잡한 서비스 간 연결을 쉽게 변경 가능하다.

---

DNS 구조와 명명 규칙

도메인은 계층 구조여서 수많은 인터넷 주소 중 원하는 주소를 효율적으로 찾아갈 수 있다.

역 트리 구조로 최상위부터 Top-Level, Second-Level, Third-Level와 같이 하위 레벨로 원하는 주소를 단계적으로 찾아간다.

도메인 주소의 구성은 아래와 같다.

도메인 계층

도메인 계층은 최대 128 계층까지 구성할 수 있다. 계층별 길이는 최대 63바이트까지 사용할 수 있고 구분자 "."를 포함한 전체 도메인 네임의 길이는 최대 255바이트까지 사용할 수 있다.

루트 도메인

도메인을 구성하는 최상위 영역이고 DNS 서버는 사용자가 쿼리 한 도메인에 대한 값을 직접 갖고 있거나 캐시에 저장된 정보를 이용해 응답한다. 해당 도메인 정보가 없다면 루트 도메인을 관리하는 루트 DNS에 쿼리 한다.

아래는 전 세계 루트 서버 목록과 루트 서버 관리 기관이다.

호스트 이름	IP 주소	관리 기관
a.root-servers.net	198.41.0.4, 2001:503:ba3e::2:30	VeriSign, Inc.
b.root-servers.net	192.228.79.201, 2001:500:84::b	University of Southern California(ISI)
c.root-servers.net	192.33.4.12, 2001:500:2::c	Cogent Communications
d.root-servers.net	199.7.91.13, 2001:500:2d::d	University of Maryland
e.root-servers.net	192.203.230.10, 2001:500:a8::e	NASA(Ames Research Center)
f.root-servers.net	192.5.5.241, 2001:500:2f::f	Internet Systems Consortium, Inc.
g.root-servers.net	192.112.36.4, 2001:500:12::d0d	US Department of Defense(NIC)
h.root-servers.net	198.97.190.53, 2001:500:1::53	US Army (Research Lab)
i.root-servers.net	192.36.148.17, 2001:7fe::53	Netnod
j.root-servers.net	192.58.128.30, 2001:503:c27::2:30	VeriSign, Inc.
k.root-servers.net	193.0.14.129, 2001:7fd::1	RIPE NCC
l.root-servers.net	199.7.83.42, 2001:500:9f::42	ICANN
m.root-servers.net	202.12.27.33, 2001:dc3::35	WIDE Project

Top-Level Domain(TLD)

최상위 도메인인 TLD는 IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형으로 구분할 수 있다.

• Generic(gTLD)
• country-code(ccTLD)
• sponsored(sTLD)
• infrastructure
• generic-restricted(grTLD)
• test(tTLD)

Generic TLD(gTLD)

특별한 제한 없이 일반적으로 사용되는 최상위 도메인이며 세 글자 이상으로 구성된다. 여러 가지의 gTLD가 있지만 대표적인 것은 아래와 같다.

gTLD	설명
com	일반 기업체
edu	4년제 이상 교육기관
gov	미국 연방정부기관
int	국제기구, 기관
mil	미국 연방군사기관
net	네트워크 관련 기관
org	비영리기관

country-code TLD(ccTLD)

국가 최상위 도메인으로 ISO 3166 표준에 의해 규정된 두 글자의 국가 코드를 사용한다. 우리나라는 "kr"을 사용한다.

ccTLD를 사용하는 경우, gTLD처럼 사이트 용도에 따른 코드를 사용한다. 예를 들어 일반 회사는 co.kr, 정부기관은 go.kr을 사용하는 방법이다.

sponsored TLD(sTLD)

특정 목적을 위한 스폰서를 두고 있는 최상위 도메인이다. 종류로는 ".aero", ".asia", ".edu" 등이 있다.

infrastructure

운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인이다. 종류에는 ".arpa"가 있다.

generic-restricted(grTLD)

특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인이다. 종류에는 ".biz", ".name", ".pro"가 있다.

test(tTLD)

IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인이다. 종류에는 ".test" 가 있다.

---

DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리 하는 과정을 거쳐야 한다.

도메인을 쿼리 하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인한다. 이는 동일한 도메인을 매번 질의하지 않고 캐시를 통해 성능을 향상하기 위해서이다.

캐시 정보에는 DNS조회를 통해 확인한 동적 DNS 캐시와 hosts 파일에 저장되어 있는 정적 DNS 캐시가 존재한다.

캐시에 필요한 도메인 정보가 없다면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장한다.

윈도우에서 DNS 캐시를 확인하는 방법은 cmd 창에서 'ipconfig /displaydns' 명령을 사용한다.

 

인터넷 상용화 전에는 hosts 파일을 이용해 호스트 이름과 IP을 매핑하여 사용했다. 하지만 상용화된 후에는 폭증하는 단말들을 중앙화된 체계로 수용하기 위해 DNS 체계가 만들어졌다.

아래는 캐시와 DNS를 이용해 도메인 이름 쿼리를 하는 예제이다. 로컬 캐시를 조회 후 로컬 캐시에 없다면 DNS 서버로 다시 쿼리 한다.

로컬 캐시 유무에 따른 도메인 쿼리 방법

해당 과정은 DNS 시스템 관점에서 도메인에 대한 결괏값을 클라이언트에 보내주는 과정이다.

기본적으로 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받는다. 

DNS 기능을 서버에 올리면 DNS 서버를 기본적으로 루트 DNS 관련 정보를 가지고 있다. 클라이언트 쿼리가 자신에게 없다면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리 한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS가 어디인지 응답한다.

전체 과정을 보면 DNS 가 중심이 되어 루트부터 상위까지 차근차근 쿼리를 보내 결괏값을 알아내고 클라이언트에 응답한다. 호스트가 DNS 서버에 질의했던 방식을 재귀적 방식, DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내는데 이를 반복적 쿼리라고 한다.

아래의 예를 통해 쿼리 과정을 설명하겠다.

도메인의 재귀적, 반복적 쿼리

1. 사용자 호스트는 'zigispace.net'이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
2. 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 'zigispace.net'에 대해 쿼리
3. DNS 서버는 'zigispace.net'이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에. net에 대한 TLD 정보를 가진 도메인 주소를 쿼리
4. 루트 DNS는 'zigispace'의 TLD인 '.net'을 관리하는 TLD 네임 서버 정보를 DNS에 응답
5. DNS는 TLD 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리
6. TLD 네임 서버는 'zigispace.net'에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답
7. DNS는 zigi 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리
8. zigi 네임 서버는 'zigispace.net'에 대한 정보를 DNS 응답
9. DNS는 'zigispace.net'에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 'zigispace.net에 대한 정보를 응답
10. 사용자 호스트는 DNS로부터 받은 'zigispace.net'에 대한 IP 정보를 이용해 사이트 접속

---

마스터와 슬레이브

DNS 서버는 마스터(Master, Primary) 서버와 슬레이브(Slave, Secondary) 서버로 나눌 수 있다. 마스터와 슬레이브에 우선순위는 존재하지 않고 모두 도메인 쿼리에 응답한다. 

두 서버를 구분하는 기분은 도메인에 대한 존(Zone) 파일을 직접 관리하는지 여부이다.

마스터는 존 파일을 직접 생성해 도메인 관련 정보를 관리하고

슬레이브 서버는 마스터에 만들어진 존 파일을 복제한다. 이 과정을 영역 전송(Zone Transfer)이라고 한다.

 

DNS 마스터, 슬레이브 서버는 이중화에서 일반적으로 사용하는 액티브-스탠바이(Active-Standby)나 액티브-액티브(Active-Active) 형태로 구성하지 않는다. 

DNS 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답할 수 없다. 이 시간을 만료 시간(Expiry Time)이라고 하고 SOA 레코드에 설정된다.

만료시간 안에 슬레이브 서버가 마스터 서버에서 존 정보를 가져오지 못하면 슬레이브는 존 정보를 사용할 수 없다.

따라서 만료시간 안에 마스터 서버를 복구하거나 슬레이브 서버를 마스터로 전환해야만 서비스 장애를 막을 수 있다.

<참고>
액티브-스탠바이 : 두 개의 노드 중 액티브 노드만 서비스를 제공하고 스탠바이 노드는 대기하고 있다가 액티브에 장애가 발생하면 서비스를 시작
액티브-액티브 : 두 개의 노드가 동시에 서비스를 제공하고 한 노드에 문제가 발생하면 다른 노드에서 서비스를 계속 제공

---

DNS 주요 레코드

도메인에는 다양한 내용을 매핑할 수 있는 레코드가 있다. 다양한 DNS 레코드 중 주로 사용하는 몇 가지 레코드는 아래와 같다. 

레코드 종류	내용
A(IPv4 호스트)	도메인 주소를 IP 주소(IPv4)로 매핑
AAAA(IPv6 호스트)	도메인 주소를 IP 주소(IPv6)로 매핑
CNAME(별칭)	도메인 주소에 대한 별칭
SOA(권한 시작)	본 영역 데이터에 대한 권한
NS(도메인의 네임 서버)	본 영역에 대한 네임 서버
MX(메일 교환기)	도메인에 대한 메일 서버 정보(Mail eXchanger)
PTR(포인터)	IP 주소를 도메인에 매핑(역방향)
TXT(레코드)	도메인에 대한 일반 텍스트

A(IPv4 호스트)

A 레코드는 기본 레코드로 도메인 주소를 IP 주소로 변환하는 레코드이다.

사용자가 DNS에 질의한 도메인 주소를 A 레코드에 설정된 IP 주소로 응답한다. 

도메인과 IP 주소를 1:1, 1:N, N:1로 매핑 가능하다. 만약 서버 1 대에 여러 웹 서비스를 구동해야 한다면 여러 도메인에 동일한 IP를 매핑하고 HTTP 헤더의 HOST 필드에 도메인을 명시해 웹 서버를 구분해 서비스할 수 있다.

AAAA(IPv6 호스트)

AAAA 레코드는 A와 달리 IPv6 주소 체계에서 사용되며 역할은 같다.

CNAME(별칭)

이 레코드에는 도메인 주소를 매핑한다. 네임 서버가 CNAME 레코드에 대한 질의를 받으면 CNAME 레코드에 설정된 도메인 정보를 확인하고 그 도메인 정보를 내부적으로 다시 질의한 결과 IP 값을 응답한다. 대표적으로 "www"가 있다.

도메인에 대한 IP 주소 변경 시 레코드값 설정 변경

그림에 대해 설명하자면, 구글이라는 웹 사이트를 접속할 때(구글이 해당 그림처럼 설정돼있다고 가정) google.com, google.co.kr으로 접속한다. 이 두 주소를 각각 A 레코드로 매핑하면 IP 주소 변경 시 둘 다 값을 변경해야 한다.

하지만 CNAME 레코드를 활용하면 google.com에 대한 IP주소만 변경해도 된다.

SOA(Start Of Authority:권한 시작)

도메인 영역에 대한 권한을 나타내는 레코드이다.  SOA 레코드는 해당 도메인의 주 DNS 서버에 이름을 할당하고, 데이터를 얼마나 오래 캐시에 저장할 수 있는지 지정하는 레코드이고 SOA 레코드가 없을 경우 다른 레코드를 등록할 수 없다.

NS(Name Server:도메인의 네임 서버)

도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드이다. 권한이 있는 네임 서버 정보를 해당 도메인에 설정하는 역할 외에 하위 도메인에 대한 권한을 다른 네임 서버로 위임하는 역할로도 사용된다.

네임서버(Name Server) : 도메인 이름과 IP의 상호변환을 가능하게 해주는 서버

MX(Mail eXchange:메일 교환기)

메일 서버를 구성할 때 사용되는 레코드이다. 해당 도메인을 메일 주소로 갖는 메일서버를 해당 레코드로 선언한다.

메일서버에서 메일을 보낼 때는 MX 레코드를 참조해 동작하는데 우선순위 값을 이용해 다수의 MX 레코드를 선언할 수 있다.

PTR(Pointer:포인터)

이 레코드는 A 레코드와 반대로 IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드이다. A 레코드가 정방향 조회용이라면 PTR은 역방향 조회용이다. 하지만 A와 달리 IP와 도메인이 1:1 관계만 갖는다.

TXT(TeXT:레코드)

도메인에 대한 설명과 같이 간단한 텍스트를 입력할 수 있는 레코드이다.

---

DNS에서 알아두면 좋은 내용

• 도메인 위임
• TTL
• 화이트 도메인
• 한글 도메인

도메인 위임(DNS Delegation)

도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만 도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임하기도 한다. 즉, 자신이 가진 도메인 관리 권한을 다른 곳으로 일부 위임해 위임한 곳에서 세부 레코드를 관리하도록 하는 것이다.

이 방법이 가능한 이유는 도메인은 계층 구조이기 때문에 특정 계층의 레코드를 위임하면 해당 레코드의 하위 계층은 함께 위임 처리되기 때문이다.

위임을 통해 특정 도메인의 하위 도메인을 별도로 관리

그림처럼 A DNS 서버는 5개의 레코드 정보가 있다. 이때 도메인 하위에 post영역을 추가하고 해당 영역을 B GSLB에서 관리하려고 할 때 A DNS 서버는 post 영역 관리 권한을 B GSLB로 넘겨줄 수 있다.

즉, 도메인 위임 기능을 쓰면 특정 영역을 다른 네임 서버에서 관리할 수 있는 권한을 위임하게 된다. 특정 영역에 대한 관리 주체를 분리하는 용도로 사용할 수 있어 계열사에서 특정 도메인을 분리하거나 GSLB 등 다양한 용도로 사용 가능하다.

TTL

도메인의 TTL(Time To Live)은 DNS에 질의해 응답받은 결괏값을 캐시에서 유지하는 시간을 뜻한다.

로컬 캐시에 저장된 도메인 정보를 계속 갖고 있는 것이 아니라 DNS에 설정된 TTL 값에 따라 그 시간만 저장한다.

 

TTL 값이 클수록 DNS 재귀적 쿼리로 인한 응답 시간을 많이 줄일 수 있고 결과적으로 전체 네트워크 응답 시간이 단축된다. 하지만 DNS에서 도메인 관련 정보가 변경되었을 때 새로 변경된 값으로 DNS 정보 갱신이 오래 걸린다.

TTL 값이 작을수록 DNS의 정보 갱신이 빨라지므로 DNS 쿼리량이 늘어나 DNS 서버 부하가 증가할 수 있다.

그래서 TTL은 상황에 따라 적절히 조절하는 것이 좋다.

화이트 도메인

정상적인 도메인을 인증, 관리하는 제도로 스팸메일 차단 활동에 사용된다. 반대로 불법적인 스팸메일을 발송하는 사이트를 실시간 블랙리스트 정보로 관리하는 것을 RBL(Realtime Blackhole List)라고 한다.

그래서 도메인 등록 시 화이트 도메인에 등록해야 하며 사전에 해당 도메인에 SPF(Sender Policy Framework)가 설정되어 있어야 한다.

SPF 레코드를 통해 등록된 정보와 일치하는지 확인한다. 일치하지 않는다면 비정상적인 메일 서버에서 전송된 것으로 간주해 스팸 처리한다.

최대 길이는 512바이트이기 때문에 유의해야 한다.

도메인에 SPF 레코드를 설정하려면 TXT 레코드를 사용한다. 설정 방법은 아래와 같다.

● Windows(TXT 레코드 사용)
 o 최초 등록 SPF: v=spf1 ip4:x.x.x.x -all
 o 추가 등록 SPF: v=spf1 ip4:x.x.x.x ip4:x.x.x.x -all
● Unix, Linux
 o 최초 등록 SPF: Domain. IN TXT "v=spf1 ip4:x.x.x.x -all"
 o 추가 등록 SPF: Domain. IN TXT "v=spf1 ip4:x.x.x.x ip4:x.x.x.x -all"

한글 도메인

도메인 주소는 한글로도 만들 수 있는데 사용자가 도메인을 한글로 등록하고 DNS에서는 한글을 퓨니코드로 변경하고 이 퓨니코드를 DNS에 도메인을 생성해야 한다.

퓨니코드(Punycode) : 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법

---

호스트 파일 설정

DNS을 이용해 도메인 주소를 IP 주소로 변환하는 방법 외에도 도메인과 IP 주소를 매핑해놓은 hosts 파일을 이용하여 도메인-IP 주소 쿼리를 사용할 수 있다.

hosts로 설정한 도메인 정보는 로컬 호스트의 DNS 캐시 정보로 남기 때문에 DNS에 의한 질의보다 우선순위가 높다.

즉, 테스트 목적으로 사용한 후 해당 도메인 정보를 삭제하지 않으면 원하는 접속이 안될 수 있다.

hosts 파일을 임의로 조작해 사용자의 정보를 빼내는 방법이 존재하는데 사이트의 디자인을 동일하게 구성하고 도메인도 원래 도메인 그대로 사용해 접속한 것처럼 보여 매우 위험하다. 그래서 보안 프로그램에서 hosts 파일이 변경되었습니다 라는 경고 팝업창이 뜨는 것이다.

<참고>
https://server-talk.tistory.com/176
https://ddka.tistory.com/entry/SOA-%EB%A0%88%EC%BD%94%EB%93%9Cstart-of-authority-record