Bind8 und mehrere Interfaces: Unterschied zwischen den Versionen

Aus NOBAQ
Zur Navigation springenZur Suche springen
(Die Seite wurde neu angelegt: x)
 
Zeile 1: Zeile 1:
−
x
+
<section begin="head"/>
 +
Wird der bind an mehrere Netzwerkinterfaces (auch aliases) gebunden, so werden standardmäßig transfers trotzdem über das erste Interface abgewickelt! Das herauszufinden hat mich jetzt 2 Stunden gedauert. Dem Slave-Server wurde ein alias mit eigener IP Adresse hinzugefügt (eth0:0). Sonst wurde nix verändert. Auf dem Masterserver wurde lediglich die alte durch die neue IP ersetzt. Obwohl sozusagen sonst nichts verändert wurde, funktionierten auf einmal die Transfers nicht mehr. Sogar der Paketfilter in der mitte wurde komplett abgeschaltet (pylon) [...]
 +
<section end="head"/>
 +
 
 +
Die misteriösen Fehlermeldungen auf dem Master:
 +
 
 +
May 11 03:08:30 ianus named[5640]: client 192.168.200.121#52896: zone transfer ’stiftingtal.net/IN’ denied
 +
May 11 03:08:31 ianus named[5640]: client 192.168.200.121#48771: zone transfer ‘wlan.lan/IN’ denied
 +
May 11 03:08:31 ianus named[5640]: client 192.168.200.121#38276: zone transfer ‘intern.stiftingtal.net/IN’ denied
 +
May 11 03:08:38 ianus named[5640]: client 192.168.200.121#33757: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
 +
May 11 03:08:39 ianus named[5640]: client 192.168.200.121#41264: zone transfer ‘wlan.lan/IN’ denied
 +
May 11 03:08:40 ianus named[5640]: client 192.168.200.121#38104: zone transfer ’stiftingtal.net/IN’ denied
 +
May 11 03:09:09 ianus named[5640]: client 192.168.200.121#56117: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
 +
May 11 03:09:13 ianus named[5640]: client 192.168.200.121#37460: zone transfer ‘intern.stiftingtal.net/IN’ denied
 +
May 11 03:10:20 ianus named[5640]: client 192.168.200.121#57543: zone transfer ’stiftingtal.net/IN’ denied
 +
May 11 03:10:34 ianus named[5640]: client 192.168.200.121#47467: zone transfer ‘wlan.lan/IN’ denied
 +
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#53561: zone transfer ‘intern.stiftingtal.net/IN’ denied
 +
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#34744: zone transfer ’stiftingtal.net/IN’ denied
 +
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#45430: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
 +
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#41127: zone transfer ‘wlan.lan/IN’ denied
 +
 
 +
und auf dem Slave:
 +
 
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer
 +
May 11 03:10:39 nobaq named[14192]: transfer of ’stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:10:39 nobaq named[14192]: transfer of ’stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘0.168.192.in-addr.arpa/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘0.168.192.in-addr.arpa/IN’ from 192.168.0.1#53: end of transfer
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:10:39 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: end of transfer
 +
May 11 03:11:25 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:11:25 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: end of transfer
 +
May 11 03:11:27 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
 +
May 11 03:11:27 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer
 +
 
 +
Komischerweise sieht man auf dem Master, dass, obwohl alle IPs auf 192.168.200.111 geändert wurden, noch immer auf 192.168.200.121 verbunden wurde. Genau dieser Transfer wurde aber nicht mehr erlaubt, da die IP-Adresse ja ersetzt wurde!!
 +
 
 +
Warum das passiert ist, wie ich bereits beschrieben habe, dass die Transfers standardmässig über das erste Interface abgewickelt werden und dementsprechend auch diese IP Adresse bekommen.
 +
 
 +
Bis ich endlich nach verzweifelter Suche die Lösung gefunden habe, hat es einige Zeit gedauert. Der folgende Befehl im '''slave''' weist bind an, das folgende Interface als Transferquelle zu verwenden:
 +
 
 +
transfer-source 192.168.200.111;
 +
 
 +
Das gute daran ist, dass man das auch direkt in die zonen-Blöcke eintragen kann, um somit seine Hauptkonfiguration nicht zu verändern und nur die source Adresse für bestimmte slaves ändern zu müssen. zum Beispiel:
 +
 
 +
zone "intern.stiftingtal.net" {
 +
        type slave;
 +
        file "slave/intern.stiftingtal.net.db";
 +
        masters { 192.168.0.1; };
 +
        transfer-source 192.168.200.111;};
 +
 +
zone 0.168.192.in-addr.arpa. {
 +
        type slave;
 +
file "slave/ptr/wlan.lan.db";
 +
        masters { 192.168.0.1; };
 +
        transfer-source 192.168.200.111;
 +
};
 +
 
 +
[[Kategorie:Weblog]]

