saruman
Benutzer
- Mitglied seit
- 08. Apr 2015
- Beiträge
- 42
- Punkte für Reaktionen
- 0
- Punkte
- 12
Anleitung: War ja extra ein dahinter.
1.) Verstanden, danke!
3.) Dann versteh ich nicht warum sich das bis zum Anlegen der getrennten Anbieter- und Protokollkonfigurationen noch immer fehlerhaft verhalten hat. _Eigentlich_ hätte mit dem Weglassen der statischen URL-Parameter thisipv4=0&thisipv6=0 aus der mitgelieferten Konfiguration schon alles funktionieren müssen. Denn die in Deinem Test gebauten URLs sind (bis auf die beiden Parameter) an sich korrekt. Diese hatte ich aber schon bei den letzten Tests rausgenommen und aufgrund der Antwort von regfish in deren Case nicht wieder reinkonfiguriert. Die waren also beide schon weg.
4.) Okay, auch verstanden. Wenn ich also ein eigenes Protokoll für IPv6 nutze kann ich - bezogen auf regfish - auch einfach den dyndns6.regfish.de bei Aktualisierungsserver eintragen und muss ihn nicht noch ein zweites Mal bei "Aktualisierungsserver IPv6" eintragen.
Ich habs grad noch mal mit den mitgelieferten regfish-Definitionen versucht (ohne die beiden thisipv4/6=0). Bei Update des AAAA Records wird der gleichnamige A Record gelöscht. Ich habe mir allerdings mal Update-Mails von regfish schicken lassen. Dort sieht man folgendes:
IPv4-Update:
IPv6 Update:
Bei aa.bb.cc.dd handelt es sich tatsächlich jedes Mal um ein- und dieselbe IPv4 Adresse.
Das Update welches von den von mir erzeugten Anbietern/Protokollen getriggert wird, sieht irgendwie anders aus:
IPv4-Update:
Und für IPv6:
Bei den vordefinierten Konfigurationen wird irgendwie mehr mitgeschickt. Für mich sieht das so aus als würden trotzdem thisipv4 und ipv4 mitgeschickt werden - auch wenn die gar nicht benutzt werden sollten. Außerdem scheint dort trotz IPv6 Update der IPv4 Updateserver genutzt zu werden.
1.) Verstanden, danke!
3.) Dann versteh ich nicht warum sich das bis zum Anlegen der getrennten Anbieter- und Protokollkonfigurationen noch immer fehlerhaft verhalten hat. _Eigentlich_ hätte mit dem Weglassen der statischen URL-Parameter thisipv4=0&thisipv6=0 aus der mitgelieferten Konfiguration schon alles funktionieren müssen. Denn die in Deinem Test gebauten URLs sind (bis auf die beiden Parameter) an sich korrekt. Diese hatte ich aber schon bei den letzten Tests rausgenommen und aufgrund der Antwort von regfish in deren Case nicht wieder reinkonfiguriert. Die waren also beide schon weg.
4.) Okay, auch verstanden. Wenn ich also ein eigenes Protokoll für IPv6 nutze kann ich - bezogen auf regfish - auch einfach den dyndns6.regfish.de bei Aktualisierungsserver eintragen und muss ihn nicht noch ein zweites Mal bei "Aktualisierungsserver IPv6" eintragen.
Ich habs grad noch mal mit den mitgelieferten regfish-Definitionen versucht (ohne die beiden thisipv4/6=0). Bei Update des AAAA Records wird der gleichnamige A Record gelöscht. Ich habe mir allerdings mal Update-Mails von regfish schicken lassen. Dort sieht man folgendes:
IPv4-Update:
Code:
% Soeben ist eine DynDNS Aktualisierung erfolgt:
%
% Basisinformation
% ----------------------------------------------------
% Ihre DynDNS Domain...: foo.bar.
% Angefordert durch....: aa.bb.cc.dd
% Datum/Uhrzeit........: 11.09.2016, 20:01:54 Uhr
% ----------------------------------------------------
%
% Anforderung
% ----------------------------------------------------
ipv4: aa.bb.cc.dd
thisipv4:
ipv6:
fqdn: test.foo.bar.
forcehost:
ttl: 60
authtype:
ismx:
% ----------------------------------------------------
Remote-Addr: aa.bb.cc.dd
X-Forwarded-For:
% ----------------------------------------------------
%
%[Ende des Berichts]
IPv6 Update:
Code:
% Soeben ist eine DynDNS Aktualisierung erfolgt:
%
% Basisinformation
% ----------------------------------------------------
% Ihre DynDNS Domain...: foo.bar.
% Angefordert durch....: aa.bb.cc.dd
% Datum/Uhrzeit........: 11.09.2016, 20:02:48 Uhr
% ----------------------------------------------------
%
% Anforderung
% ----------------------------------------------------
ipv4:
thisipv4:
ipv6: aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh
fqdn: test.foo.bar.
forcehost:
ttl: 60
authtype:
ismx:
% ----------------------------------------------------
Remote-Addr: aa.bb.cc.dd
X-Forwarded-For:
% ----------------------------------------------------
%
%[Ende des Berichts]
Bei aa.bb.cc.dd handelt es sich tatsächlich jedes Mal um ein- und dieselbe IPv4 Adresse.
Das Update welches von den von mir erzeugten Anbietern/Protokollen getriggert wird, sieht irgendwie anders aus:
IPv4-Update:
Code:
% Soeben ist eine DynDNS Aktualisierung erfolgt:
%
% Basisinformation
% ----------------------------------------------------
% Ihre DynDNS Domain...: foo.bar.
% Angefordert durch....: aa.bb.cc.dd
% Datum/Uhrzeit........: 11.09.2016, 16:11:00 Uhr
% ----------------------------------------------------
%
% Anforderung
% ----------------------------------------------------
ipv4: aa.bb.cc.dd
thisipv4:
ipv6:
fqdn: diskstation.foo.bar.
forcehost:
ttl: 60
authtype:
ismx:
% ----------------------------------------------------
Remote-Addr: aa.bb.cc.dd
X-Forwarded-For:
% ----------------------------------------------------
%
%[Ende des Berichts]
Und für IPv6:
Code:
% Soeben ist eine DynDNS Aktualisierung erfolgt:
%
% Basisinformation
% ----------------------------------------------------
% Ihre DynDNS Domain...: foo.bar.
% Angefordert durch....: aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh
% Datum/Uhrzeit........: 11.09.2016, 16:11:01 Uhr
% ----------------------------------------------------
%
% Anforderung
% ----------------------------------------------------
thisipv6:
ipv6: aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh
fqdn: diskstation.foo.bar.
forcehost:
ttl: 60
authtype:
ismx:
% ----------------------------------------------------
Remote-Addr: aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh
X-Forwarded-For:
% ----------------------------------------------------
%
%[Ende des Berichts]
Bei den vordefinierten Konfigurationen wird irgendwie mehr mitgeschickt. Für mich sieht das so aus als würden trotzdem thisipv4 und ipv4 mitgeschickt werden - auch wenn die gar nicht benutzt werden sollten. Außerdem scheint dort trotz IPv6 Update der IPv4 Updateserver genutzt zu werden.