How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record)

Lars_

Hi all,

my WAN interface is Dual stack and I am using No-IP.com. Updating my IPv4 works just fine when selecting "No-IP" as service in pfSense. However, this will only update the A record of the hostname. Hence I added a second service, "No-IP (v6)", but it looks like this entry is outdated and can no longer be used. Any attempt results in System Log showing:

/services_dyndns_edit.php: Curl error occurred: Could not resolve host: dynupdate.no-ip.com

I initially assumed my IPv6 configuration was broken, until I realised that dynupdate.no-ip.com does not at all have an AAAA record.

If I understand it correctly, there are two options:

Update the AAAA record while talking to dynupdate.no-ip.com using IPv4 (its A record). I don't know if this is something pfSense is capable of.
Update the AAAA record using the URL ip1.dynupdate6.no-ip.com instead, which has an AAAA record. I found the URL through Google and I'm not sure if this is officially supported by No-IP.

If option 2 is the only way forward, how can I change the URL from dynupdate.no-ip.com to ip1.dynupdate6.no-ip.com for the service service "No-IP (v6)"?

Does the faulty URL qualify as a bug that should be reported to pfSense developers?

Lars_

To fix it, I've been experimenting with "Custom (v6)", tried different Update URLs:

ip1.dynupdate6.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP%

ip1.dynupdate6.no-ip.com?hostname=thisismydomain.ddns.net&myip=%IP%

but it does not seem to work and I don't know why. System Log says it updated just fine.

Same for
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP%
with option "HTTP API DNS Options = Force IPv4 DNS Resolution" enabled.

No-IP API information

Netgate Docs

SteveITS

@Lars_ FWIW We looked at this in our No-IP not that long ago and I don't think there's a way to set up a dynamically updating AAAA record...? When we tried to do so we could manually create an AAAA in their system but IIRC there was no way to set up credentials and hence update it. The hostnames we could create that were update-able were all A records.

They do have docs, like a Linux page https://www.noip.com/support/knowledgebase/automatic-ipv6-updates-linux-duc (which ends "If you have a dual stack type network, the No-IP DUC will default to the IPv4 address") but AFAICT it doesn't work that way. Unless we were completely missing something.

Lars_

@SteveITS Determined testing pays off. It works now

Same for
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP%
with option "HTTP API DNS Options = Force IPv4 DNS Resolution" enabled.

I was actually quite close. The solution is to update the AAAA record using IPv4:

Service Type: Custom (v6)

HTTP API DNS Options = Force IPv4 DNS Resolution

Update URL:
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myipv6=%IP%

Note: It has to be &myipv6=, not &myip=

Is this something that makes sense to be implemented in No-IP (v6) and No-IP (free-v6)? It would not work if IPv4 DNS resolution isn't available, but I guess that is not very common in the wild.

Haven't found a way to tag this thread as SOLVED.

SteveITS

@Lars_ What pfSense version are you on?

https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#dynamic-dns
"Fixed: RFC 2136 Dynamic DNS cannot update AAAA records over IPv6 "

Lars_

@Lars_ What pfSense version are you on?

Been on 2.8.0 since I started looking into this whole matter.

The fix you quoted (AAAA records can now be updated over IPv6) wouldn't matter actually, as No-IP itself doesn't support updating AAAA records via IPv6 in the first place. At least not via "dynupdate.no-ip.com/nic/update". Hence, I showed how to update the AAAA record via IPv4.

michael7786

I'm running into basically the same issue with Route53 v6.

I think an important characteristic of the bug is that you need to use IPv4 when updating Route53. Amazon doesn't provide a AAAA record for route53 and presumably they do not provide an IPv6 endpoint for API requests.

I was looking at the source code and I think I found the issue.

dyndns.class is used for dynamic DNS. Basically it will do a REST API call. It uses the Curl lib to make it happen.

Here's dyndns.class line 416:
https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/master/entry/src/etc/inc/dyndns.class#L416

Here we're setting the variable _addressFamilyRequest. In case we are doing dynamic DNS with an IPv6 interface, then this value is set to AF_INET6 (this value comes from the C socket API and it means "Address Family IPv6").

