Endlich ein DynDNS auf deutsch

Hallöchen,


biete ab Jetzt IPv6 auch noch. DS Lite und Dual Stack kommen noch die nächsten tage.

Gruß
Robert
 
Moin,

ich arbeite gerade an einem Portmapper, da es bei vielen Internetzugängen mit IPv6 sehr starke Unterschiede gibt und auch andere Vorgehensweisen nötig sind.

Es gibt momentan noch einige Internetzugänge, bei denen die Nutzer nicht einmal eine eigene IPv6-Adresse bekommen.
Dies ist mir bei einigen mobilen Zugängen aufgefallen, dort werden dem eingewählten Client nur eine interne IPv4 / IPv6 vergeben
oder die IP-Adressen sind bei dem jeweiligen Provider für Portweiterleitungen gesperrt.

Anfang des Jahres waren noch viele Funktionen einfacher Nutzbar, nur bei den Providern setzt es sich langsam durch,
dass viele Ports gesperrt werden.

Hierbei sind dann DynDNS überflüssig, da der Bezug für die DNS fehlt.

Hier ist ein VPN-Tunnel dann eher die bessere Lösung.
Aber der Portmapper wird dieses Jahr wohl nichts mehr, da die Umsetzung in Kombination mit den DynDNS-Funktionen sehr komplex ist.

Gruß
 
Soo , jetzt läuft IPv6 sauber... irgendwie hat sich ein Fehler eingeschlichen in dem die Alten IP´s nicht gelöscht wurden.

ToDo
- Dual Stack
- SPF Record
- TXT Record
- usw
 
Hab endlich einen Anbieter gefunden, der IPv4, IPv6 macht und ich nicht jeden Monat irgendwelche Links anklicken muss, dass meine Adresse auch nicht abläuft.
https://nsupdate.info/ :)
 
die wachsen zurzeit schneller als die Pilze aus dem boden :D
?
 
Zuletzt bearbeitet:
Wenn man bereit ist nen 10ner im Jahr zu zahlen kann ich www.core-networks.de Empfehlen, mehrere Benutzer möglich für DDNS, mehre Domains auf einmal updatebar, und DNSSEC, DANE ect. möglich.

Domain wo man Nameserver angeben kann wird benötigt dort, dieses geht teils mit Freidomains im DSL Vertrag oder so.
 
Zuletzt bearbeitet von einem Moderator:
schon, aber wozu das alles ? 90% der User sind im meisten fällen keine "Freaks" die sich sowiso selber was basteln.

Es soll einfach und sicher bleiben.
 
Ist doch einfach, gibt ne Update URL wie bei anderen DDNS auch.
 
Es muss doch nicht immer kostenpflichtig sein

Viele Features, von denen ich das ein order andere zwar auch im Angebot habe.

Aber wozu benötigt der "Otto-Normal-Nutzer" alle diese Features?
Ich habe alle zusätzlichen Funktion nur dabei, damit das DynDNS mit anderen Funktionen wie Domainregistrierungen besser kombinierbar ist.
Ich versuche mit meinem Dienst auch den einfachen Nutzern diverse Sonderfunktionen einfach und unkompliziert anzubieten,
nur sind die Zusatzfunktionen wie Domainregistrierungen nicht immer kostenlos. Das eigendliche DynDNS schon.

Bei mir können auch Domains die extern registriert sind über unsere Nameserver für DynDNS genutzt werden, ohne das es 10 € im Jahr kostet.
Das einzige was bei freedyn.de kostenpflichtig ist, sind Webspace, IP-Tunnel und IP-Portmapper,
da dies viele Ressourcen verbraucht und in dem Sinne nicht direkt mit DynDNS zutun hat, aber damit kombinierbar ist.
Das sind alles Funktionen, die von den Nutzern gewünscht wurden und nicht weil es sein muss.

Bei freedyn.de und ddnss.de sind taucht keine Werbung auf und auch kein Link zum aktiv halten eines Benutzerkontos.
 
Zuletzt bearbeitet:
Da scheint ja richtig Konkurrenz aufzukommen... der Dienst selbst ist ja sehr einfach und alles was viele da herumbauen ist auch in meinen Augen überflüssig. Die Spreu trennt sich vom Weizen wenn es um die Verfügbarkeit geht.

