BIND 9.7.3 auf Debian Squeeze mit ISC DHCP Server 4.1.1-P1

[pangu]

Einen wunderschönen guten Abend miteinander,

ich bin recht frisch dabei mit Debian und Linux und habe einige Fragen offen. Ich hoffe ihr könnt mir etwas unter die Arme greifen und mir bei meinem Problem helfen. Es geht um die korrekte Einrichtung eines DNS- und DHCP-Servers auf einer frischen Debian Squeeze Installation.

Mein Szenario ist eigentlich ziemlich simpel: Ein kleines Home-Office mit einigen Win7- und Linux-Clients, und zwei drei Linux-Servern. Mein frisch installierter Squeeze-Server heißt server01 und hat die IP 192.168.0.235. Er soll als Primary Domain Controller + Fileserver fungieren (mit Samba), als DHCP-Server, DNS-Server und NTP-Server. Samba ist noch nicht konfiguriert. Ich arbeite im 192.168.0.0/24 Subnet, mein Internet-Router hat die 192.168.0.1. Ich möchte dass mein DNS-Server nur für mein LAN erreichbar ist und auch nur für die Auflösungen intern zuständig sein soll. Wenn jemand ins Internet will, dann soll er direkt über die 192.168.0.1 auf DNS zugreifen und nicht meinen DNS-Server belasten. Ich bin mir jedoch nicht sicher, ob ich das korrekt eingestellt habe und ob ich hätte FORWARDING nutzen sollen oder nicht.

Ich habe momentan BIND und DHCP mit DDNS eingerichtet. Zuvor habe ich ein eigenes key-file generiert, das funktioniert auch soweit alles. Ich denke mein Netzwerk ist korrekt konfiguriert. Wenn ich hostname oder hostname -f absetze dann erhalte ich beide Male als Antwort server01.intern.mydomain.de

Meine wichtigsten Configs sehen so aus:

/etc/network/interfaces

Code: Alles auswählen

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.0.235
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1

/etc/resolv.conf

Code: Alles auswählen

domain intern.mydomain.de
search intern.mydomain.de
nameserver 127.0.0.1
nameserver 192.168.0.1

/etc/hosts

Code: Alles auswählen

127.0.0.1       localhost.intern.mydomain.de localhost
192.168.0.235   server01.intern.mydomain.de server01
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

/etc/bind/named.conf:

Code: Alles auswählen

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/bind.keys";
controls {
        inet 127.0.0.1 allow { localhost; };
};

/etc/bind/named.conf.options:

Code: Alles auswählen

options {
        directory "/var/cache/bind";
        forwarders {
        192.168.0.1;
        };
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
        query-source address * ;
        recursion yes;
        version "REFUSED";
        allow-recursion {
        127.0.0.1;
        192.168.0.0/24;
        };
        allow-query {
        127.0.0.1;
        192.168.0.0/24;
        };
};

/etc/bind/named.conf.local

Code: Alles auswählen

key mykeyfile {
        algorithm HMAC-MD5;
        secret "blablabla==";
};
zone "intern.mydomain.de" {
        type master;
        allow-update { key mykeyfile; };
        file "/var/cache/bind/zone.intern.mydomain.de";
};
zone "0.168.192.in-addr.arpa" {
        type master;
        allow-update { key mykeyfile; };
        file "/var/cache/bind/reversezone.192.168.0";
        notify no;
};

/var/cache/bind/zone.intern.mydomain.de

Code: Alles auswählen

