BIND9/Troubleshooting: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(14 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Allgemein zu vermeidende Fehler ==
Es kommt häufig vor, dass Anfänger bei der Bearbeitung der Konfigurationsdateien von BIND Fehler machen oder bei der Verwendung von <tt>named</tt> zunächst Schwierigkeiten haben.
* Viele der nachfolgend beschriebenen Probleme können Sie aber vermeiden, wenn Sie Folgendes beachten:
* ''Erhöhen Sie die Seriennummer, wenn Sie eine Zone-Datei bearbeiten.'' <br/>Wenn die Seriennummer nicht erhöht wird, hat Ihr Master-Name-Server zwar die korrekten neuen Informationen, Ihr Slave-Name-Server werden jedoch nie über diese Änderungen oder den Versuch informiert, die Daten in der Zone zu aktualisieren.
* ''Achten Sie darauf, dass Sie geschweifte Klammern und Strichpunkte in der <tt>/etc/named.conf</tt>-Datei richtig verwenden.'' <br/>Ein ausgelassenes Semikolon oder eine nicht geschlossene geschweifte Klammer kann dazu führen, dass <tt>named</tt> nicht startet.
* ''Denken Sie daran, in den Zone-Dateien nach jedem FQDN Punkte (<tt>.</tt>) zu setzen und sie beim Hostnamen wegzulassen.'' <br/>Der Punkt bedeutet, dass der angegebene Name komplett ist.
* Wird er weggelassen, platziert <tt>named</tt> den Namen der Zone oder des <tt>$ORIGIN</tt>-Werts hinter den Namen, um ihn zu vervollständigen.
* ''Wenn Ihre Firewall Verbindungen von Ihrem <tt>named</tt> zu anderen Nameservern blockiert, müssen Sie möglicherweise die Konfigurationsdatei bearbeiten.''
* Standardmäßig verwendet die Version 9 von BIND willkürliche Ports oberhalb von 1024, um andere Name-Server abzufragen.
* Einige Firewalls gehen jedoch von Name-Servern aus, die für die Kommunikation nur den Port 53 verwenden.
* Um die Verwendung des Port 53 durch <tt>named</tt> zu erzwingen, fügen Sie in <tt>/etc/named.conf</tt> folgende Zeile zur <tt>options</tt>-Direktive hinzu:
query-source address * port 53;
== Bind9 Master Slave replication: Zone transfer not working ==
== Bind9 Master Slave replication: Zone transfer not working ==
audit: type=1400 audit(1575835512.723:69): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/slave/tmp-cBkaqhFqRy" pid=15305 comm="isc-worker0000" requested_mask="c" denied_mask="c" fsuid=116 ouid=116


On a Bind master server, it is pretty much "standard" to run everything within /etc/bind. As this is a master DNS server, the zone files are usually updated manually.
* On a Bind master server, it is pretty much "standard" to run everything within /etc/bind.  
 
* As this is a master DNS server, the zone files are usually updated manually.
But if you run a master-slave-replication, do not use the same directory structure on the slave!
* But if you run a master-slave-replication, do not use the same directory structure on the slave!


By troubleshooting a case, where the replication did not work and the zone files were not created on the slave server, I came across the following error message in syslog on the slave:
By troubleshooting a case, where the replication did not work and the zone files were not created on the slave server, I came across the following error message in syslog on the slave:
Zeile 15: Zeile 29:
  named[318]: zone example.com/IN: sending notifies (serial 2014090801)
  named[318]: zone example.com/IN: sending notifies (serial 2014090801)
  named[318]: dumping master file: /etc/bind/zones/tmp-kP27d0CASU: open: permission denied
  named[318]: dumping master file: /etc/bind/zones/tmp-kP27d0CASU: open: permission denied
  kernel: [239980.946541] type=1400 audit(1410164178.794:90): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/zones/tmp-kP27d0CASU" pid=319 comm="named" requested_mask="c" denied_mask="c" fsuid=111 ouid=111
  kernel: type=1400 audit(1410164178.794:90): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/zones/tmp-kP27d0CASU" pid=319 comm="named" requested_mask="c" denied_mask="c" fsuid=111 ouid=111
audit:  type=1400 audit(1575835512.723:69): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/slave/tmp-cBkaqhFqRy" pid=15305 comm="isc-worker0000" requested_mask="c" denied_mask="c" fsuid=116 ouid=116


Interesting. The master sends the notify for the zone and the slave receives the notify and the transfer is initiated. But when the slave tries to create the zonefile in /etc/bind/zones, a permission denied error arises. One line further the "blocker" is identified: apparmor.
* The master sends the notify for the zone and the slave receives the notify and the transfer is initiated.  
* But when the slave tries to create the zonefile in /etc/bind/zones, a permission denied error arises.  
* One line further the "blocker" is identified: apparmor.


Indeed, in the apparmor profile for /usr/sbin/named (/etc/apparmor.d/usr.sbin.named) does not allow the bind process to write anything into /etc/bind/:
In the apparmor profile for /usr/sbin/named (/etc/apparmor.d/usr.sbin.named) does not allow the bind process to write anything into /etc/bind/:


   # /etc/bind should be read-only for bind
   # /etc/bind should be read-only for bind
Zeile 31: Zeile 48:
   /var/cache/bind/ rw,
   /var/cache/bind/ rw,


As solution, one should use /var/lib/bind/(zones) as path for the zone files, which are dynamically created through the master-slave replication.
=== Solution ===
Use /var/lib/bind/(zones) as path for the zone files, which are dynamically created through the master-slave replication.
 
[[Kategorie:BIND9]]

Aktuelle Version vom 6. Februar 2023, 14:10 Uhr

Allgemein zu vermeidende Fehler

Es kommt häufig vor, dass Anfänger bei der Bearbeitung der Konfigurationsdateien von BIND Fehler machen oder bei der Verwendung von named zunächst Schwierigkeiten haben.

  • Viele der nachfolgend beschriebenen Probleme können Sie aber vermeiden, wenn Sie Folgendes beachten:
  • Erhöhen Sie die Seriennummer, wenn Sie eine Zone-Datei bearbeiten.
    Wenn die Seriennummer nicht erhöht wird, hat Ihr Master-Name-Server zwar die korrekten neuen Informationen, Ihr Slave-Name-Server werden jedoch nie über diese Änderungen oder den Versuch informiert, die Daten in der Zone zu aktualisieren.
  • Achten Sie darauf, dass Sie geschweifte Klammern und Strichpunkte in der /etc/named.conf-Datei richtig verwenden.
    Ein ausgelassenes Semikolon oder eine nicht geschlossene geschweifte Klammer kann dazu führen, dass named nicht startet.
  • Denken Sie daran, in den Zone-Dateien nach jedem FQDN Punkte (.) zu setzen und sie beim Hostnamen wegzulassen.
    Der Punkt bedeutet, dass der angegebene Name komplett ist.
  • Wird er weggelassen, platziert named den Namen der Zone oder des $ORIGIN-Werts hinter den Namen, um ihn zu vervollständigen.
  • Wenn Ihre Firewall Verbindungen von Ihrem named zu anderen Nameservern blockiert, müssen Sie möglicherweise die Konfigurationsdatei bearbeiten.
  • Standardmäßig verwendet die Version 9 von BIND willkürliche Ports oberhalb von 1024, um andere Name-Server abzufragen.
  • Einige Firewalls gehen jedoch von Name-Servern aus, die für die Kommunikation nur den Port 53 verwenden.
  • Um die Verwendung des Port 53 durch named zu erzwingen, fügen Sie in /etc/named.conf folgende Zeile zur options-Direktive hinzu:
query-source address * port 53;


Bind9 Master Slave replication: Zone transfer not working

  • On a Bind master server, it is pretty much "standard" to run everything within /etc/bind.
  • As this is a master DNS server, the zone files are usually updated manually.
  • But if you run a master-slave-replication, do not use the same directory structure on the slave!

By troubleshooting a case, where the replication did not work and the zone files were not created on the slave server, I came across the following error message in syslog on the slave:

named[318]: client 10.10.44.67#7865: received notify for zone 'example.com'
named[318]: zone example.com/IN: Transfer started.
named[318]: transfer of 'example.com/IN' from 10.10.44.67#53: connected using 10.10.44.68#33813
named[318]: zone example.com/IN: transferred serial 2014090801
named[318]: transfer of 'example.com/IN' from 10.10.44.67#53: Transfer completed: 1 messages, 33 records, 1170 bytes, 0.001 secs (1170000 bytes/sec)
named[318]: zone example.com/IN: sending notifies (serial 2014090801)
named[318]: dumping master file: /etc/bind/zones/tmp-kP27d0CASU: open: permission denied
kernel: type=1400 audit(1410164178.794:90): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/zones/tmp-kP27d0CASU" pid=319 comm="named" requested_mask="c" denied_mask="c" fsuid=111 ouid=111
audit:  type=1400 audit(1575835512.723:69): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/slave/tmp-cBkaqhFqRy" pid=15305 comm="isc-worker0000" requested_mask="c" denied_mask="c" fsuid=116 ouid=116
  • The master sends the notify for the zone and the slave receives the notify and the transfer is initiated.
  • But when the slave tries to create the zonefile in /etc/bind/zones, a permission denied error arises.
  • One line further the "blocker" is identified: apparmor.

In the apparmor profile for /usr/sbin/named (/etc/apparmor.d/usr.sbin.named) does not allow the bind process to write anything into /etc/bind/:

 # /etc/bind should be read-only for bind
 # /var/lib/bind is for dynamically updated zone (and journal) files.
 # /var/cache/bind is for slave/stub data, since we're not the origin of it.
 # See /usr/share/doc/bind9/README.Debian.gz
 /etc/bind/** r,
 /var/lib/bind/** rw,
 /var/lib/bind/ rw,
 /var/cache/bind/** lrw,
 /var/cache/bind/ rw,

Solution

Use /var/lib/bind/(zones) as path for the zone files, which are dynamically created through the master-slave replication.