Die "automatische" Auswahl von ddnss ist für mich aber noch nicht nachvollziehbar bzw. kann aus meiner Sicht ungewollte Ergebnisse liefern. Es wird wohl davon abhängig gemacht ob die Update-URL über die IPv4 oder IPv6 Adresse aufgerufen wird. Wie macht man ein IPv4-Update bei einem DualStack Anschluss wenn die IPv6-Auflösung bevorzugt ist?
 
In der Update URL einfach beide IP Adressen angeben, die FB hat ja für Platzhalter. Also nicht mit automatischer Ermittlung arbeiten.

Ich weiß nicht was ihr euch so aufregt, war nur eine Empfehlung, wenn Leute mit "Geiz ist geil" denken, darf eh alles nichts kosten, werbefrei und Premiumsupport. ;)

Muss ja jeder selbst wissen. Auswahl gibt ja genug, und gibt ja hier noch Sammelthema mit kostenlosen DDNS Diensten.

robert78@ SPF Record kannst von ToDo streichen, wird nicht verwendet mehr, sondern im TXT.
 
back too root :/


somthing wrong
habe zur zeit zu kämpfen mit bind


** Edit

NS Server Updaten wieder.....
 
Zuletzt bearbeitet:
SPF für eine dynamische Adresse? Ich bin etwas verwirrt. Oder geht es um eine über ddnss.de reservierte/verwaltete komplette Domain?

Wenn nicht einmal Firmen, die eigentlich Vorreiter bei der E-Mail-Sicherheit und bei der Spam-Bekämpfung sind (DANE ist "durchimplementiert") ihre eigenen SPF-Angaben mit einem "-all" beenden können:
Code:
~ # dig +short posteo.de txt
"v=spf1 a a:mx01.posteo.de a:mx02.posteo.de a:mx02a.posteo.de a:mx03.posteo.de a:mx04.posteo.de a:mx02b.posteo.de a:mout01.posteo.de ?all"
, dann stellt sich ohnehin die Frage nach dem künftigen Sinn.

Vielleicht kann mir ja jemand, der seinerseits solche SPF-Records künftig anbieten will (dann sicherlich über einen Generator und nicht als "Freitext", oder?), mal erklären, warum eine Firma, die alle ihre Mail-Server mit geeigneten Zertifikaten (und die Domain mit passenden RRSIG-Einträgen) ausgestattet hat, sich am Ende nicht sicher ist, ob zusätzliche Server im Internet, die sich als "posteo.de" ausgeben, nun ein Fehler sind oder nicht und stattdessen diese Frage mit "?all" ... also "neutral" (kann sein, kann aber auch nicht sein) ... beantworten muß?

Ich blicke vermutlich den Sinn eines SPF-Records nicht oder ich sehe irgendwelche kruden Randbedingungen (teilweise bei Bounces oder Weiterleitungen vielleicht) nicht, die so einen Eintrag erforderlich machen könnten (und mache es selbst dann entsprechend falsch). Wenn eine Weiterleitung ordentlich mit passenden Headern versehen wird (Envelope-From), spielt dieses alte Thema auch keine Rolle mehr und ansonsten gibt es auch noch SRS ... was bringt also (außer der Chance für Spammer, sich immer noch als "posteo.de" auszugeben) dieser Eintrag?

Selbst die "Positivliste" der Mailserver existiert am Ende auch (eben sogar bei Posteo, die es m.E. besser wissen sollten und das tatsächlich absichtlich, wie mir der Chef per E-Mail versicherte, aber ohne jede Begründung) umsonst, weil ja schon der erste "a"-Eintrag ohne Namen jedes System, das in der Domain posteo.de einen gültigen A-Record vorweisen kann (und sei es der Laptop des Pförtners oder die Kaffeemaschine, wenn die eine öffentliche Adresse mit passendem Namen haben), als zulässig ausweist und eine korrekt arbeitende SPF-Implementierung (wenn ich da nicht etwas fundamental falsch verstehe, dann lasse ich mich gerne aufklären, wo mein Denkfehler liegt) bereits beim ersten "a" die Entscheidung "ist tatsächlich posteo.de" treffen würde (oder eben nicht) und die nachfolgenden Abfragen einzelner benannter A-Records eigentlich nur dann ein anderes Ergebnis liefern dürften, wenn da irgendetwas anderes nicht stimmt in der Domain.

