<<< Date Index >>>     <<< Thread Index >>>

Re: Verisign SiteFind



Nils Ketelsen <nils@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> On Tue, Sep 16, 2003 at 05:07:50PM +0200, Florian Weimer wrote:
>
>> Das ist noch das geringste Problem. Interessant ist die Situation,
>> wenn man
>> 
>> example.com  86400   IN      MX      10 mail1.xeample.com
>> example.com  86400   IN      MX      20 mail2.example.com
>> 
>> hat -- das funktionierte nämlich bislang ohne auffällige Probleme.
>
> Ja, das ist ja mein Beispiel aus dem IRC... 

Ja, tut mir leid. Bin inzwischen zu sehr an "Weitergabe ist in
Ordnung, solang Du meinen Namen wegläßt" gewohnt. Und heute war nicht
wirklich ein guter Tag. 8-/

> Allerdings gibt es noch ein Paar andere interessante Effekte:
>
> 1. "sender_verify", also die Funktion die Absenderdomain einer mail auf
> Existenz zu prüfen um Spammer abzuwehren, funktioniert jetzt wesetlich
> seltener. Also wieder ein Paar Spammer mehr die durchkommen.

Ich mache ganz gute Erfahrungen mit Callout-Prüfung. Das funktioniert
bei Exim, wenn man besagte IP-Adresse mit ignore_target_hosts erdet.

> 2. Skripte um Webseiten auf ungültige Links zu ueberpruefen kann man sich
> jetzt auch in die Haare schmieren, weil ja alles existiert (obwohl: Gerade
> jetzt bekomme ich von der Verisign-Möhre nur noch connection refused). 

Interessanter Punkt.

Das bringt mich auf eine Idee: Vielleicht sollte man einen
Protest-Web-Bug auf seine Seiten setzen?

> 3. Man kann spannende Statistiken machen und so Domainnamen später Bewerten,
> die noch nicht vergeben sind (1$ pro Aufruf vor Vergabe, vielleicht?)

Man munkelt, daß sie das schon vorher machten. Technisch war das ja
möglich.

> 4. Man kann sehen, wer welche mails an wen zu schicken versucht (obwohl ich
> glaube, dass der Mail-Ablehner dazu noch zu doof ist). Und was ist erst wenn
> der anfaengt die Mails anzunehmen? Duerfte eine interessante Datensammlung
> werden. Warum muss auf dem host eigentlich ueberhaupt etwas auf port 25
> lauschen?

Weil sonst die Queues volliefen. RST auf ein SYN ist nur ein
temporärer Fehler.

Es gibt keine allgemein funktionierende Möglichkeit zu signalisieren,
daß ein Host, unabhängig von irgendwelchen DNS-Einträgen, nicht am
Mail-Verkehr teilnimmt.

> 5. <Geruecht> Bei der Suchfunktion, die man auf der vertipper-Seite findet
> bezahlen die Betreiber um weit oben auf der Liste der Suchergebnisse zu
> landen. Und zwar zahlen die pro Hit, der aus der Suchfunktion ausgeloest
> wird. Das koennte eine Cashcow fuer Verisign werden</Geruecht>

Ich glaube nicht, daß das DFN-CERT was bezahlt hat, aber sie tauchten
dort unter "DFN-CERT" auf. Aber die Suchfunktion ist eigenwillig. Sehr
signifikante Schlagwörter lieferten kein Ergebnis, obskure
Kombinationen liefen dann aber doch die betreffende Seite.

> 6. Wieviel Traffic verursacht Verisign eigentlich damit, dass es
> nicht mehr ein einfaches NXDOMAIN zurückgibt, sondern jedes mal die
> Seite durchbläst?

Da muß ich Verisign als Root-Server- und TLD-Betreiber in Schutz
nehmen. Der zusätzliche Verkehr dürfte im Vergleich zu dem, was durch
den Windows-DNS-Bug verursacht wird, kaum ins gewicht fallen.

> 7. Wie wirkt es sich auf DNS-Caches aus, die muessten ja jetzt mehr zu
> cachen haben oder aber früher expiren und damit DNS als Gesamtsystem mehr
> belasten.

NXDOMAINs werden auch gecachet, also sollte das keinen so grossen
Unterschied machen. Der 15-Minuten-Timeout fuer * ist da eher kuerzer.

--
To unsubscribe, e-mail: debate-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: debate-help@xxxxxxxxxxxxxx