[Info] Vorsicht bei der Buchung von "Chiemgau DSL" - kein RDNS für dyn. IP-Adressen

[PeterPawn]

das ist zumindest dann eine schlechte Idee, wenn man auf irgendwelche Dienste angewiesen sein sollte oder zugreifen möchte, die auf einem vorhandenen "reverse DNS"-Eintrag für die eigene IP-Adresse bestehen.

http://chiemgau-dsl.info

Ich habe zwei Anschlüsse mit (etwas erweiterten) FRITZ!Boxen dort zu betreuen und stellte dabei fest, daß für das bei den Kunden u.a. auch verwendete IP-Segment 46.253.76.0-46.253.79.255 keine PTR-Einträge im DNS zu finden sind.

Nun ist das zwar nicht wirklich zwingend (RFC 1912 "empfiehlt" es nur), aber es gehört eben doch "zum guten Ton" ... daher dachte ich, es wäre komplikationslos zu beheben.

Meine Anfrage an den Support dort (am 13.07.2016) wurde dann am 20.07.2016 mit

Sehr geehrter Herr X (da hatte dann nicht einmal das korrekte Abschreiben des Nachnamens aus der Mail geklappt),

wir werden uns dies überprüfen und gegeben falls Änderungen vornehmen.

Mit Freundlichen Grüßen

...

beantwortet, seitdem ist nichts weiter zu vermelden. Es wurden auch keine passenden RDNS-Einträge erzeugt (jedenfalls bis jetzt), das habe ich natürlich geprüft.

Da ich davon ausgehe, daß da nun auch nichts mehr passieren wird, sehe ich mich zur oben ausgesprochenen Warnung veranlaßt.

Es gibt ja durchaus genug Dienste, welche auf die prinzipielle Auflösung einer anfragenden IP-Adresse bauen (nicht umsonst haben die größeren Provider auch für ihre dynamisch zugewiesenen Adressen entsprechende Zonen im DNS eingerichtet) und die sind sicherlich nicht alle in der (recht komfortablen) Position, an die Stelle einer Abfrage des tatsächlich zuständigen Servers einfach eine "fake zone" zu setzen, wie ich das jetzt tun werde - damit muß ich zumindest meinen Code nicht ändern und die Sicherheit an dieser Stelle schmälern.

Sollte seitens des Anbieters tatsächlich doch noch ein Eintrag erfolgen (und er mich davon in Kenntnis setzen, denn das kriege ich dann nicht mehr mit, wenn mein Server dort selbst SOA wird für meine eigenen Anfragen), dann werde ich das hier gerne noch entsprechend vermerken.

EDIT: Wenn jetzt jemandem auffallen sollte, daß der Text im Beitrag keinen Anschluß mehr an den Titel hat, muß er weiterlesen bis zur Kritik von @oldschool2k7, damit der Zusammenhang deutlich wird. Für die Änderung des ersten Satzes im Beitrag fehlt mir die Lust und die Phantasie und ein passender Gegenvorschlag (der zur Änderung der Einheit von "subject" und "body" dazu gehört hätte) ist an mir vorbeigegangen.

 

[HabNeFritzbox]

Welche Dienste sollten es denn sein die Probleme machen sollen?

Spontan fällt mir nur Email ein, jedoch wird wohl kein Mailserver direkt über DSL versenden im privaten Bereich.

 

[oldschool2k7]

Mir fällt auch nur E-Mail dazu als möglicher Dienst ein. Liegt denn überhaupt ein Business-Anschluss mit fester IP-Adresse vor? Das würde ich als (sinnvolle) Voraussetzung für einen PTR-Record ansehen.

Eine allgemeine Warnung vor diesem Anbieter aufgrund dieser speziellen Problematik halte ich für übertrieben - Titel sollte angepasst werden.

 

[PeterPawn]

Eine allgemeine Warnung vor diesem Anbieter aufgrund dieser speziellen Problematik halte ich für übertrieben - Titel sollte angepasst werden.

Wo liest Du da "eine allgemeine Warnung"? Die Punkte im Titel lassen es für mein Empfinden sehr deutlich werden, daß da noch etwas kommt und es paßt nun einmal nicht der gesamte Beitrag in den Titel. Alternativen muß man dann nicht nur fordern, sondern auch vorschlagen. Lese ich einen solchen, der dieselbe Aussagekraft hat (also den Leser zur Fortsetzung der Lektüre animiert oder auffordert - auch in den Ergebnislisten von Suchmaschinen), dann können wir ja darüber reden. "Vorsicht" wäre m.E. deutlich zu kurz und würde wohl auch mit den Board-Regeln kollidieren.

