Hilfe bei ipv6 und DynDNS

[woodym]

6. OK ich habe jetzt verstanden dass mit IP/encrypt wohl IP pushen und LetsEncrypt ausstellen gemeint ist? Da fehlt mir trotzdem Dokumentation dazu was das heißt bzw. ob ich als Nutzer dann noch auf irgendwas achten muss. Was für ein Token muss ich setzen oder wird das automatisch gesetzt, etc.

Das sind noch die Beispiele die ich mit aufnehemn will. Bei Let's encrypt will ich komplett eine Beschreibung für Dehydrated und einem Update machen.
Das kommt dann auch mit der Beschreibung für pfsense und noch einige andere Geräte wie das dort eingetragen werden muß.

7. Minor C&P Error: Edit-Maske bei "Token" hat als Überschrift "IPv6 Ändern" ;)

das ist geändert ;-)

Ich bin wirklich begeistert. Ich hätte nicht erhofft soviel Input zu bekommen.
vielen Dank! jetzt bin ich nur noch gespannt wie das mit IPv6 und pfSense funktioniert.

bye woodym

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

wenn du 5 Domains hast (3 aktive und 2 inaktive) kannst du hier 6 Beispiele zeigen lassen. Welches Beispiel sollte ich dann per Default nehmen?

Ah, da ich nichts angelegt hatte, habe ich die Birne bei den Domains nicht gesehen. Ich würde default die User Auth machen oder alternativ die erste angelegte Domain weil das die meisten Fälle trifft. Andere Alternative wäre vielleicht die Birne bei der User-Auth vielleicht hinter die User ID zu packen damit sie mehr auffällt. Nur ne Kleinigkeit :)

So habe ich schon Stunden damit zugebracht einen gültigen Aktivierungslink zu erhalten. Die Nerverei wollte ich den Nutzern ersparen.

Verständlich. Vielleicht kann man aus der Essenz von beidem eine Zwischenlösung finden (Link gültig für 30/60min?) und danach neu erstellen. Nur eine Idee/Feedback.

wobei auch ein POST dann denkbar wäre.

Sorry, PUSH war da falsch, POST war gemeint :)

Und ich dachte das ich das auch der Homepage mich schon viel zu viel darüber ausgelassen hatte.

Nach anlegen von einer Domain dann was zu LE zu lesen hat mir dann auch den Anstoß gegeben, was das sein könnte ;)

vielen Dank! jetzt bin ich nur noch gespannt wie das mit IPv6 und pfSense funktioniert.

Wenn mein Aktivierungslink funktionieren würde, bekämst du dein Feedback zeitnah :D

[JeGr]

Eine kleine UI Anmerkung am Rande: POLS - Prinzip der kleinsten Überraschung. Dazu:

• Mache das "i" für die Infos auch blau wie die Glühbirne und/oder such dir ggf. ein "i" im Kreis aus (wie das typische info-i von Infopoints). Dann assoziiert man das automatisch als Info und bei blau denken mehr an einen Link -> onmouseover als bei einem schwarzen i

[woodym]

Wenn mein Aktivierungslink funktionieren würde, bekämst du dein Feedback zeitnah :D

Du kannst alles machen, auch ohne Aktivierung. Nur das die 'box' immer wieder kommt im Dashboard. Davon abgesehen sehe ich das der Account aktiviert ist. Du mußt also den Aktivierungslink also bereits geklickt haben. Und auch die Box sollte nicht mehr erscheinen.

[JeGr]

Jap kurz nach meinem Post hat es dann "gefruchtet" und der Link hatte plötzlich einen Effekt ;) Wie oben beschrieben, würde ich die UI dafür aber etwas umbauen und den Reminder nach einem Mal ausgeblendet lassen und nur noch als Leiste einblenden. Und wer eingeloggt den Link klickt, bekommt sein Dashboard auf und ne grüne Meldung dass der Account jetzt aktiviert ist - wer nicht eingeloggt ist dann einfach die jetzige Info mit Login.

[JeGr]

@woodym Oookay wo soll ich anfangen ;)