$ORIGIN .
$TTL 604800     ; 1 week
intern.mydomain.de     IN SOA  server01.intern.mydomain.de. hostmaster.server01.intern.mydomain.de. (
                                2011012104 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server01.intern.mydomain.de.
router                          A       192.168.0.1
client1festip                 A       192.168.0.11
client2festip                 A       192.168.0.12
client3festip                 A       192.168.0.13

/var/cache/bind/reversezone.192.168.0

Code: Alles auswählen

$ORIGIN .
$TTL 604800     ; 1 week
0.168.192.in-addr.arpa  IN SOA  server01.intern.mydomain.de. hostmaster.server01.intern.mydomain.de. (
                                2011012103 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server01.intern.mydomain.de.
1                         PTR     router
11                       PTR     client1festip
12                       PTR     client2festip
13                       PTR     client3festip

/etc/default/bind9

Code: Alles auswählen

RESOLVCONF=yes
OPTIONS="-u bind -4"

/etc/default/isc-dhcp-server

Code: Alles auswählen

INTERFACES="eth0"

/etc/dhcp/dhcpd.conf

Code: Alles auswählen

key mykeyfile {
        algorithm HMAC-MD5;
        secret "blablabla==";
};
server-name               server01;
server-identifier           server01;
ddns-updates                on;
ddns-update-style           interim;
ddns-domainname             "intern.mydomain.de";
ddns-rev-domainname         "in-addr.arpa.";
do-forward-updates          on;
ignore                      client-updates;
option domain-name              "intern.mydomain.de";
option subnet-mask              255.255.255.0;
option domain-name-servers      192.168.0.235, 192.168.0.1;
option broadcast-address        192.168.0.255;
option ntp-servers              192.168.0.235;
option ip-forwarding            off;
default-lease-time              86400;
max-lease-time                  172800;
authoritative;
log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
    range                       192.168.0.101 192.168.0.199;
    option routers              192.168.0.1;
    allow                       unknown-clients;

  zone intern.mydomain.de. {
    primary 127.0.0.1;
    key mykeyfile;
  }

  zone 0.168.192.in-addr.arpa. {
    primary 127.0.0.1;
    key mykeyfile;
  }
}

Meine zwei Zonen-Datein liegen in /var/cache/bind und haben root als owner, und bind als Gruppe. Die Berechtigungen lauten 644. Soweit so gut: ich starte nslookup und teste.

root@server01:/root# nslookup
> client1festip
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: client1festip.intern.mydomain.de
Address: 192.168.0.11
>

gebe ich jedoch die IP ein, dann erhalte ich:

> 192.168.0.11
Server: 127.0.0.1
Address: 127.0.0.1#53

11.0.168.192.in-addr.arpa name = client1festip.0.168.192.in-addr.arpa.

Wieso sieht die Reverse-Abfrage denn so aus mit dem Zusatz in-addr.arpa ??? Ich habe mal zwei DHCP-Clients andocken lassen. Die DDNS Vorgänge scheinen geklappt zu haben. Wenn ich das gleiche mit nslookup, jedoch mit einem dynamisch eingetragenen DHCP-Client mache, dann erhalte ich eine 'richtige' Schreibweise des FQDN, siehe hier:

> pc3
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: pc3.intern.mydomain.de
Address: 192.168.0.122
>

> 192.168.0.122
Server: 127.0.0.1
Address: 127.0.0.1#53

122.0.168.192.in-addr.arpa name = pc3.intern.mydomain.de.
>

Ich hab daraufhin natürlich gleich in meine Zonendatei gespickelt, wie das der DHCP-Server über DDNS eingetragen hat. Siehe da, die DHCP-Clients wurden anders eingetragen, und zwar mit dem FQDN als Name.

/etc/var/cache/bind/zone.intern.mydomain.de

Code: Alles auswählen

[...]
                        NS      server01.intern.mydomain.de.
$ORIGIN intern.mydomain.de. <-- das hier ist neu reingeschrieben worden
router                          A       192,168.0.1
client1festip                 A       192.168.0.11
client2festip                 A       192.168.0.12
client3festip                 A       192.168.0.13
-->und dieser Block wurde neu reingeschrieben
$TTL 43200      ; 12 hours
pc3                     A       192.168.0.122
                        TXT     "31ad7482f7a34b3fcf5ba116efb43eb1f3"
pc4                     A       192.168.0.101
                        TXT     "31a7bd32fb232e30364ad1587ea7894279"
$TTL 604800     ; 1 week <--bis hier

und in der Reverse-Zone-Datei sieht man deutlich, dass bei den DHCP-Clients die FQDN eingetragen wurde:

/var/cache/bind/reversezone.192.168.0

Code: Alles auswählen

[...]
                        NS      server01.intern.mydomain.de.
neu reingeschrieben ab hier -->
$ORIGIN 0.168.192.in-addr.arpa. 
1                       PTR     router
11                     PTR      client1festip
12                      PTR     client2festip
$TTL 43200      ; 12 hours
101                     PTR     pc4.intern.mydomain.de.
122                     PTR     pc3.intern.mydomain.de.
$TTL 604800     ; 1 week <-- bis hier
13                      PTR     client3festip

Muss ich alle meine Angaben in der Zone-Datei also von Hand auf FQDN abändern, beispielsweise client1festip abändern auf client1festip.intern.mydomain.de ??? und das gleiche auch in der Reverse-Zonedatei? Oder habe ich nur einen Schalter übersehen, bzw. falsch gesetzt?

Hoffe ihr könnt mir diese Frage beantworten, genauso ob ich das Forwarding ein- oder ausschalten soll. Wie gesagt, ich möchte dass mein DNS-Server nur mit IPv4 lokal in meinem LAN arbeitet, ohne dass er von aussen erreichbar wäre (unabhängig obs die Firewall durchlässt) und dass er nur für lokale Adresse auflösen soll. Wenn ich ich nämlich in den Logs nachsehe, dann erscheinen dort Meldungen, dass Domainnamen aus dem Internet aufgelöst wurden. Das will ich aber nicht, denn das soll doch direkt mein Router beantworten und nicht mein DNS-Server lokal.

Hier einige Meldungen aus /var/log/syslog und /var/log/daemon.log die mich beunruhigen:

Code: Alles auswählen

Nov 15 18:26:22 server01 named[5161]: /etc/bind/named.conf:18: couldn't install keys for command channel 127.0.0.1#953: file not found
Nov 15 18:26:22 server01 named[5161]: /etc/bind/named.conf:18: couldn't add command channel 127.0.0.1#953: file not found
--> das ist die Zeile hier aus meiner named.conf, was ist daran falsch?? inet 127.0.0.1 allow { localhost; };

Nov 15 18:27:20 server01 named[5161]: success resolving 'teredo.ipv6.microsoft.com/A' (in 'microsoft.com'?) after disabling EDNS
Nov 15 18:27:20 server01 named[5161]: success resolving 'www.msftncsi.com/A' (in 'msftncsi.com'?) after disabling EDNS
Nov 15 18:29:36 server01 named[5161]: success resolving 'ksn2.kaspersky-labs.com/A' (in 'kaspersky-labs.com'?) after disabling EDNS
Nov 15 18:29:36 server01 named[5161]: success resolving 'ksn2.kaspersky-labs.com/AAAA' (in 'kaspersky-labs.com'?) after reducing the advertised EDNS UDP packet size to 512 octets

Nov 15 18:54:35 server01 named[5161]: managed-keys-zone ./IN: Unable to fetch DNSKEY set 'dlv.isc.org': timed out

Ich entschuldige mich für den langen Text, aber ich möchte mein Problem ausführlich schildern, dass überhaupt geholfen werden kann. Ich danke recht herzlich im Voraus und wünsche allen einen erholsamen Abend.

Grüße,
Michael.

[Cae]

Ein paar Punkte:

• hostname und hostname -f sollten so etwas wie host und host.domain.tld ausgeben, nicht beides mal host.domain.tld. Stichwort /etc/hostname - da sollte nur der Hostname drinstehen. Oder?
• die named.conf.options hat eine öffnende Klammer zu wenig (Typo?).
• normalerweise sollten die Zonendateien in /etc/bind/ liegen, da Konfigurationsdateien nun mal nach /etc/ gehören. Also die angelegten Zonendateien nach /var/ symlinken: ln -s /etc/bind/foo.db /var/cache/bind/
• ich würde den anderen Nameserver rausschmeißen und mich nur auf den lokalen verlassen, da er ja den anderen cacht. Aber als Fallback ist das ok.
• möglicherweise irre ich mich, aber sollte die NS-Direktive nicht mit IPs gefüttert werden? Wir haben doch keinen DNS, um den Namen aufzulösen.

Gruß Cae

[pangu]

Hallo Cae und einen guten Morgen,

• hostname und hostname -f hatte ich so angepasst, weil es explizit in einem Tutorial so angegeben wurde. Den Hintergrund kenne ich nicht. Naja, werds wieder rückgängig machen danke für den Hinweis.
• named.conf.options wurde in meinem Beitrag angepasst. Da war ein Typo-Fehler drin, die ersten zwei Zeilen fehlten.
• laut der named.conf.options werden die ja auch defaultmässig in /var/cache/bind genutzt, auch in den gesamten Tutorials hatte ich das so gesehen. Ich denke deshalb, weil die Zonendateien variable Dateien sind, in denen geschrieben werden. Ausserdem wird ja automatisch erstmal das Cache-File .jnl jeder einzelnen Zone angelegt, deshalb vermutlich auch der meiner Ansicht nach korrekten Wahlweise des Verzeichnisses unter /var/cache/bind. Sollte doch aber keine Probleme bereiten, oder doch? Rechte und so stimmen ja, Logs meckern ja auch nicht. Die Zonendateien können gelesen und beschrieben werden.
• welchen anderen NS rausschmeißen meinst du? den 192.168.0.1 ? Ich hab den immer als zweiten DNS angegeben (auch per DHCP so verteilt an meine Clients), dass die Hosts trotzdem noch im Internet surfen können, selbst wenn mal dieser primary DNS 192.168.0.235 ausfallen sollte.
• du meinst sicherlich meine Zonendateien? Die sind randvoll mit IPs und Hostnamen gefüttert, ich habe zur Übersichtlichkeit nur drei fiktive Clients und den Router hier im Beispiel aufgeführt

EDIT: Fehler behoben

Code: Alles auswählen

Nov 15 18:26:22 server01 named[5161]: /etc/bind/named.conf:18: couldn't install keys for command channel 127.0.0.1#953: file not found
Nov 15 18:26:22 server01 named[5161]: /etc/bind/named.conf:18: couldn't add command channel 127.0.0.1#953: file not found
--> das ist die Zeile hier aus meiner named.conf, was ist daran falsch?? inet 127.0.0.1 allow { localhost; };

Diese Fehlermeldungen aus dem Log habe ich behoben. Die Authentifizierung des Control-Channels war fehlgeschlagen. Ich hatte irgendwann die rndc.key aus dem /etc/bind/ Verzeichnis gelöscht, weil ich dieses standard file nicht mehr benötigte. Ich hatte ja ein eigenes keyfile kreiert. Tja, da lag ich wohl falsch, denn BIND braucht unbedingt diese Datei wie ich durch googeln herausgefunden habe. Ich hab also daraufhin mit "rndc-confgen -a" wieder eine Datei /etc/bind/rndc.key erstellen lassen. Diese Datei habe ich dann so bearbeitet, dass auf mein eigenes Keyfile zugegriffen wird mit der passenden security-Phrase. Der BIND-Server braucht unbedingt diese rndc.key Datei in seinem Verzeichnis, dann funktioniert auch der Controllchannel. Nähere Infos gibts hier --> http://www.zytrax.com/books/dns/ch7/controls.html

Code: Alles auswählen

Nov 15 18:54:35 server01 named[5161]: managed-keys-zone ./IN: Unable to fetch DNSKEY set 'dlv.isc.org': timed out

in meiner /etc/named.conf hatte ich manuell die /etc/bind/bind.keys includiert. Die sind wohl für DNSSEC-Validierung zuständig. Wenn ich das richtig interpretiere brauche ich aber keine DNSSEC-Validierung, da ja mein DNS-Server nicht draussen im öffentlichen Internet rumhantieren soll, sondern lediglich lokal seine Dienste anbieten soll. Ich bin mal auf die dlv.isc.org mit dem Webbrowser um zu sehen was rauskommt. Es war tatsächlich etwas mit DNSSEC. Nachdem ich diese Zeile wieder entfernt habe, scheinen keine Meldungen in diesem Stil im Log aufzutreten. Ich hoffe mein DNS-Server versucht jetzt also in Zukunft nicht mehr sich irgendwo im Internet zu validieren. Ich werde das weiter beobachten und lasse mich natürlich gerne auch korrigieren, falls ich falsch liegen sollte.

Ich wollte ja ursprünglich, dass meine DHCP-Clients sich unterscheiden in ihrem FQDN und eine extra Zone für diese erstellen. Das vergessen wir mal schnell wieder, ich werde das nicht durchführen, um keinen Mismatch durch die Sub-Domains zu erhalten (dhcpclient.intern.mydomain.de und intern.mydomain.de). Es ist ja physikalisch gesehen alles in derselben Domain, also intern.mydomain.de. Ich habe mal gegoogelt zur dhcpd.conf --> http://www.daemon-systems.org/man/dhcpd.conf.5.html da gibt es die feine Möglichkeit:

ddns-hostname name;
The name parameter should be the hostname that will be used in set-
ting up the client's A and PTR records. If no ddns-hostname is
specified in scope, then the server will derive the hostname automat-
ically, using an algorithm that varies for each of the different
update methods.

Interessieren würde mich hier, ob ich irgendwo und irgendwie dem DHCPD beibringen könnte, dass er am ermittelten Hostname einfach noch dranhängt -dhcpclient. Würde also beispielsweise der PC3 über den DHCP-Server eine Lease erhalten, so sollte der Hostname ergänzt werden und quasi per DDNS als "PC3-dhcpclient" eintragen. Weiß jemand wie so etwas gehen könnte?

Noch zu klärende Fehler wären die hier:

Code: Alles auswählen

Nov 15 18:27:20 server01 named[5161]: success resolving 'teredo.ipv6.microsoft.com/A' (in 'microsoft.com'?) after disabling EDNS
Nov 15 18:27:20 server01 named[5161]: success resolving 'www.msftncsi.com/A' (in 'msftncsi.com'?) after disabling EDNS
Nov 15 18:29:36 server01 named[5161]: success resolving 'ksn2.kaspersky-labs.com/A' (in 'kaspersky-labs.com'?) after disabling EDNS
Nov 15 18:29:36 server01 named[5161]: success resolving 'ksn2.kaspersky-labs.com/AAAA' (in 'kaspersky-labs.com'?) after reducing the advertised EDNS UDP packet size to 512 octets

Das Ursprungsproblem wird hier wohl die Firewall sein, die keine DNS-Pakete größer als 512 über UDP erlaubt. Das ist aber wohl zwingend für das EDNS-Protokoll erforderlich. Ich setze den Cisco RVS4000 Router ein, konnte aber keine Einstellung diesbezüglich finden. IPS und FIREWALL will ich deswegen nicht komplett deaktivieren. Infos zu EDNS gibts auf Google oder Wikipedia. Das neue Kommando DO wird über EDNS abgewickelt, und es ist für DNSSEC zuständig. Ich könnte natürlich EDNS komplett deaktivieren in meiner /etc/bind/named.conf.options indem ich ganz unten außerhalb der Options-Klausel folgendes hinzufüge:

server ::/0 {
edns no;
};

server 0.0.0.0/0 {
edns no;
};

damit würde ich EDNS komplett ausschalten in meinem BIND-Server, aber das ist ja auch nicht die feine Lösung weil das Problem nicht an der Wurzel behoben wurde. Oder was denkt ihr?
Bitte um kurze Bestätigung, ob ich mit meinen Vermutungen richtig liege.

Mir ist vor allem am Wichtigsten, dass ich meinem BIND quasi beibringe: "löse nur anhand deiner Zonendatei auf, also nur lokal für das 192.168.0.0/24 Netz. Alles andere schicke bitte SOFORT und DIREKT an die 192.168.0.1" soll sich der Router dann weiterkümmern. Wie sage ich das dem BIND ??

[unitra]

damit dein DNS Server aus dem WAN nicht erreichbar ist (egal ob mit Firewall oder ohne) solltest du folgenden Eintrag in die named.conf setzten

Code: Alles auswählen

 allow-query { 127.0.0.1; 192.168.0.0/24; };

Aber ich sehe gerade du hast diesen Eintrag bereits gesetzt.

und vielleicht noch zur Sicherheit

Code: Alles auswählen

version "Get lost p4L!";

Wenn dein Server 2 physikalische Netzwerk Schnittstellen hat, könntest du den Service (BIND daemon) an das von Dir bevorzugte Interface binden, das geht generell mit fast jeder software, auch mit Samba (bind interfaces) oder ähnlich, dann an die Interface IP "binden". Damit wir der Dienst an dem(WAN) Interface nicht angeboten.

Bezüglich der 2-ten Frage dass die DNS Abfragen zum WAN (also alle Abfragen außer LAN) an den Router oder sonstwo geschickt werden sollen, und dein Server damit nicht belästigt werden soll, ich weiss nicht ob das so funktioniert. Denn dein Client kriegt ja schon einen DNS Server zugewiesen, oder eine liste von DNS Servern. Dein Interner BIND wird immer die Abfragen abbekommen, auch wenn er sie durch den forward Eintrag in der named.conf weiterleitet. Das wird glaube ich so nicht funktionieren, da müsste der Client schon die Entscheidung treffen an welchen DNS Server er die Abfragen schickt, dazu müsste er entscheiden und vor allem wissen dass eine Abfrage Intern (LAN) ist und die andere Abfrage extern (WAN) ist.

[pangu]

Hi,

er hat nur eine Schnittstelle, auf die er natürlich lauscht und seine Serverdienste bereitstellt. Ich hab jetzt nochmals gegoogelt. Selbst auf den Cisco-Support-Forums konnte ich keine Hinweise zwecks EDNS zu meinem Router (Cisco RVS4000) finden. Was mich halt wundert ist, dass das überhaupt auftritt. Du meinst also, dass das durch den Client fabriziert wird weil der Client versucht aufs Internet zuzugreifen? Aber das würde ja dann bedeuten, dass mein lokaler BIND9-Server irgendwelche Namensserver aus dem Internet kontaktiert. So zeigt es ja auch das Logfile an. Das soll mein DNS-Server aber gar nicht. Ich dachte ich hätte ihm das ausdrücklich gesagt mit dem Forward-Befehl auf die 192.168.0.1 (das ist mein Router). Demnach sollten ja alle DNS-Auflösungen die nicht mit meinem LAN zu tun haben, einfach blind an die 192.168.0.1 forgewardet werden.

Anscheinend tun sie das aber nicht, sonst wäre dieser EDNS-Hinweis im Log gar nicht erst aufgetaucht. Bitte korrigiert mich wenn ich falsch liege.

Das läßt also meine Frage immer noch dastehen --> wie bringe ich meinem DNS-Server bei, dass er für DNS-Auflösungen im Internet nicht selbst danach sucht, sondern blind einfach an die 192.168.0.1 forwarded und meinem Router überlässt?

[pangu]

Ich kann das leider immer noch nicht lokalisieren. Mein BIND-Server scheint hier selbstätig im Internet aufzulösen und das Ergebnis an seine Clients weiterzugeben. Obwohl ich ihm das nicht erlaube. Ich hab das folgendermaßen getestet:

Auf meinem BIND-Server habe ich in der named.conf.option den Abschnitt forwarders auskommentiert:

Code: Alles auswählen

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

//      forwarders {
//      192.168.0.1;
//      };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };

        query-source address * ;

        recursion yes;

        version "Get lost a**hole!";

        allow-recursion {
        127.0.0.1;
        192.168.0.0/24;
        };

        allow-query {
        127.0.0.1;
        192.168.0.0/24;
        };

};

