Hallo Leute,

ich habe einige Probleme mit meinem neu aufgesetzten DNS Server.

Ich habe bei einem externen Anbieter die URL/Hostname: www.myHostename.de (ich nenne sie einfach mal so).
Mein Interner Server hat den gleichen Hostname verpasst bekommen, nun habe ich nach Anleitung von eine sogenannte Split-DNS eingerichtet...
dies bedeutet rufe ich im Browser www.myHostname.de auf gelange ich auf den externen Webspace, trage ich allerdings "meinServer.myHostname.de" ein werde ich auf meinen internen Server geroutet.

Nun habe ich aber folgende Nslookup ergebnisse:


nslookup sollte die IP Adresse des Servers ausgeben, und das ohne fehler meldungen...! Zusätzlich habe ich das ganze auch nochmal genau andersherum probiert:

Ohne jetzt weiter Ursachenforschung betrieben zu haben -- kennst Du RFC 2606 ?

Es gibt für den internen Gebrauch extra reservierte Top Level-Domains (TLDs), siehe z.B. RFC 2606.
Weshalb verwendest Du intern nicht einfach eine andere Toplevel-Domain, also z.B. .test, .example, .invalid oder .local (.local ist zwar nicht in dieser RFC vorgesenen, aber meines Wissens nach Bonjour- und Zeroconf-tauglich)?

Extern also weiterhin www.myhostname.de und intern also z.B.
www.myhostname.test oder
www.myhostname.invalid oder
www.myhostname.local

Damit dürftest Du das Problem und Konflikte drumherum sicher schon mal komplett ausklammern, denn Missverständnisse kommen so dann gar nicht erst auf bzw. der DNS-Server muss gar nicht erst so konfiguriert werden, dass er etwaige Missverständnisse ggf. umschiffen muss...
Ich praktiziere das seit Jahren so und ohne Probleme.

Die Abfrage aus Deinem Beispiel funktioniert deshalb nicht, weil der Computer überhaupt noch nicht dazu konfiguriert wurde, den eigenen DNS zu benutzen. Er fragt in beiden Beispiel einen offiziellen Server der Telekom.

Was das "zdm" im ersten Beispiel soll, wird auch nicht ganz klar ...

In der Tat ist es die einfachste Lösung, eine eigene TLD zu benutzen. Für eine solche Konfiguration ist ".private" die beste Wahl.

".local" darf auf keinen Fall benutzt werden, da das sofort zu einem Konflikt mit Bonjour und eventuell vorhandenen Windows-Servern führt.

ZDM ist der titel des lokalen Servers...
Warum wurde der Computer dafür nicht konfiguriert? DNS wurde angelegt und Forwarder adressen der Telekom eingetragen, der Client hat als DNS-Server den lokalen Server (ZDM) eingetragen.

Nein, ganz bestimmt nicht. Dann würde nicht ein DNS-Server der Telekom (217.0.43.17) antworten.

Ich werde gleich mal einen Screenshot posten wenn ich wieder am Server bin... ich teste vom Server aus und DNS-Server Ip ist gleich die IP des Servers (sehe ich hier gerade noch über VPN).

Ist .private irgendwo in irgendeinem RFC festgelegt bzw. empfohlen? Wenn nein, warum ausgerechnet .private? Wenn schon nicht RFC 2606-konform (wo ja konkrete reservierte TLDs aufgeführt sind), warum dann ausgerechnet bevorzugt .private? Wäre dann nicht auch jeglicher andere String (der nicht irgendwo reserviert ist), bspw. .lokal oder .zuhause denkbar?

