Am două servere BIND care rulează BIND 9:
BIND 9.11.36-RedHat-9.11.36-3.el8 (versiunea de asistență extinsă) <id:68dbd5b>
rulează pe Linux x86_64 4.18.0-372.9.1.el8.x86_64 #1 SMP marți, 10 mai 08:57:35 EDT 2022
construit de make cu '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '-- prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr /share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr /share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '- -enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '-- with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/ pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '- -with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=nu' '-- cu-libjson' ' --enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full -report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 - Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin -cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/ rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compilat de GCC 8.5.0 20210514 (Red Hat 8.5.0-10)
compilat cu versiunea OpenSSL: OpenSSL 1.1.1k FIPS 25 martie 2021
conectat la versiunea OpenSSL: OpenSSL 1.1.1k FIPS 25 martie 2021
compilat cu versiunea libxml2: 2.9.7
legat la versiunea libxml2: 20907
compilat cu versiunea libjson-c: 0.13.1
legat la versiunea libjson-c: 0.13.1
compilat cu versiunea zlib: 1.2.11
legat la versiunea zlib: 1.2.11
conectat la versiunea maxminddb: 1.2.0
compilat cu versiunea protobuf-c: 1.3.0
legat la versiunea protobuf-c: 1.3.0
suportul pentru fire este activat
căi implicite:
configurație numită: /etc/named.conf
Configurare rndc: /etc/rndc.conf
Cheia rădăcină DNSSEC: /etc/bind.keys
cheie de sesiune nsupdate: /var/run/named/session.key
fișier PID numit: /var/run/named/named.pid
fișier de blocare cu nume: /var/run/named/named.lock
directorul geoip: /usr/share/GeoIP
Serverul principal este la 172.16.19.243, iar cel secundar la 172.16.19.251. Ei pot trimite ping unul altuia, iar portul 53 (UDP și TCP) este deschis pe ambele. Ambele funcționau, dar un cod nou a fost introdus în automatizarea noastră și ambele au pierdut accesul la rețea timp de aproximativ două ore. Este posibil ca configurația să fi fost schimbată.
Secundarul nu afișează fișiere de zonă în /etc/named/. Transferurile de zonă eșuează:
DNS-Secundar numit[546308]: general: info: zona 19.16.172.in-addr.arpa/IN: reîmprospătare: cod rcode neașteptat (SERVFAIL) de la master 172.16.19.251#53 (sursa 0.0.0.0#0)
/var/log/named/zone_transfers în emisiunea principală:
xfer-out: info: client @0x7f48600ebf90 69.61.12.108#47302 (ns4.mydomain.example): cerere de transfer de zonă defectuoasă: „ns4.mydomain.example/IN”: zonă neautoritară (NOTAUTH)
... 3 zile mai târziu are loc o întrerupere, dar nu apar jurnalele...
... la câteva ore după întrerupere și repetând până în prezent...
notify: info: zona mydomain.example/IN: trimiterea notificărilor (seria 2022051909)
notificare: info: zona 19.16.172.in-addr.arpa/IN: trimitere notificări (serie 2022051909)
notificare: info: zona 16.16.172.in-addr.arpa/IN: trimitere notificări (serie 2022051909)
notificare: info: zona 17.16.172.in-addr.arpa/IN: trimitere notificări (serie 2022051909)
notificare: info: zona 18.16.172.in-addr.arpa/IN: trimitere notificări (serie 2022051909)
Problema nu se rezolvă prin rulare rndc retransfer mydomain.example. De asemenea, solicitarea AXFR cu dig eșuează:
dig -t axfr mydomain.exemplu 172.16.19.243
; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> -t axfr mydomain.exemplu 172.16.19.243
;; opțiuni globale: +cmd
; Transferul a eșuat.
; Transferul a eșuat.
Interogarea înregistrărilor A și a PTR-urilor de pe internet pentru a mastera lucrări. A face același lucru cu secundarul nu reușește acum:
dig @172.16.19.251 191.19.16.172.in-addr.arpa ptr
; <<>> DiG 9.18.2 <<>> @172.16.19.251 191.19.16.172.in-addr.arpa ptr
; (1 server găsit)
;; opțiuni globale: +cmd
;; Am raspuns:
;; ->>HEADER<<- opcode: QUERY, stare: SERVFAIL, id: 57626
;; steaguri: qr rd; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 0, SUPLIMENTARE: 1
;; AVERTISMENT: recursiunea este solicitată, dar nu este disponibilă
;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
; COOKIE: 204e72e23787aef415f9ec7562866219e93a158c23f1f323 (bine)
;; SECȚIUNEA DE ÎNTREBĂRI:
;191.19.16.172.in-addr.arpa. ÎN PTR
;; Timp de interogare: 48 ms
;; SERVER: 172.16.19.251#53(172.16.19.251) (UDP)
;; CÂND: joi, 19 mai, 10:28:39 CDT 2022
;; MSG SIZE rcvd: 83
/etc/named.conf al masterului este prezentat mai jos:
Opțiuni {
permite-interogare {
nici unul;
};
permite-transfer {
nici unul;
};
recursiunea nu;
auth-nxdomain nr; # conform cu RFC1035
răspunsuri minime da;
minim-orice da;
dnssec-activare da;
validare dnssec da;
};
zona "." ÎN {
tip indiciu;
fișierul „named.ca”;
};
includ „/etc/named.rfc1912.zones”;
includ „/etc/named.root.key”;
//Zone de sistem
zona „mydomain.example” ÎN {
tip master;
fișierul „/etc/named/mydomain.example.db”;
allow-query {orice;
};
permite-transfer {
gazdă locală;
172.16.19.243;
};
anunta da;
};
zona "16.16.172.in-addr.arpa" IN {
tip master;
fișierul „/etc/named/16.16.172.in-addr.arpa.rev”;
allow-query {orice;
};
permite-transfer {
gazdă locală;
172.16.19.243;
};
anunta da;
};
// Zonele pentru 17 - 19 sunt incluse în configurație cu *exact* același format. Generat programatic - dacă există
// o greșeală de tipar aici, apoi există în toate. Niciun transfer de zonă nu funcționează.
/etc/named/16.16.172.in-addr.arpa.rev pe master este după cum urmează:
86400 USD TTL
@ ÎN SOA ns3.mydomain.example. admin.mydomain.example. (
2022051917 ;Serial
3600 ;Reîmprospătare
1800 ;Reîncercați
604800 ;Expiră
86400; TTL minim
)
;; Toate înregistrările zonei NS
@ ÎN NS ns3.mydomain.example.
@ ÎN NS ns4.mydomain.example.
;; Toate înregistrările PTR din zonă
* IN PTR HDN-UIDO
Din nou, nicio căutare DNS pentru nicio înregistrare nu funcționează pe secundar, dar toate funcționează pe master. Niciun transfer de zone de la master la secundar. Toate zonele și configurațiile sunt generate programatic, deci dacă există o eroare într-o zonă, aceasta va fi prezentă pentru toate. Nu au fost găsite alte erori de notă în jurnalele. Fără refuzuri SELinux pe niciunul dintre servere. Permisiunile /etc/named/ sunt 0770 root:named system_u:object_r:named_conf_t:s0 pe ambele servere. Eliminarea tuturor fișierelor .jnl nu a ajutat (a fost doar unul pe master, și nu în /etc/named).
Care ar putea fi cauza? Mulțumesc.
EDIT 5/19
Am confirmat că ambele servere au 53/UDP și 53/TCP deschise unul față de celălalt.
Din secundar:
dig @172.16.19.243 +tcp 200.18.16.172.in-addr.arpa ptr
; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @172.16.19.243 +tcp 200.18.16.172.in-addr.arpa ptr
; (1 server găsit)
;; opțiuni globale: +cmd
;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 6246
;; steaguri: qr aa rd; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1
;; AVERTISMENT: recursiunea este solicitată, dar nu este disponibilă
;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
; COOKIE: a9c777930fc7d210a2b794de6286b88d1d5f01b2a729a2f5 (bun)
;; SECȚIUNEA DE ÎNTREBĂRI:
;200.18.16.172.in-addr.arpa. ÎN PTR
;; SECȚIUNEA RĂSPUNSURI:
200.18.16.172.in-addr.arpa. 86400 IN PTR EHB-DYN.18.16.172.in-addr.arpa.
;; Timp de interogare: 0 ms
;; SERVER: 172.16.19.243#53(172.16.19.243)
;; CÂND: joi, 19 mai, 16:37:15 CDT 2022
;; MSG SIZE rcvd: 110
numită-checkzone a fost folosit pentru a verifica toate zonele. Singura problemă pe care a raportat-o a fost lipsa unei înregistrări pentru NS4, care a fost, de asemenea, subliniată în comentarii. Am notat acest lucru și l-am schimbat pe servere, dar schimbarea nu a ajuns la această întrebare când am scris-o. În orice caz, nu a rezolvat problema.
numit-checkconf a fost rulat pe ambele servere și ambele au returnat starea 0.
Serverul slave are mai multe adrese, dar folosește adresa corectă (afișată) pentru a interoga masterul, așa cum se confirmă cu o captură de pachet pe master.
Înregistrarea A a fost eliminată din fișierul de configurare a zonei inverse. Fragmentul de fișier de mai sus este corect.