Version vom 1. Februar 2008, 16:11 Uhr

Wird der bind an mehrere Netzwerkinterfaces (auch aliases) gebunden, so werden standardmäßig transfers trotzdem über das erste Interface abgewickelt! Das herauszufinden hat mich jetzt 2 Stunden gedauert. Dem Slave-Server wurde ein alias mit eigener IP Adresse hinzugefügt (eth0:0). Sonst wurde nix verändert. Auf dem Masterserver wurde lediglich die alte durch die neue IP ersetzt. Obwohl sozusagen sonst nichts verändert wurde, funktionierten auf einmal die Transfers nicht mehr. Sogar der Paketfilter in der mitte wurde komplett abgeschaltet (pylon) [...]


Die misteriösen Fehlermeldungen auf dem Master: 

May 11 03:08:30 ianus named[5640]: client 192.168.200.121#52896: zone transfer ’stiftingtal.net/IN’ denied
May 11 03:08:31 ianus named[5640]: client 192.168.200.121#48771: zone transfer ‘wlan.lan/IN’ denied
May 11 03:08:31 ianus named[5640]: client 192.168.200.121#38276: zone transfer ‘intern.stiftingtal.net/IN’ denied
May 11 03:08:38 ianus named[5640]: client 192.168.200.121#33757: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
May 11 03:08:39 ianus named[5640]: client 192.168.200.121#41264: zone transfer ‘wlan.lan/IN’ denied
May 11 03:08:40 ianus named[5640]: client 192.168.200.121#38104: zone transfer ’stiftingtal.net/IN’ denied
May 11 03:09:09 ianus named[5640]: client 192.168.200.121#56117: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
May 11 03:09:13 ianus named[5640]: client 192.168.200.121#37460: zone transfer ‘intern.stiftingtal.net/IN’ denied
May 11 03:10:20 ianus named[5640]: client 192.168.200.121#57543: zone transfer ’stiftingtal.net/IN’ denied
May 11 03:10:34 ianus named[5640]: client 192.168.200.121#47467: zone transfer ‘wlan.lan/IN’ denied
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#53561: zone transfer ‘intern.stiftingtal.net/IN’ denied
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#34744: zone transfer ’stiftingtal.net/IN’ denied
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#45430: zone transfer ‘0.168.192.in-addr.arpa/IN’ denied
May 11 03:10:39 ianus named[5640]: client 192.168.200.121#41127: zone transfer ‘wlan.lan/IN’ denied

und auf dem Slave: 

May 11 03:10:39 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:10:39 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer
May 11 03:10:39 nobaq named[14192]: transfer of ’stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:10:39 nobaq named[14192]: transfer of ’stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer
May 11 03:10:39 nobaq named[14192]: transfer of ‘0.168.192.in-addr.arpa/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:10:39 nobaq named[14192]: transfer of ‘0.168.192.in-addr.arpa/IN’ from 192.168.0.1#53: end of transfer
May 11 03:10:39 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:10:39 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: end of transfer
May 11 03:11:25 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:11:25 nobaq named[14192]: transfer of ‘wlan.lan/IN’ from 192.168.0.1#53: end of transfer
May 11 03:11:27 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: failed while receiving responses: REFUSED
May 11 03:11:27 nobaq named[14192]: transfer of ‘intern.stiftingtal.net/IN’ from 192.168.0.1#53: end of transfer

Komischerweise sieht man auf dem Master, dass, obwohl alle IPs auf 192.168.200.111 geändert wurden, noch immer auf 192.168.200.121 verbunden wurde. Genau dieser Transfer wurde aber nicht mehr erlaubt, da die IP-Adresse ja ersetzt wurde!!

Warum das passiert ist, wie ich bereits beschrieben habe, dass die Transfers standardmässig über das erste Interface abgewickelt werden und dementsprechend auch diese IP Adresse bekommen.

Bis ich endlich nach verzweifelter Suche die Lösung gefunden habe, hat es einige Zeit gedauert. Der folgende Befehl im slave weist bind an, das folgende Interface als Transferquelle zu verwenden: 

transfer-source 192.168.200.111;

Das gute daran ist, dass man das auch direkt in die zonen-Blöcke eintragen kann, um somit seine Hauptkonfiguration nicht zu verändern und nur die source Adresse für bestimmte slaves ändern zu müssen. zum Beispiel: 

zone "intern.stiftingtal.net" {
        type slave;
        file "slave/intern.stiftingtal.net.db";
        masters { 192.168.0.1; };
        transfer-source 192.168.200.111;};

zone 0.168.192.in-addr.arpa. {
        type slave;

file "slave/ptr/wlan.lan.db"; 

        masters { 192.168.0.1; };
        transfer-source 192.168.200.111;
};
Abgerufen von „http://niki.hammler.net/w/index.php?title=Bind8_und_mehrere_Interfaces&oldid=454“