• Erster Punkt und kurze Rückfrage: Warum im Dashboard so komplex mit UserID/PW und nicht nur einen langen sagen wir SHA256 Hash als API Token für die ID des entsprechenden DynDNS? Sollte es nicht unsicherer machen, aber mich persönlich irritiert User/PW da das "scheinbar" random hashes sind und die UserID auch bei jedem Eintrag und beim "alle ändern" unterschiedlich ist. Somit wäre ein einzelner API Key String pro Punkt (alle ändern / all per user | einzelne ändern / per domain) als Token sicher einfacher.
• Zweiter Punkt: deine jetzige API/GET Struktur lässt es überhaupt nicht zu, dass du IP4 und IP6 gleichzeitig übergibst. Kann die pfSense zwar (momentan) noch nicht, wäre aber einfach einzupflegen und würde somit einen unnötigen Call und Check sparen. Du wertest aber nur $ip aus, somit kann man nur eines pro Call übergeben.
• Dritter und bösester Punkt: Du machst keine Eingabeprüfung. Sowas ist nicht nur schlechter Stil sondern auch potentieller Buffer Overflow/OutOfBounds/whatever Security Impact. Warum hab ich das bemerkt? Weil ich beim manuellen Submit einer IP6 mich noch gewundert habe, wie du rausfinden willst bei nur einem IP Parameter, was ich eigentlich sende - IP4 oder IP6. Leider gar nicht. Die Doppelpunkte der IP6 werden schlichtweg verworfen und statt dessen der komplette Zeichensalat der über bleibt in dein IP4 Feld geschrieben. Das klingt nach Code Desaster waiting to happen ;) Geht also gar nicht.
  Ich würde hier ganz klar zwischen ip4/ip6 als Parameter unterscheiden, dann können auch beide mit einem Call übergeben werden UND es muss dringend eine Eingabeprüfung her, was als Wert für ID/PW/Token/Whatever und als IP4/IP6 reinkommt. Nie einfach irgendwelche Werte platt weiterverarbeiten. Immer vom Schlimmsten ausgehen ;) Und selbst wenn irgendein Framework einen Schutz gegen Injects hat - trotzdem immer Input Validation machen. Bringt ja nichts wenn ich "irgendeinen quark" da reinschreiben kann und das steht bei IPv4 -> du trägst das ja im DNS ein und dort killt der Mist dann ggf. die DNS Zone für alle...
• vierter Punkt: ich habe es dadurch nicht geschafft überhaupt deine API dazu zu bewegen, irgendeinen Wert in IP6 Felder zu übernehmen. Egal welchen Quatsch ich reingeschrieben habe, alles ist im IP4 Feld gelandet - for better or worse. Dadurch dass wohl beim Verwerten ein paar Sonderzeichen wie Klammern und eben auch Doppelpunkte entfernt werden, wird keine gültige IP6 zusammen gebaut.
• fünfter Punkt: Die Ausgabe nach dem Submit ist erstmal nett und ausführlich - aber zu viel. Die meisten APIs von Routern, die die Ausgabe checken erwarten höchstens die erste Zeile, nämlich ein OK %IP% oder derlei bei der die IP4 oder IP6 nochmal bestätigt wird oder ein ERROR/FAIL und %IP% (was eben übermittelt wurde -> vielleicht ja falsches Format). Alles mehr und vor allem Multiline ist für die Parser der Tod. Die pfSense kanns zwar theoretisch, spuckt aber auch seltsam rum und bekommt nur "OK <IP-Kauderwelsch> change false" zurück, was doof ist. Warum der Submit von pfSense false gibt während der exakt gleiche String "true" im Browser wirft ist mir auch noch nicht klar. Dazu weiß ich nicht was auf Serverseite ankommt.

Grüße

[woodym]

@JeGr said in Hilfe bei ipv6 und DynDNS:

@woodym Oookay wo soll ich anfangen ;)

• Erster Punkt und kurze Rückfrage: Warum im Dashboard so komplex mit UserID/PW und nicht nur einen langen sagen wir SHA256 Hash als API Token für die ID des entsprechenden DynDNS? Sollte es nicht unsicherer machen, aber mich persönlich irritiert User/PW da das "scheinbar" random hashes sind und die UserID auch bei jedem Eintrag und beim "alle ändern" unterschiedlich ist. Somit wäre ein einzelner API Key String pro Punkt (alle ändern / all per user | einzelne ändern / per domain) als Token sicher einfacher.

Das ist dem Umstand geschuldet das viele Router nur eine begrenzte Anzahl von DynDNS können. Deshalb habe ich die User/PW-Kombination gewählt um möglichst hohe kompatibilität zu haben.

• Zweiter Punkt: deine jetzige API/GET Struktur lässt es überhaupt nicht zu, dass du IP4 und IP6 gleichzeitig übergibst. Kann die pfSense zwar (momentan) noch nicht, wäre aber einfach einzupflegen und würde somit einen unnötigen Call und Check sparen. Du wertest aber nur $ip aus, somit kann man nur eines pro Call übergeben.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):
update -> verwendet ipv4 die durch die verbindung verwendet wurde
update?aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv4 und ipv6
update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4
update?ip=1.2.3.4&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 und eine beliebige ipv4

