[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: host.conf manpage in SuSE-versau^H^H^Hesserter glibc?



Moin,

Am Dienstag, den 05.04.2005, 08:36 +0200 schrieb Martin Reising:
> On Tue, Apr 05, 2005 at 12:59:06AM +0200, Jan Kohnert wrote:
> > Joerg Rossdeutscher schrieb:
> > > Das kannst du machen. Dann hast du einen internen DNS, der diese Namen
> > > auflöst. Alle Rechner da draussen lösen über den "offiziellen" DNS auf,
> > > und der kennt zwar [www.]gesindel.de, nicht aber omaskiste.gesindel.de.

> > Das ist ja, was ich sage, "verbiegen" des DNS.

> Wieso "verbiege" ich das DNS? Ich benutze eine mir zugewiesene Domain, und
> kann damit sicherstellen, das 1.) die daraus generierten MID eindeutig sind 
> und 2.) meine "inoffizielle" Domain nicht für etwas anderes normiert wird.

Du "verbiegst" Domains, weil die Hostnamen nicht eindeutig sind. Rechner
im Intranet können "kiste.gesindel.de" auflösen - Rechner im Internet
kennen diesen Hostnamen nicht.

Eine mögliche Gefahr dabei:

Meine Domain ist "gesindel.de". Das ist so ein typisches
Ein-Euro-Neunzig-Hosting, auf dem meine Website vor sich hin
kompostiert.

Wenn ich jetzt zuhause mit den Hostnamen "ratti.gesindel.de" und
"rattisfreundin.gesindel.de" arbeiten will, muss ich diese Namen selbst
auflösen. Das kann ich auf meinem hausinternen Server tun. Damit bin ich
aber auch gezwungen, ALLES für "gesindel.de" aufzulösen. Den MX,
"www.gesindel.de", "gesindel.de", "mail.gesindel.de". Das sind alles
Dienste, die nicht unter meiner Kontrolle stehen. Wenn jetzt der
Provider den MX umbiegt, liefert mein interner DNS für interne Anfragen
auf diese Ressourcen Mist. Solche Fehler will man nicht wirklich suchen.

In der Tat mache ich es genau so in der Firma. Da macht das aber auch
Sinn, weil eine entsprechende Infrastruktur vorhanden ist, mit mehreren
Zonen, Post von draussen, Post von drinnen, Laptops die von draussen an
interne Ressourcen wollen - da will man sowas.

Aber zuhause? Da stellt sich mir die Sinnfrage. Eigentlich schon
bekloppt genug, für 2 Rechner einen Server zu haben - das ist dann noch
mit Spiel- und Basteltrieb zu erklären.

Ich bin sicher, man kann obige Probleme mit dem Nameserver anders lösen.
Ich halte es aber einfach für übertrieben. Abgesehen ist es ganz
praktisch, wenn man mal wieder hier und da etwas (ver-)bastelt und Mails
an "test@local" gleich am Smarthost von T-Online scheitern. Ups. Soweit
sollten sie eigentlich gar nicht kommen...



> > Entweder häng ich mit "offizieller" domain im Netz un ALLE meine Namen
> > werden öffentlich aufgelöst,
> 
> Wer, außer dir, fordert das? Es gibt Firmen die ein /16 besitzen und
> benutzen, deren externe DNS aber nur eine handvoll Namen auflösen; forward
> und reverse.

Ich fordere das auch. Für mich. Der Übersicht wegen.

> > oder ich hab ein privates Netzwerk und dann muß ich dafür sorgen, das meine
> > Namen intern korrekt aufgelöst werden, am besten aber mit inoffizieller
> > domain
> 
> Wohin das führt sehen wir ja hier sehr schön. 

Naja - prinzipiell ist fast alles, was gar keinen Punkt enthält, illegal
und somit verwendbar. Es gibt überhaupt nur extrem wenige Ausnahmen:
local, localhost, invalid - mehr fallen mir jetzt nicht ein. Warum man
ausgerechnet das etablierte "local" nehmen musste und nicht einfach
IRGENDWAS anderes - zum Beispiel "autoconf" oder "zeroconf" oder
"__rendezvous" werden wir wohl nie erfahren. Aber es war bestimmt blöder
"local" umzudefinieren als es zu verwenden.




> > Also: privates Netz: Inoffizielle Domain. Und ich wiederhole mich: Ich kann 
> > nicht verstehen, warum im RFC 2606 die inoffizielle Domain ".local" nicht 
> > dabei ist. Nun ist jeder mit privatem Netzwerk gezqungen, auf ".invalid" oder 
> > die anderen Möglichkeiten umzustellen. Ich kann ja nachvollziehen, daß auch 
> > für inoffizielle Domains ein Standard hermuß, aber dann bitte richtig.
> 
> Entweder verlassen niemals Daten dieses private Netz, dann ist die TLD
> belanglos.
> Verlassen Daten dieses private Netz, dann ist sicher zu stellen das aus dem
> FQDN generierte MID eindeutig sind. Also müssen die Domainname in dieser TLD
> registriert werden. Das existiert schon.

Das ist technisch korrekt.

Technisch korrekt wäre es auch, die Konfigdatei für exim unter dem Namen
"000oooOOOO0ooooooOO00OoO.conf" abzuspeichern. Aber man macht sich das
Leben einfach, weil das Übersicht-behalten für Menschen schwieriger ist
als für Rechner. :-)

Wenn ich in einer Logdatei feststelle, daß etwas sich als "@local"
identifiziert, obwohl es eigentlich nach draussen sollte, dann ist das
erstmal einfacher, als mir zu überlegen, welcher Mailserver im
Received-Header welchen DNS befragt hat, um den Hostnamen aufzulösen,
und ob der jetzt "ratti.gesindel.de" hätte kennen müssen oder nicht.


> > > Zunächst mal ist "ratti.local" genauso hierarchisch wie
> > > "ratti.gesindel.de", nur eben "eins höher".
> 
> local. ist Freiwild und wird nicht von dir Kontrolliert. gesindel.de. gehört
> dir und du kannst darin deine eigene Strukturen umsetzen.

Wenn mir der DNS "gehören" würde. Das ist für den Heimanwender aber
selten der Fall, und dann wird es komplex.

> > > Zum zweiten gibt es erstmal keinen Grund, die interne Kommunikation als
> > > Teil der Internet-Hierarchie zu begreifen und es dem unterzuordnen. Kann
> > > man machen - muss man aber nicht.
> 
> Es ist kein in sich geschloßenes Netz, denn es kommuniziert mit dem Internet.

Man kommt heutzutage von jedem Kabel in jedes, wenn man nur weit genug
hinterherkrabbelt, und irgendwo hat bestimmt jemand ein Ethernetkabel an
eine Wasserleitung gelötet. :-)

Trotzdem würde ich bei einer Maskierung oder einem Proxy nicht mehr von
direkt verbundenen Systemen mit gemeinsamer Logik sprechen.

Gruß,
Ratti



-- 
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: