DNS를 알아보기 전에 도메인에 대해서 살펴보겠습니다.
도메인이란?
구글이나 네이버의 웹사이트에 IP 주소를 입력하고 접속하는 사람은 거의 없습니다. 대개는 다른 포털 사이트에서 검색해서 검색 결과의 링크를 타고 웹 사이트를 방문하거나 www.google.com이나 www.naver.com 같은 형태의 영문 주소를 웹 브라우저의 주소 창에 입력해서 웹 사이트에 접속합니다.
구글이나 네이버가 인터넷 공개한 IP 주소 대신 사용하는 www.google.com이나 www.naver.com 같은 형태의 영문 주소를 도메인(Domain) 또는 도메인 이름(Domain name, 또는 호스트 네임, Host name)이라고 합니다.
즉, 도메인이란 숫자 형태의 IP 주소를 사람이 기억하기 쉬운 문자로 표현한 주소입니다.
<그림 1> IP 주소와 도메인
쉽게 이해하는 네트워크 15. 도메인 의미와 계층 구조 및 DNS 네임 서버(ft. 도메인의 가치) (tistory.com)
DNS
휴대폰으로 전화를 걸 때 모든 전화번호를 외우지 않고, 휴대폰 연락처에 저장해 놓은 이름과 전화번호를 사용합니다. 전화를 걸 상대방의 이름을 입력하면 연락처에서 이름에 대응하는 전화번호가 검색되는 시스템을 이용한 것입니다.
휴대폰 연락처와 같이 도메인과 IP 주소를 저장해 놓은 시스템을 DNS(Domain Name System)라고 합니다. 즉 DNS는 전 세계의 IP 주소에 대응하는 도메인을 효율적으로 관리하기 위해 개발된 시스템입니다. IP 주소와 도메인을 저장하고 관리하는 컴퓨터나 애플리케이션을 DNS 서버라고 합니다. 다시 말해 DNS 서버는 IP 주소와 도메인을 저장하고 맵핑(mapping)하는 일종의 데이터베이스입니다.
학교나 기업의 네트워크에서 자체적으로 DNS 서버를 만들어 운영하기도 하고, ISP가 관리하는 DNS 서버를 사용할 수도 있습니다. 이러한 DNS 서버들이 전 세계의 모든 호스트들의 IP 주소와 도메인을 관리하며 IP 주소를 도메인으로 변환하거나 도메인을 IP 주소로 변환하는 DNS 서비스를 제공하고 있습니다.
따라서 도메인에 대응하는 IP 주소를 알고 싶거나 IP 주소에 대응하는 도메인을 알고 싶으면 DNS 서버에게 물어보면 됩니다.
즉, DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환해 주는 역할을 하는 시스템입니다. 그리고 이러한 변환 시스템을 운영하고 있는 서버를 DNS 서버, 또는 네임서버라고 합니다. 이 DNS 서버에 요청이 들어오면 도메인 주소와 연결되어 있는 IP 주소를 찾아서 응답하지요.
한 번 전체적인 과정을 살펴볼까요?
먼저 일반 사용자, 즉 호스트는 원하는 도메인을 브라우저에 입력합니다. 우리의 컴퓨터는 보통 DNS 서버의 IP를 기억하고 있는데, 따라서 입력받은 뒤 DNS 서버의 IP로 아까 받았던 도메인 주소를 전달합니다.
그럼 DNS 서버는 평소에는 수많은 도메인 이름들을 기억하고 있다가, 어떤 호스트에게서 요청이 들어오면 받은 도메인이 가리키고 있는 IP 주소를 찾아서 반환합니다.
그 결과 호스트는 받은 IP 주소와 일치하는 서버에 접근할 수 있게 됩니다.
[해치지 않는 웹] 4. DNS (brunch.co.kr)
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 서버에 보내는데 이를 반복적 쿼리라고 한다.
아래의 예를 통해 쿼리 과정을 설명하겠다.
<도메인의 재귀적, 반복적 쿼리>
- 사용자 호스트는 'zigispace.net'이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
- 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 'zigispace.net'에 대해 쿼리
- DNS 서버는 'zigispace.net'이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에. net에 대한 TLD 정보를 가진 도메인 주소를 쿼리
- 루트 DNS는 'zigispace'의 TLD인 '.net'을 관리하는 TLD 네임 서버 정보를 DNS에 응답
- DNS는 TLD 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리
- TLD 네임 서버는 'zigispace.net'에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답
- DNS는 zigi 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리
- zigi 네임 서버는 'zigispace.net'에 대한 정보를 DNS 응답
- DNS는 'zigispace.net'에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 'zigispace.net에 대한 정보를 응답
- 사용자 호스트는 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://rooftoproom-whale.tistory.com/36
참고서적: 고재성, 이상훈.『IT 엔지니어를 위한 네트워크 입문』. 길벗. 2022
'Network tech > IP(Internet Protocol)' 카테고리의 다른 글
[TCP/UDP] TCP에 대해서 알아보자! (0) | 2023.07.27 |
---|---|
[DHCP] IP를 동적으로 할당하는 데 사용하는 프로토콜_DHCP (0) | 2023.07.26 |
[IP network] NAT(Network Address Translation)은 무엇인가? (0) | 2023.07.25 |
[IP 주소] 공인 IP와 사설IP (0) | 2023.07.22 |
[IP 클래스] IP 주소의 '클래스' _ A클래스, B클래스, C클래스 (0) | 2023.07.21 |