1. DNS(Domain Name Service)란?
우리가 Google 웹 사이트에 접속한다고 생각해 보자. 거의 모든 사람이 www.google.com으로 접속하지 172.217.160.78이나 142.250.74.14(Google 웹 서버의 IP 주소)를 입력해서 접속하지는 않을 것이다. 이때 www.goole.com과 같이 IP주소를 사람이 읽을 수 있는 방식으로 대신한 방법이 도메인 네임(Domain Name)이다. 또한 도메인 네임을 IP 주소로 변환해 주는 것을 이름 해석(name resolution)이라고 하는데 이러한 과정을 해주는 컴퓨터(또는 서버)가 DNS(Domain Name System) 서버(Linux에서는 Name Server라고 한다)이다.
그렇다면 DNS 서버가 없었을 때는 어떻게 했을까? 가장 기본적인 방법은 IP 주소를 직접 쳐서 접속하는 것이다. 초창기에는 컴퓨터가 많지 않았기 때문에 주로 접속하는 사이트의 IP 주소를 적어놓고 접속하는 것이 가능했을 것이다. 그러다 컴퓨터 대수가 점점 증가하면서 사용된 방식이 /etc/hosts(Windows의 경우 C:\Windows\system32\drivers\etc\hosts) 파일을 사용하는 것이다.
다음과 같이 IP 주소와 URL을 hosts 파일에 기록해 놓으면 URL을 이용하여 패킷을 보내도 자동으로 IP주소로 매칭되어 접속이 가능하다. 그러나 컴퓨터가 대폭 증가하면서 hosts 파일을 이용하는 것도 한계에 봉착하게 되어 나온 것이 DNS이다(여전히 hosts 파일은 종종 사용된다).
DNS는 쉽게 비교하면 114와 같다. 우리는 서울 시청 민원실의 전화번호를 알지 못하면 114에 전화해서 "서울 시청 민원실(=도메인 네임)의 전화번호(=IP주소)를 알려주세요"라고 요청할 수 있고, 114는 우리의 요청을 받아 전화번호를 알려준다. 이러한 114처럼 DNS 서버도 클라이언트가 도메인 네임을 질의하면 해당 도메인 네임과 매칭되는 IP 주소를 알려준다.
초창기에는 DNS 서버 한 대만으로도 IP주소와 도메인 네임을 관리하는 것이 가능했으나, 기하급수적으로 컴퓨터가 증가하면서 몇 대의 서버만으로 모든 IP주소와 도메인 네임의 변경 사항을 적용하는 것이 불가능하게 되었다. 그래서 고안된 것이 다음과 같은 도메인 네임의 체계이다.
구조도에서도 보이듯이 모든 도메인(영역)을 한 대의 DNS 서버가 관리하지 않고, 루트 도메인(.)이 최상위 도메인(.kr, .jp, .com..)를, 최상위 도메인이 차상위 도메인(ac, co..)을, 차상위 도메인이 3차 도메인(daum.net., naver.com. ..)을 관리하는 계층적인 구조로 이뤄져 있다. 도메인 네임 체계를 고려하여 다음 도메인 네임을 읽으면 이렇게 해석할 수 있다.
| www.naver.com. | 루트 도메인 밑에 com 도메인 밑에 naver 도메인 밑에 있는 www라는 이름의 호스트 |
*루트 도메인(.)을 명시해주는 것은 매우 중요하다. 항상 인지하도록 하자(없을 경우 오류가 생기는 경우가 많다)
이제 우리는 www.naver.com이 속해있는 도메인이 naver.com이라는 것을 알게 되었다. 여기서 www.naver.com 과 같이 도메인 이름과 호스트 이름이 완전하게 갖춰진 도메인 네임의 형태를 FQDN(Fully Qualified Domain Name, 혹은 그냥 도메인 네임이라고 하기도 한다)이라고 명명한다. 도메인을 다음과 같이 간단히 정리했으니 참고해보도록 하자.
루트 도메인(root domain)
- 모든 도메인의 시작점
- 도메인 네임의 마지막에 . 으로 명시
일반 최상위 도메인(GTLD, General Top Level Domain)
- com => company
- net => network
- org => organization
국가 최상위 도메인(CCTLD, Country Code Top Level Domain)
- kr, jp, cn..
차상위 도메인
- ac, co, go
*DNS는 서비스 포트로 UDP 53(DNS query), TCP 53(DNS Zone Transfer)를 사용한다.
2. 도메인 네임을 해석하는 과정: DNS Query
이제 도메인 네임을 어떤 과정을 통해 해석(resolving)하는지 알아보자. 도메인 네임을 해석하여 IP주소를 얻는 과정을 DNS Query(질의)라고 한다. DNS Query는 재귀적으로(recursive) 이뤄지는데, 이는 원하는 결과를 얻을 때까지 서버들(루트, TLD, Master)에게 반복적으로 질의를 하여 클라이언트에 반환할 최종적인 답을 얻어냄을 의미한다. 다음은 DNS Query 과정을 구조도로 표현한 자료이다. 각 서버에 대한 설명은 차후 자세히 할 예정이니, 조금 이해되지 않는 부분이 있더라도 흐름 위주로 파악해보자. DNS Query에는 UDP 53번 포트를 사용한다.
1. PC(DNS Client)에서 Cache 네임 서버(Cache DNS Server)에게 www.evil.com의 IP주소를 질문한다.
*네임 서버(NS, Name Server)는 DNS 서버와 동일한 의미이다.
2. Cache 네임 서버(Local NS, Local Name Server)는 DNS Cache를 확인하여..
- 캐쉬된 내용이 있으면 바로 응답한다.
- 캐쉬된 내용이 없으면 상위 네임 서버들과 Name Resolution 과정을 수행한다.
- cache: 자주 사용하는 데이터나 요청에 대한 응답을 임시로 저장하는 메모리, 여기서는 Name Resolution을 통해 얻어온 정보를 임시로 DNS Cache에 저장하는 것을 의미한다.
3. 루트 힌트(root hint)를 통해 Cache 네임 서버는 동일한 질문(www.evil.com의 IP주소)을 루트 네임 서버에 질의한다.
- 루트 네임 서버는 자신이 아는 데까지 알려주고, 모를 경우 루트 도메인 안에 있는 com 도메인을 관리하는 com 네임 서버의 주소를 알려준다.
4. Cache 네임 서버는 com 네임 서버에 동일한 질문을 한다.
- com 네임 서버도 자신이 아는 데까지 알려주고, evil 도메인을 관리하는 evil.com 네임 서버의 주소를 알려준다.
5. Cache 네임 서버는 evil.com 네임 서버에 동일한 질문을 한다.
- evtl.com 네임 서버도 자신이 아는 데까지 알려준다 => evil.com 도메인 안에 있는 www 호스트의 주소를 알려준다.
6. Cache 네임 서버는 최초 질문에 대한 답을 얻었기때문에 알아낸 정보를 cache에 저장하고(Caching), 질문했던 PC(DNS Client)에게 알아낸 정보를 전달한다.
**DNS Query 명령어
nslookup
- DNS Query에 사용되는 명령어
- 옛날부터 많이 사용하여 대부분의 OS에서 지원된다
- dig에 비해 기능이 단순하고, 고급 기능이 부족하다
dig
- nslookup에 비해 고급 기능이 보강됐으나, Windows에서 지원하지 않는다
사용 방법
- nslookup
- set type=[질의 종류 ns, mx, a...]
3. NS 서버 종류(cache, master, gtld, cctld, root) 및 설정 방법
*Rocky Linux 9.4 기반 설정 방법 입니다.
*토폴로지 내에서 실습용으로 DNS 서버가 작동하게만 구성해놓은 것으로 세부적인 설정 방법은 다를 수 있습니다.
1) Cache NS
1. dns(인터넷이 연결되었을 경우 repository에서), rpm (인터넷이 안될 때, ISO 파일에서)을 이용해 DNS 서비스 데몬 패키지(bind) 설치
*왜 데몬 이름이 bind지?
BIND(Berkeley Internet Name Domain)는 가장 널리 사용되는 DNS(Domain Name System) 서버 소프트웨어(프로그램)이다.
2. /etc/named.conf (데몬 설정 파일) 설정
- listen-on port [포트 번호] { DNS 요청을 받을 네트워크 인터페이스의 IP 주소;} ;
- DNS 서버가 어떤 네트워크 인터페이스로부터 포트 번호를 통해 DNS 요청을 수신할지 설정
- any: 모든 요청을 받는다(IP 설정을 통해 제한할 수 있다)
- allow-query {DNS Query에 대해 응답할 클라이언트의 IP 주소;} ;
- 어떤 클라이언트의 DNS Query에 대해 응답할지 설정
- dnssec-validation [yes/no];
- DNS Query는 UDP 방식으로 통신되기 때문에, 신뢰할 수 없다(위, 변조 여부를 확인할 수 없음)
- 이런 부분을 보완하기 위해 나온 것이 DNSSEC(DNS 서비스 보안 모듈)
- 기본적인 실습을 위해 DNSSEC를 해제해준다
3. DNS 서비스 데몬 실행 및 확인
systemctl start named
systemctl satus named
netstat -anp | grep named
*root hint: 루트 NS의 주소를 적어놓은 파일 (루트 네임 서버는 A~M까지 전 세계에 13개가 존재한다)
=> 실습 시 모든 루트 NS을 만들기 힘들기 때문에 필요한 루트 힌트만 남겨두고 지워서 사용하자!
2) Authoritative NS (권위있는 네임 서버, Master NS) (daum.net.)
권한 있는 네임 서버(Authoritative NS)는 naver.com., google.com.과 같은 특정 도메인을 관리하고 최종적인 응답을 제공하는 NS이다.
1. 기본적인 설정은 Cache NS와 동일 (1~3번을 선행하여 설정하기)
2. 권한 있는 NS로 설정 (/etc/named.conf 또는 named.rfc1912.zones에 설정)
*데몬이 실행될 때, include된 파일이 함께 실행되기 때문에 어디에 설정해도 상관없다(관리 목적으로 분리)
/etc/named.rfc1912.zones에 다음과 같이 설정해준다.
zone "daum.net" IN { //zone = domain
type master; //master => 내가 이 domain의 주인이다
file "daum.net.zone"; // zone file => 이 영역에 대한 정보는 daum.net.zone 파일에 있다
};
3. 존 파일(zone file) 수정
- vi /var/named/daum.net.zone 으로 도메인의 존 파일을 만들고 아래의 내용을 설정한다
$TTL 1D
@ IN SOA ns1.daum.net. admin.daum.net. (
<-- "이 존파일은 daum.net Domain에 대한 정보이다" 라는 선언
2023092101
1D
1H
1W
3H
)
@ IN NS ns1.daum.net.
ns1 IN A 10.255.0.111
----------------------------------------------------------------------------------------------
@ => 현재 도메인 = daum.net.
SOA(Start of Authrity) => 존의 권한에 대한 레코드(관리 정보와 기본 설정 제공)
ns1.daum,net. => 현재 도메인의 네임서버의 이름
admin.daum.net. => 관리자의 이메일 주소
2023092101 => 시리얼 넘버(**존 파일이 변경될 경우 시리얼 번호를 증가시켜줘야 함/일반적으로 YYYYMMDDNN 형식)
1D => refresh 타이머, slave 네임 서버가 master 네임 서버에 변경 사항을 재조회하는 간격
1H => retry 타이머, slave 네임 서버가 master 네임 서버에 연결이 실패했을 때, 재접속하는 간격
1W => expire 타이머, master/slave 서버 간의 연결이 일정 시간 이상 실패하면 해당 존 데이터를 폐기하는 시간
3H => Minimum TTL, DNS 레코드가 최소한 유지되어야 하는 시간
@ IN NS ns1.daum.net.
=> 현재 도메인의 NS 레코드(도메인을 관리하는 네임 서버의 이름을 기록한 것)
ns1 IN A 10.255.0.111
=> ns1은 .이 붙지 않기 때문에 @이 붙었다고 상정하게 된다
=> ns1 = ns1.daum.net.
=> ns1.daum.net.의 A 레코드(도메안 네임의 IPv4 주소)
4. DNS 서비스 데몬 실행 및 확인
뒤에서 사용 될 DNS Query type과 레코드(record) 대해서도 미리 알아두자.
*DNS Query type(질의 유형)
: DNS Query 시 특정 레코드를 질의하여 필요한 정보를 가져오게 된다. 레코드의 종류는 다음과 같다.
A(Address) 레코드
- 도메인 이름을 IPv4 주소로 변환
AAAA(IPv6 Address) 레코드
- 도메인 이름을 IPv6 주소로 변환
CNAME(Canonical Name) 레코드
- 도메인 이름을 다른 도메인 이름으로 매핑
- www.naver.com이 naver.com의 CNAME을 가질 경우, www.naver.com을 쳤을 때, naver.com으로 리다이렉트(redirect) 된다
NS(Name Server) 레코드
- 도메인을 관리하는 권한 있는 네임 서버의 목록을 반환
SOA(Start of Authority) 레코드
- 도메인에 대한 권한 있는 정보를 반환(관리 정보, 시리얼 넘버, 타이머 등..)
MX(Mail eXchange) 레코드
- 도메인에 연결된 메일 서버 정보를 반환
PTR(Pointer) 레코드
- IP 주소를 도메인 이름으로 변환하는 역방향 질의 (Inverse Query)에 사용
3) Root NS (.)
1. 기본적인 설정은 Cache NS와 동일 (1~3번을 선행하여 설정하기)
2. Root NS로 설정 (/etc/named.conf 또는 named.rfc1912.zones에 설정)
zone "." IN {
type master;
file "root.zone";
};
3. 존 파일 수정 (/var/named/root.zone)
$TTL 1D
@ IN SOA a.root-servers.net. admin.root-servers.net. (
2023020701
1D
1H
1W
3H
)
. IN NS a.root-servers.net.
a.root-servers.net. IN A 198.41.0.4
4. DNS 서비스 데몬 실행 및 확인
4) TLD NS (net.)
1. 기본적인 설정은 Cache NS와 동일 (1~3번을 선행하여 설정하기)
2. TLD NS로 설정 (/etc/named.conf 또는 named.rfc1912.zones에 설정)
zone "net" IN {
type master;
file "net.zone";
};
3. 존 파일 수정 (/var/named/net.zone)
$TTL 1D
@ IN SOA a.gtld-servers.net. admin.gtld-servers.net. (
2023020701
1D
1H
1W
3H
)
net. IN NS a.gtld-servers.net.
a.gtld-servers IN A 192.5.6.30
4. DNS 서비스 데몬 실행 및 확인
여기까지가 각 네임 서버를 기본적으로 설정하는 방법이다. 여기까지 완전히 설정됐다면 nslookup 명령어를 이용해서 정상적으로 네임 서버들이 동작하는지 확인해보자. 아마 루트(.)까지는 결과가 나오지만 net.의 결과는 다음과 같이 나올 것이다.
앞으로 가 DNS Query 과정을 다시 보게 되면 우리가 net.에 대해 DNS에 질의했을 때, 루트 네임 서버는 . 까지 밖에 알지 못하기 때문에 .net 네임 서버(TLD NS)의 정보를 Cache 네임 서버에 반환한 후, 다시 .net 네임 서버로 질의해서 결과값을 얻게끔 해야한다. 이러한 과정을 .net 서버에 '위임한다' 라고 하며, 방금 전의 오류가 생긴 이유는 우리가 기본 설정 외 하위 서버에 위임한다는 내용을 설정하지 않았기 때문이다.
4. 위임 설정 방법
1) Root NS에서 TLD NS로 위임해주기
위임해주는 과정은 간단하자. 루트 존 파일(root.zone)에 해당 내용을 추가해주면 된다.
$TTL 1D
@ IN SOA a-root. admin. (
2021121301
1D
1H
1W
3H
)
. IN NS ns1.
ns1 IN A 198.41.0.4
net. IN NS a.gtld-servers.net.
<-- net 도메인의 네임서버 이름, Root 도메인 아래의 net. 도메인에 대한 관리를 a-tld.net.에 위임한다.
a.gtld-servers.net. IN A 192.5.6.30
<-- a-tld.net(net을 관리하는 네임서버) 호스트의 IP주소
설정이 변경됐다면, systemctl restart named로 변경 사항을 적용 시켜줘야 한다. 특히 Cache 네임 서버의 경우 결과값을 찾을 수 없다는 오류의 결과까지 Cache DB에 저장하기 때문에 꼭 restart 해줘야 한다. 여기까지 완료됐다면, .net에 대한 결과가 나올 것이다.
동일한 방법으로 TLD NS에서 권한 있는 NS에게 위임해주는 것까지 설정을 완료해보자.
2) TLD NS에서 로 위임해주기
$TTL 1D
@ IN SOA a.gtld-servers.net. admin.gtld-servers.net. (
2023020701
1D
1H
1W
3H
)
@ IN NS a.gtld-servers.net.
a.gtld-servers.net. IN A 192.5.6.30
daum.net. IN NS ns1.daum.net.
ns1.daum.net. IN A 113.61.107.5
더 나아가 권한 있는 네임 서버의 존 파일에 다양한 호스트를 등록하면, daum.net. 뿐만이 아니라 www.daum.net., smtp.daum.net., 등 다양한 호스트에 대해 질의가 가능할 것이다.
DNS 관련 포스팅이 너무 길어지는 관계로 네임 서버 이중화와 영역 전송(Zone Transfer), 역방향 질의(Reverse DNS Lookup)에 관해서는 다음 포스팅에 이어 정리하도록 하겠다....
힘들지만 오늘도 해낸 나를 위한 한 마디,
"운명은 내가 만든 한계만큼 작아지고, 내가 정한 목표만큼 위대해진다", James Allen
"꿈은 원대하게, 목표는 현실적으로"
'System > Linux' 카테고리의 다른 글
| [Linux] FTP (1) | 2024.10.07 |
|---|---|
| [Linux] DNS part 2 (2) | 2024.10.03 |
| [Linux] 원격 관리 서비스(Telnet, SSH) (1) | 2024.09.26 |
| [Linux] 파일 시스템, 마운트 (0) | 2024.09.25 |
| [Linux] 저장소(Storage)관리 (5) | 2024.09.24 |