Ich habe für einen ganz konkreten Einsatzfall (und das nun sehr ausführlich und deutlich) gewarnt und einem Kunden weder zu- noch abgeraten ... lediglich darauf aufmerksam gemacht, daß es ein Problem mit einem solchen Anschluß geben kann (auch da steht kein "muß") und wo genau dieses dann liegt.

Das halte ich für legitim, genauso wie irgendwelche Hinweise, wenn ein Anbieter nur DS-Lite oder IPv4 per CGN offeriert ... der Kunde sollte vorher genau wissen, was er erhält.

Den Zusammenhang mit einem Business-Anschluß und einer festen IP gibt es eben gerade nicht und was man selbst als "sinnvolle Voraussetzung" ansieht, liegt sicherlich auch im Auge des Betrachter. Ich beziehe mich da eindeutig auf das oben verlinkte RFC, wo im Abschnitt 2.1 im fünften Satz genau der folgende Text steht:

For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Auch das habe ich von Beginn an klargestellt, daß es kein "Zwang" (MUST) ist ... aber es gehört zum guten Ton. Das geht schon da los, wo ein Webserver dann vergeblich versucht, eine DNS-Auflösung für den Inhalt der CGI-Variablen "REMOTE_HOST" zu erhalten.

Und selbst wenn hier jedem "nur" E-Mail als Dienst einfällt - ist das noch kein Grund? Wer kann mir denn genau auflisten, welcher unabhängige Mail-Provider wie mit einer fehlschlagenden RDNS-Auflösung umgeht, von "posteo.de" bis zu "lavabit.com"?

Ja, schon der Push-Mail-Versand von so einem Anschluß über meinen Postfix-Mailserver scheitert eben (neben dem eigenen DynDNS-Service), weil das für einen SMTP-Server "normal" ist, wenn er als erstes eine solche Abfrage versucht, bevor er weitere Ressourcen für eine derartige Verbindung bereitstellt und schon das werde ich nicht ändern, weil ein Anbieter einen DSL-Anschluß bei seinen Kunden betreibt, der eben keine Reverse-Auflösung unterstützt ... und den offerierten Zusammenhang mit einer festen IP-Adresse und einen Business-Anschluß gibt es nicht.

Also tu bitte nicht so, als würde ich hier "Provider-Bashing" betreiben ... ich kann über die restlichen Qualitäten dieses Providers gar nichts sagen (also auch nichts Schlechtes, wenn man mal von einem recht gemütlichen Kundenservice absieht, der mit der deutschen Schriftsprache auf Kriegsfuß steht) und meine "Warnung" bezieht sich ganz klar auf einen einzelnen Aspekt, der durchaus auch anderen auf die Füße fallen könnte.

Wer hier der Meinung ist, etwas gelesen zu haben, ich wolle den aufgelösten Namen beeinflussen (da macht dann ein Einwand mit Business-Anschluß und fester IP-Adresse vielleicht wieder Sinn), der hat eben falsch gelesen ... ich erwarte nur, daß es einen beliebigen Eintrag für die Adresse in der in-addr.arpa-Domain gibt.

 

[oldschool2k7]

Wo liest Du da "eine allgemeine Warnung"?

Natürlich hier:

Vorsicht bei der Buchung von "Chiemgau DSL"

Alternativen muß man dann nicht nur fordern, sondern auch vorschlagen.

Das muß ich zweifellos nicht und es ist auch nicht meine Aufgabe, anderen Usern sinnvolle Titel vorzuschlagen ;-)
Trotzdem hier eine spontane, imho deutlich aussagekräftigere Alternative die es (statt der genannten allgemeinen Warnung) auf den Punkt bringt: "Kein PTR Record bei Chiemgau DSL"

Also tu bitte nicht so, als würde ich hier "Provider-Bashing" betreiben ...

Ich finde mit dem von dir gewählten Titel (und den irrelevanten Hinweisen auf die mangelhafte Rechtschreibung) vermittelst du aber diesen Eindruck - daran ändern auch drei Punkte nichts.

 

[qwertz.asdfgh]

"Kein PTR Record bei Chiemgau DSL"

Ne ne, also wenn schon Änderung dann eher so (korrekte RS ist ja nicht so wichtig):
"Vorsicht! Nix mit das PTR Record bei Chiemgau DSL"