Das waren die einzigsten Zeilen, die der BIND von irgendwelchen Weiterleitungen kennt. Nachdem ich jetzt aber auskommentiert habe und den Server restartet habe, sollte er eigentlich keine einzige DNS-Anfrage seiner Clients an die 192.168.0.1 (mein inet-Router) forwarden. Getestet habe ich das wie folgt: am Win7-Client habe ich meine Netzwerkeinstellung manuell so angepasst, dass als DNS-Server definitiv nur mein BIND-Server steht. Ich kann mit nslookup nun DNS-Abfragen testen. Meine lokalen Namensauflösungen funktionieren einwandfrei. Aber jetzt kommt's --> sobald ich öffentliche Domainname in nslookup eingebe (z.B. lycos.com), dann kriegt er die trotzdem aufgelöst und zwar von meinem BIND-Server ! Das ist unmöglich, wieso ? Das bedeutet also, dass mein BIND-Server trotzdem die DNS-Anfrage an die 192.168.0.1 weitergeleitet hat. Wie zum Geier weiß mein Debian-Server (BIND) wie er ins Internet gelangt um DNS abzufragen? Geht er automatisch über das Gateway und nutzt die gleiche Gateway-Adresse, die ihm bekannt ist, auch als DNS-Adresse? Das kann ich mir nicht vorstellen, das wäre ja fatal. Übrigens: in meiner /etc/resolv.conf habe ich stehen:

