PDNS 로그를 수집하고자 할때 아래와 같이 설정하면 됩니다.

아래는 PDNS 4.2 에서 테스트 하였습니다.

1. 설정

데몬 구동 파일을 백업하고 수정합니다.

# cp -arp /usr/lib/systemd/system/pdns.service /usr/lib/systemd/system/pdns.service.bak

# vi /usr/lib/systemd/system/pdns.service

PDNS 설정을 추가합니다.

# vi /etc/pdns/pdns.conf

rsyslog 설정을 추가합니다.

서비스 데몬 설정 상 debug level 로 해놓아서 아래 로깅 설정이 중요합니다.

vi /etc/rsyslog.conf

로그 디렉토리를 생성합니다.

# mkdir /var/log/pdns

2. 적용

# systemctl daemon-reload
# systemctl restart pdns
# systemctl restart rsyslog

3. 확인

# cd /var/log/pdns
# ll
합계 145288
drwxr-xr-x  2 root root      4096  3월 29 09:41 .
drwxr-xr-x. 9 root root      4096  3월 29 16:37 ..
-rw-------  1 root root 147126477  3월 30 07:46 pdns.debug
-rw-------  1 root root       998  3월 29 09:30 pdns.err
-rw-------  1 root root      1331  3월 29 09:27 pdns.info
-rw-------  1 root root   1619633  3월 29 09:39 pdns.warn

pdns.debug 파일에 도메인 질의했던 Remote IP 와 Record Type, Domain name 등 정보가 간략히 출력되는데

참고로 packetcache 값은 아래 의미를 가지고 있습니다.

- HIT : 이전에 처리된 DNS 쿼리 결과가 캐시에 저장되어 있고, 현재 처리중인 쿼리와 동일한 결과를 반환할 수 있습니다.

           이 경우, pdns 서버는 저장된 정보를 즉시 반환하므로, 쿼리 처리 시간이 매우 빠릅니다.
- MISS : 이전에 처리된 DNS 쿼리 결과가 캐시에 없으며, 실제 DNS 서버에서 새로운 쿼리를 처리해야 합니다.

              이 경우, pdns 서버는 실제 DNS 서버로부터 결과를 가져와서 반환해야 하므로, 쿼리 처리 시간이 증가할 수 있습니다.

* 참고

도메인 질의가 많은 서버의 경우 로그 파일 사이즈도 방대하게 늘어나기 때문에

아래 URL 참고하여 logrotate 로 로그 파일을 관리 하면 됩니다.

(내용중 PDNS 설정 부분 참조)

https://sysdocu.tistory.com/63

네임서버 성능을 확인하기 위해 다량의 도메인 질의를 해 볼 수 있습니다.

아래 설치 및 사용 방법을 확인해 주세요.

CentOS 7 기준으로 작성되었습니다.

1. 설치

# cd /usr/local/src

# wget https://www.dns-oarc.net/files/dnsperf/dnsperf-2.3.2.tar.gz
# tar xfvz dnsperf-2.3.2.tar.gz
# cd dnsperf-2.3.2/
# ./configure
# make
# make install

2. 사용

도메인을 질의하기 위해 테스트 또는 유명 도메인과 A 레코드를 질의하기 위해 A 값을 파일로 만듭니다.

# echo "sysdocu.kr A" > list.txt

아래와 같은 형식으로 테스트가 가능합니다.

# dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1

* 옵션 설명

- s : 네임서버 IP 또는 도메인 (생략시 127.0.0.1)

- d : 도메인 또는 도메인이 들어있는 파일명

- T : 사용할 스레드 수

- Q : 쿼리량

- l : 질의 지속 시간 (초)

1초에 1000개 쿼리 수행 결과는 아래와 같이 나옵니다.

DNS Performance Testing Tool
Version 2.3.2

[Status] Command line: dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1
[Status] Sending queries (to 8.8.8.8)
[Status] Started at: Tue Mar 28 16:16:00 2023
[Status] Stopping after 1.000000 seconds
[Status] Testing complete (time limit)

Statistics:

  Queries sent:         1000
  Queries completed:    1000 (100.00%)
  Queries lost:         0 (0.00%)

  Response codes:       NOERROR 1000 (100.00%)
  Average packet size:  request 28, response 112
  Run time (s):         1.000256
  Queries per second:   999.744066

  Average Latency (s):  0.000880 (min 0.000374, max 0.019629)
  Latency StdDev (s):   0.001580

[TIP] Docker 룰이 포함된 iptables 룰 저장 및 복구

iptables 기본 룰에서 docker 컨테이너등을 실행하면 컨테이너가 사용하는 포트의 연결을 위해

