리눅스 강의 10일차_2025_02_12

어제는 nmcli 명령어와 bind 패키지를 설치하고, 실행, 방화벽 개방, 서비스 확인까지 공부했다.

 

오늘은 방화벽을 열고 dns 설정 파일들을 변경하였다.

 

오늘은 크게 봐서는 하나의 실습을 여러 번 진행하였는데 집에서 처음부터 해보겠다.

 

일단 마스터 네임 서버를 먼저 만들고 그다음 두 번째 리눅스로 슬레이브 네임 서버를 만들 것이다.

 

일단 네임 서버가 설치되어 있는지 확인해 보겠다.

 

패키지명은 bind이다.

 

dnf list bind를 치면 네임 서버 데몬이 설치되어 있는지 확인 가능하다.

 

만약 설치 안 되어 있다면 dnf install bind로 설치하자

 

그다음은 방화벽을 열어줘야 한다.

 

네임 서버는 DNS 프로토콜을 사용하므로 포트 번호 tcp, udp 53을 사용한다.

 

 

재부팅 뒤에도 이 포트를 열어두고 싶다면 --permanent 명령어를 사용하면 된다.

 

왼쪽은 이미 개방된 방화벽에 또 연다는 명령어를 사용해서 그렇다.

 

방화벽을 다 설정했다면 firewall-cmd --reload 명령으로 방화벽을 재부팅해 준다.

 

 

이젠 시스템을 실행시킬 시간이다.

 

만약 이미 실행 중이더라도 네임 서버의 설정이 바뀌었다면 항상 restart를 해줘야 그 변경 사항이 기록된다.

 

 

만약 ps aux | grep named로 프로세스가 실행 중인지 확인 후 실행 중이라면 아직 변경 사항이 없어 굳이 할 필요가 없지만

 

restart는 시작도 시켜주고 재부팅도 시켜줘서 서비스 중이 아닌 연습 중인 이 상황에서는 restart를 그냥 사용했다.

 

이제 네임 서버의 설정을 바꾸기 위해서 네임 서버의 설정 파일이 어디에 있는지 알아야 한다.

 

 

우리는 보통 named.conf 파일을 사용해서 네임 서버의 설정을 바꿀 것이다.

 

vi 편집기로 열어보자

 

 

처음 들어가면 이런 모습의 파일이다. 

 

관리에 편하도록 주석을 제거하고 우리에게 필요한 내용만 남겨보자.

 

ns1 컴퓨터는 서버 ip를 201로 바꿔야 한다.

 

두 번째 리눅스의 named.conf 파일을 편집한 모습이다.

 

일단 directory는 해당 설정 파일들은 이 디렉토리 하위에 있어야 하거나, 만들어야 한다는 내용이다.

 

이 파일에 대해서 설명하자면 일단 listen-on  port 53 { 192.168.1.202; }; 

이 내용은 53번 포트로 들어오는 dns 요청을 들을 랜카드(IP주소)는 무엇인가?

정도로 해석이 가능하다.

 

allow-query { any; };

이 내용은 내가 운영하는 도메인에서 누가 나에게 질의를 할 수 있는가?

any로 설정하면 모든 클라이언트가 나에게 질의할 수 있다.

 

allow-query-cache { any; };

이 내용은 내 네임 서버가 캐시하고 있는 데이터를 누가 조회할 수 있는가?

여기서 recursion은 기본적으로 yes이고 나의 네임 서버에 재귀 질의를 허용함으로 

나의 네임 서버를 이용해서 질의가 가능해진다.

 

기본적인 파일 설정은 이 정도면 된다.

 

이제 마스터, 슬레이브 구조를 만들고 싶다면 먼저 첫 번째 리눅스에 conf 파일에 마스터 설정 후 해당 파일을 생성해 보자.

 

 

서버의 타입은 마스터이며, 도메인명은 swj.so.mega 이다.

/var/named/ 디렉토리에 swj.so.mega.zone이라는 이름의 파일에 Slaves 네임 서버에게 갱신 주기를 알려주는 파일을 만들 것이다.

두 번째 리눅스 IP로 swj.so.mega.zone 이라는 파일을 전송해 줄 것이다.

정도로 해석이 가능해보인다.

 

당연히 ip값같은 오류는 직접 찾아내야 하지만 문법적 오류는 이 명령어로 설정 파일을 검사할 수 있다.

 

자 이제 swj.so.mega.zone파일을 만들러 가자

 

첫 번째 파일은 생략하지 않고 작성하고 두 번째 파일을 정석대로 작성해 보겠다.

 

 

생략하지 않으면 이 구조를 지켜서 작성해야 한다. (물론 ; 이후의 주석은 적지 않아도 무방하다)

 

swj.so.mega. 의 네임 서버의 이름은 ns1.swj. so.mega.라는 이름과 ns2.swj. so.mega. 이 있고

각각의 주소는 192.168.1.201과 192.168.1.202라는 주소이다.

만약 www.swj. so.mega.나 db.swj. so.mega. 에 접속하고 싶다면 192.168.1.201로 접속하라 라는 뜻이다.

물론 아직 웹서버와 db 서버를 구축하지는 않았다. 

다만 첫 번째 리눅스에서 서비스를 할 것이므로 설정을 해둔 것이다.

 

완성했다면 다시 bash로 나와서 named-checkzone swj.so.mega /var/named/swj.so.mega.zone 명령어를 사용해 swj.so.mega.zone 파일에 문법적 오류가 없는지 확인해 본다.

 

 

이런 식으로 ok가 나오면 문법적 오류는 없는 것

 