• Dritter und bösester Punkt: Du machst keine Eingabeprüfung. Sowas ist nicht nur schlechter Stil sondern auch potentieller Buffer Overflow/OutOfBounds/whatever Security Impact. Warum hab ich das bemerkt? Weil ich beim manuellen Submit einer IP6 mich noch gewundert habe, wie du rausfinden willst bei nur einem IP Parameter, was ich eigentlich sende - IP4 oder IP6. Leider gar nicht. Die Doppelpunkte der IP6 werden schlichtweg verworfen und statt dessen der komplette Zeichensalat der über bleibt in dein IP4 Feld geschrieben. Das klingt nach Code Desaster waiting to happen ;) Geht also gar nicht.
  Ich würde hier ganz klar zwischen ip4/ip6 als Parameter unterscheiden, dann können auch beide mit einem Call übergeben werden UND es muss dringend eine Eingabeprüfung her, was als Wert für ID/PW/Token/Whatever und als IP4/IP6 reinkommt. Nie einfach irgendwelche Werte platt weiterverarbeiten. Immer vom Schlimmsten ausgehen ;) Und selbst wenn irgendein Framework einen Schutz gegen Injects hat - trotzdem immer Input Validation machen. Bringt ja nichts wenn ich "irgendeinen quark" da reinschreiben kann und das steht bei IPv4 -> du trägst das ja im DNS ein und dort killt der Mist dann ggf. die DNS Zone für alle...

Nicht ganz richtig. Die nicht gültigen Zeichen werden aus den Übergaben entfernt. Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.
Die Unterscheidung (siehe punkt 3) für ipv4 und ipv6 ist durchaus vorhanden. Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

• vierter Punkt: ich habe es dadurch nicht geschafft überhaupt deine API dazu zu bewegen, irgendeinen Wert in IP6 Felder zu übernehmen. Egal welchen Quatsch ich reingeschrieben habe, alles ist im IP4 Feld gelandet - for better or worse. Dadurch dass wohl beim Verwerten ein paar Sonderzeichen wie Klammern und eben auch Doppelpunkte entfernt werden, wird keine gültige IP6 zusammen gebaut.

hast du auch aaaa= für ipv6 verwendet?

• fünfter Punkt: Die Ausgabe nach dem Submit ist erstmal nett und ausführlich - aber zu viel. Die meisten APIs von Routern, die die Ausgabe checken erwarten höchstens die erste Zeile, nämlich ein OK %IP% oder derlei bei der die IP4 oder IP6 nochmal bestätigt wird oder ein ERROR/FAIL und %IP% (was eben übermittelt wurde -> vielleicht ja falsches Format). Alles mehr und vor allem Multiline ist für die Parser der Tod. Die pfSense kanns zwar theoretisch, spuckt aber auch seltsam rum und bekommt nur "OK <IP-Kauderwelsch> change false" zurück, was doof ist. Warum der Submit von pfSense false gibt während der exakt gleiche String "true" im Browser wirft ist mir auch noch nicht klar. Dazu weiß ich nicht was auf Serverseite ankommt.

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'. Danach kommt die verwendete ipv4
als nächste Zeile kommen die Weiteren Übergabeparameter. Dann ob ein Update stattgefunden hat oder nicht (change true/false). Ein Update findet nur statt wenn sich die Daten zum letzten Update (also den DNS-Einträgen) geändert haben. Wenn es einfacher für dich ist, kannst du das auch als JSON bekommen (out=json). Wenn du also OK und change false erhälst, heißt das das alles in ordnung ist und deine Daten zu keiner Änderung im DNS geführt haben (weil schon so gesetzt).

Ich habe mir auch gerade die Log-Files angesehen und gesehen das du ip=<ipv6> verwendet hast und nicht aaaa=<ipv6>. Ich befürchte das ich die Beschreibung dafür nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

bye woodym

edit:
jetzt habe ich in den Logfiles auch die Aufrufe gefunden die scheinbar von der pfSense gekommen sind oder von einem DynDNS-Client:

"GET /update?user=xxxxx&pw=yyyyyy&ip=xx.yyy.z.aaa HTTP/1.1" 200 60 "-" "phpDynDNS/0.7"
"GET /update?user=xxxxx&pw=yyyyyy&ip=aaaa:bbbb:cccc:dddd:eee:fff:aaa:eeee HTTP/1.1" 200 78 "-" "phpDynDNS/0.7"

(User/PW/IPv4/IPv6 verfremdet)

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

hast du auch aaaa= für ipv6 verwendet?