Mir ist das schon bekannt, vor Jahren haben mit der Begründung sämtliche Linux-Distris das umgestellt, nachdem sie zuvor jahrelang .local benutzt und vergeben haben. Ich frage mich allerdings, warum Apple in seinem heutigen MacOSX diese nicht-RFC2606-konforme .local TLD selber einsetzt bzw. in seinen Sharing-Konfigurationseinstellungen als festen (und meiner Erfahrung nach leider unveränderlichem) Bestandteil des Gerätenamens einsetzt, wenn er so problembehaftet ist.
Wieso wird er dann von Apple unter MacOSX nicht gänzlich gemieden oder wenigstens veränderbar gestaltet, sondern fest zugewiesen? Habe bisher keine Antwort drauf, weshalb Apple .local anscheinend fest verdrahtet und das in allen anderen Fällen ein "No-Go" ist. Kannst Du mir da eine Antwort drauf geben?

Im Zweifel lieber RFC-konform bleiben.

Das ist nicht nötig. Die Ausgabe von nslookup zeigt klar, wer im Moment der maßgebliche DNS-Server ist.

Selbst wenn Du glaubst, das eingestellt zu haben, ist diese Einstellung (noch ?) nicht im System angekommen.

Gibt es denn eine Config wo ich die nachkontrollieren kann?

Hauptsächlich wohl in:

• /etc/named.conf (was bzw. welcher Server steht dort z.B. im Eintrag forwarders drin? Und: forward: first oder forward only eingetragen?)
• /etc/resolv.conf
• Die entsprechenden (Zone-)Dateien im Verzeichnis /var/named

Neben nslookup (man nslookup oder online unter ) ist noch das Programm dig (man dig oder online unter ) sehr hilfreich, die DNS-Konfiguration zu überprüfen.

Darüberhinaus sollte der eigene lokale DHCP-Server bzgl. der eigenen DNS-Server- Informationen entsprechend angepasst sein, damit er diese Informationen an die Clients weitertragen kann.

Ich bin verwirrt... /etc/named.conf schein leer zu sein?! Dabei ist in der GUI alle eingetragen!

Das ist alles was Pico anzeigt:
must be contained in views.

Schau mal etwas genauer -- ich sehe da u.a. folgende Einträge:
include "/etc/dns/options.conf.apple";
include "/etc/dns/loggingOptions.conf.apple";
include "/etc/dns/publicView.conf.apple";

Da werden also Dateien inkludiert bzw. ausgelagert (entweder zwecks Übersichtlichkeit/Lesbarkeit dieser Config-Datei oder/und zwecks besserer Handhabung). Vielleicht solltest Du Dir diese betreffenden ausgelagerten Dateien mal näher anschauen? Möglicherweise steht dort ja drin, wonach Du Ausschau hältst.

Ok ich habs... kommt mir allerdings alles etwas wenig vor da ich die von sierkb angefragten infos nicht finden kann.


File: /etc/dns/options.conf.apple

File: publicView.conf.apple

File: /etc/resolv.conf

Was macht da bei Dir die Angabe "search myURL.de" drin?

Siehe auch , ,

Und wenn ich mir Deine Datei publicView.conf.apple so anschaue, so ist da offenbar für Deine lokale Domain noch nix konfiguriert bzw. dort sind ebenfalls noch Platzhalter drin in den dort definierten zone-Abschnitten:


Was machen da die offensichtlichen Platzhalter "dada.de" und "db-myURL.de" drin?
Du meinst nicht, dass da sinnvollere Angaben drinstehen sollten?

Am Besten, Du beschäftigst Dich erstmal mit den Grundlagen, wie man BIND bzw. einen DNS-Server korrekt aufsetzt. Und zwar ohne GUI und ohne Klicki-bunti. Damit Du verstehst, was Du tust.
HowTos und Manpages dazu gibt es im Netzt genug, z.B.

Red Hat: How to set up a home DNS server
oder
Red Hat: Berkeley Internet Name Domain (BIND)
oder

Um nur mal eine zufällige Auswahl zu nennen. Es gibt bestimmt auch bessere Dokumente im Netz. Sicher auch passend für MacOSX Server bzw. FreeBSD. Einfach mal die Suchmaschine Deiner Wahl bemühen. Und nimm Dir Zeit dafür.