이제 네임 서버를 restart 해서 설정을 적용하고 한번 윈도우(192.168.1.200)에서 접속해 보자.

 

 

아무래도 udp통신이기 때문에 server failed가 자주 뜬다.

 

거부가 아닌 실패면 여러 번 시도하면 결국은 응답할 가능성이 높다.

 

이제 내 도메인을 질의해 보자

설정해 둔 대로 잘 응답하는 것을 볼 수 있다.

 

이젠 Slave 서버인 두 번째 리눅스를 설정할 차례이다.

 

 

conf 파일 상부는 동일하게 설정하고 하부의 zone 부분을 슬레이브로 만들어 보자

 

 

타입은 슬레이브 서버, 파일은 /var/named/slaves/ 디렉토리에 swj.so.mega.bak.zone 파일의 이름으로 만들어야 한다는 것이다.

 

아까 allow-transfer 명령어로 이 ip주소를 기록했으니 192.168.1.201에서 마스터에게 받는 슬레이브라고 설정해야 한다.

 

이제 실행해 보자 (named-checkconf 필수!! )

 

systemctl restart named.service 를 사용하면 바로 해당 위치에 마스터에게 받아온 파일이 생성된다.

 

 

이렇게 마스터가 슬레이브 서버에 전송하는 방식이 밀어 넣는 느낌이라 하여 push 방식이라고 한다.

 

마스터/슬레이브 서버 모두 응답을 잘하는 것을 볼 수 있다.

 

존 파일 업데이트 방식은 push, pull 두 가지 있는데 전 방식이 push 방식이고 pull 방식은 refresh 시기에 업데이트된 파일을 받지 못하는 상황이 생겼을 때 슬레이브 서버가 retry 시간에 맞춰 요청 시 시리얼 번호가 더 높다면 직접 zone 파일을 

마스터로부터 받아오는 방식을 pull이라고 하는 것 같다. ( 사실 아직 실습을 하지 못했고 내일 해주신다고 한다)

 

아까 zone 파일 생략 방식만 설명하고 넘어가겠다.

생략 없는 버전

생략의 방식은 이러하다

 

    1 - 마지막에 .을 생략하면, swj.so.mega. (ORIGIN)이 붙는다.

     이 파일에서 .을 잊으면 안 되는 이유로 만약 ns1.swj.so.mega라 적는다면 ns1.swj.so.mega.swj.so.mega.로 해석한다.

     ns1.swj.so.mega. 을 ns1만 치면 뒤에 .가 와야 하므로 암묵적으로 ns1.swj.so.mega.로 해석된다.

    2 - mega.com. (ORIGIN)은 @으로 대체할 수 있다.

    .의 생략이 필요 없이 ORIGIN 과 아예 같은 값이라면 @으로 적어서 생략할 수 있다.

    3 - 도메인/호스트(질문)을 생략하면 위의 내용이 이어진다.

    도메인의 @값이 연속된다면 @를 빼도 된다.

     하지만 가독성을 위해서

                                        swj.so.mega. IN NS ns1.swj.so.mega.

                                        ns1.swj.so.mega. IN A 192.168.1.201

                                        swj.so.mega. IN NS ns2.swj.so.mega.

                                        ns2.swj.so.mega. IN A 192.168.1.202

이런 식으로 연속된 값이 아니게 설정된다면  윗부분만 뺄 수 있다.

                                       

이렇게 생략이 가능하다.

 

 

오류 없음을 확인

 

실습은 여기서 끝이고 이젠 DNS 조회 유틸리티에 관하여 알아보자

---

레코드의 형식은 이러하다.

 

SOA : 권한의 시작(Start Of Authority), 마스터 NS 관련 정보
NS : 네임 서버(Name Server), Master/Slave 구분 없이 출력
A : ipv4 주소
AAAA : ipv6 주소
CNAME : 별칭(Alias, Cannonical Name)
PTR : ip주소 -> 도메인네임 (port)

 

1. nslookup : 윈도우, 리눅스에서 모두 사용 가능한 명령어이다.

사용 방법은 간단하게

nslookup [-type=레코드] 도메인/호스트 [DNS 서버_IP]로 사용이 가능하다.

 

2. dig : named 데몬에 포함된 공식 유틸리티이다.

굉장히 자세하게 조회해 주고 필요에 따라 필요 정보만 얻을 수도 있다.

사용 방법은 순서만 바뀐

dig [@DNS_서버] 도메인/호스트 [레코드] [+옵션]

전에는 응답 형식이 크게 4가지로 질의, 응답, 어솔리티, 추가_섹션으로 나왔다고 설명해 주셨지만.

 

버전이 지나면서 이젠 응답, 어솔리티 등 전부 보이지는 않는 모습이다.

 

질의(QUESTION)_섹션
http://www.swj.so.mega.IN A ??

응답(ANSWER)_섹션
http://www.swj.so.mega.IN A 192.168.1.201

어솔리티(AUTHORY)_섹션
http://www.swj.so.mega.IN NS ns1.swj.so.mega.
http://www.swj.so.mega.IN NS ns2.swj.so.mega.

추가_섹션(ADDITIONAL)
ns1.swj.so.mega. IN A 192.168.1.201
ns2.swj.so.mega. IN A 192.168.1.202

 

섹션마다 이런 형식으로 나온다고 한다.

 

옵션은 +short 같은 옵션을 사용하면 원하는 정보만 얻어낼 수 있다.

 

이런 식으로 말이다.

 

호스트는 배우지 않아 제외하겠다.