https://fedoramagazine.org/how-to-setup-a-dns-server-with-bind/
이 기사에 따라 바인딩에서 DNS 서버를 설정했습니다.
Master=192.168.1.206=master.example.com
Client=192.168.1.3=client.example.com
//
// /etc/named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
#listen-on port 53 { 127.0.0.1; 192.168.1.2; };
#listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { localhost; 192.168.1.0/24; };
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
#dnssec-validation yes;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "example.com" IN {
type master;
file "forward";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "reverse";
allow-update { none; };
};
이렇게 정방향 및 역방향 영역 파일을 설정했습니다.
#forward
$TTL 86400
@ IN SOA master.example.com. admin.example.com. (
2023010401 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
86400 ;Minimum TTL
)
@ IN NS master.example.com.
@ IN A 192.168.1.206
@ IN A 192.168.1.3
@ IN A 192.168.1.4
master IN A 192.168.1.206
webserver IN A 192.168.1.4
#reverse
$TTL 86400
@ IN SOA master.example.com. admin.example.com. (
2023010401 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
86400 ;Minimum TTL
)
@ IN NS master.example.com.
@ IN PTR example.com.
master IN A 192.168.1.206
webserver IN A 192.168.1.4
206 IN PTR master.example.com.
4 IN PTR webserver.example.com.
그런 다음 /etc/resolv.conf
메인 서버에 설정했습니다.
search example.com
nameserver 192.168.1.206
이제 마스터한테 가서 해볼게
dig example.com
답변을 받았지만 받았어요AUTHORITY=0
[root@dns01 named]# dig example.com
; <<>> DiG 9.16.23-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55501
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b15240d00532152a010000006623f6970bb37622180b1f28 (good)
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 86400 IN A 192.168.1.3
example.com. 86400 IN A 192.168.1.206
example.com. 86400 IN A 192.168.1.4
;; Query time: 0 msec
;; SERVER: 192.168.1.206#53(192.168.1.206)
;; WHEN: Sat Apr 20 18:08:39 WEST 2024
;; MSG SIZE rcvd: 123
답변1
시스템에서 를 사용하는 경우 을 가리키도록 systemd-resolved
시스템이 다시 작성될 수 있습니다 . 이는 신뢰할 수 없는 답변을 설명할 수 있습니다. 파서의 캐시에서 해당 답변을 가져올 수 있습니다./etc/resolv.conf
nameserver 127.0.0.53
systemd-resolved
(이런 경우 /etc/resolv.conf
시스템을 레거시 호환성을 위해서만 존재하는 오래된 구성 파일로 처리해야 함을 나타냅니다. resolvectl
이 경우 실제 DNS 확인자 설정을 참조하세요.)
dig
기본값에 의존하는 대신 권한 있는 서버에 직접 연결하도록 명시적으로 지시해 보세요 .
dig example.com @192.168.1.206