Das führt also für den Spammer "myspam.org", der sich als "mx09.posteo.de" ausgibt (gesetzt den Fall, er kommt durch eine Prüfung der MX- und PTR-Records, weil der MTA das nicht richtig checkt), zu einer Prüfung aller A-Records der Domain posteo.de und da so ein Eintrag für "mx09.posteo.de" vermutlich nicht existiert, werden dann noch einmal die A-Records für alle explizit angegebenen Servernamen abgefragt. Nachdem die mit einiger Sicherheit auch nicht auf die IPv4-Adresse des Absenders passen (einen IPv6-fähigen MX hat posteo.de offenbar tatsächlich nicht, jedenfalls nicht laut DNS), wird dann am Ende noch lapidar festgestellt: "Na ja, ob das nicht doch einer meiner Server ist, kann ich nicht genau sagen, ich sage einfach mal: neutral". Wo liegt da der Sinn eines solchen SPF-Records bzw. wo liegt mein Denkfehler? Was soll das einzelne "a" am Beginn der Liste? Warum kein "-all" am Ende, nicht mal ein "softfail" (~all)?

Hat zwar nichts mit DynDNS an sich zu tun, aber ich habe hier "SPF" gelesen und da stelle ich einfach mal meine Fragen ... ich bin ja offensichtlich nicht der Einzige hier, der sich mit diesem Thema herumschlägt, vielleicht kann mir ja jemand auf die Sprünge helfen.
 
Man kann aber Domains per DDNS updaten lassen, und via Relay/Smarthost Mails versenden, und gibt im TXT den SPF Wert an, und legt fest dass nur das Relay verwendet werden darf und Rest bekommt nen ~ oder -.

Somit kann man auch in Firmen oder Zuhause eigenen Mailserver betreiben trotz nicht fixer IP im Businessanschluss mit rDNS Eintrag.
 
Da scheint ja richtig Konkurrenz aufzukommen... der Dienst selbst ist ja sehr einfach und alles was viele da herumbauen ist auch in meinen Augen überflüssig. Die Spreu trennt sich vom Weizen wenn es um die Verfügbarkeit geht.

Die "automatische" Auswahl von ddnss ist für mich aber noch nicht nachvollziehbar bzw. kann aus meiner Sicht ungewollte Ergebnisse liefern. Es wird wohl davon abhängig gemacht ob die Update-URL über die IPv4 oder IPv6 Adresse aufgerufen wird. Wie macht man ein IPv4-Update bei einem DualStack Anschluss wenn die IPv6-Auflösung bevorzugt ist?

Das ist etwas komplizierter und jeder hat dabei sein eigenes Prinzip, auch wenn es eigendlich immer das gleiche ist.

Bei mir erfolgt das Update von IPv4 und IPv6 über zwei verschiedene URLs, die jeweils auch nur über IPv4 oder IPv6 erreichbar sind.
Das IPv4 Update erfolgt eigendlich in den meisten Fällen über den Router, wobei das IPv6 Update von dem Gerät durchgeführt werden sollte,
dessen IPv6-Adresse auch über das DynDNS geroutet werden soll. Ein IPv6-Update vom Router gibt immer ein falsches Ergebnis, da dann die IPv6-Adresse des Routers übermittelt wird und nicht die des IPv6-Präfix, der für die Endgeräte vergeben wird. Und bei echtem DualStack kann man je eh beides Nutzen, ausser der Provider sperrt die nötigen Ports. Alternativ kann auch beides mit einem URL-Aufruf gesetzt werden, jedoch müssen die IP's dann über die Werte "myip" und "myip2" übermittelt werden. Jeder Dienst hat da so seine eigene Lösung, das das DNS-System komplex ist und dort manchmal mehrere Wege zum Zeil zeigen.
 
@HabNeFritzbox:
Also mein Mailserver ist so konfiguriert, dass ohne bzw. mit dynamischen PTR abgelehnt wird. Dass Firmen einen in-House Mailserver nutzen ist sinnvoll und gut aber für die externe Kommunikation braucht es ein- wie ausgehend mindestens einen "richtigen" Mailserver um eine betriebssichere Kommunikation zu gewährleisten.

@yourdom:
Verschiedene URLs für das Update ist die perfekte Lösung. Leider gibt es (ganz allgemein) einige Daemons die noch nicht IPv6-ready sind. Ich hoffe, dass sich das auch noch ändern wird.
 
In der Update URL einfach beide IP Adressen angeben, die FB hat ja für Platzhalter. Also nicht mit automatischer Ermittlung arbeiten.

Ich weiß nicht was ihr euch so aufregt, war nur eine Empfehlung, wenn Leute mit "Geiz ist geil" denken, darf eh alles nichts kosten, werbefrei und Premiumsupport. ;)