자동으로 iptables 룰이 추가됩니다.

하지만 iptables 룰을 잘못 수정하였다가 컨테이너 서비스가 먹통 되는 일이 생기는데 이를 방지하기 위해

iptables 룰을 주기적으로 저장해 두어야 합니다.

-----------------------------------

# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0           
DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            192.168.96.2         tcp dpt:3306
ACCEPT     tcp  --  0.0.0.0/0            192.168.96.3         tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            192.168.96.4         tcp dpt:9000
ACCEPT     tcp  --  0.0.0.0/0            192.168.96.3         tcp dpt:80

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0           
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

-----------------------------------

현재 iptables 룰 저장

# iptables-save > iptables_20221222.rules

백업한 iptables 룰 복원

# iptables-restore < iptables_20221222.rules

혹시 백업해둔 룰이 없을땐 서비스 중지를 감수하고 docker 를 재시작 하면 컨테이너가 구동되면서 iptables 룰이 재구성 됩니다.

# systemctl restart docker

우분투 19.04 버전에서 네임서버를 운영하기 위한 절차 입니다.

아래 절차만 순차적으로 따라하셔도 구축이 되며,

사용하고 계신 A, MX, CNAME 레코드 등에 대해서는 알맞게 레코드를 추가하여 설정하시면 됩니다.

1. 설치

root@sysdocu:~# apt -y install bind9

2. 도메인 설정

파일을 열어 아래 내용을 추가 합니다.

root@sysdocu:~# vi /etc/bind/named.conf.local

새로운 zone 파일을 생성하여 내용을 입력합니다.

root@sysdocu:~# vi /var/cache/bind/sysdocu.com.zone

설정한 내용을 적용합니다.

root@sysdocu:~# systemctl enable bind9

root@sysdocu:~# systemctl restart bind9

3. 질의 테스트

1) 로컬에서 질의 확인

root@sysdocu:~# nslookup sysdocu.com localhost

Server: localhost

Address: ::1#53

Name: sysdocu.com

Address: 192.168.10.2

[root@localhost ~]# nslookup sysdocu.com 192.168.10.2

Server: 192.168.10.2

Address: 192.168.10.2#53

Name: sysdocu.com

Address: 192.168.10.2

4. 참고

- 네임서버로 사용하기 위해 방화벽에서 UDP 53 번 포트 허용하는 것은 필수 입니다.

- 도메인 구입처에서 호스트 및 네임서버를 변경하면 시간이 한참 지나 적용이 될 수 있으므로

  이점 참고하여 운영하시기 바랍니다.

PDNS 에 DDNS 기능이 있는것 같은데, 아직 개발 단계에 있다는 말도 있고..

SSH 키를 이용해 인증하는것 같아 제 나름의 방법대로 구축 방법을 기술하였습니다.

1. Client 설정

Client 서버에서 네임서버로 IP 정보를 전송해야 하므로, Client 서버에 아래와 같은 명령을 이용하여 주기적으로 IP를 체크, 업데이트 할 수 있도록 해야합니다.

아래 인증 방법 두 가지 중 하나를 이용하면 됩니다.

인증 방법1

# lynx -source -auth=아이디:패스워드 'http://ns1.sysdocu.com/update.php?도메인'

인증 방법2

# wget -O - --http-user=아이디 --http-passwd=패스워드 'http://ns1.sysdocu.com/update.php?도메인'

위 스크립트가 5분마다 자동 실행될 수 있도록 자동 스케쥴러에 등록해 놓습니다.

아래 예에서는 아이디 및 패스워드, 갱신할 도메인 sysdocu.com 을 실제로 입력하였습니다.

# crontab -e

2. Server 설정

네임서버에서는 Client 서버의 IP 정보를 수시로(1분 마다) 체크 하고 있다가 변경되어질 때, 업데이트 합니다.

그래서 Client 서버에서 보내오는 신호를 체크하고 DB에 저장된 IP값과 비교, IP 값이 다를 경우 업데이트 하는 스크립트를 만들어야 합니다.

우선 pdns DB에 users 테이블을 추가합니다. 아이디로 검색해 본인이 사용하는 도메인이 맞는지 확인하기 위해 사용됩니다.

# vi users.sql

# mysql -p pdns < users.sql

Enter password:  (패스워드 입력)

추후에 사용할때는 users 테이블에 실제 사용하는 아이디랑 도메인이 들어가 있어야 작동을 합니다.

예) user1    sysdocu.com

      user1    www.sysdocu.com

      user2    system.sysdocu.com

# touch /usr/local/apache/htdocs/update.php    // ns1.sysdocu.com 의 기본 디렉토리 안에 빈페이지를 생성합니다.

