Alle paar Tage sichte ich das Maillog auf Ablehnungen und prüfe, wer weswegen "schuld" ist. Jetzt beschäftigt mich hier ein Fall, bei dem ich mir nicht ganz sicher bin, wer hier etwas falsch interpretiert.
Die Webseite beautyjunkies.de verschickt Newsletter & Co über die Server der neTVenture TV & Software Solutions und die nutzen ein Subnetz 78.138.80.0/25 ihres Providers MESH GmbH (78.138.80.0/21).
Der betroffenen Newsletterserver ist der 78.138.80.16. Ein PTR RR existiert eigentlich nicht.
;; QUESTION SECTION:
;116.80.138.78.in-addr.arpa. IN PTR
;; ANSWER SECTION:
116.80.138.78.in-addr.arpa. 82632 IN CNAME 116.0-127.80.138.78.in-addr.arpa.
116.0-127.80.138.78.in-addr.arpa. 600 IN PTR mx01.ssis.eu.
Der PTR RR selbst ist für den Host nicht gesetzt, statt dessen gibt es nur ein CNAME 116.0-127.80.138.78.in-addr.arpa, der auf 116.0-127.80.138.78.in-addr.arpa. verweist. Für 116.0-127.80.138.78.in-addr.arpa gibt es dann auch ein PTR RR auf mx01.ssis.eu. lautet.
Meine Interpretation: Der Eintrag 116.0-127.80.138.78.in-addr.arpa ist RFC-Konform für die Delegierung der Subnetze des Netzbetreibers an den Provider, dann aber wurde bei der weiteren Delegierung an den Kunden "vergessen", die CNAMEs zu löschen und die PTR RR wurden einfach angehängt. Der DNS Client der UTM verfolgt den CNAME nicht weiter (weil er an dieser Stelle nicht RFC-Konform wäre?).
Laut RFC darf ein PTR RR nicht auf einen CNAME RR verweisen (was zutrifft), aber ein PTR RR darf durchaus nur über ein CNAME RR erreichbar sein (was auch zutrifft). In der RFC steht aber nichts, dass beides gleichzeitig (nicht) zutreffen darf. Und wenn ein DNS CLient danach handelt, ist es logisch, dass er keinen gültigen RDNS Eintrag findet, oder?
Nebenbei: Auf der UTM kommt DIG aus den BIND-Utils 9.6 zum Einsatz und löst den CNAME nicht auf. Ab 9.7 wird der CNAME aufgelöst. Ist das also nur ein Versionsproblem? Aber die 9.7 ist schon über zwei Jahre alt.
Grüße vom
Klaus
This thread was automatically locked due to age.