Das ist nirgends dokumentiert ;) Auch in keinem Beispiel.
Zudem: warum wieder POLS unterlaufen mit ip= und aaaa= ? Das ist etwas unintuitiv. Wären es bspw. ip4= und ip6= gewesen (was ich ausprobiert hatte), wäre das sinnvoller gewesen. oder eben a= und aaaa= wenn wir bei DNS Notation sind, da bin ich dann dabei. :)

Das ist dem Umstand geschuldet das viele Router nur eine begrenzte Anzahl von DynDNS können. Deshalb habe ich die User/PW-Kombination gewählt um möglichst hohe kompatibilität zu haben.

Richtig, aber die Router kennen verschiedene Dienste und haben ggf. auch Custom Settings wo man selbst die URL eingibt. Dann sind die Parameter doch egal? Einen vorhandenes Dienst-Template kann man eh nicht nutzen, da dann die URL nicht stimmt, daher sehe ich da den Sinn nicht unbedingt, getrennte User/Pass Hashes zu nutzen. Zumal es die URI ziemlich unhandlich macht irgendwo einzutragen, da durch die User/Pass Parameter alles so weit nach hinten geschoben wird, dass es kaum eine UI geben dürfte, wo man den wichtigen Punkt -> also die IP4/IP6 Parameter noch sehen kann.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Klar :) Aber wie gesagt: Principle of least surprise! a) dass du an der Stelle plötzlich DNS Notation als Parameter nutzt mit aaaa= steht/stand nirgends ;) und b) ist das unintuitiv wenn der andere Parameter ip= heißt. Ich würde - wie oben gesagt - sehr stark dafür plädieren, das in ip4 und ip6 zu benennen, das ist klar und präzise und jeder weiß was gemeint ist :)

Nicht ganz richtig. Die nicht gültigen Zeichen werden aus den Übergaben entfernt. Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Das mag sein - deshalb hatte ich das auch eingegrenzt und nochmal genannt, dass da Zeichen rausgefiltert werden. Aber es ist trotzdem nicht fehlersicher. Wenn ich da "das ist der letzte Quatsch" übergebe muss das einfach kommentarlos abgelehnt werden weil es keine IP ist. Und nicht dann als "dasistderletzteQuatsch" im IPv4 Feld drinstehen und ggf. im blödesten Fall noch so als "IN A" Record im DNS landen ;)

Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

Und wie? Vorsicht Falle. Wenn ich mit primärer IP6 Adresse bei dir ankomme dann liest deine $Scriptsprache im Normalfall die IP der Verbindung aus und listet diese. Das ist nicht fix eine IP4 Adresse, das kann auch problemlos bei einem v6 only Netz eine IP6 sein. Und dann pushst du wirklich wieder die Adresse ins falsche Feld -> wo wir wieder bei plausability checks für die Felder sind ;) Wir haben selbst eine Art Mini DynDNS Check geschrieben (Output unterschiedlich aber mit Parameter bspw. auch identisch zu http://checkip.dyndns.org nur eben mit HTTPS) und das dort bemerkt: wenn wir aus unserem Office mit v6 kommen listet PHP bspw. im $SERVER Array als Verbindungs-IP des Clients unsere IP6, nicht die IP4. Daher mussten wir extra Parameter mit einbauen bzw. unterschiedliche DNS Namen einbauen, damit man gezielt die IP4 oder IP6 eines Clients auslesen kann. Was du bekommst kannst du meistens nicht bestimmen :)

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'.

Im "Check Output" der pfSense wird aber alles verarbeitet. Daher sind da Multiline Ausgaben der Tod ;) Zudem müsste ich z.B. die letzte Zeile jetzt nicht haben (mit dem Host bzw. User Hash). Wenn du Update true/false noch mit anzeigen willst, klar, dann aber besser hintendran. Allerdings fliegt dir dann der DynDNS Check weg wenn man auf

OK %IP% update true

prüft und dann beim zweiten Update ggf. das update false zurück kommt, weil die IP schon gesetzt ist. Dann failt der Check und meckert (unnötig).

"phpDynDNS/0.7"

Jup das ist der Client den die pfSense nutzt.

nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

Das liegt in der Sache: FAQs sind Anlaufstelle wenn ich Fragen habe oder was wirklich nicht klappt. Wenn aber im Dashboard die Hilfen/Beispiele sind und ich die ausprobiere und die nicht funktionieren, weil statt dessen Unsinn in die Variable geklopft wird, gehe ich von Bug aus, nicht von "Muss die FAQ lesen, obs irgendwelche Hidden-Secret-Parameter gibt" :D
Zudem sind die FAQs nicht im Dashboard verlinkt soweit ich sehe ;)

Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Richtig -> aber wurde das SO in den DNS gepusht? Wenn ja noch schlimmer weil das dann für einen DNS DOS simpelst genutzt werden kann, da dir mit so einem Quatscheintrag wie oben der gesamte Resolver bzw. die DNS Zone weggeschossen werden kann.