:lach:

 

[PeterPawn]

Ich weiß ja nicht, welche Aussagekraft Du hinter "Kein PTR Record bei Chiemgau DSL" sehen magst ... da reagiert m.E. kein Mensch drauf, wenn er sich über einen DSL-Anschluß bei diesem Anbieter informieren will, einfach weil mit dieser "Beschreibung" niemand etwas anfangen kann.

Wenn Du etwas an meinem Titel auszusetzen hast und eine Änderung sehen willst, dann mußt Du tatsächlich einen Vorschlag machen. Ein "so geht es nicht" ist "nur" eine Meinung und solange Du kein Admin/Moderator bist (dort darfst Du meinen Beitrag selbstverständlich melden und wenn man das genauso sieht wie Du, wird man sich sicherlich mit mir in Verbindung setzen), sei Dir diese unbenommen ... zu einem konstruktiven Vorschlag oder konstruktiver Kritik gehört immer noch der Vorschlag, wie es denn besser/anders ginge. Deinen (ja offenbar widerwilligen) Vorschlag finde ich jedenfalls nicht besser ... er ist wieder "so technisch", daß der "normale Benutzer" sich darunter erst einmal gar nichts vorstellen kann.

Den Hinweis auf mangelhafte Form der Antwort hast erst Du mit Deinem Einwurf überhaupt provoziert ... ich habe mich in #1 nur darüber mockiert, daß nicht einmal die Anrede stimmte und wenn Du auch nur die geringste Ahnung von Support haben solltest, dann wüßtest Du, wie wichtig solche Kleinigkeiten sind (einfach um dem Kunden "ein gutes Gefühl" zu vermitteln) und wie explizit Mitarbeiter im Support in solchen Dingen geschult werden. Wenn Du mit einer Hotline telefonierst und die sprechen die mehrmals mit dem Namen an, dann liegt das auch nicht daran, daß sie Dich genau kennen und nur auf Deinen Anruf gewartet haben ... es ist einfach Teil des "Pamperns" der Kunden und da ist eine einfache schriftliche Nachricht, in der schon das vierte Wort nicht stimmt (und eine Verballhornung des tatsächlichen Namens ist, die man sich sogar im täglichen Leben verbittet) einfach schon tödlich. Aber wie gesagt, das war nur eine Petitesse und die Bemerkung mit dem "Kriegsfuß" taucht eindeutig erst in der Antwort auf Deinen "Vorwurf" auf ... und auch eine ordentliche Antwort gehört für mich tatsächlich zu einem guten Support, denn so eine Nachricht zeigt auch dem Kunden (dessen "Sprachrohr" ich in diesem Zusammenhang war), wie man sich wirklich um sein Anliegen bemüht und das ist hier in meinen Augen (auch wegen der Reaktionszeit von 7 Tagen) mangelhaft.

Habe ich denn wenigstens Deinen Irrtum in Bezug auf eine feste IP-Adresse und "meine Erwartungshaltung" ausräumen können?

- - - Aktualisiert - - -

Ich habe den Titel jetzt etwas erweitert und hoffe damit auch @oldschool2k7 "Genüge getan" zu haben ... wenn nicht, bleibt Dir ja noch der Weg über den Link unten links unter dem Beitrag.

- - - Aktualisiert - - -

Und um auch das noch festzuhalten (und den Verdacht von unhaltbaren "Verdächtigungen" meinerseits zu entkräften) ... für andere IP-Segmente (z.B. 31.209.160.0-31.209.175.255 von demselben Provider) gibt es diese PTR-Records sehr wohl:

[B]# dig -x 31.209.168.21 any[/B]

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 31.209.168.21 any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35143
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;21.168.209.31.in-addr.arpa.    IN      ANY

;; ANSWER SECTION:
21.168.209.31.in-addr.arpa. 3600 IN     PTR     [COLOR="#FF0000"]cust-21-168-209-31.ip-customer.net.[/COLOR]

;; Query time: 50 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 12 00:37:05 CEST 2016
;; MSG SIZE  rcvd: 103

[B]# dig 21.168.209.31.in-addr.arpa soa[/B]

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> 21.168.209.31.in-addr.arpa soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2413
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;21.168.209.31.in-addr.arpa.    IN      SOA

;; AUTHORITY SECTION:
168.209.31.in-addr.arpa. 3600   IN      SOA     [COLOR="#FF0000"]nsa.ip-fabric.net.[/COLOR] noc.ip-fabric.net. 2013082801 43200 1800 1209600 3600

