DynDns1 / DynDns2 updates

[remkohat]

DynDns1 / DynDns2 updates are not working properly.
IP of hostname is set to 127.0.0.1 in DNS despite the correct myip value being sent by the router.

I use Nginx as webserver so the .htaccess file in /nic does nothing.
It's replaced by this in the vhost config:

# DynDNS v1 (legacy)
rewrite ^/nic/dyndns$ /ddns/update.php break;
rewrite ^/nic/statdns /ddns/update.php break;

# DynDNS v2
rewrite ^/nic/update$ /ddns/update.php break;

which rewrites

https://<ispconfighost>/nic/update?hostname=<hostname>&myip=<ip>

to

https://<ispconfighost>/ddns/update.php?hostname=<hostname>&myip=<ip>

Proven by the ispconfig access log that shows the correct rewritten uri.

[mhofer117]

Where exactly did you add the nginx rewrites?
Unfortunately I don't have access to an ispconfig installation with nginx at the moment, so I'm just guessing here:

---

It's possible that your vhost does not forward the correct REQUEST_URI to the php script.
This results in the wrong protocol (default instead of dyndns) being used.
The following parameter is required in nginx php config:

fastcgi_param  REQUEST_URI        $request_uri;

In my experience this is included in the default parameters of an nginx installation (/etc/nginx/fastcgi_params), which should be used by the default nginx vhost of ISPConfig: https://git.ispconfig.org/ispconfig/ispconfig3/-/blob/develop/server/conf/nginx_vhost.conf.master#L209

---

In addition, the IP 127.0.0.1 also means the script is not getting the real remote IP.
This means you have not configured TRUSTED_PROXY_KEY, TRUSTED_PROXY_IP and/or the X_FORWARDED_FOR header. However this is not directly related to your issue because the DynDns protocols should use the query parameter instead...

---

If I find some time I will set up an nginx installation and create appropriate documentation. If you can provide more details about your configuration, this would help.

[remkohat]

On the same server nginx is setup as proxy (managed by ISPConfig as webserver) in front of ISPConfig.

I use a custom nginx directive because of the rewrites:

proxy_set_header    X-Real-IP            $remote_addr;
proxy_set_header    X-Forwarded-For      $proxy_add_x_forwarded_for;
proxy_set_header    X-Forwarded-Proto    $scheme;
proxy_set_header    Host                 $host;
proxy_http_version 1.1;
proxy_intercept_errors on;

location / {
    # DynDNS v1 (legacy)
    rewrite ^/nic/dyndns$ /ddns/update.php break;
    rewrite ^/nic/statdns /ddns/update.php break;

    # DynDNS v2
    rewrite ^/nic/update$ /ddns/update.php break;

    proxy_pass https://localhost:2222/;
}

/etc/nginx/nginx.conf has been updates with these lines:

real_ip_header X-Forwarded-For;
set_real_ip_from 127.0.0.1;

so ISPConfig logs now show real IP instead of 127.0.0.1

As far as fastcgi goes, if vhost wouldn't forward correct REQUEST_URI to php then there would be tons of other problems which there are not.
fastcgi_param REQUEST_URI $request_uri; is part of /etc/nginx/fastcgi_params

[mhofer117]

OK I see, so because you are rewriting the URL before sending it to ispconfig upstream, the original REQUEST_URI is lost.

Can you check if it's possible to rewrite the URL in ispconfig directly, instead of on the revese proxy?
Under System -> Server Config -> Web or similar.

Otherwise I will need to implement a workaround for this use case.

[remkohat]

The original REQUEST_URI isn't lost at all.
It's rewritten by the rewrite rules before proxying, the same as the .htaccess file does under Apache.

If the REQUEST_URI would be lost than the hostname to update in the DNS would be lost too.
That's not the case. The correct hostname is updated, but not with the myip value.

I've done some more testing.
Everytime the hostname in the DNS is updated with the IP that had sent the request to ISPConfig.
The myip value is completely ignored.

[remkohat]

To show REQUEST_URI is not lost are these redacted logs:

Access log proxying vhost:
<remote ip> - - [20/Feb/2023:17:04:42 +0100] "GET /nic/update?hostname=<hostname>&myip=<ip> HTTP/1.0" 200 36 "-" "DrayDDNS Client (3.9.9)"

Access log ISPConfig:
<remote ip> - - [20/Feb/2023:17:04:42 +0100] "GET /ddns/update.php?hostname=<hostname>&myip=<ip> HTTP/1.1" 200 47 "-" "DrayDDNS Client (3.9.9)"

[mhofer117]

The query parameters are not lost, but the path is.
The path is used for identifying the correct protocol: https://github.com/mhofer117/ispconfig-ddns-module/blob/master/lib/updater/DdnsUpdater.php#L22

I created a local test install with nginx+ispconfig to work on a solution.

[remkohat]

I see what you mean now.

Why not only check the parameters in the query?
Looking at the settings page in ISPConfig I'd say the standard update url and dyndns1/dyndns2 update url are using different parameters.

Another option when using a (nginx) proxy could be letting it add a custom header to be checked for as alternative for the missing path.

[mhofer117]

I opted for the custom header as this will be more reliable.

