Also, erst mal Danke an alle, die bisher geantwortet haben. Ich habe mir erst mal alle Antworten durchgelesen, bevor ich jetzt hier auf alles antworte. Sandy Drobic wrote:

Martin Deppe wrote:

...

Hallo Leute,

ich hätte gern mal wieder eure Hilfe:

Ich habe Internet und ein Intranet (wie vermutlich die meisten von euch) in dem ich jetzt auch einen DNS-Server laufen habe. Prinzipiell tut er ja auch, aber eben nicht ganz korrekt.

Er soll folgendes tun: 1. alle Anfragen bzgl. externer Adressen an den DNS-Server (in meinem Fall) von Hansenet weiterleiten (logisch - funktioniert auch), 2. alle Anfragen bzgl. lokaler Adressen korrekt auflösen (funktioniert leider NICHT) und

Weil du keine zone dafür eingerichtet hast, nehme ich an.

...

3. dem DHCP-Daemon und dem SMB-Server die korrekten Daten geben, so daß auch Windows-Rechner auf das lokale Netzwerk zugreifen können, wie sie es ins Internet auch jetzt schon können.

Es ist eigentlich umgekehrt. Die Clients aktualisieren die Einträge in den Zonen. Dafür muss der DNS-Server so eingerichtet sein, dass die Clients auch die Erlaubnis dazu haben. Auch hierfür solltest du eine Zone erstellen oder zumindest in deiner internen Zone dynamic-dns updates erlauben.

Hallo Sandy, darüber habe ich gelesen, hatte aber wohl noch nicht ganz realisiert, was das wirklich bedeutet. Es ist jedenfalls eine Eigenschaft, die ich auch in mindestens einem Fall brauche :-), da ich in dem Fall eine dyn. IP-Adresse vom DNS-Server zurück geben lasse.

[ ... ]

Detlef Reichelt wrote:

Moin Ralf,

Am Sun, 20 Jan 2008 22:09:49 +0100 schrieb Ralf Arndt :

...

Verwende besser eine TLD die nicht existiert. Sofern ich http://de.wikipedia.org/wiki/Top-Level-Domain und http://de.wikipedia.org/wiki/Multicast_DNS#Multicast_DNS richtig verstehe wäre .local eine gute Wahl.

genau im Gegenteil, die sollte man nicht verwenden, da sie von Multicast-DNS genutzt wird. Ich nutze immer $name.netz, SUSE schlägt $name.site vor. Beides ist eine gute Wahl. ;)

Detlef

Hallo Detlef, dann werde ich wohl meine Rechner alle auf ".my.site" umstellen - vielleicht reicht es ja es am DHCP-Server (und evtl. DNS-Server) umzustellen. Falls nicht, muß ich die Clients eben auch entsprechend umstellen, sodaß sie die Domain vom DHCP-Server bekommen. Detlef Reichelt wrote:

Moin Martin,

Am Sun, 20 Jan 2008 19:33:12 +0100 schrieb Martin Deppe :

...

4. DNS- und DHCP-Server

ich denke, du schlägst dich mit Bind rum? Das ist in einem kleinem Netz meistens "mit Kanonen auf Spatzen schießen". Versuch dich an dnsmasq, kannst du mit YaST installieren und er ist sehr einfach über die /etc/dnsmasq.conf zu konfigurieren. Es bietet dir einen DHCP- und DNS-Server ohne großen Aufwand an, der normalerweise alles mitbringt, was du im heimischen Netz so brauchst.

Detlef

Stimmt, und danke für den Tipp. Klingt wirklich interessant. Da ich allerdings davon ausgehe, daß ich später mit bind arbeiten müssen werde, möchte ich lieber selbiges verstehen und hier so zum laufen bringen, wie ich es brauche. Kyek, Andreas, VF-DE wrote:

Martin.Deppe@web.de wrote:

...

Ich habe Internet und ein Intranet (wie vermutlich die meisten von euch) in dem ich jetzt auch einen DNS-Server laufen habe. Prinzipiell tut er ja auch, aber eben nicht ganz korrekt.

Er soll folgendes tun: 1. alle Anfragen bzgl. externer Adressen an den DNS-Server (in meinem Fall) von Hansenet weiterleiten (logisch - funktioniert auch),