Code: Alles auswählen

search intranet.meinefirma.de
nameserver 127.0.0.1

damit sage ich meinem System explizit, dass er den lokalen Host für Namensauflösungen verwenden soll. Somit landet er dann auf dem lokalen BIND-Server. Er kann also gar nicht wissen, dass auf 192.168.0.1 (mein Router) auch DNS kann und trotzdem kommt er irgendwie dahin.

Woher weiß er das aber? wird das irgendwo anders noch geregelt ohne meines Wissens?

meine ifconfig:

Code: Alles auswählen

~# ifconfig
eth0      Link encap:Ethernet  HWaddr fa:dd:4f:3e:ff:be
          inet addr:192.168.0.235  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2397 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1608 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:299250 (292.2 KiB)  TX bytes:570771 (557.3 KiB)
          Interrupt:23

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10615 (10.3 KiB)  TX bytes:10615 (10.3 KiB)

meine routing table:

Code: Alles auswählen

~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

[Cae]

Ich hab's nicht ausprobiert, aber könnte die Kiste einfach von der Root-Zone her auflösen? Schnippel doch mal mit Wireshark (schön, buntig) oder tcpdump/ngrep (Konsole, ebenso aussagekräftig) mit, was so auf Port 53 TCP/UDP hinter dem Bind-Rechner passiert.