Edit:

AAAA... Update IP6

Habe ich gerade getestet. Das nächste Problem: Wenn ich nur aaaa= angebe (würde trotzdem den Parameter ändern), werden beide IPs geändert. IP4 wird "geraten" aus der Verbindung, IP6 wird gesetzt wie angegeben. Sollte man IMHO so nicht machen aus Gründen wie oben (ggf. wird IP auch als IP6 ausgelesen etc., was passiert bei reiner v6 Verbindung ...). Zudem ist der Rückgabewert für die pfSense faktisch "falsch" weil dann als Resonse "OK <IP4>" zurückkommt, wenn ich ne IP6 geändert habe.

Gruß Jens

[JeGr]

Noch einen Punkt oben ergänzt

[woodym]

Richtig, aber die Router kennen verschiedene Dienste und haben ggf. auch Custom Settings wo man selbst die URL eingibt.

das 'ggf.' ist genau das problem. Eben nicht alle haben diese mit der Möglichkeit der Angabe der URL.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Klar :) Aber wie gesagt: Principle of least surprise! a) dass du an der Stelle plötzlich DNS Notation als Parameter nutzt mit aaaa= steht/stand nirgends ;) und b) ist das unintuitiv wenn der andere Parameter ip= heißt. Ich würde - wie oben gesagt - sehr stark dafür plädieren, das in ip4 und ip6 zu benennen, das ist klar und präzise und jeder weiß was gemeint ist :)

Das war hier anders gemeint.. In pfSense kann ich auch User und PW angeben. Diese werden auch richtig verarbeitet. Auch bleibt dann die URL etwas verständlicher ;-)

Das mag sein - deshalb hatte ich das auch eingegrenzt und nochmal genannt, dass da Zeichen rausgefiltert werden. Aber es ist trotzdem nicht fehlersicher. Wenn ich da "das ist der letzte Quatsch" übergebe muss das einfach kommentarlos abgelehnt werden weil es keine IP ist. Und nicht dann als "dasistderletzteQuatsch" im IPv4 Feld drinstehen und ggf. im blödesten Fall noch so als "IN A" Record im DNS landen ;)

Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

Und wie? Vorsicht Falle. Wenn ich mit primärer IP6 Adresse bei dir ankomme dann liest deine $Scriptsprache im Normalfall die IP der Verbindung aus und listet diese. Das ist nicht fix eine IP4 Adresse, das kann auch problemlos bei einem v6 only Netz eine IP6 sein. Und dann pushst du wirklich wieder die Adresse ins falsche Feld -> wo wir wieder bei plausability checks für die Felder sind ;) Wir haben selbst eine Art Mini DynDNS Check geschrieben (Output unterschiedlich aber mit Parameter bspw. auch identisch zu http://checkip.dyndns.org nur eben mit HTTPS) und das dort bemerkt: wenn wir aus unserem Office mit v6 kommen listet PHP bspw. im $SERVER Array als Verbindungs-IP des Clients unsere IP6, nicht die IP4. Daher mussten wir extra Parameter mit einbauen bzw. unterschiedliche DNS Namen einbauen, damit man gezielt die IP4 oder IP6 eines Clients auslesen kann. Was du bekommst kannst du meistens nicht bestimmen :)

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'.

Im "Check Output" der pfSense wird aber alles verarbeitet. Daher sind da Multiline Ausgaben der Tod ;) Zudem müsste ich z.B. die letzte Zeile jetzt nicht haben (mit dem Host bzw. User Hash). Wenn du Update true/false noch mit anzeigen willst, klar, dann aber besser hintendran. Allerdings fliegt dir dann der DynDNS Check weg wenn man auf

OK %IP% update true

prüft und dann beim zweiten Update ggf. das update false zurück kommt, weil die IP schon gesetzt ist. Dann failt der Check und meckert (unnötig).

Muß dann für den test nicht nur 'OK' oder 'OK ' oder '^OK' eingetragen werden?

"phpDynDNS/0.7"

Jup das ist der Client den die pfSense nutzt.

nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

Das liegt in der Sache: FAQs sind Anlaufstelle wenn ich Fragen habe oder was wirklich nicht klappt. Wenn aber im Dashboard die Hilfen/Beispiele sind und ich die ausprobiere und die nicht funktionieren, weil statt dessen Unsinn in die Variable geklopft wird, gehe ich von Bug aus, nicht von "Muss die FAQ lesen, obs irgendwelche Hidden-Secret-Parameter gibt" :D
Zudem sind die FAQs nicht im Dashboard verlinkt soweit ich sehe ;)