Muss ja jeder selbst wissen. Auswahl gibt ja genug, und gibt ja hier noch Sammelthema mit kostenlosen DDNS Diensten.

robert78@ SPF Record kannst von ToDo streichen, wird nicht verwendet mehr, sondern im TXT.

Die Platzhalter sind halt nur für IPv4 gut, bei IPv6 bringt es einem garnichts, ausser man will via VPN über die FritzBox auf das eigene Netzwerk zugreifen.

Aufregen tut sich doch keiner :rolleyes:, nur es ging um OTTO-Normal-Nutzer, für die ist das zu kompliziert.
Und die, die wissen wie das geht, bauen sich den Dienst selber nutzen dann kostenlose Secondary DNS wie BuddyDNS und als Master nen billigen vServer. - Wenn nicht gerade nen Dedi genutzt wird.

DynDNS-Anbieter gibt es viele und viele auch mit schlechten Servern. Ich habe ganz zu anfang auch einen Server als Master gehabt und einen als Slave von einem kostenlosen Hoster. Mitlerweile nutze ich alles eigene Systeme bei denen ich die Konfiguration kenne und auch die Backups selbst verwalte. Es gibt nicht schlimmeres, als wenn ein DNS-Dienst schlagartig down ist, weil der Master durch verschiede IP's zugleich als Slave dient. Und da gibt es mehr Dienste als man denkt, die so arbeiten. Auch ich hatte vor knapp einem Jahr kleinere Probleme mit den Systemen, bis ich dann alle komplett selbst verwaltet habe und 100% eigene Lösungen verwende.

Dies kann man auch nicht direkt als Konkurrenzkampf ansehen, jeder Dienst hat seine Vorteile, aber auch Nachteile.
Jeder Nutzer kann sich seinen Dienst aussuchen, denn nicht jeder hat den gleichen Internetanschluss und nicht jeder Dienst ist mit jedem Anschluss kompatibel.

Man kann aber Domains per DDNS updaten lassen, und via Relay/Smarthost Mails versenden, und gibt im TXT den SPF Wert an, und legt fest dass nur das Relay verwendet werden darf und Rest bekommt nen ~ oder -.

Somit kann man auch in Firmen oder Zuhause eigenen Mailserver betreiben trotz nicht fixer IP im Businessanschluss mit rDNS Eintrag.

Da würde ich mich nicht darauf verlassen! SPF sagt nur, dass E-Mails unter der jeweiligen Domain nur von den festgelegten Hosts versendet werden dürfen.
Wenn da jetzt ein Host ist, der zwar als SPF als einziger Mail-Relay der Domain gesetzt und über eine IP-Adresse ohne sauberen rDNS an das Internet angebunden ist, dann greifen bei den meisten Mailservern noch ganz anderen Sperren.

Anbieter wie z. B. T-Online, GMX, Co. prüfen den rDNS und wenn dieser nicht mit dem Hostnamen im SMTP-Banner identisch ist, wird die jeweilige Mail abgewiesen.
 
@HabNeFritzbox:
Ich verstehe die Idee, sehe aber gleichzeitig das Problem, das nun einmal sehr viele Mail-Server (in meinen Augen richtigerweise) einerseits die Übereinstimmung von MX- und PTR-Record für einen "Gesprächspartner" prüfen und teilweise sogar noch darüber hinausgehen, indem die IP-Adresse mit bekanntermaßen dynamisch genutzten Blöcken abgeglichen wird (hier scheitert so ein Server dann) oder auch der Domain-Name aus der Begrüßung schon für eine Prüfung des Vorhandenseins eines MX-Eintrags (als eine Art Ausweis, daß es sich um einen Mail-Server handelt, was nicht ganz korrekt ist nach RFC) genutzt wird (das schafft so eine Domain dann sogar noch).

Der SPF-Record soll ja eigentlich primär auf den Reverse-Path aus dem "MAIL FROM"-Kommando zur Anwendung kommen (Punkt 2.4), gleichzeitig empfiehlt ("is RECOMMENDED") RFC 7208 aber (Punkt 2.3), auch die HELO-Identität (oder EHLO) schon zu prüfen (und zwar vor "MAIL FROM") und das ist eben auch die Angabe, die viele Server schon vor einer optionalen SPF-Prüfung abgleichen mit dem DNS - und zwar häufig nicht nur, ob die angegebene Adresse existiert, sondern eben auch, ob es die des verbundenen "Clients" (aus Sicht des MTA) ist.