Gruß Cae

[pangu]

Du meinst, dass der Debian-Server, auf dem BIND9 läuft, nicht über seine konfigurierte /etc/resolv.conf geht, sondern heimlich durch andere Türen zu den Root-Servern? Ich hab noch nicht geschnüffelt, aber ich frage mich: wieso sollte er das tun? Das wird doch bestimmt nicht die Intension der Debian-Entwickler sein

aber das würde wiederum folgendem widersprechen.

1.) Ich bin am Debian-Server eingeloggt
2.) meine /etc/resolv.conf zeigt auf keinen öffentlichen Server, da steht als nameserver nur die 127.0.0.1 drin
3.) ich beende den BIND9 mit "/etc/init.d/bind9 stop"
4.) die Namensauflösung funktioniert nicht mehr, ich krieg keine Antwort auf Domain-Namen im Internet, natürlich auch keine internen, BIND9 ist ja tot.

Das bedeutet dass der BIND9 tatsächlich die Namensauflösung macht.

5.) sobald ich den BIND9 wieder mit "/etc/init.d/bind9 start" starte, krieg ich sowohl meine interne LAN-Auflösungen korrekt dargestellt, als auch öffentliche DNS-Auflösungen.

Es ist also 100%ig, dass der Dienst BIND9 oder irgendein davon abhängiger Sub-Dienst die Namensauflösung im inet durchführt.