Kein Problem: DNS von Hansenet (oder besser; falls Du einen router verwendest: IP des Routers) als forwarder in die DNS Konfig eintragen. Sicherstellen, das deine resolv.conf auf deinen DNS zeigt; resolv.conf NICHT ändern lassen, falls Dein PC einwählt (im Falle eines routers kein Problem)

...

2. alle Anfragen bzgl. lokaler Adressen korrekt auflösen (funktioniert leider NICHT) und

Fehlkonfiguration von a) Netz (resolv.conf der clients) oder b) DNS (lokale Zone falsch/nicht definiert)

Die Zone ist zwar definiert, aber vielleicht in der falschen Datei - sodaß sie tatsächlich eben doch nicht definiert ist - oder mit ziemlicher Sicherheit nicht korrekt definiert, weshalb ich mich ja auch an euch wende, nachdem ich mit dem Buch bisher nicht klar kam.

...

3. dem DHCP-Daemon und dem SMB-Server die korrekten Daten geben, so daß auch Windows-Rechner auf das lokale Netzwerk zugreifen können, wie sie es ins Internet auch jetzt schon können.

??? Die clients bekommen deinen Server als DNS/DHCP/SMB Server angegeben; dieser muss natürlich die Dienste dann korrekt bereitstelen.

Falls dein Rechner selber die DSL-Verbindung aufbaut ist es wichtig, das du nicht die "MODIFY_RESOLV_CONF*" in /etc/sysconfig/* erlaubt hast; Ferner musst Du dem lokalen Netz DNS Anfragen erlauben.

Das ist aber normale Bind-Konfig und eigentlich nichts besonderes; ich habe eine solche Konfig hier seit langem laufen.

Andreas

BTW: Ich empfehle _fast_ immer die Verwendung eines externen DSL-Routers; ansonsten fehlt mir in deiner Aufstellung massiv die Firewall. Wenn dein PC die Verbindung aufbaut ist er von aussen erreichbar; daher besser hinter einem Router aufbauen; das Risiko ist _deutlich_ geringer!

Sorry, ich hatte vergessen, die Firewall zu erwähnen, die läuft natürlich auch, und zwar auf dem gateway, welches sich per DSL einwählt und dabei die resolv.conf unbehelligt läßt. Ich habe keinen externen Router, weil mir das seinerzeit zu teuer war und ich sowieso einen Server brauch(t)e für z.B. Faxempfang und eben die Dienste SMB-, NFS-, DHCP-, DNS- und Print-Server. Kennt denn niemand eine GUTE und eben verständliche Dokumentation, aus der ich all die Informationen herauslesen könnte, die ich brauche? Ich kann nicht glauben, daß es noch niemanden so genervt hat, daß immer wieder dieselben Fragen aufkommen, daß niemand eine solche Dokumentation bisher erstellt hat? Ich verstehe ja, daß es sich um ein recht komplexes Thema handelt (tut es das eigentlich wirklich?), aber es muß doch einen Weg geben, es jemandem, der es eben nicht kennt, ausreichend verständlich nahe zu bringen, so daß er sich ein System entsprechend selbst aufbauen kann. Also, wie sieht das aus? "named" greift auf "/etc/named.conf" für die eigene Konfiguration zu. In "/etc/named.conf" habe ich im Moment folgende Zonen definiert (Bemerkungen als Kommentare): # Brauche ich diese Zone eigentlich und wofür ist die? zone "." IN { type hint; file "root.hint"; }; zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; }; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; allow-update { none; }; }; # Macht es was, daß die folgende Datei nicht existiert? include "/etc/named.conf.include"; zone "my.site" IN { file "master/my.site"; type master; allow-update { none; }; // @Sandy: Hier müßte dann das lokale Netz rein, damit die Clients ihre eigenen Daten dem Server bekannt machen können, richtig? allow-query { localhost; 192.168.1.0/24; // IPv4 Intranet only }; allow-transfer { none; }; }; logging { category queries { log_file; }; category default { log_file; }; channel log_file { file "/var/log/dns-server-md.log" size 10M; }; }; Tja, ich habe dann noch ein paar andere Dateien, aber ich glaube, ich muß mir mal eine Zeichnung von der Struktur machen, um da richtig durch zu steigen. Heute bin ich aber schon zu müde dazu! Martin -- Linux User #281156 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Andreas, Kyek, Andreas, VF-DE wrote:

Martin.Deppe@web.de wrote:

Ich antworte mal nur auf "meinen" Teil, OK?

[...]

...

Kyek, Andreas, VF-DE wrote:

Sorry, ich hatte vergessen, die Firewall zu erwähnen, die läuft natürlich auch, und zwar auf dem gateway, welches sich per DSL einwählt und dabei die resolv.conf unbehelligt läßt.

Moment; langsam: Der "Server" und das "Gateway" sind zwei verschiedene Rechner?

Nein, nein, alles auf EINEM Rechner!

Dann kannst du den eigenen DNS-Server auf dem Server laufen lassen und als forwarder z.B. den deines Providers nutzen. Allerdings ist das Gateway dann wahrscheinlich nicht an den DNS auf dem Server angeschlossen; ist nicht schlimm sollte man aber im Hinterkopf behalten.

...

Ich habe keinen externen Router, weil mir das seinerzeit zu teuer war und ich sowieso einen Server brauch(t)e für z.B. Faxempfang und eben die Dienste SMB-, NFS-, DHCP-, DNS- und Print-Server.

Hier sieht das wieder nach _einem_ Rechner für DSL und Server aus! Was denn nun?

[...]

...

Also, wie sieht das aus? "named" greift auf "/etc/named.conf" für die eigene Konfiguration zu.

Ja

...

In "/etc/named.conf" habe ich im Moment folgende Zonen definiert (Bemerkungen als Kommentare):

# Brauche ich diese Zone eigentlich und wofür ist die? zone "." IN { type hint; file "root.hint"; };

Die braucht der bind, wenn er die Requests nicht selber auflösen kann. DNS ist hierarchisch organisiert. Ein DNS Server ist für seine Domain(s) zuständig (authoritativ) und beantwortet alle Anfragen für diese. Kommt nun ein Request für etwas ausserhalb der Domain, kommt a) die Antwort aus dem cache, falls sie da ist und TTL noch nicht erreicht b) die Frage wird an den forwarder geleitet, falls definiert c) er sucht selber. Dazu befragt er einen root-NS (aus root.hint) nach dem zuständigen für die TLD (com, de, ...). Diesen wiederum fragt er nach dem nächsten Teil (heise.de, hp.com, ...) u.s.w bis er auf einen NS trifft, der die Frage beantworten kann (entweder aus dessen cache oder weil er authoritativ für die Anfrage ist)

Ah, danke für die Info, daß macht die Sache doch um einiges klarer, obwohl ich es eigentlich auch vorher schon hätte verstanden haben sollen :-( Na ja, manchmal braucht man es vielleicht einfach nochmal in anderen Worten! Wenn ich also einen Forwarder korrekt eingerichtet habe, könnte ich theoretisch auf obige Zone verzichten, richtig?

...

zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; }; };

Die hier habe ich nicht.

Die stand bzw. steht im erwähnten Buch. Brauche ich wahrscheinlich auch nicht, vermute ich mal.

...

zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; };

zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; allow-update { none; }; };

Die brauchst du!

...

# Macht es was, daß die folgende Datei nicht existiert? include "/etc/named.conf.include";

zone "my.site" IN { file "master/my.site"; type master; allow-update { none; }; // @Sandy: Hier müßte dann das lokale Netz rein, damit die Clients ihre eigenen Daten dem Server bekannt machen können, richtig? allow-query { localhost; 192.168.1.0/24; // IPv4 Intranet only }; allow-transfer { none; }; };

a) Die clients die Daten bekanntgeben? Nee, ich würde 'nen DHCP-Server aufsetzen und diesem dynamische Updates am DNS erlauben. Wie das geht, findest du bestimmt im Netz (ich hab's auch dort gefunden!)

b) Hier fehlt die "reverse-zone"; also die Definition von

zone "1.168.192.in-addr.arpa" IN { type master; file ... }

Da hab' ich jetzt was eingebaut, aber die zone-Datei ist wahrscheinlich nicht korrekt oder? $TTL 1W @ IN SOA localhost. root.localhost. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS localhost. 1 IN PTR localhost.

Ansonsten klappt der reverse DNS nicht; dein Bind ist NICHT korrekt konfiguriert.

Was hier VÖLLIG fehlt (und ich als mindestens unschön empfinde) ist ein "forwarder".

Siehe oben!

Deine Konfig würde _alles_ was nicht lokal aufgelöst werden kann über die root-DNS versuchen aufzulösen (s.o.) Wenn das jeder macht, kannst Du die root-DNS bald vergessen!

Schon gut, schon gut, dazu möchte ich nicht beitragen ;-)

Sinn der forwarder ist, das dein DNS alles nicht lokale über z.B. den DNS des Providers versucht aufzulösen. Dieser wird bestimmt schon länger laufen und einen entsprechend gut aufgebauten cache haben. Damit entlastet man die Zugriffe auf die root-NS. Also bitte eine Section

forwarders { x.x.x.x; y.y.y.y; } forward first;

Habe ich gemacht, wie gesagt, siehe oben!

in die named.conf (section options); das sagt deinem Bind: Alles nicht lokale gebe zuerst an einen forwarder und nur wenn der nicht erreichbar ist, gehe über die root-NS.

Jetzt muss ich was tun

Andreas

Super, vielen Dank Andreas, ich hoffe, ich komme dann morgen mal dazu, meine komplette Struktur hier darzustellen, aber wahrscheinlich erst Fr. oder am WE. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Andreas, Kyek, Andreas, VF-DE wrote:

Martin.Deppe wrote. [...]

...

Wenn ich also einen Forwarder korrekt eingerichtet habe, könnte ich theoretisch auf obige Zone verzichten, richtig?

Nee, lass den Eintrag mit root.hint ruhig drin. (Ich hab's noch nie ohne probiert!)

gut, das laße ich dann mal drin!

Das ist doch aber nicht die 1.168.192.in-addr.arpa, oder? So sieht bei mir die 127.0.0.... aus

Es sieht tatsächlich so aus, weil ich noch nicht kapiert habe, wie es richtig aussehen muß. Das ist ja genau der Knackpunkt!

Deine müsste IMO z.B. so aussehen: --- cut here --- $TTL 1W 1.168.192.in-adr.arpa. IN SOA server.my.site. root.localhost. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum

IN NS server.my.site. 1 IN PTR server.my.site. 2 IN PTR anderer_Rechner.my.site. 3 IN PTR noch_ein_Rechner.my.site. --- cut here ---

Das ganze natürlich passend zur Zonendefinition in my.site!

Also, "1.168.192.in-adr.arpa" sieht dann jetzt so bei mir aus: -------------------------------------------------------------------- start of file $TTL 1W 1.168.192.in-adr.arpa. IN SOA gateway.my.site. root.localhost. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS gateway.my.site. 1 IN PTR gateway.my.site. 104 IN PTR martin4.my.site. 110 IN PTR inna.my.site. 111 IN PTR martin11.my.site. -------------------------------------------------------------------- end of file Und "my.site" folgendermaßen: -------------------------------------------------------------------- start of file $TTL 2d @ IN SOA gateway.my.site. root.gateway.my.site. ( 2007093000 ; serial 3h ; refresh 1h ; retry 1w ; expiry 1d ) ; minimum gateway IN A 192.168.1.1 martin4 IN A 192.168.1.104 inna IN A 192.168.1.110 martin11 IN A 192.168.1.111 -------------------------------------------------------------------- end of file was mit Sicherheit nicht (völlig) korrekt ist, würde ich sagen! Außerdem habe ich gerade festgestellt, daß meine Routingtabelle einen falschen Eintrag enthält, würde ich sagen: -------------------------------------------------------------------- start of file Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface lo1.br01.acham. * 255.255.255.255 UH 0 0 0 dsl0 192.168.2.0 * 255.255.255.0 U 0 0 0 eth2 192.168.1.0 * 255.255.255.0 U 0 0 0 eth3 link-local * 255.255.0.0 U 0 0 0 eth2 loopback * 255.0.0.0 U 0 0 0 lo default * 0.0.0.0 U 0 0 0 dsl0 -------------------------------------------------------------------- end of file oder ist der Eintrag "link-local" korrekt und wenn ja, wozu ist er dann da? Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig wrote:

On Sun, Jan 20, 2008 at 07:33:12PM +0100, Martin Deppe wrote:

...

3. dem DHCP-Daemon und dem SMB-Server die korrekten Daten geben, so daß auch Windows-Rechner auf das lokale Netzwerk zugreifen können, wie sie es ins Internet auch jetzt schon können.

Ich benutze dafuer eigntlich immer den in Samba eingebauten WINS-Server (smb.conf "wins support=yes")

Dann wiederrum haben wir 20 Rechner, alle mit einer festen IP-Adresse.

Ok, mache ich ja auch, aber der Samba-Server wiederum muß die Adressen ja auch irgendwo her bekommen und das funktioniert bei mir noch nicht korrekt. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org