Wenn es Dir also tatsächlich gelingt, die rDNS-Hürde zu nehmen und auch noch ein Gegenüber zu finden, das keine Prüfung auf dynamisch vergebene Adressen vornimmt (viele Blacklist-Server haben ja die dynamischen Bereiche permanent in ihren Listen), dann verstehe ich das am Ende wieder, wenn so eine SMTP-Konversation überhaupt bis zu dem Punkt kommt, wo eine SPF-Prüfung stattfinden könnte.

Aber ein Server, der die ersten Prüfungen nicht vornimmt (selbst wenn die nirgendwo explizit festgeschrieben sind, gibt es ja so etwas wie "best practice", auch wenn man da unterschiedliche Meinungen vertreten kann, was sinnvoll und notwendig ist), der wird (meine Meinung wieder nur) sich am Ende auch nicht um einen SPF-Record kümmern ... insofern sehe ich die theoretische Begründung, mich würde aber mal interessieren, wie sich das in der Praxis tatsächlich auswirkt bzw. welche Server bis zu diesem Punkt kommen.

Wenn so ein Relay von einem Anschluß mit einer dynamischen Adresse dann eine E-Mail erfolgreich versenden kann und der empfangende MTA prüft tatsächlich im Verlauf der Einlieferung den SPF-Record, müßte sich ja eine entsprechende Abfrage direkt am DNS-Server nachweisen lassen. Denn auch so ein SPF-Record dürfte dann ja nur eine sehr kleine TTL haben, wenn man nicht will, daß irgendwelche anderen Forwarder Abfragen nach diesem SPF-Record aus ihren Caches beantworten. Oder aber, man arbeitet mit "a" anstelle von "ip4" oder "ip6", dann bleibt der SPF-Record weitgehend unverändert ... aber auch dann müßte ja anschließend jeweils eine Abfrage nach dem A-Record auftauchen (oder auch nach AAAA-Records, denn das "a" im SPF schließt IPv6-Lookups ein).

Würde mich echt mal interessieren ... lange nicht alle Mail-Server setzen tatsächlich SPF ein (selbst wenn es seit 18 Monaten endlich ein RFC dazu gibt), aber viel mehr vergleichen (nach meiner Erfahrung, die ist nur empirisch und so viel ausgehenden SMTP-Traffic zu verschiedenen Servern habe ich nicht von meinem MX aus, wenn das 200 sind, ist das extrem viel) die Übereinstimmung von MX- und PTR-Record, von der Nutzung diverser Blacklists (z.B. SORBS) mal ganz abgesehen ... insofern würde ich die spätere Prüfung eines SPF-Records und die Bereitstellung eines solchen Eintrags "vorsichtshalber" eher als "nice to have" denn als wirksame Verbesserung der Möglichkeiten so eines eigenen Relays sehen - aber ich mag mich auch täuschen, was die Prüfungen der MTAs angeht und zu sehr von meiner eigenen Vorgehensweise beeinflußt sein.
 
Zuletzt bearbeitet:
Daher ja nen Relay/Smarthost, der auch rDNS ect alles hat, da kann man ja T-Online, Posteo ect. für als Relay verwenden ohne Probleme.
 
@HabNeFritzbox:
Also mein Mailserver ist so konfiguriert, dass ohne bzw. mit dynamischen PTR abgelehnt wird. Dass Firmen einen in-House Mailserver nutzen ist sinnvoll und gut aber für die externe Kommunikation braucht es ein- wie ausgehend mindestens einen "richtigen" Mailserver um eine betriebssichere Kommunikation zu gewährleisten.

@yourdom:
Verschiedene URLs für das Update ist die perfekte Lösung. Leider gibt es (ganz allgemein) einige Daemons die noch nicht IPv6-ready sind. Ich hoffe, dass sich das auch noch ändern wird.

@andiling:
Viele Großunternehmen haben einen eigenen Inhouse-Mailserver, hierbei ist dieser aber mit sauberen rDNS ausgestatten und hat meistens einen Backup-MX, der irgendwo im RZ steht und nur zum Einsatz kommt, falls etwas mit dem Inhouse-Server nicht ok, oder dieser nicht erreichbar ist.
Für einen sauberen Mailverkehr ist rDNS mit einer festen IP und gültigen SMTP-Banner zwingend erforderlich. SPF dient eigendlich nur der SPAM-Unterdrückung.

Die Daemons, welche noch nicht IPv6-Ready sind, benötigen dann andere Lösungen als einfache DynDNS.
Aber es gibt auch genügend Daemons, die das können.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.