Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Allgemeine Frage zu dhcp und domain names
33 views
Skip to first unread message
Edzard Egberts
Oct 18, 2012, 7:52:12 AM10/18/12
to
Ich habe ein Problem mit einem Slackware-System das wahrscheinlich am
Mangel an Hintergrundwissen liegt:
Wenn ich dhcp mit "dhcpcd -h unit3 eth0" starte, wird eine Domain ".lan"
angehängt, so dass "ping unit3" nichts findet und nur "ping unit3.lan"
funktioniert. Auch mit der Option "--fqdn none" lässt sich die Erzeugung
dieses qualifizierten Domain Namens nicht abschalten und es ist auch
nicht möglich, eine andere Domain anzugeben, z.B. "dhcpcd -h
unit3.ed.home eth0" ergibt ebenfalls "unit3.lan". Die Domain ".lan" ist
auf dem System nirgendwo hinterlegt und kommt daher vermutlich vom
dhcp-Server (DSL-Router im Keller).
Mein Problem ist jetzt, dass ich nicht genau weiß, wo dieses ".lan"
herkommt und vor allem, wie ich das ermitteln oder festlegen kann. Idee
war eigentlich, dass meine Software auf "unit3" verbindet und das unter
DHCP immer klappt. Jetzt habe ich aber keinen bekannten Namen mehr,
sondern der wird (aus meiner Sicht) willkürlich geändert, war mir wie
ein Bug vorkommt.
Die offensichtliche Frage ist also, was hat es damit auf sich und wie
finde ich den richtigen Namen heraus?
Wenn man DHCP übrigens über die Datei /etc/rc.d/rc.inet1.conf mit
DHCP_HOSTNAME[0]="unit3" startet, kann dhcp plötzlich doch einen
unqualifizierten Namen ohne ".lan" erzeugen und genau diese Inkonsistenz
hat mich gerade kalt erwischt. ;o(
Mangel an Hintergrundwissen liegt:
Wenn ich dhcp mit "dhcpcd -h unit3 eth0" starte, wird eine Domain ".lan"
angehängt, so dass "ping unit3" nichts findet und nur "ping unit3.lan"
funktioniert. Auch mit der Option "--fqdn none" lässt sich die Erzeugung
dieses qualifizierten Domain Namens nicht abschalten und es ist auch
nicht möglich, eine andere Domain anzugeben, z.B. "dhcpcd -h
unit3.ed.home eth0" ergibt ebenfalls "unit3.lan". Die Domain ".lan" ist
auf dem System nirgendwo hinterlegt und kommt daher vermutlich vom
dhcp-Server (DSL-Router im Keller).
Mein Problem ist jetzt, dass ich nicht genau weiß, wo dieses ".lan"
herkommt und vor allem, wie ich das ermitteln oder festlegen kann. Idee
war eigentlich, dass meine Software auf "unit3" verbindet und das unter
DHCP immer klappt. Jetzt habe ich aber keinen bekannten Namen mehr,
sondern der wird (aus meiner Sicht) willkürlich geändert, war mir wie
ein Bug vorkommt.
Die offensichtliche Frage ist also, was hat es damit auf sich und wie
finde ich den richtigen Namen heraus?
Wenn man DHCP übrigens über die Datei /etc/rc.d/rc.inet1.conf mit
DHCP_HOSTNAME[0]="unit3" startet, kann dhcp plötzlich doch einen
unqualifizierten Namen ohne ".lan" erzeugen und genau diese Inkonsistenz
hat mich gerade kalt erwischt. ;o(
Message has been deleted
Edzard Egberts
Oct 18, 2012, 9:55:49 AM10/18/12
to
Frank Graf schrieb:
> Wie sieht der Inhalt der Dateien:
>
> /etc/hosts
>
Das ist noch die Default, ohne die einleitenden Bemerkungen:
# For loopbacking.
127.0.0.1 localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1 darkstar.example.net darkstar
> /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search lan
nameserver 10.0.0.1
nameserver 10.0.0.1
nameserver 213.33.99.70
> Wie sieht der Inhalt der Dateien:
>
> /etc/hosts
>
Das ist noch die Default, ohne die einleitenden Bemerkungen:
# For loopbacking.
127.0.0.1 localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1 darkstar.example.net darkstar
> /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search lan
nameserver 10.0.0.1
nameserver 10.0.0.1
nameserver 213.33.99.70
Message has been deleted
Edzard Egberts
Oct 18, 2012, 11:30:01 AM10/18/12
to
Frank Graf schrieb:
Stimmt.
> Der Eintrag "search lan" sollte eigentlich dafür sorgen daß ein "nslookup
> unit3" bzw. "ping unit3" funktioniert. (es wird dann auch "unit3.lan"
> ausprobiert)
Das ist aber der Eintrag vom unit3, das muss sich eigentlich nicht
selber finden. ;o)
Damit sind wir wieder am Anfang - der Steuerrechner, der auf unit3
verbinden soll, weiß nichts von "lan" und ich weiß nicht, wie der das
herausfinden kann, bzw. wie unit3 den eigenen Namen setzt, ohne dass der
ergänzt wird. Ich habe das noch einmal mit nmap getestet und dabei ist
mir aufgefallen, dass sich der DSL-Router "dsldevice.lan" nennt. Das
bestätigt meinen Verdacht, dass da das "lan" her kommt. Mein Rechner
(Fedora) bekommt das aber nicht mit, so dass ein lookup nicht funktioniert.
Ich verstehe also nicht, warum sich Slackware je nach Art des
dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein
Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in
den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch
das abzufragen.
Ich brauche also eine Befehlszeile, die unter Slackware den dhcpcd mit
einem unqualifizierten Namen aufruft (also nur "unit3" setzt), oder
einen Befehl, der mir unter Fedora die Benennung des lokalen Netzwerks
ermittelt, also das "lan" liefert. Ich weiß, dass ersteres über die
Systemkonfiguration geht und denke, das sollte dann auch irgendwie über
Befehlszeile gehen. Bei der alternativen Abfrage stehe ich völlig auf
dem Schlauch.
Der dhcpcd muss dem dhcp-Server (Router) doch irgendwie sagen, ob er
einen unqualifizierten Namen möchte, oder ob der Name ergänzt werden
soll, das muss doch irgendwie geregelt sein?
>> # Generated by dhcpcd for interface eth0
>> search lan
>> nameserver 10.0.0.1
>> nameserver 10.0.0.1
>> nameserver 213.33.99.70
>
> Ich gehe davon aus daß 10.0.0.1 die IP-Adresse des DSL-Routers ist?
>> search lan
>> nameserver 10.0.0.1
>> nameserver 10.0.0.1
>> nameserver 213.33.99.70
>
Stimmt.
> Der Eintrag "search lan" sollte eigentlich dafür sorgen daß ein "nslookup
> unit3" bzw. "ping unit3" funktioniert. (es wird dann auch "unit3.lan"
> ausprobiert)
Das ist aber der Eintrag vom unit3, das muss sich eigentlich nicht
selber finden. ;o)
Damit sind wir wieder am Anfang - der Steuerrechner, der auf unit3
verbinden soll, weiß nichts von "lan" und ich weiß nicht, wie der das
herausfinden kann, bzw. wie unit3 den eigenen Namen setzt, ohne dass der
ergänzt wird. Ich habe das noch einmal mit nmap getestet und dabei ist
mir aufgefallen, dass sich der DSL-Router "dsldevice.lan" nennt. Das
bestätigt meinen Verdacht, dass da das "lan" her kommt. Mein Rechner
(Fedora) bekommt das aber nicht mit, so dass ein lookup nicht funktioniert.
Ich verstehe also nicht, warum sich Slackware je nach Art des
dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein
Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in
den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch
das abzufragen.
Ich brauche also eine Befehlszeile, die unter Slackware den dhcpcd mit
einem unqualifizierten Namen aufruft (also nur "unit3" setzt), oder
einen Befehl, der mir unter Fedora die Benennung des lokalen Netzwerks
ermittelt, also das "lan" liefert. Ich weiß, dass ersteres über die
Systemkonfiguration geht und denke, das sollte dann auch irgendwie über
Befehlszeile gehen. Bei der alternativen Abfrage stehe ich völlig auf
dem Schlauch.
Der dhcpcd muss dem dhcp-Server (Router) doch irgendwie sagen, ob er
einen unqualifizierten Namen möchte, oder ob der Name ergänzt werden
soll, das muss doch irgendwie geregelt sein?
Message has been deleted
Message has been deleted
Edzard Egberts
Oct 19, 2012, 2:36:13 AM10/19/12
to
>> Ich verstehe also nicht, warum sich Slackware je nach Art des
>> dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein
>> Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in
>> den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch
>> das abzufragen.
>
> Der Steuerrechner (Fedora) kann von der Domain "lan" nichts wissen.
>> dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein
>> Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in
>> den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch
>> das abzufragen.
>
Der freundliche Kunde, der gerade sein unit3 angestöpselt hat, weiß das
auch nicht unbedingt.
> Trage auf dem Steuerrechner in der Datei /etc/resolv.conf die Domain "lan"
> in die search Liste ein.
Da der Kunde darauf aber vielleicht keinen Zugriff hat, könnte er es
auch ins Steuerprogramm eintragen - falls er es weiß. Besser wäre
natürlich, wenn das Steuerprogramm die Domain selbst ermittelt. Dann muß
der Kunde nämlich nichts außer der Seriennummer wissen und die steht
drauf. So weit war ich schon mal.
> Dein DSL-Router verwendet "lan" als Domain. Das kann man möglicherweise
> ändern, aber irgend eine Domain mußt Du verwenden.
Nein, muß ich nicht. Das mit den unqualifizierten Namen funktioniert
einwandfrei. unit3 verwendet auch den unqualifizierten Namen, wenn man
den direkt in die Systemkonfiguration einträgt und damit laufen schon
ein paar units. Das hatte aber den Nachteil, dass für jede Änderung das
gesamte System gebootet werden musste, deshalb habe ich die ganze
Netzwerkeinrichtung auf dynamisch mit Befehlszeile(n) geändert. Das
klappt sonst auch einwandfrei (öffnet auch zusätzliche statische
Adressen), nur ist jetzt plötzlich dieses Domainproblem aufgetaucht. Das
möchte ich gerne ausbügeln, um diese Arbeit zu retten.
Edzard Egberts
Oct 19, 2012, 2:53:45 AM10/19/12
to
Oliver Sch@d schrieb:
> Dafür ist der Host aber selbst zuständig, denn im DNS wirst du kaum die
> Toplevel-Domain unit3 mit A-Record stehen haben.
Für unqualifizierte Namen im lokalen Netzwerk ist das auch nicht nötig.
> Dein Freund ist die /etc/hosts, dort eintragen den Host "unit3" auf die
> externe oder interne IP, fertig.
Das ist qualifizierte Netzwerkeinrichtung mit Admin-Rechten, die ich mir
sparen will.
> Aber wenn ich ehrlich bin, hab ich dein Problem echt noch nicht
> verstanden, wer wen unter welchen Namen oder auch nicht erreichen können
> soll und welche Variablen du beeinflussen kannst in dem Szenario oder
> nicht.
Das habe ich dem Frank auch gerade noch mal erklärt. Noch mal ganz kurz:
Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das
wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen "unit3"
wissen und kann damit von jedem anderen Rechner des Netzwerks eine
Verbindung aufbauen. Das funktionierte, bis ich die Netzwerkeinrichtung
des unit3 auf Konfiguration mit Befehlszeile umgestellt habe (was ich
aber gerne beibehalten würde). Jetzt nennt sich unit3 plötzlich
unit3.lan (siehe "fqdn") und ist damit nicht mehr sicher in beliebigen
Netzwerken erreichbar.
Die Frage ist also, wie ich dem dhcpcd bei Aufruf mit Befehlszeile dazu
bewege, den unqualifizierten Namen zu verwenden (--fqdn none ist es
nicht), oder wie das Steuerprogramm die DHCP-Domain des aktuellen
Netzwerks ermitteln kann.
Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
> Dafür ist der Host aber selbst zuständig, denn im DNS wirst du kaum die
> Toplevel-Domain unit3 mit A-Record stehen haben.
Für unqualifizierte Namen im lokalen Netzwerk ist das auch nicht nötig.
> Dein Freund ist die /etc/hosts, dort eintragen den Host "unit3" auf die
> externe oder interne IP, fertig.
Das ist qualifizierte Netzwerkeinrichtung mit Admin-Rechten, die ich mir
sparen will.
> Aber wenn ich ehrlich bin, hab ich dein Problem echt noch nicht
> verstanden, wer wen unter welchen Namen oder auch nicht erreichen können
> soll und welche Variablen du beeinflussen kannst in dem Szenario oder
> nicht.
Das habe ich dem Frank auch gerade noch mal erklärt. Noch mal ganz kurz:
Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das
wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen "unit3"
wissen und kann damit von jedem anderen Rechner des Netzwerks eine
Verbindung aufbauen. Das funktionierte, bis ich die Netzwerkeinrichtung
des unit3 auf Konfiguration mit Befehlszeile umgestellt habe (was ich
aber gerne beibehalten würde). Jetzt nennt sich unit3 plötzlich
unit3.lan (siehe "fqdn") und ist damit nicht mehr sicher in beliebigen
Netzwerken erreichbar.
Die Frage ist also, wie ich dem dhcpcd bei Aufruf mit Befehlszeile dazu
bewege, den unqualifizierten Namen zu verwenden (--fqdn none ist es
nicht), oder wie das Steuerprogramm die DHCP-Domain des aktuellen
Netzwerks ermitteln kann.
Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
Edzard Egberts
Oct 19, 2012, 9:29:06 AM10/19/12
to
Frank Graf schrieb:
> Trage auf dem Steuerrechner in der Datei /etc/resolv.conf die Domain "lan"
> in die search Liste ein.
>
> also z. B.:
>
> "search lan"
Das sollte der dhcpcd ja selber machen und heute steht nicht nur "search
lan" in der resolv.conf, sondern sogar "domain lan"! Dem entsprechend
geht der Zugriff auf das unit3 jetzt wieder ohne FQDN. Das Problem war
also mein Entwicklungsrechner, vermutlich musste nach der Umschaltung
des Netzwerks auf DHCP doch besser mal gebootet werden. :o/
> Dein DSL-Router verwendet "lan" als Domain. Das kann man möglicherweise
> ändern, aber irgend eine Domain mußt Du verwenden.
Das habe ich dann wohl auch immer getan und wußte das bloß nicht, weil
das lookup funktionierte, ohne mir Bescheid zu sagen. ;o)
>> Ich brauche also
läuft auch unter Windows).
Na ja, jetzt weiß ich nicht nur, warum es funktioniert, sondern kann
sogar einen FQDN in die Software eingeben - mir war ebenfalls nicht
bewusst, dass ich mit meiner DHCP-Einrichtung gar nicht aus dem lokalen
Netz herauskomme.
>> Damit sind wir wieder am Anfang - der Steuerrechner, der auf unit3
>> verbinden soll, weiß nichts von "lan"
>
>> verbinden soll, weiß nichts von "lan"
>
> Der Steuerrechner (Fedora) kann von der Domain "lan" nichts wissen.
Ähem - das war gestern!
> Trage auf dem Steuerrechner in der Datei /etc/resolv.conf die Domain "lan"
> in die search Liste ein.
>
>
> "search lan"
Das sollte der dhcpcd ja selber machen und heute steht nicht nur "search
lan" in der resolv.conf, sondern sogar "domain lan"! Dem entsprechend
geht der Zugriff auf das unit3 jetzt wieder ohne FQDN. Das Problem war
also mein Entwicklungsrechner, vermutlich musste nach der Umschaltung
des Netzwerks auf DHCP doch besser mal gebootet werden. :o/
> Dein DSL-Router verwendet "lan" als Domain. Das kann man möglicherweise
> ändern, aber irgend eine Domain mußt Du verwenden.
das lookup funktionierte, ohne mir Bescheid zu sagen. ;o)
>> Ich brauche also
>> einen Befehl, der mir unter Fedora die Benennung des lokalen Netzwerks
>> ermittelt, also das "lan" liefert.
"more /etc/resolv.conf" bzw. unter Windows "ipconfig -All" (die Software
>> ermittelt, also das "lan" liefert.
läuft auch unter Windows).
Na ja, jetzt weiß ich nicht nur, warum es funktioniert, sondern kann
sogar einen FQDN in die Software eingeben - mir war ebenfalls nicht
bewusst, dass ich mit meiner DHCP-Einrichtung gar nicht aus dem lokalen
Netz herauskomme.
Thomas Noll
Oct 20, 2012, 3:53:59 AM10/20/12
to
Edzard Egberts wrote:
> Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
Glaube ich nicht.
> Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
Das Problem dürfte eher die Anzahl der dhcp-Server in deinem Netz sein, und
deren Verfügbarkeit abbängig vom Startzeitpunkt des zweiten.
--
Woo Hoo Woo Hoo Hoo
Message has been deleted
Edzard Egberts
Oct 22, 2012, 2:04:45 AM10/22/12
to
Oliver Sch@d schrieb:
>> sich unit3 plï¿œtzlich unit3.lan (siehe "fqdn") und ist damit nicht mehr
Na ja, mit "allgmeine Frage" lag ich schon richtig, ich hatte bloￜ keine
Ahnung. So wie ich das jetzt verstanden habe, braucht eine DHCP-Adresse
immer eine Top-Level-Domain und fï¿œr den lokalen DSL-Router ist das eben
".lan". Man kann aber auch den unqualifizierten Namen benutzen, weil der
dhcpcd beim Start in die /etc/resolv.conf das entsprechende
search-lookup einstellt (und das ging schief).
Das wusste ich nicht und dachte, dass der unqualifizierte Name im
Normalfall schon reicht. Mir wï¿œre das wohl auch nie aufgefallen, aber
beim Umstellen der Netzwerkeinstellungen wurde die resolv.conf wohl
nicht aktualisiert, so dass die unqualifizierten Namen plï¿œtzlich nicht
mehr funktionierten.
> Edzard Egberts wrote:
>
>> Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das
>> wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen
>> "unit3" wissen und kann damit von jedem anderen Rechner des Netzwerks
>> eine Verbindung aufbauen. Das funktionierte, bis ich die
>> Netzwerkeinrichtung des unit3 auf Konfiguration mit Befehlszeile
>> umgestellt habe (was ich aber gerne beibehalten wï¿œrde). Jetzt nennt
>
>> Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das
>> wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen
>> "unit3" wissen und kann damit von jedem anderen Rechner des Netzwerks
>> eine Verbindung aufbauen. Das funktionierte, bis ich die
>> Netzwerkeinrichtung des unit3 auf Konfiguration mit Befehlszeile
>> sich unit3 plï¿œtzlich unit3.lan (siehe "fqdn") und ist damit nicht mehr
>> sicher in beliebigen Netzwerken erreichbar.
>
> Aber wer macht denn das DNS dazu, damit unit3 ï¿œberhaupt bekannt ist?
>
Na ja, mit "allgmeine Frage" lag ich schon richtig, ich hatte bloￜ keine
Ahnung. So wie ich das jetzt verstanden habe, braucht eine DHCP-Adresse
immer eine Top-Level-Domain und fï¿œr den lokalen DSL-Router ist das eben
".lan". Man kann aber auch den unqualifizierten Namen benutzen, weil der
dhcpcd beim Start in die /etc/resolv.conf das entsprechende
search-lookup einstellt (und das ging schief).
Das wusste ich nicht und dachte, dass der unqualifizierte Name im
Normalfall schon reicht. Mir wï¿œre das wohl auch nie aufgefallen, aber
beim Umstellen der Netzwerkeinstellungen wurde die resolv.conf wohl
nicht aktualisiert, so dass die unqualifizierten Namen plï¿œtzlich nicht
mehr funktionierten.
Message has been deleted
Edzard Egberts
Oct 22, 2012, 3:07:36 AM10/22/12
to
> sein - daher habe ich dich ja gefragt, warum der DNS-Server jetzt auf
> einmal den Namen "unit3" kennt.
>
> Ok, also super, dass du dein Problem lï¿œsen konntest. :-)
Das hatte sich am nï¿œchsten Tag beim Einschalten des Rechners von selber
gelï¿œst - neu booten hilft manchmal auch bei Linux. :o/
Beim Blick in die resolv.conf (meines Steuerrechners) wurde mir dann
auch klar, warum es funktioniert. Das Hauptproblem war, dass es zwar
funktionierte, ich bis dahin aber nicht wuï¿œte, warum. ;o)
0 new messages