Later on we initialize the curl object on line 570. Then on line 572

https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/master/entry/src/etc/inc/dyndns.class#L572

We do this:

curl_setopt($ch, CURLOPT_IPRESOLVE, (($this->_addressFamilyRequest == AF_INET6) ? CURL_IPRESOLVE_V6 : CURL_IPRESOLVE_V4));

This is important. We're telling curl to only use IPv6.

From here, the code customizes the REST API call for each service. There's specialized code for noip, and route53-v6. This is where we figure out the API URL, the request body, and the http headers. There is a block of code for basically every dynamic DNS provider. I only looked carefully at route53-v6 and noip-v6. In both cases we do not update the CURLOPT_IPRESOLVE curl option.

After that we call curl_exec to execute the API call:
https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/master/entry/src/etc/inc/dyndns.class#L1918

So to fix this bug, I think we'd need to identify the REST endpoints that are IPv4 only, or we need to allow curl to fallback to IPv4.

Is there a way to communicate any of this with the folks at netgate? In a previous commit, someone already figured out what API endpoints are IPv4 only, here's the code:

https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/ddb0771962b2e1e974a908f1b02ddd94423c2903/entry/src/etc/inc/dyndns.class#L334

A possible solution might involve copy-pasting this... Another idea is to customize these particular dynamic dns code blocks so that curl uses the CURL_IPRESOLVE_WHATEVER. Here's what I mean:

https://curl.se/libcurl/c/CURLOPT_IPRESOLVE.html

SteveITS

@michael7786 said in How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record):

Is there a way to communicate any of this with the folks at netgate?

Bug reports can be made at redmine.pfsense.org.

Maybe relevant: https://redmine.pfsense.org/issues/11177 (from https://docs.netgate.com/pfsense/en/latest/releases/25-03.html#dynamic-dns)

michael7786

I did some more research and there might be some incorrect information in my previous post

Here's the part:
@michael7786 said in How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record):

~~In a previous commit, someone already figured out what API endpoints are IPv4 only, here's the code:~~

~~https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/ddb0771962b2e1e974a908f1b02ddd94423c2903/entry/src/etc/inc/dyndns.class#L334~~

~~A possible solution might involve copy-pasting this...~~ Another idea is to customize these particular dynamic dns code blocks so that curl uses the CURL_IPRESOLVE_WHATEVER. Here's what I mean:

https://curl.se/libcurl/c/CURLOPT_IPRESOLVE.html

I would like to clarify, I do not know if this is a list of DDNS providers with IPv4-only endpoints I just checked a few DNS records using nslookups and I think azurev6 might be reachable over IPv6.

When I ran this:

nslookup -type=AAAA management.azure.com

I was able to resolve a AAAA record.

Therefore, I would like to clarify that I do not know if that list is relevant.

michael7786

@SteveITS Thanks for your help! I created a regression issue at

https://redmine.pfsense.org/issues/16249

I've never done this before, so hopefully it's accepted.

@Lars_ your work-around was a huge help. I was able to track down the issues thanks to your post.

michael7786

@Lars_ I ended up creating a patch that fixes the problem for route53-v6. But I attempted to fix the problem for noip-v6 too. Feel free to try it out.

Here's a link to the relevant issue where I attached the patch:
https://redmine.pfsense.org/issues/16249#note-1

You can use the System_Patches package to apply the patch. After installing the package, you can go to:

System > Patches

From there you can click Add New Patch. This will take you to the system_patches_edit.php page. I included a screenshot that shows how to fill in the fields. The "Patch Application Behavior" values are pretty important. You'll want to set Path Strip Count to 1, and set Base Directory to /.

I don't think my patch is a good long term fix. But it might be acceptable as an immediate fix. The problem is the patch just assumes the pfsense device has an IPv4 interface. I'm not accounting for NAT64 and/or other XLAT technologies. I think a better long-term approach would be to:

Try to use IPv6 to reach the Dynamic DNS API endpoint (it should use the newly implemented behavior from pfsense 2.8.0)
If step one fails then fall back to using IPv4 or any other available connection. (maybe we need a new configuration setting to allow/force the Dynamic DNS client to use a different interface)