Das ist eine gute Anregung!

Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Richtig -> aber wurde das SO in den DNS gepusht? Wenn ja noch schlimmer weil das dann für einen DNS DOS simpelst genutzt werden kann, da dir mit so einem Quatscheintrag wie oben der gesamte Resolver bzw. die DNS Zone weggeschossen werden kann.

Dann würde nur dieser Eintrag zerschossen sein, der Zone macht das nichts ;-)

Wie sollte das für ein DDOS genutzt werden?

Edit:

AAAA... Update IP6

Habe ich gerade getestet. Das nächste Problem: Wenn ich nur aaaa= angebe (würde trotzdem den Parameter ändern), werden beide IPs geändert. IP4 wird "geraten" aus der Verbindung, IP6 wird gesetzt wie angegeben. Sollte man IMHO so nicht machen aus Gründen wie oben (ggf. wird IP auch als IP6 ausgelesen etc., was passiert bei reiner v6 Verbindung ...). Zudem ist der Rückgabewert für die pfSense faktisch "falsch" weil dann als Resonse "OK <IP4>" zurückkommt, wenn ich ne IP6 geändert habe.

so wie oben gescrieben:

update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4

dann wird nur die IPv6 geändert, alles andere bleibt unberücksichtigt.

bye woodym

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

das 'ggf.' ist genau das problem. Eben nicht alle haben diese mit der Möglichkeit der Angabe der URL.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Sollte dann aber kein Problem sein das PW einfach leer zu lassen (oder den User). Evtl. mal mit FritzBox und Custom Setting testen... grübel

@woodym said in Hilfe bei ipv6 und DynDNS:

Das war hier anders gemeint.. In pfSense kann ich auch User und PW angeben. Diese werden auch richtig verarbeitet. Auch bleibt dann die URL etwas verständlicher ;-)

Ja ich habe inzwischen gelesen in der FAQ dass man die User/Pass Hashes auch als htaccess-style Basic Auth übergeben kann. Das vereinfacht das Ganze an der Stelle natürlich. Soweit die Randomisierung von User/Pass Hashes ordentlich ist und da gesalzener SHA2 drinsteckt ist mir das dann recht egal :)

Muß dann für den test nicht nur 'OK' oder 'OK ' oder '^OK' eingetragen werden?

Müsste ich durchspielen. Momentan sieht es danach aus als würde der komplette Output geparsed.

Dann würde nur dieser Eintrag zerschossen sein, der Zone macht das nichts ;-)

Sagst du oder dein DNS Server? ;) Hängt stark vom DNS Server ab und wie er Zonen lädt. Bind ist da anders als PDNS bspw. und der wieder anders als andere. Schlußendlich hängt es am Resolver, was der aus der Zone macht. Es sei denn du behandelst jeden Eintrag als eigene voll-qualifizierte DNS Subdomain Zone, dann ist natürlich nur diese betroffen, sofern die Delegation passt.

Wie sollte das für ein DDOS genutzt werden?

DDOS != DOS. Ich schrieb absichtlich DoS -> Denial of Service. Indem ich absichtlich Bullshit in die Zone schreibe was ungeparsed als "A" oder "AAAA" in den DNS übernommen wird, kann ich die entsprechende Subzone oder ggf. auch die Master Zone killen, weil der DNS dann beim Reload die Zone entlädt wegen Fehlern. Damit funktioniert dann der Dienst nicht mehr. Daher meinte ich unbedingt sicherstellen dass bei IP4, IP6 und Token nur das korrekte Format und nur die korrekten Daten drinstehen können.

@woodym said in Hilfe bei ipv6 und DynDNS:

so wie oben gescrieben:
update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4

Wie gesagt, solche halb-Automatismen würde ich tunlichst meiden! Zumal du IMHO noch keinen Test von einer reinen IP6 Maschine hattest, oder? Du nimmst an einigen Stellen einfach an, dass Dinge so passieren. Würde ich so absolut nicht empfehlen.

Meine "Wanted" Liste wäre momentan:

• Parameter entwirren und ip4 und ip6 nutzen statt ip und aaaa
• Parameter absichern und keinen quatsch als Inhalt übernehmen (bringt niemand was)
• Keine unerwarteten Automatismen! Wenn ich nur ip6 als Parameter angebe WILL ich vielleicht gar nicht, dass ip4 automatisch gesetzt wird. Das erwarte ich auch nicht von einem DynDNS Dienst, dass der bei Weglassen von Parametern einfach Dinge automatisch "annimmt". Ist sicher benutzerfreundlich gedacht, läuft aber IMHO genau der POLS bzw. deiner zitierten KISS Strategie diametral entgegen ;)
• Token-Geschichte erklären
• Beispiele für Token und IP6 mit aufnehmen
• FAQ ggf. im Login Zustand irgendwo nochmal anzeigen (Sidenote: beim Zuklapp-Effekt der FAQ scrollt die Seite immer ans Ende was etwas nervig ist)

