1Blu-vServer -- Namensauflösung

jl_

New Member
Hi,

ich hab da ein kleines Problem mit der Namensauflösung von einem 1Blu-vServer und zwar löst er jeglichen "Mist" auf.

Code:
# ping sdjkfkl
PING sdjkfkl.1blu.de (213.83.63.68) 56(84) bytes of data.
64 bytes from 213.83.63.68: icmp_seq=1 ttl=59 time=1.78 ms
64 bytes from 213.83.63.68: icmp_seq=2 ttl=59 time=1.47 ms
64 bytes from 213.83.63.68: icmp_seq=3 ttl=59 time=0.989 ms

--- sdjkfkl.1blu.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.989/1.416/1.786/0.330 ms

Dieses komische Verhalten stört ein php-Script von mir bei der korrekten Arbeit. :P Nun hab ich die Server in der /etc/resolv.conf mal ausgetauscht. Allerdings kein Unterschied und nach einem Neustart sind die alten Einstellungen wieder hergestellt worden. An welcher Einstellung muss ich denn da drehen? Danke für die Hilfe

jl_
 
1blu wird wohl einfach einen Wildcard-Eintrag erstellt haben, der alle Subdomains von 1blu.de erfaßt und zur IP 213.83.63.68 auflöst. Da ist es egal, welchen Nameserver du in die resolv.conf einträgst, das Ergebnis wird das gleiche bleiben.
 
Du könntest versuchen, die /etc/resolv.conf mit einer ACL schreibzuschützen.
chattr +i /etc/resolv.conf

Allerdings habe ich auch öfters die Erfahrung gemacht, dass entweder der vServer nicht mehr startet oder beim Boot trotzdem drüber gebügelt wird - je nach VM.
 
Den Schreibschutz würde ich nur als letzten Notfall einsetzen, das kann zu Problemen führen. Die /etc/resolv.conf wird meist dynamisch generiert, die für die Generierung erforderlichen Dateien liegen bei Debian im Verzeichnis /etc/resolvconf (ohne Punkt) - bei anderen Distris kann es anders sein.
Dürfte aber das eigentliche Problem des PHP-Scriptes nicht lösen - den Grund schrieb ich oben ja schon.
 
# ping sdjkfkl
PING sdjkfkl.1blu.de (213.83.63.68) 56(84) bytes of data.

Wetten, Du hast ein "domain 1blu.de" oder "search 1blu.de" in der /etc/resolv.conf stehen?
Alternativ einfach gar nichts - dann ist das Default.
 
Wetten, Du hast ein "domain 1blu.de" oder "search 1blu.de" in der /etc/resolv.conf stehen?
Alternativ einfach gar nichts - dann ist das Default.

jo, da steht "search 1blu.de" drin. Liegt der Hund da begraben?

edit: So ich hab mal den genannten Eintrag entfernt und den Daemon mit "/etc/init.d/networking restart" neugestartet. Sendmail spuckt ein paar Fehlermeldungen:

mit /etc/network/if-up.d/sendmail: line 44: /usr/share/sendmail/dynamic: No such file or directory
run-parts: /etc/network/if-up.d/sendmail exited with return code 1

aber es wird mit [OK] abgeschlossen. Allerdings führt das zu keiner Besserung. Einen Schreibschutz würde ich nur ungern vergeben, da mir die Konsequenzen doch etwas zu heikel sind, da ich den vServer nicht alleine nutze. Schon mal herzlichen Dank für die Tipps. Irgendwie wird das schon klappen.

so long
 
Last edited by a moderator:
"sdjkfkl" ist ein unqualifizierter Hostname. Läßt er sich anders (z.B. über die hosts-Datei) nicht auflösen, wird er um ".1blu.de" ergänzt.
Da 1blu - wie Danton schon schrieb - einen Wildcard-Record "*.1blu.de" gesetzt hat, löst das zu diesem auf.
Das hat mehrere Folgen.
  1. Du hast ein DNS-Leck. 1blue kann durch Beobachtung der DNS-Requests erkennen, daß Du sdjkfkl gesucht hast.
  2. Du kannst nicht mehr erkennen, ob sdjkfkl existiert, da Du immer eine gültige (wenn auch unnütze) Antwort bekommst.
    Tippfehler fallen so nicht auf.
  3. Je nachdem, was auf der IP 213.83.63.68 liegt, kannst Du Dich ungewollt mit diesem (falschen) Server verbinden und dort (z.B. in FTP- oder Mail-Sessions) versehentlich Paßwörter offenbaren.
