https://fedoramagazine.org/how-to-setup-a-dns-server-with-bind/
この記事に従って、DNSサーバーをbindに設定しました
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.53systemd-resolved
/etc/resolv.conf(その現象が発生する場合は、そのシステムでは、レガシー互換性のためだけに存在する古い構成ファイルとして扱う必要があることを示しています。resolvectlその場合の実際の DNS リゾルバ設定については、を参照してください。)
digデフォルトに頼るのではなく、権威サーバーに直接接続するように明示的に指示してみてください。
dig example.com @192.168.1.206