인터넷에 연결된 수많은 컴퓨터들은 ip로 서로를 식별한다. 일반적인 ip는 점과 숫자로 구성된다. 모든 통신의 과정에서 ip로 접근정보를 추려야하는 건 출석부의 학생들을 숫자와 문자가 혼용된 식별자로 구별해야하는 것처럼 난감한 일이다. 난감함을 피하고자 학생들에게 철수, 영희, 민수 등의 이름이 있듯이 컴퓨터에게도 보다 직관적인 이름이 붙여진다. 이를 도메인 혹은 Hostname이라고 한다. 허나 이름을 무엇으로 붙이던 거의 모든 프로토콜은 결국 ip를 이용해 접근공간을 파악한다. 따라서 도메인과 ip는 양방향적으로 수월히 변환되어야하고 이런 변환 서비스를 제공하는 것이 DNS ( Domain Name System ) 이다.
과거에는 접근이 필요한 모든 host의 정보를 client가 가지고 있었다. 요즘으로 따지면 /etc/hosts 파일을 사용해서 로컬 도메인을 등록하는 식으로 모든 접근정보를 관리한 것이다. 이건 분명 불편하고 또 여러모로 불안요소가 많은 일이다. 이의 대안으로 나온 것이 DNS이며 DNS는 엄밀히 말해 인터넷 세계의 Public Domain들을 중앙관리하는 체계 혹 서비스다.
Hostname ? Domain ?
Hostname과 Domain은 굉장히 혼용되곤한다. 엄밀히 말하면 Domain은 DNS에 등록된 정보를 뜻하는 것에 가깝고, Hostname은 서버 혹은 서비스명을 말하는 것에 가깝다. 도메인은 항시 도메인 네임 레지스트리 혹은 탑레벨 도메인이라고 불리는 것으로 끝나는데 com, org, kor 등이 그것이다. 여기에 서버군 혹은 서비스군을 식별하는 이름을 하나 붙인 것이 엄밀한 의미의 Domain 이다. 가령 naver + com가 있다. 하나의 서버/서비스가 두 단어의 도메인과 대응되는 경우는 거의 없다. 으레 여러 서버/서비스들이 도메인 아래에 집합적으로 모여있기 마련이고 이때 서버/서비스들을 식별할 수 있는 이름을 붙이는데 이것이 엄밀한 의미의 Hostname 이다. 가령 blog + naver + com 이거나 webtoon + naver + com 등의 예가 있다. 동일한 목적으로 운영되어 하나의 도메인에 속해 있는 여러 서버들의 이름도 비슷하게 조립할 수 있다. 가령 machine1.datastore.com, machine2.datastore.com 등이 있겠다.
이때 Hostname도 또 두 개의 식별 이름의 조합으로 만들 수 있다. 물론 도메인 하나에 너무 많은 구분점이 들어가게 하는 건 지양해야겠다.
이렇게 구성된 도메인은 특정 서버 혹은 서비스에 대한 접근정보 혹 통신정보를 구성한다. 접근 프로토콜은 접근정보 맨 앞에 붙인다. 흔한 접근정보의 형식은 다음과 같다.
[Protocol]://[Hostname].[Domain Name].[Top Level Domain]
A Record ? CNAME ?
A Record와 CNAME은 DNS를 생성하며 피할 수 없이 만나게 될 두 개념이다. 정확하게는 A Type Record와 CNAME Type Record 가 있다. 둘은 모두 도메인과 접속정보를 연결해주는 기록인데, A Type Record는 도메인과 Ip를 연결해주는 기록이지만 CNAME Type Record는 도메인을 또 다른 도메인과 연결해주는 기록이라는 점에서 구별된다. A와 CNAME 외에 여러 Type의 기록이 더 있긴 하다만 여기서 적진 않겠다.
A Type 방식으로 도메인과 ip 만 연결해줘서 사용하면 되지 않나? 하는 의문이 들 수 있는데 실제로 CNAME 없이 A Type Record 만 사용하는게 더 낫다는 의견을 가진 전문가들도 많다고 한다. 그럼에도 타 도메인의 서비스를 Aliasing하는 경우나 IP 변동에 대응하는 경우 등에서 CNAME의 효용이 증명되긴 한다. CNAME은 Canonical Name의 약자인데
DNS 설정 및 통신 테스트
둘의 개념을 더욱 명징하게 파악하기 위해 실습을 해보기로 한다.
우선 multipass를 이용해 두 개의 가상 머신을 띄운다. os는 Ubuntu 22.04.
# network=en1 옵션으로 가상머신들이 ip를 할당받게 함 (wifi)
multipass launch --network en1 -n machine1
multipass launch --network en1 -n machine2
list로 출력했을때 머신마다 두 개의 ip가 할당되어있다. 위에 있는 ip는 Bridge 네트워크를 이용하는 private ip(Virtual ip)이고 아래의 ip가 wi-fi로 할당된 public ip다. 인터넷 통신을 위해선 public ip를 사용해야한다.
다음으로 DNS를 만들어보았다. 가비아에서 500원을 주고 샀다. 설정은 아래와 같다.
앞서 설명했던 A Record, CNAME Record 개념이 적용된다. 등록이 정상적으로 완료되면 아래처럼 pc에서 도메인 정보를 확인할 수 있다.
통신테스트를 위해 http 서버 하나를 띄워둔다.
아래와 같은 웹사이트가 서빙되어야 한다.
성공 !
성공 !
Name Server
ip와 도메인을 또 도메인과 도메인을 매핑해주는 것은 알겠다. 그렇다면 그런 매핑 관계는 어디서 해석되는 걸까? Name Server 라는 것이 그 역할을 해준다. pc에서 ip가 아닌 도메인을 사용한 트래픽이 발생하면 pc는 Name Server에 해당 도메인 정보를 질의해서 ip를 얻어내 트래픽의 url 주소를 변경한 후 트래픽을 처리한다. 이렇게 url을 변경하는 과정을 Resolution이라고 한다.
질의는 기본적으로 Q. a.domain.com ? -> A. 192.x.x.x 식으로 이루어지는데 검색 도메인이 CNAME으로 매핑되어 있다면 Name Server는 자동으로 CNAME과 매핑된 도메인에 대한 새로운 질의를 만들어 ip를 찾아낸다. 그러니까 도메인이 A Record 매핑이든 CNAME 매핑이든 결론적으로 ip가 얻어지는 것이다.
Name Server는 딱 하나만 있을까? 그렇지 않다. 이건 당연한 듯하면서도 이상한 말이다. Name Server가 여러개라면 pc의 입장에서 특정 도메인을 Resolution 할 때 어떤 Name Server에 질의를 해야할 지를 어떻게 찾아내는가? 각각의 Name Server는 인터넷 상에 존재하는 모든 도메인의 매핑 정보를 알고 있는가? 아니면 특정 도메인과 특정 Name Server를 매핑한 메타 정보를 관리하는 서비스가 또 따로 있는가?? DNS 질의 과정에 대해 자세히는 파악하지 못했는데 인터넷 세상은 Name Server를 계층식으로 두어 이 문제를 해결한다. Pc의 입장에서 가장 가까운 Name Server에서 먼저 질의를 하고 없으면 다음으로 넘어가고 하는 식이다. 또 각 계층에선 질의 결과가 캐싱된다.
Name Server의 종류도 다양한데 Internel Name server / Forwarder Name Server / Internet Name Server 등이 있다. 가장 유명한 public Name Server 중 하나는 8.8.8.8의 ip를 가진 Google Name Server 다. 종류로 따지면 Forwarder Name Server 다. 일반적인 it 회사들은 자체 Name Server를 구성하여 사용하기도 한다.
다음은 머신의 Name Server 설정을 바꿔보는 실습이다. 우분투 머신의 Name Server 정보는 /etc/resolv.conf 파일에서 확인할 수 있다. 127.0.0.53 은 엄밀히 말해 Name Server 의 주소는 아니고 도메인 질의를 Name Server로 넘겨주는 로컬 프로세스 (systemd-resolved 가 구동) 의 정보다.
실제 Name Server 주소는 아래로 확인할 수 있다. DNS 라고 명시된 부분이 Name Server의 목록이다. 192.x.x.x 는 가상 머신 Gateway 정보다. Gateway가 dns 기능도 가지고 있는지 아니면 단순히 host에 도메인 질의를 넘겨주는 것 뿐인지는 모르겠다. 나머지 210.x.x.x 와 219.x.x.x 는 wi-fi에 명시된 Name Server 정보다.
아래의 과정을 통해 Name Server 설정을 변경한다.
# 아래의 설정 파일 변경
sudo vi /etc/systemd/resolved.conf
>>>
[Resolve]
DNS=8.8.8.8
FallbackDNS=8.8.4.4
Domains=domain00x.shop
<<<
# systemd-resolved 프로세스 재시작
sudo service systemd-resolved restart
# 설정 파일 변경
sudo rm -f /etc/resolv.conf
sudo ln -sv /run/systemd/resolve/resolv.conf /etc/resolv.conf
/etc/resolv.conf 를 열어 변경 결과를 확인한다.
도메인 질의도 한 번 때려준다. !
추가로 /etc/resolv.conf 에서 search 로 명시된 부분은 앞서 /etc/systemd/resolved.conf 에서 Domains에 적은 것인데 도메인 없이 host로만 통신을 할 수 있게 해준다. 말하자면 아래처럼 chost1 식으로 도메인 정보 없이 호스트 정보만 가진 트래픽이 있을 때 chost1 에 .domain00x.shop 을 붙여주는 역할이라고 보면 되겠다.
Name Server 구축
private 한 환경 하에선 Name Server를 직접 구축하곤 한다. 이땐 사설 업체에 도메인 등록을 할 필요 없이 내부망용 도멘을 운용할 수 있다.
Name Server 용 머신을 한 대 띄워준다.
multipass launch --network en1 -n nameserver
# ip check
ubuntu@nameserver:~$ ip addr
...
inet 192.168.35.163/24 brd 192.168.35.255 scope global dynamic enp0s2
리눅스 환경에서 자체 nameserver 구축을 지원해주는 bind9 라는 것이 있다. 이걸 이용해보기로 한다.
# bind9 installation
sudo apt-get install -y bind9
# bind9 service active check
ubuntu@nameserver:~$ service bind9 status
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-09-18 11:56:30 KST; 1min 37s ago
# /etc/bind/named.conf.options 수정
## dns 설정
>>> 변경
options {
directory "/var/cache/bind";
// 질의 허용 ip
allow-query {
any;
};
// 질의 재귀 호출 가능 여부
// yes인 경우 로컬에서 질의가 실패하면 forwarder로 질의를 넘김
recursion yes;
forwarders {
8.8.8.8;
};
dnssec-validation auto;
listen-on-v6 { any; };
};
# /etc/bind/named.conf.local 수정
## domain zone 생성
>> 추가
zone "mydomain00x.shop" {
type master;
file "/etc/bind/db.mydomain00x.shop";
};
# /etc/bind/db.mydomain00x.shop 생성
sudo cp /etc/bind/db.local /etc/bind/db.mydomain00x.shop
>>> 변경
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA mydomain00x.shop. root.mydomain00x.shop. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS mydomain00x.shop.
@ IN A 192.168.35.163
machine1 IN A 192.168.35.81
machine2 IN A 192.168.35.42
chost1 IN CNAME machine1.mydomain00x.shop.
chost2 IN CNAME machine2.mydomain00x.shop.
# 설정들 구문 화인
named-checkconf
# bind9 재시작
sudo systemctl restart bind9.service
설정을 제대로 마쳤다면 구축한 nameserver에 도메인 질의를 날릴 수 있다!
recursion을 no로 하면 로컬 옵션에 등록되지 않은 도메인에 대한 질의는 불가능하다.
NameServer 머신과 tcp/53 통신이 가능한 외부에선 해당 Name Server를 이용할 수 있다. 앞서 기술된 Name Server 설정 변경 방법으로 machine1의 기본 NameServer를 자체 구축한 서버로 변경한다. 그러면 해당 도메인을 이용한 통신이 가능해진다.
아래는 domain 질의 결과!
참조
https://library.gabia.com/contents/domain/4146/
http://doc.kldp.org/KoreanDoc/html/PoweredByDNS-KLDP/using-cname.html
https://docs.python.org/ko/3/library/socket.html#socket.gethostbyaddr
https://unix.stackexchange.com/questions/588658/override-ubuntu-20-04-dns-using-systemd-resolved
'IT 일반' 카테고리의 다른 글
| [Python] Child process 생성 (0) | 2022.12.03 |
|---|---|
| About 유의적 버전 Semantic Version (0) | 2022.09.02 |
| Mac os 내 경량 Linux 환경 구성하기 feat. linuxkit (0) | 2022.09.02 |
