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 "[EMAIL PROTECTED]" 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/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
