HOSTBLOGGER.de

Die allwissende Müllhalde ist PRO PTR für alle Adressen.

Internet standards documents (RFC 1033, RFC 1912 Section 2.1) specify that "Every Internet-reachable host should have a name" and that such names match with a reverse pointer record.

In der Realität sieht es meist anders aus. Als guter Provider gehört es aber einfach dazu.

RR ist für mich auch ein Muss: gerade wenn man einfach mal zu MySQL connected macht der MySQL-Server einen reverse-lookup - und der dauert ohne Eintrag einfach ewig. Das wäre nur ein Beispiel pro RR-DNS.

Das ist ein must have!

Wir setzen die per default - damit, falls der Kunde darauf vergisst, wenigstens Mails über die Server versendet werden können. BTW: wir setzen natürlich auch den passenden fDNS dazu.

Uiui, dann muss ich mal eine Lanze brechen als einziger Gegner.

Ich bin auf jeden Fall gegen einen Default Reverse-Record für Server. Bei DSL Kunden kann ich nachvollziehen das man sowas vieleicht als Default-Wert setzt weil der Kunde (technisch) nicht in der Lage ist dafür einen Wert zu definieren. Aber auch hier finde ich den Wert nicht hilfreich, es ist schlicht RFC konform einen PTR zu setzen (SHOULD).

Für Server sollte zumindest die Möglichkeit bestehen diesen Default-Eintrag wieder zu "abzubestellen". Ich will das bei meinem Server ein sauberes NXDOMAIN bei der Suche nach einem PTR als antwort kommt. Ich fahre forward (A) verschiedene Namen und möchte keine Rückschlüsse auf die Web-Instanzen ziehen lassen.

Mir stellt sich ausserdem die Frage: Wenn es dann aber einen "generierten-RR" gibt muss ich den auch in meiner Webserverconfig oder meinen SSL-Certs vorsehen? Schließlich wird er doch auch forward als A-Record angeboten...
Als A-Record genutzt würde der Name im Falle von SSL-Diensten also einen häßlichen Fehler liefern.

Die genannten Gründe "Pro-Default-RR" kann ich alle nicht nachvollziehen.

Eine "Outgoing-SMTP" IP muss selbstverständlich einen DNS-Namen haben. Aber auch hier muss es ein "vernünftiger" Name sein. PTRs die nach "dynamisch" ausschauen, also die IP Dezimal oder Hexadezimal im Namen kodiert haben werden bewusst von vielen Mailservern als Spam deklariert oder schlecht gescored. Das ist auch gut so. Es deutet schließlich auf einen dynamischen Adressbereich hin und mag je nach Anforderung ein hinreichendes Kriterium für Spam sein.

Reverse-Records als "Security-Feature" wie auch immer zu nutzen halte ich allerdings für grob fahrlässig! Macht das nicht! Wer meint seinem MySQL- oder IRC-Diensten damit auchnur ein µ an zusätzlicher "authentifizierung" zu spendieren versteht nicht was da technisch passiert! Der Text in der Reverse-Antwort bleibt schlicht nicht vertrauenswürdig - den kann jeder Besitzer des Netzes (/der IP) frei festlegen.
Das ist ganz wichtig das man das vor augen hat wenn man die PTR-Antwort sieht. Aus diesem Grund ist es auch nicht besonders ratsam in security-kritischen Logfiles die IPs in DNS-Namen auflösen zu lassen, ein Angreifer kann euch da sonstswas in die Logfiles reinschreiben und keiner merkt was.

Und zu guter letzt: Meinen Hoster kann man sich auch gerne im whois anschauen.

Als guter provider braucht man seine Kunden nicht bevormunden

Gruß, skub

Und was gibt Dir ein NXDOMAIN mehr an "Sicherheit" als ein default-PTR, der nix mit den gehosteten Domains zu tun hat? IPs kann man doch genauso vergleichen.

Ein SSL-Cert mußt Du für den Namen auch nur bauen, wenn unter dem was erreichbar ist. Das bezieht sich ja auf nen Namen, nicht auf die IP. Die anderen Certs auf dem Host enthalten sich doch auch nicht gegenseitig, oder?
Und was interessiert es Dich, ob es beim Zugriffsversuch auf den Host einen Fehler gibt? Beim direkten Zugriff über die IP tritt doch eh das gleiche Problem auf. Genauso wie bei antiken Browsern, die noch keine virtuellen Hosts unterstützen

Wenn ein PTR static im Namen hat, wird der Host von der dynbl iirc nicht geblockt. Aber ich kann es verstehen, wenn manitu nicht verraten möchte, ob eine IP statisch oder dynamisch vergeben wurden.

MySQL und IRC wurden hier nicht als Beispiele für Authentifizierung angeführt, sondern für Dienste, bei denen der Verbindungsaufbau durch das Warten auf den Timeout verzögert wird.Gilt auch noch für etliche andere. Und in logs sollte sowieso beides auftauchen.

Also ich bin mal eine lange Zeit mit fester IP und PTR auf netzstreife.bka.de unterwegs gewesen. Hat für viel Freude gesorgt

Das kommt eben genau darauf an, ob die IP im PTR enthalten ist, oder nicht. Wir setzen hier auf ein anderes Pferd, damit der PTR einen Inhalt bekommt.