Einen DNS-Server aufzusetzen ist nicht trivial. Nie. Auch, wenn's wie im Fall von MacOSX Server GUI-gestützt ist. Das grafische Interface ist lediglich ein Aufsatz auf das, was unter der Haube geschieht, und der grafische Aufsatz muss nicht immer unbedingt das tun, was Du eigentlich erwartest (bei MacOSX Server ist das offenbar besonders zu beachten und leider manchmal der Fall). In jedem Fall und ob mit GUI oder ohne: Du solltest schon genau wissen, was Du tust und warum und wo Du was einstellen musst. Nimm Dir Zeit, setze Dich mit der (Grundlagen-)Materie auseinander. Es lohnt sich, wenn Du's am Ende genau verstanden hast.

Und: meinen Tipp zu Anfang beherzigen. Nimm für den lokalen Gebrauch eine eigene TLD, am besten eine von den in RFC 2606 reservierten. Die sind extra dafür da! Für den lokalen Gebrauch. Damit man sie für solche Zwecke nutzt wie Du es vorhast, und damit das Konfliktpotential auf diese Weise minimiert wird und gewisse Probleme gar nicht erst auftauchen können!

Hmm, für mich sieht die Config eher nach einem HighJack der Domain "dada.de." aus, wobei auch dies innerhalb des eigenen LANs funktionieren kann, sofern die IP-Adresse von "www.dada.de" auch im Zone-File richtig konfiguriert ist.

Zunächst geht aus dem Original-Posting hervor, dass der Server 217.0.43.17 auf alle DNS-Anfragen antwortet. Statt dessen gilt für das LAN allerdings 192.168.0.3. Da stimmt etwas nicht. Ein Test mit NSLookup sollte als DNS-Server den 192.168.0.3 zurückgeben.

Ergo: Die resolv.conf stimmt auf der Kiste nicht, auf der das Ganze für das Ursprungsposting ausprobiert wurde.

Kleiner test: nslookup www.mactechnews.de sollte die IP-Adresse dieser Seite, zusammen mit dem antwortenden Server 192.168.0.3 zurückgeben. Damit wäre dann geklärt, dass resolv.conf stimmt und der Bind als DNS-Dienst läuft.

Sobald das der Fall ist, geht die Suche im Zone-Record weiter. Die Datei db.myURL.de enthält die komplette Zone und sollte in etwa so aussehen:

Wichtig: nach jeder Änderung am Zone-File ist die "serial" hochzuzählen.

Meine Vermutung ist, dass 217.0.43.17 als "ns" in der tatsächlichen Config steht. Dieser wiederum erfährt nie von den Maschinen im LAN, da Zone Transfers per Config (none) verboten wurden und gibt für alle 192er Adressen, sowie die zusätzlichen Namen "kenn ich nicht" zurück. Vielleicht liegt hier die Ursache.

myURL habe ich nur genutzt da ich meinen echten Hostname/URL hier nicht so öffentlich machen wollte (dada ist kein placeholder) aber einmal habe ich es übersehen! EGal, zu spät.

@blubblablax

Also als IP für dada habe ich 82.165.105.134 ermittelt und eingetragen.

nslookup test:

Habe mal das Zone Record FIle herausgesucht, was mir auffällt ist das Serial recht hoch ist?!


In der resolv.conf ist 192.168.0.3 als NS eingetragen.

Ja, und wie man an der neuen Ausgabe von nslookup sieht, ist inzwischen das Problem behoben: Nun antwortet der richtige Name-Server, nämlich Dein eigener.

Welches Problem besteht jetzt noch?

Stichwort: Date based serial number style (YYYYMMDDnn)
Also: vierstellige Jahreszahl + zweistellige Monatszahl + zweistellige Tageszahl + zweistellige fortlaufende Nummer.