;; Query time: 37 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 12 00:41:13 CEST 2016
;; MSG SIZE  rcvd: 112

[B]# whois 31.209.168.21[/B]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '31.209.160.0 - 31.209.175.255'

% Abuse contact for '31.209.160.0 - 31.209.175.255' is '[email protected]'

inetnum:        31.209.160.0 - 31.209.175.255
netname:        DE-IP-FABRIC-20110503
country:        DE
org:            ORG-iG70-RIPE
admin-c:        MB22788-RIPE
tech-c:         MB22788-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      MB34194-MNT
mnt-lower:      WR1199-MNT
mnt-routes:     MNT-EWRO
mnt-domains:    WR1199-MNT
mnt-domains:    MB34194-MNT
created:        2011-05-03T09:46:56Z
last-modified:  2016-04-14T10:48:30Z
source:         RIPE # Filtered

organisation:   ORG-iG70-RIPE
org-name:       ip-fabric GmbH
org-type:       LIR
address:        Oetztalerstr. 1
address:        D-81737
address:        Muenchen
address:        GERMANY
phone:          +498921231900
fax-no:         +498921231901
abuse-c:        AR14616-RIPE
admin-c:        WR1199-RIPE
admin-c:        MB22788-RIPE
mnt-ref:        MB34194-MNT
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
created:        2010-11-25T11:36:33Z
last-modified:  2016-04-14T09:50:51Z
source:         RIPE # Filtered

person:         Martin Born
address:        ip-fabric GmbH
address:        Oetztaler Strasse 1
address:        D-81373 Muenchen
phone:          +49 89 21231900
nic-hdl:        MB22788-RIPE
mnt-by:         MB34194-MNT
created:        2010-12-27T17:17:44Z
last-modified:  2010-12-27T17:17:44Z
source:         RIPE # Filtered

% Information related to '31.209.160.0/20AS6663'

route:          31.209.160.0/20
descr:          ip-fabric GmbH
origin:         AS6663
mnt-by:         MNT-EWRO
created:        2012-12-31T15:18:35Z
last-modified:  2012-12-31T15:18:35Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.87.4 (DB-1)

Der Provider hat also durchaus den notwendigen DNS-Server ... ob die Delegierung für das Segment existiert, ist nicht so einfach zu ermitteln, aber im WhoIs ist das Segment dem Provider ja zugeordnet:

[B]# whois 46.253.76.0[/B]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '46.253.76.0 - 46.253.79.255'

% Abuse contact for '46.253.76.0 - 46.253.79.255' is '[email protected]'

inetnum:        46.253.76.0 - 46.253.79.255
netname:        IPF-DSL-ACCESS
descr:          Customer Dial In Pool
country:        de
admin-c:        MB22788-RIPE
tech-c:         MB22788-RIPE
status:         ASSIGNED PA
mnt-by:         MB34194-MNT
mnt-by:         WR1199-MNT
mnt-lower:      MB34194-MNT
mnt-routes:     MB34194-MNT
created:        2011-04-21T08:20:39Z
last-modified:  2013-03-05T09:32:00Z
source:         RIPE

person:         Martin Born
address:        ip-fabric GmbH
address:        Oetztaler Strasse 1
address:        D-81373 Muenchen
phone:          +49 89 21231900
nic-hdl:        MB22788-RIPE
mnt-by:         MB34194-MNT
created:        2010-12-27T17:17:44Z
last-modified:  2010-12-27T17:17:44Z
source:         RIPE # Filtered

% Information related to '46.253.64.0/20AS6663'

route:          46.253.64.0/20
descr:          ip-fabric GmbH
origin:         AS6663
mnt-by:         MNT-EWRO
created:        2012-12-31T15:19:42Z
last-modified:  2012-12-31T15:19:42Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.87.4 (DB-1)

Da das WhoIs von derselben Organisation verwaltet wird, wie die Domain "in-addr.arpa", ist es aber durchaus legitim anzunehmen, daß auch dort die Zone delegiert werden könnte.

Jetzt müßte ich wieder hingehen und den Titel erneut ändern ... denn es sind ja nicht sämtliche Adressen betroffen, die dieser Provider benutzt. Nun würde ich an dieser Stelle aber darauf bauen, daß dann jemand den Thread tatsächlich liest und dort steht schon in #1 überdeutlich, auf welches Segment ich mich beziehe.