Can you try the latest Release (1.2.3), with the following new header:

  proxy_set_header X-Original-Request-URI $request_uri;

I have also created a small guide for nginx here: https://github.com/mhofer117/ispconfig-ddns-module/wiki/Setup-Proxy-Domain-(nginx)

In case you are using ispconfig for shared hosting, I suggest you disable set_real_ip_from in /etc/nginx/nginx.conf again and use the suggested configuration instead.

Let me know if you run into other issues or if it works.

[remkohat]

An even better solution than I had in mind!

Added the header in proxy vhost and replaced DdnsUpdater.php

Seems to be working like a charm!
In the Draytek router I was testing with I entered a bogus ip in the url instead of Draytek's variable for the wan ip.
Dns updated with the bogus ip as it should do.

In /etc/nginx/nginx.conf you want set_real_ip_from 127.0.0.1; when using the webserver as a proxy.
Especially in a shared hosted enviroment.
So you'll see the client's real ip in the logs instead of 127.0.0.1.
Otherwise the only link between vhost log and proxied log (in this case ISPConfig) is the timestamp when troubleshooting uri's for example. Having the client's real ip in all logs makes searches I whole lot easier.
I wanted that anyway but hadn't come to it yet, so I'll be leaving that setting as is.

I've read your proxy page in the wiki and have a few remarks on that.
Anyone who is using a proxy in front of ISPConfig will already have a location / section that is proxying so the location = /ddns/update.php section is redundant. Especially since it doesn't do any rewriting.
And in the .htaccess file you're doing other redirects than in your location /nic/ section. It's my believe that yours is incomplete. Adding the rewrite rules from my earlier post in the existing location / section does exactly the same as your .htaccess file would do in Apache.

You also asked for multiserver feedback in the readme.
I have a multiserver enviroment with several dedicated web, mail and dns servers. And ISPConfig on a dedicated server (with proxy for acces to the panel through port 80 and 443).
You do the full install on the master server (that hosts the ISPConfig panel) and only import the ddns table into the dbispconfig database on all member servers. That's it.

[mhofer117]

In /etc/nginx/nginx.conf you want set_real_ip_from 127.0.0.1; when using the webserver as a proxy. Especially in a shared hosted enviroment. So you'll see the client's real ip in the logs instead of 127.0.0.1.

Just keep in mind that this allows everything running on your system to spoof client IPs. That is why I won't recommend it and am personally running my ISPConfig instances on port 443 directly.

I've read your proxy page in the wiki and have a few remarks on that. Anyone who is using a proxy in front of ISPConfig will already have a location / section that is proxying so the location = /ddns/update.php section is redundant. Especially since it doesn't do any rewriting. And in the .htaccess file you're doing other redirects than in your location /nic/ section. It's my believe that yours is incomplete. Adding the rewrite rules from my earlier post in the existing location / section does exactly the same as your .htaccess file would do in Apache.

The provided snipped works as-is. You could add that to your standard domain without proxying the complete ISPConfig instance. Anything more is up to the individual administrator. You are right that the .htaccess is more granular than a location /nic/, but for simplicity and compatibility I provided a single location block.

You also asked for multiserver feedback in the readme. I have a multiserver enviroment with several dedicated web, mail and dns servers. And ISPConfig on a dedicated server (with proxy for acces to the panel through port 80 and 443). You do the full install on the master server (that hosts the ISPConfig panel) and only import the ddns table into the dbispconfig database on all member servers. That's it.

Thank you for the feedback, good to hear that it works in multiserver setups! Is it really required to add the DB table to the member servers?

Seems to be working like a charm! In the Draytek router I was testing with I entered a bogus ip in the url instead of Draytek's variable for the wan ip. Dns updated with the bogus ip as it should do.

Are you willing to provide some screenshots of your Draytek configs for another examples wiki page?

[remkohat]

Here is a Draytek example:

I've successfully configured custom ddns on models 2133, 2925, 2926, 2927 and 2962. The page looks the same on all of them.

Yes importing the table in all member servers is a requirement.
At first I imported it in the master server only.
Almost immediately I got spammed every minute (ISPConfig's cron schedule) by all member servers, saying the table couldn't be synced.
Apparently members are forced to sync custom/non-default tables including it's data, even though a member has no use for it what so ever.

[mhofer117]

Thank you for providing the screenshot and clarification on the multi-server setup!

[glowf1sh]

Hi there, i am having problems to get this to run with my FritzBox 7590. I can update the A-record correctly with the simple method URL but it is not updating the A-record via the fritzbox.

In the DynDNS Section of the fritzbox i have this:

Update-URL: i put the URL from "DynDns1 / DynDns2 updates" which looks like this:
https://ispconfigurl.tld/nic/update?hostname=arecord.subdomain.domain.tld&myip=YOUR_IP_ADDRESS

Domainname: subdomain.domain.tld
Benutzername (Username): none
Kennwort (Password): The token i got from the module when creating the access.

I dont know why it is not updating the a-record.

What might i be doing wrong or how could i debug this?

[mhofer117]

Hi @glowfishDE
Can you open a separate issue for that and provide some more details about your setup?

• Are you running Apache or a different webserver?
• Which Port is your ISPConfig instance running on?

[glowf1sh]

Sure :) Will do. Thanks Marcel.