EDIT: Ich hab einen Dienst entdeckt namens lwresd. Ich hab mir dessen Beschreibung in der manpage mal angeschaut. Wieso zum Geier läuft der? ich hab den nie installiert, konfiguriert oder explizit gestartet. Vielleicht liegt hier der Hund begraben? Aber nach einem schnellen Test mit "/etc/init.d/lwresd stop" funktioniert die Internetauflösung trotzdem noch. Hmm... Eine Seite im Internet sagt außerdem zu diesem lwresd folgendes:

The lwresd daemon is essentially a caching-only name server that responds to requests using the lightweight resolver protocol rather than the DNS protocol. Because it needs to run on each host, it is designed to require no or minimal configuration. Unless configured otherwise, it uses the name servers listed on nameserver lines in /etc/resolv.conf as forwarders, but is also capable of doing the resolution autonomously if none are specified.

The lwresd daemon may also be configured with a named.conf style configuration file, in /etc/lwresd.conf by default. A name server may also be configured to act as a lightweight resolver daemon using the lwres statement in named.conf.

Dabei macht mich dieses genannte "...doing autonomously resolution..." doch etwas skeptisch. Woher wüßte er dann aber, dass der einzigst funktionieren Nameserver noch mein Gateway ist? Geht er automatisch davon aus, dass mein Gateway auch DNS-Auflösungen kann?

[pangu]

Da schau her ...

If /etc/resolv.conf contains any nameserver entries, lwresd sends recursive DNS queries to those servers. This is similar to the use of
forwarders in a caching name server. If no nameserver entries are present, or if forwarding fails, lwresd resolves the queries
autonomously starting at the root name servers, using a built-in list of root server hints.

Ich hab jetzt in meiner /etc/resolv.conf von 127.0.0.1 auf die 192.168.0.235 abgeändert. Das ist der gleiche Host, wo auch BIND9 läuft. Jetzt würde ich natürlich gerne wissen wollen, ob dieser Dienst lwresd9 das als EINGETRAGEN oder NICHT interpretiert ? Denn die 127.0.0.1 die ich davor drinstehen hatte, interpretierte er wohl ganz klar mit NICHTS EINGETRAGEN, also kontaktierte er die Root-Server womöglich.