BIND: Forwarder ist nur bei bestimmten Adressen erfolgreich

[dolphin]

Hi!

Ich habe ein Problem mit BIND innerhalb einer Organisation. Konkret sieht es so aus:

• Die Organisation betreibt einen BIND-Server. Der loest Rechnernamen in IP-Adressen auf, und zwar sowohl interne Rechnernamen ("rechner1.organisation.loc" --> 192.168.x.x-Netze / 10.x.x.x-Netze) als auch externe Rechnernamen ("rechner2.organisation.net" --> oeffentliche IP-Adressen.
• Innerhalb einer Abteilung habe ich mir einen eigenen BIND-Server installiert. Der soll fuer abteilungsinterne Rechner zustaendig sein. Alles andere soll dieser BIND an den BIND-Server der Organisation forwarden.

Ich habe einen Debian-Wheezy-Rechner (Debian 7.2.0) aufgesetzt und da BIND installiert:

Code: Alles auswählen

apt-get install bind9

Danach habe ich an der Default-Konfiguration genau ZWEI Aenderungen durchgefuehrt.

Aenderung 1:
In der "/etc/bind/named.conf.options" habe ich als Forwarder den fuer die gesamte Organisation zustaendigen Name-Server eingetragen.

Aenderung 2:
In der gleichen Datei habe ich des Weiteren die Zeile

Code: Alles auswählen

allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 127.0.0.0/8; };

hinzugefuegt, damit die Abteilung die Organisation auch dann befragen darf, wenn es um weltweite Rechnernamen jenseits der Zustaendigkeit der gesamten Organisation geht.

Dann habe ich das Ganze mit "dig" getestet:

• Test 1: dig @<IP BIND Organisation> debianforum.de
• Test 2: dig @<IP BIND Abteilung> debianforum.de
• Test 3: dig @<IP BIND Organisation> rechner1.organisation.net
• Test 4: dig @<IP BIND Abteilung> rechner1.organisation.net
• Test 5: dig @<IP BIND Organisation> rechner2.organisation.loc
• Test 6: dig @<IP BIND Abteilung> rechner2.organisation.loc

Ergebnisse:

• Bei Test 1 bis Test 5 liefert "dig" stets die korrekte IP-Adresse des angegebenen Rechners.
• Bei Test 6 liefert "dig" KEINE IP-Adresse.

Bewertung des Ergebnisses:

• "debianforum.de" ist ein Rechner ausserhalb der Organisation. "BIND Abteilung" hat also einen Forward nach "BIND Organisation", und der wiederum einen Forward nach "BIND ISP" gemacht. Klappt wunderbar.
• "rechner1.organisation.net" hat einen Domain-Namen, der auf ".net", ".de" oder ".com" endet. Klappt auch, obwohl "BIND Organisation" fuer diesen Rechner zustaendig ist, also nicht extra noch einen Forward nach "BIND Internet Service Provider" machen muss.
• "BIND Organisation" ist aber auch fuer "rechner2.organisation.loc" zustaendig. Und hier liefert "BIND Abteilung" kein Ergebnis.

Fragen:

• Warum scheitert das Experiment bei "rechner2.organisation.loc"?
• Was ist bei ".loc"-Adressen anders als bei ".net"-Adressen? Warum werden die anders behandelt?
• Was kann ich wo konfigurieren, damit ".loc"-Adressen auch wie ".net"-Adressen behandelt werden?

Mir scheint, als waere dieser Fall nicht wirklich kompliziert. Vielmehr sieht es danach aus, als wuerde irgendwo ein geheimer Schalter existieren, den ich nur umzulegen brauche, sobald ich ihn finde. Ist das so? Und wenn ja, wo ist dann der Schalter?

Besten Dank im Voraus,
dolphin

[hec_tech]

Welchem Server gehört denn die Zone "organisation.loc"?

Darf der andere Server diese Zone auch abfragen?

Ich glaube du brauchst eventuell am anderen Server ein "allow-query".

[dolphin]

Welchem Server gehört denn die Zone "organisation.loc"?

Darf der andere Server diese Zone auch abfragen?

Ich glaube du brauchst eventuell am anderen Server ein "allow-query".

Die gehoeren alle zu "BIND Organisation".

Es ist geplant, dass sich "BIND Abteilung" fuer Namen des Typs "rechner3.abteilung.loc" zustaendig fuehlen wird.
Das klappt auch super, aber fuer die Fragestellung ist die Zone "abteilung.loc" eher irrelevant.

Die Frage, ob "BIND Abteilung" von "BIND Organisation" die Zone "organisation.loc" abfragen darf, ist ein interessanter Hinweis.
Wir werden der Sache mal nachgehen, ich fuer meinen Teil werde ab Sonntag dann mal rueckmelden, ob das die Ursache war.

Vielen Dank schon mal.
dolphin

[dolphin]

Hi!

Ich wollte noch schnell diesen Thread hier abschliessen.

Wir haben nun bei "BIND Organisation"
in "/etc/bind/named.conf.options" im 'Option'-Block
die Option
"allow-query { any; };"
gesetzt.

In "BIND Abteilung" haben wir zusaetzlich noch
in "/etc/bind/named.conf.options" die Option
"dnssec-validation auto;" durch "dnssec-validation no;"
ersetzt und die Option "dnssec-enable no;" eingefuegt.

Die Aenderung im uebergeordneten BIND ist offenbar notwendig,
damit er dem untergeordneten BIND ueberhaupt seine Informationen
rausrueckt. Ob das wirklich zwingend ist, dazu muesste man das
allerdings mal isoliert testen. Es koennte auch sein, das es auch
ohne "allow-query { any; };" funktioniert.

Die Aenderung im untergeordneten BIND ist notwendig, weil
z.B. laut "http://www.zytrax.com/books/dns/ch7/security.html"
die Optionen "dnssec-enable" und "dnssec-validation" per Default
auf "yes" gesetzt sind, was dazu fuehrt, dass der untergeordnete
BIND per Default den Auskuenften des uebergeordneten BIND-Servers
nicht traut, solange die BIND-Server nicht in einem gegen DNS-Spoofing
gerichteten Trust-Network eingebunden sind. Die Loesung ist:
Die Security-Massnahmen ausschalten, der untergeordnete BIND-Server
wird jetzt vertrauensselig, traut also jedem BIND-Server, und der
Aufbau funktioniert zunaechst.

- dolphin -