# vi /root/ipcheck.sh

이제 위 스크립트가 1분마다 자동으로 실행될 수 있도록 자동 스케쥴러에 등록해 놓습니다.

# crontab -e

또한 인증 받은 사람만(아이디, 패스워드로 확인) 업데이트가 가능하도록 아파치 웹인증 암호를 걸어 놓습니다.

# cd /usr/local/apache/htdocs    // ns1.sysdocu.com 의 기본 디렉토리

# vi .htaccess

# /usr/local/apache/bin/htpasswd -c .htpasswd sysdocu

New password : ********

Re-type new password : ********

위와 같이 아이디 sysdocu 와 그에 해당하는 패스워드를 설정했습니다. 이제 생성한 아이디, 패스워드 사용자만 update.php 파일에 접근이 가능합니다.

여기에 아이디, 패스워드를 추가 할때는 -c 옵션을 빼고 동일하게 명령을 수행하면 됩니다.

그리고 .htpasswd 파일의 위치를 잘 입력해주어야 합니다. 현재 디렉토리에서는 파일명만 적되, 다른 디렉토리에 위치한 상태에서 명령을 내릴 때는 절대경로, 또는 상대경로를 이용하여 위치를 정확히 입력합니다.

# /usr/local/apache/bin/htpasswd .htpasswd UserID

-c 옵션은 초기 사용자를 생성 할때만 사용됩니다. 여러개의 아이디를 만든 후 -c 옵션을 잘못 주었다면 기존의 아이디가 모두 사라져버리므로 주의를 해야 합니다. (주기적으로 인증 파일 백업 권장)

* 참고 : 이용자 삭제

# /usr/local/apache/bin/htpasswd -D .htpassd UserID

BIND는 오픈 소스의 성격에 맞게 다양한 로그와 디버거 정보를 제공하고 있습니다.

특히 로그는 성격에 맞게 Category로 나누어져 있으며, Category별로 다양하게 저장이 가능합니다.

시스템의 부하와 디스크의 공간이 있다면 로그를 많이 남겨두는 것이 장애시 분석을 가능하게 하는 방법입니다. 가급적이면 로그를 많이 남겨두는 것이 좋습니다.

로그는 named.conf에 적용을 하면 되며, 카테고리별 설명은 아래와 같습니다.

아래는 BIND9에서 제공하는 모든 Category를 적용한 샘플입니다. 

logging {
	channel "default_syslog" {
		// Send most of the named messages to syslog.
		syslog local2;
		severity debug;
	};
	channel "default_syslog" {
		file "log/default.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "general_syslog" {
		file "log/general.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "database_syslog" {
		file "log/database.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "security_syslog" {
		file "log/security.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "config_syslog" {
		file "log/config.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "resolver_syslog" {
		file "log/resolver.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "xfer-in_syslog" {
		file "log/xfer-in.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "xfer-out_syslog" {
		file "log/xfer-out.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "notify_syslog" {
		file "log/notify.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "client_syslog" {
		file "log/client.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "unmatched_syslog" {
		file "log/unmatched.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "network_syslog" {
		file "log/network.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "update_syslog" {
		file "log/update.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "update_security_syslog" {
		file "log/update_security.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "queries_syslog" {
		file "log/queries.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "dispatch_syslog" {
		file "log/dispatch.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "dnssec_syslog" {
		file "log/dnssec.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "lame-servers_syslog" {
		file "log/lame-servers.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel "delegation-only_syslog" {
		file "log/delegation-only.log" versions 3 size 20m;
		severity debug;
		print-category yes;
		print-severity yes;
		print-time yes;
	};

	category default { default_syslog; };
	category general { default_syslog; };
	category database { database_syslog; };
	category security { security_syslog; };
	category config { config_syslog; };
	category resolver { resolver_syslog; };
	category xfer-in { xfer-in_syslog; };
	category xfer-out { xfer-out_syslog; };
	category notify { notify_syslog; };
	category client { client_syslog; };
	category unmatched { unmatched_syslog; };
	category network { network_syslog; };
	category update { update_syslog; };
	category update-security { update_security_syslog; };
	category queries { queries_syslog; };
	category dispatch { dispatch_syslog; };
	category dnssec { dnssec_syslog; };
	category lame-servers { lame-servers_syslog; };
	category delegation-only { delegation-only_syslog; };	
};
[출처] BIND9를 위한 로그 설정|작성자 네임서버
네임서버 이야기 | 네임서버 (http://blog.naver.com/netpiadns/50021687725)

[출처] 네임서버 이야기 | 네임서버 (http://blog.naver.com/netpiadns/50021687725)