https://fedoramagazine.org/wie-man-einen-DNS-Server-mit-Bind einrichtet/
Ich habe den DNS-Server gemäß diesem Artikel in Bind eingerichtet
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; };
};
Ich habe die Vorwärts- und Rückwärtszonendatei wie folgt eingerichtet.
#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.
Dann richte ich /etc/resolv.confdies im Masterserver ein
search example.com
nameserver 192.168.1.206
Jetzt gehe ich zum Master und mache
dig example.com
Ich bekomme die Antwort, aber ich bekommeAUTHORITY=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
Antwort1
Wenn Ihr System verwendet systemd-resolved, wird Ihr /etc/resolv.confmöglicherweise so umgeschrieben, dass es auf verweist nameserver 127.0.0.53, den Caching-Resolver von systemd-resolved. Das könnte die nicht autoritative Antwort erklären: Sie erhalten es möglicherweise aus dem Cache des Resolvers.
(Wenn dies geschieht, ist dies ein Zeichen dafür, dass Sie /etc/resolv.confdieses System als veraltete Konfigurationsdatei betrachten sollten, die nur aus Gründen der Legacy-Kompatibilität vorhanden ist. Suchen Sie resolvectlin diesem Fall nach den tatsächlichen DNS-Resolver-Einstellungen.)
Geben Sie explizit an, digdass eine direkte Verbindung zum autoritativen Server hergestellt werden soll, statt sich auf die Standardeinstellungen zu verlassen:
dig example.com @192.168.1.206