Hi,
On Thu, Feb 19, 2004 at 02:34:39PM +0100, Benedikt Stockebrand wrote:
> Gert Doering <[EMAIL PROTECTED]> writes:
>
> >> das habe ich erst auch gedacht, aber dann gemerkt, da� ich da einen
> >> Denkfehler gemacht habe: Wenn ich einen Rechner habe, der die Privacy
> >> Extensions benutzt, den aber zum Beispiel als Sysadmin hausintern per
> >> Ssh erreichen will, mu� ich ihn wiederfinden.
> >
> > Das *ist* der Denkfehler. Services lauschen auf der statischen Adresse.
>
> Also um mal ganz genau zu nehmen: Manche lauschen auch auf allen
> Adressen, einschlie�lich den tempor�ren. Mindestens FreeBSD verh�lt
> sich bei einem Listen auf * so und im RFC steht dazu auch nicht, da�
> das anders sein sollte.
Aeh, ja. Ich war unpraezise. Ich meinte "wenn man auf den sshd-Dienst
connecten will, wird man die 'well-known'-Adresse nehmen (SAC, DHCPv6,
fest konfiguriert" und fuer ausgehende Dienste eben die privacy-Adressen.
Natuerlich koennte man technisch auch auf privacy-Adressen connecten,
aber die sind halt eben per se "nicht bekannt"... :-)
> Aber das nur am Rande, grunds�tzlich hast Du Recht, das Argument mit
> der Ssh zieht in dieser Form nicht. War etwas sp�t gestern abend.
Das meinte ich :-)
> > Die Privacy-Extention-Adressen werden fuer abgehenden Verkehr benutzt.
> Richtig. Trotzdem kann ich sie auch f�r ankommenden Verkehr benutzen,
> wenn ich denn die Adresse wei�. So wie zum Beispiel mit Active Mode
> FTP (ich wei�, auch das ist eine Krankheit).
Jo. Wobei AFAIR bei EPRT/EPSV eh' einfach "die IP des Control-Channels"
verwendet wird.
> > Site-Local ist so gut wie tot.
> Bitte nicht diese Diskussion, das f�hrt zu nichts. Der Site-Local
> Scope existiert nunmal, also m�ssen wir ihn irgendwo ber�cksichtigen.
> Es zwingt uns ja niemand, ihn selbst zu benutzen.
Ich will die Diskussion nicht ernsthaft fuehren. Ich will nur darauf
hinweisen, dass es da genug offene Punkte gibt, um bzgl. Strategieen
mit site-locals sehr vorsichtig zu sein.
> > Lies die RFC noch mal.
>
> Habe ich getan. Du hast Recht, die tempor�ren Adressen werden nur
> zus�tzlich angelegt. Aber trotzdem zwei Punkte, warum ich auch die
> tempor�ren Adressen im DNS haben will:
>
> - In RFC 3041, Seite 13/14, wird das Thema angesprochen, da� die
> Reverse Maps zur Authentisierung benutzt werden. Wo kein PTR RR
> existiert, wird die Verbindung vom Server abgew�rgt.
Muss ich nachlesen.
> Auch da kann man sich beliebig lange dar�ber streiten, ob das so gut
> oder schlecht ist, es ist einfach so. Und wenn ich die letzten
> Anti-Spam-Diskussionen nicht v�llig falsch verstanden habe, ist
> genau so etwas auch in Arbeit, um die Absender-Adressen von Mails zu
> �berpr�fen.
SPF setzt auf Verifikation ueber die forward-Domain ("nur das Subnetz
XYZ/nn ist berechtigt, Mails mit dem Absender [EMAIL PROTECTED] zu versenden"),
da braucht man das reverse DNS gar nicht. Bei anderen Verfahren bin
ich nicht sicher, wie das gemacht wird.
> Auf das verwandte Problem mit den Timeouts bei erfolglosen Reverse
> Lookups hat ja Achim Friedland schon aufmerksam gemacht.
Kann ich nicht nachvollziehen. Wenn die DNS-Chain als solche in Ordnung
ist, gibt es keinen Grund fuer timeouts.
> - Au�erdem kann ich mit einem Packet Sniffer sehr viel einfacher nach
> Fehlern suchen, wenn ich nicht �berall nur Adressen sehe. Den
> entsprechenden Name Server w�rde ich zwar nicht �ffentlich
> zug�nglich machen, aber selbst benutzen w�rde ich ihn gerade in
> Aufbau- und Debugphasen doch ganz gerne. Split Namespaces sind ja
> keine Geheimwissenschaft. Und wenn alles l�uft, kann man das ganze
> ja auch wieder abschalten.
Privacy-Extentions laufen u.A. genau diesem Punkt ("wer war das eigentlich")
massiv zuwider... - darum geht's ja wohl.
Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 58081 (57882)
SpaceNet AG Mail: [EMAIL PROTECTED]
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
80807 Muenchen Fax : +49-89-32356-299
_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