Ansonsten ggf. noch ein bisschen optischer Feinschliff und es wuppt. Außer dass mir nicht klar ist, wie dein LE/Tokensystem von der pfSense aus triggerbar sein kann/soll?

[woodym]

Hallo Jens,

vielen dank für deine Analyse und deiner konstruktiver kritik. Ich muß deine Vorschläge noch auf den Blick auf andere Router beurteilen. Die Beschreibungen sind ja gerade noch am werden was ja der Grund für meine bitte um hilfe war ;-). Die FAQ's bzw. die Beschreibung der Parameter auch im Dashboard zugänglich zu machen ist sicher ein sehr guter Vorschlag. Ob ich die Parameter so einfach ändern kann ist fraglich, da schon einige die bisherigen verwenden (muß ich aber in den logfiles nochmal genau prüfen was genommen wird... vielleicht die Namen ändern und die alten noch erhalten um kompatibel zu sein).
Was mich noch interessieren würde wie du bei pfSense jetzt den Update machst? Wie übermittelst du die ipv6? Über custom (v6) und %IP% ?

bye woodym

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

vielen dank für deine Analyse und deiner konstruktiver kritik.

Sehr gern

@woodym said in Hilfe bei ipv6 und DynDNS:

Die Beschreibungen sind ja gerade noch am werden was ja der Grund für meine bitte um hilfe war ;-)

Verständlich :)

@woodym said in Hilfe bei ipv6 und DynDNS:

Ob ich die Parameter so einfach ändern kann ist fraglich, da schon einige die bisherigen verwenden (muß ich aber in den logfiles nochmal genau prüfen was genommen wird...

Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend. Klare Cuts sind sinnvoller und im frühen Stadium sinnvoller als ewig alten Kram mitzuschleppen. Als Übergang kann man sicher beides etablieren und testen - wenn es geht, würde ich einfach eine kurze Infomail an die vorhandenen Accounts senden mit der Bitte die Konfiguration zu prüfen/ändern und gut. Genauso auch wegen der "automagischen" Defaults. Da würde ich definitiv zu raten, das abzuklemmen und keine Parameter einfach automatisch zu erraten - schon allein weil man diese dann versuchen könnte zu spoofen über die übergebenen Server-Header.

Was mich noch interessieren würde wie du bei pfSense jetzt den Update machst? Wie übermittelst du die ipv6? Über custom (v6) und %IP% ?

Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)

[woodym]

Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend....

Nein, nicht IPV6. Aber was viel genutzt wird das automatische erkennen der IP :-( . Die früheren DynDNS Client haben irgend wo die externe IP angefragt und dann nur bei änderungen die an DynDNS übertragen. Solche Router wie pfSense machen das etwas inteligenter, sie wissen aufgrund der etablierten Verbindung zumindest den Zeitpunkt wann die IP sich ändert und können dann aktiv werden fals Handlungsbedraf besteht. Das ermittel der IP übernimmt ja srvhome selber womit ein intelligenter Client nicht mehr nötig ist. Einfache Systeme die hinter der FW sitzen können damit eine IP mitteilen ohne sie kennen zu müssen. Genau das wird gerne genutzt.
Das sind eigentlich zwei Forderungen die sich wiedersprechen. Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.

Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)

Das ist eine gute Idee ein Parameter für eine einfach Antwort ;-).
Übrigens sollte dein Update so (custom (v6)) mit IPV4 sofort funktionieren. Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).

Das mit dem automatischen ermitteln der IP hatte bisher bei einem Nutzer nicht funktioniert weil dessen Aufrufe über ein Zwangsproxy gesendet wurden. Da wiederum ist auch keine Verbindung direkt zu seinem Router möglich.

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

haben irgend wo die externe IP angefragt

meistens: http://checkip.dyndns.org

Genau das wird gerne genutzt.

Kein Grund das nicht zu unterstützen, aber dann sollte man das ggf. als Parameter wie "ip=auto" oder als extra Parameter "...&discover=auto" oder ähnliches anhängen. IMHO sollte deine Default URL nicht standardmäßig "magic" machen ;)

Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.