Ich würde es ändern - "man resolv.conf" beschreibt, wie.
 
Je nachdem was Du verwendest:

Code:
[B]NAME[/B]
       dhcpcd - DHCP client daemon

[B]SYNOPSIS[/B]
       dhcpcd    [-dknrBCDHKNRSTY]    [-z <reboot   timeout>]   [-t <timeout>]
            [-c <ExecFilePath>]      [-h <hostname>]      [-i <vendorClassID>]
            [-I <clientID>]   [-l <leasetime>]   [-s [ipaddr]]  [-G [gateway]]
            [-w <windowsize>] [-L <ConfigDir>] [interface]

[B]DESCRIPTION[/B]
       -K     [U]Keep  the searchlist from an existing resolv.conf[/U] when replacing
              the file.  dhcpcd will add it to the  domainname  received  from
              the DHCP server.

       -R     [U]Prevents dhcpcd from replacing existing /etc/resolv.conf file.[/U]

FILES
       /etc/resolv.conf
              file  created  by dhcpcd when the client receives DNS and domain
              name options.  The  old  /etc/resolv.conf  file  is  renamed  to
              /etc/resolv.conf.sv  and will be restored back when dhcpcd exits
              for any reason.

Code:
NAME
       dhclient.conf - DHCP client configuration file

DESCRIPTION
       The  dhclient.conf file contains configuration information
       for  dhclient,  the  Internet  Software  Consortium   DHCP
       Client.

OPTION MODIFIERS
       In some cases, a client may receive option data  from  the
       server which is not really appropriate for that client, or
       may not receive information that it needs, and for which a
       useful  default value exists.   It may also receive infor*
       mation which is useful, but which needs to be supplemented
       with  local  information.   To handle these needs, several
       option modifiers are available.

       The supersede statement

        supersede [ option declaration ] ;

       If for some option [U]the client should always use a locally-
       configured value[/U] or values rather than  whatever  is  sup*
       plied  by  the  server, these values can be defined in the
       supersede statement.
 
Jetzt bin ich vollkommen verwirrt. Die IPs sind doch statisch eingetragen. Die bekomme ich doch nicht über DHCP. Es müsste doch genügen den Eintrag "search 1blu.de" aus der resolv.conf zu entfernen und networking neuzustarten. Funktioniert aber nicht. Wenn das klappen würde könnte ich mir ein Script basteln, dass beim Hochfahren des vServers ausgeführt wird oder jemand erklärt mir wie 1blu die Datei immer wieder überschreibt und wie ich das verhindern kann, außer dem Schreibschutz.

lg
 
Das deine Kiste eine feste IP-Adresse hat, heißt noch lange nicht, dass dein Provider kein DHCP verwendet ;)

Eintragungen in die resolv.conf benötigen keinen network restart.

Schau mal unter /var/lib/dhcp oder /var/lib/dhcp3. Dort wirst du vermutlich ein paar Files vorfinden, in denen deine Leases stehen. Dort müsste auch die Searchdomain mitkommen.
 
Das deine Kiste eine feste IP-Adresse hat, heißt noch lange nicht, dass dein Provider kein DHCP verwendet ;)

Eintragungen in die resolv.conf benötigen keinen network restart.

Schau mal unter /var/lib/dhcp oder /var/lib/dhcp3. Dort wirst du vermutlich ein paar Files vorfinden, in denen deine Leases stehen. Dort müsste auch die Searchdomain mitkommen.

Die eine Datei dhclient.leases ist leer. Wenn die resolv.conf keinen neustart braucht, sollte sich doch auch das Problem lösen, wenn ich den Eintrag "search 1blu.de" entferne. Das Problem bleibt aber vorhanden.
 
Wenn du keinen search-Eintrag hast, wird als Default die lokale Domain angenommen, das wird bei dir vermutlich auch 1blu.de sein.
Wenn ich das richtig im Kopf habe, sollte der Eintrag
Code:
search .
helfen.
 
Die eine Datei dhclient.leases ist leer.

Und die andere ? ;)

Wie sieht deine resolv.conf aus?

Sowie da search 1blu.de und/oder domain 1blu.de steht und 1blu einen Wildcard DNS Record angelegt hat, wirst du das nicht los.
 
Wenn du keinen search-Eintrag hast, wird als Default die lokale Domain angenommen, das wird bei dir vermutlich auch 1blu.de sein.
Wenn ich das richtig im Kopf habe, sollte der Eintrag
Code:
search .
helfen.

thats it! thx
 
Back
Top