Wirklich relevant und wirklich wichtig ist diese Serial Number eigentlich nur dann, wenn der betreffende DNS-Server Teil des öffentlichen DNS-Netzes ist und sich bzw. seine Zone records mit anderen öffentlichen Nameservern abgleicht bzw. abgleichen muss oder diese gespiegelt werden sollen. Denn dann ist es sehr für derlei Abgleiche wichtig, wie alt die Informationen der einzelnen Zone records sind, welcher Eintrag neuer ist und welcher älter bzw. welche Nummer insgesamt höher ist und welche niedriger.

Für den Gebrauch eines DNS-Servers in einem lokalen Netz, der kein fester Bestandteil des öffentlichen DNS ist, spielt diese Serial Number eigentlich keine Rolle bzw. wird nicht weiter beachtet. Trotzdem sollte man sich der Vollständigkeit halber besser auch beim Einsatz eines DNS-Servers in einem lokalen Netz angewöhnen, sie zu pflegen und jedesmal hochzusetzen (also aktuelles Datum + zweistellige fortlaufende Nummer), wenn man an den Zone records irgendwas geändert hat, wie blubblablax richtigerweise angemerkt hat. Das übt und hält fit und lässt keinen Schlendrian aufkommen.

Ja ansich nur noch "Non-authoritative answer".
Aber soweit ich weiss ist das auch nicht so tragisch wenn der Server nicht Offiziell im Netz hängt, oder?

siehe z.B.

Sehe ich auch so.
Bekomme ich bei meinem eigenen Nameserver in meinem lokalen Netz auch.
Ist schon echt lange her, dass ich den aufgesetzt habe, und er läuft, und läuft, und läuft... Keine Probleme damit.

Ok, jetzt fragt sich nur noch, ob der DNS auch zdm.dada.de auflösen kann. Wenn ja, dann war es das (fast) schon. Die Rückrichtung (0.168.192.in-addr.arpa.) muss entsprechend auch noch angepasst/überprüft werden.

Also ein nslookup meiner serveradresse "3.0.168.192.in-addr.arpa." brachte nur "no answer" zdm.dada.de fand er hingegen ohne Probleme.

Aber ist es nicht normal das meine IP als Offizielle Adresse nicht gefunden wird?
Immerhin leitet doch der DNS Server doch nach aussen ins Offizielle Netz und sucht da?!

Dann ist die Rückwärtsauflösung in der Zone 0.168.192.in-addr.arpa. falsch eingestellt. Ist der R-Eintrag richtig angelegt?

Ich dachte, Du wolltest ein Split-DNS-Verfahren einrichten? Dann muss Dein eigener DNS-Server schon die richtige Antwort liefern.

Sykane:

Wie eingangs von mir bereits empfohlen: benutze das DNS-Werkzeug dig, um Deine DNS-Konfiguration auf Richtigkeit zu überprüfen. Für genau solche Zwecke gibt es dieses Werkzeug. Die Manpage dazu mit den verschiedenen Dir zur Verfügung stehenden Abfragemöglichkeiten mittels dig findest Du entweder mit 'man dig' oder online z.B. unter .

Was ergibt bei Dir zum Beispiel ein 'dig @192.168.0.3 -x 192.168.0.3' bzw. ein 'dig @192.168.0.3 -x 192.168.0.0' ? Wo zeigen die dort auftauchenden Einträge hin?

zdm:~ administrator$ dig @192.168.0.3 -x 192.168.0.3

zdm:~ administrator$ dig @192.168.0.3 -x 192.168.0.0

Für mich sieht das alles ok aus?
zdm.dada.de zeigt auf 192.168.0.3 und umgekehrt genau so... DIG ist wirklich um einiges aussagekräftiger...

Mit nslookup geht das auch. Du musst das Programm nur mit den richtigen Parametern aufrufen. In Deinem Fall wäre richtig gewesen:

nslookup -type=ptr 3.0.168.192.in-addr.arpa.

oder aber einfach

nslookup 192.168.0.3

Der DNS-Server arbeitet also korrekt. Du hast nur die Antworten des Clients falsch interpretiert.