Oder zwei URLs. Aber mit Parametern wäre es IMHO sinnvoller. Weniger Pflegeaufwand und niemand sagt, dass man keine neuen Features über Trigger/Parameter hinzufügen kann :) So wie bspw. der Output in JSON. Hier noch ein "output=minimal" (als Beispiel) für die pfSense als Feedback mit "OK <bla>" ist ja ein anderer Punkt. Stört keine vorhandene Konfiguration. Oder umgekehrt: ein "minimum" als Standard ausrollen -> KISS. Und alles andere als schweizer Messer dranbauen mit Parametern. Das wäre zumindest die Design-Philosophie die ich verfolgen würde :)

Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).

Jein. Taucht sie nicht :) Nicht wenn dein Service komplett wäre, was er nicht ist. Deine Seite ist nämlich nicht Dual Stack fähig. Sprich ich kann mein DynPrefix nur via v4 einliefern. Wenn ich aber DSlite habe, will ich gerade das ja nicht ;) Somit sollte deine Adresse (www.srvhome.de) dringend DualStack liefern und per v6 erreichbar sein.

Wenn sie das ist, kann sie sinnvoll von allen genutzt werden. Vorher nicht. Und wenn sie das ist, dann funktioniert deine "automagic" leider nicht mehr, denn dann wird - je nachdem was das OS präferiert - die Verbindung bereits via IP6 aufgebaut und du erhältst beim Auslesen der Verbindung ... die IP6. Und keine IP4 mehr ;) Außer dein Check/Test würde noch weitere nachgeschaltete komplexere Sachen aufrufen, um außer der IP4 auch die IP6 und umgekehrt zu ermitteln. Würde gehen, aber nunja ... vielleicht unnötig.

Grüße

[JeGr]

@woodym Ich bin auch immer noch interessiert daran, zu lesen ob/wie es weitergeht und kann gern weiter testen. Würde mich dann aber über Feedback freuen.

[woodym]

Hallo Jens,
im augenblick bin ich etwas ausgebremst mit den Aktivitäten. Ich habe bei einigen aktiven Nutzern nachgefragt wie das mit einem Umbau der Aufrufe bei ihnen aussehen würde und habe bisher noch nicht sehr viel resonanz erhalten... warte also noch auf Antworten.
Für die, die bisher geantwortet haben ist das egal; hauptsache sie müssen nichts ändern :-( .
Ich tendiere jedoch dazu einen ditry-call zu haben (wie jetzt mit automatismen) und einen clean-call so wie du ihn dir wünschen würdest.

Auf dein Angebot mit weiteren tests komme ich dann gerne auf dich zurück :-) .
Bezüglich tests fällt mir noch ein das du nachsehen wolltest ob die Antwort auch so '^OK*' (also regex) geprüft werden kann.

bye woodym

[JeGr]

@woodym said in Hilfe bei ipv6 und DynDNS:

Bezüglich tests fällt mir noch ein das du nachsehen wolltest ob die Antwort auch so '^OK*' (also regex) geprüft werden kann.

Nein geht nicht. Ein Regex im Feld ist nicht möglich. Zudem liefert dein Ergebnis bei einem IPv6 push immer noch ein "OK <IPv4>" zurück, was an der Stelle einen Match unmöglich macht, da %IP% bei einem v6 Eintrag der pfSense die IP6 enthält und damit kein "OK %IP%" funktioniert. Ansonsten wäre es kein Problem den false/true einzubauen in der nächsten Zeile. Ich empfehle aber da eh weniger Infos und hoffe dass sich bei deinem Dienst noch was tut in der Richtung meiner Vorschläge, dann wäre das eine tolle Alternative auch für IP6 Geschädigte wie mich.

[fapo]

noch ein vorschlag.
eine ipv6 hat ja einen prefix teil und einen welches das gerät bestimmt.
Wenn man pro host den static teil angeben könnte, wäre es möglich über die pfsense ein update durchführen zu können und alle hosts wären wieder online.
ich hatte vor jahren mal vor sowas auch zu bauen, allerdings habe ich aufgegeben
Die begränzung auf 3 Hosts finde ich auch ein bissle wenig.
Ich habe Schließlich 4722366482869650000000 Adressen (und wirklich fast soviele Rechner :-) )

[JeGr]

Da es evtl. auch mehrere Prefixe gibt die man updatet, wäre ein Switch schön: In der Art "prefix_update=1" könnte man dann bestimmen, dass alle hinterlegten IP6 ein neues Prefix bekommen, der Suffix aber konstant bleibt.

Dann müsste es sinnvoll allerdings sehr wahrscheinlich

1. mehr IP6 Einträge geben als 3 (o.ä.)
2. eine UI geben, mit der man selbst v6 Hosts anlegen kann für die sich dann nur das Prefix ändert.

Wäre sicherlich eine schöne Sache sowas zu haben.