Dynamic DNS with DynDns.org not updating reliably

[mldowling]

Hello @cover & @vtjballeng,
What is the real reason you want inbound failover on a domain name? If it is only to access your local security cameras (and we hope you have them on an isolated VLAN from the rest of your network), then there are alternative to making this work using the services and features available from Peplink|Pepwave. We are finding less and fewer reasons nowadays to be opening ports inbound to any network.

On some of the higher end Peplink Routers (such as the Balance 380, 580, 710 & hight plus the SDX & EPX), the router can act as a domain authority updater, giving the options for inbound load balancing and failover much like the outbound services of the routers. From what we can recall, this feature has been available in the higher end routers since pre firmware 6.x.x and is often underestimated in its power and abilities, we use it where an organisation needs to have inbound load balancing and failover for servers within their data centres or operations facilities.

This image shows the options that can be configured, image is from Firmware 8.1.0 in a Balance 580.

In other Peplink|Pepwave routers that do not have the above feature, we are setting up clients with a FushionHub in the cloud (most of these we host on behalf of our clients), we then created a SpeedFusion link with the clients Peplink|Pepwave router. On the clients Pepwave|Peplink router we close all incoming ports and have no DDNS running. The FusionHub sits behind some secret stuff protection (ie firewall) within the datacentre, the customer is assigned a domain name that points to the FusionHub’s public-facing IP.

Not only do we use this for customers who want to access remote cameras, though we also use this for customers who operate SIP/VoIP PBXs at their sites and other inbound services that need the clean failover of multiple connections. We leave all connections running with equal Priority 1 on the router and manage all traffic and failover to backups using VLANs and outbound policies.

There are many previous posts within the forum on using everything mentioned above that can help you achieve these results.
Happy to Help,
Marcus

[vtjballeng]

@zegor_mjol

need a routable IP address - one reachable from the outside. If your connections are behind a (carrier) NAT then you need to set up a connection to (and by way of) some outside router, e.g., a fusionhub.

Secondly, assume that you have routable IP address(es) to the WAN interface(s) of the device (be they dynamic or static) then Peplink is offering a DNS name for each interface of the device though its Incontrol2 registration. And in particular it defines a hostname for the IP address employed by the device to connect to IC2. That may vay over time (as connections are enabled or disabled).

@zegor_mjol, thanks. The connections are routable. I was hoping to use standard DDNS as dyndns is built into some other systems we use and it’s convenient. The mypeplink service is a workaround option. My link structure in IC2 shows somerandomnumber.mypep.link and I only see it as a global setting not a per WAN setting.

So, are wan-1.somerandomnumber.mypep.link and ic2-detected.somerandomnumber.mypep.link valid FQDNs? Or will I simply point to somerandomnumber.mypep.link which seems to be the way it’s arranged?

[vtjballeng]

@mldowling

here are many previous posts within the forum on using everything mentioned above that can help you achieve these results.
Happy to Help,
Marcus

@mldowling, fundamentally I think my expectation is for DDNS to work correctly and update to the current active WAN connection as is done with other commonly available hardware. Workarounds feel like the equivalent of instructions on how to get into the back seat of a 4 door vehicle through the front doors or the trunk because, for some wonky reason, the rear doors don’t work. Maybe we should just ask that the rear doors work instead?

As for our reasons, we’ve got some services that run through dyndns that update our slack channel to tell my company to stop streaming on backup internet and voip pointers. We also have some integration with backups to some nodes remotely hosted. Having correctly working DDNS is the simplest option for our integration right now because we had working DDNS on our older Cradlepoint hardware.

The speedfusion option is something we planned to do but this isn’t our core work and would be happy to have someone else set it up for us. We planned a Vultr instance and just follow existing instructions on how to accomplish that. I’ll check in with you on that issue.

[zegor_mjol]

@vtjballeng

The connections are routable. I was hoping to use standard DDNS as dyndns is built into some other systems we use and it’s convenient.

There seem to be two threads in this conversation, yours and that of @cover, with different architectures.

His fallback connection (AT&T) is not routable, thus the fusionhub approach is likely the least expensive way to achieve routable access to his systems when the fallback connection becomes activated.

As an added bonus, with the fusionhub as the internet connection breakout point the same IP address will work regardless of whether he is connected to the world using the primary or the secondary WAN interface.

@vtjballeng

The mypeplink service is a workaround option. My link structure in IC2 shows somerandomnumber.mypep.link and I only see it as a global setting not a per WAN setting.

“somerandomnumber” can be replaced by your choice of name. It set in an editable field on IC2:

@vtjballeng

So, are wan-1.somerandomnumber.mypep.link and ic2-detected.somerandomnumber.mypep.link valid FQDNs?

Yes. With multiple WANs with routable IP addresses my experience is that the resolution of the FQDN is to all the routable addresses. E.g. for a device with three WANs (all on Verizon, incidentally), each with a routable IP address you get this:

% dig MyName.mypep.link
…
;; ANSWER SECTION:
MyName.mypep.link. 60 IN A 166.xxx.xxx.xxx
MyName.mypep.link. 60 IN A 166.yyy.yyy.yyy
MyName.mypep.link. 60 IN A 166.yyy.zzz.zzz

If you want the IP address of a specific interface you prefix the FQDN with the interface identifier:

dig cellular-1. MyName.mypep.link
…
;; ANSWER SECTION:
cellular-1.MyName.mypep.link. 60 IN A 166.xxx.xxx.xxx

@vtjballeng

Or will I simply point to somerandomnumber.mypep.link which seems to be the way it’s arranged?

There is a difference between somerandomnumber.mypep.link and ic2-detected.somerandomnumber.mypep.link. The former will return the routable IP addresses (if any) of the interfaces, and the latter will provide the current breakout address for the connection of the device to IC2. If you are employing a FusionHub and routing traffic through that connection then the ic2-detected address will be that of the FusionHub.

For the example above, you get

dig ic2-detected MyName.mypep.link
;; ANSWER SECTION:
ic2-detected. MyName.mypep.link. 60 IN A 108.www.www.www

If your system has two or more WANs, then I expect the ic2-detected hostname will return the IP address of the WAN currently being employed for IC2. If there is only one such, then I expect the IP address will be to whichever WAN is currently up (i.e., the automatic update you are looking for).

Cheers,

Z