previous version supported using internal IP addressing

[bmcdonough]

I currently run an older version of this project, which supported public IP, specified IP address, or interface.

    --ip-source public | IP | INTERFACE
        This arguments defines how to get the IP we update to.
        public    - use the public IP of the device (default)
        IP        - use a specific IP passed as argument
        INTERFACE - use the IP of an interface passed as argument eg: eth0 eth0.1 or eth0:1

In this current version, within the lambda subdir, index.py has the following comment:

# To disable internal IP find the block of text:
# '# Comment out the following 4 lines to disable internal IP'
# and do that ;)

However the code does not contain this. Would this be a feature request to add back in local IP addressing?

[masberta]

Thanks for highlighting this, I will for now remove the comments referring to the missing functionality and review the previous version of the code to see if it can be re-implemented.

I'll leave this issue open while I asses the level of effort to bring that functionality back.

[masberta]

Reviewed previous implementation and I'm not sure I'd like to proceed mostly for security reasons as it will allow to set an arbitrary IP.

Can you provide a use case which will justify this feature? For internal IP and networks there are potential other solutions that can be more effective than relying on dynamic DNS.

[bmcdonough]

I use an older revision, from 2020, so looks like commit 373a366. I have a few different devices in my house, and I use it to set the DHCP assigned IP address to a name. This allows me to then have DNS resolve for services: server101.dyn.domain.com

Fast forward to a few years later I was trying to implement another server and realized you updated the code. In trying to bring my setup in to the future, I realized I could not use your updated code. So I am continuing to use the older version from 2020, which works great.

[pswired]

I am also looking to have this functionality restored. The use case is to update a dynamic DNS entry for a dual-WAN router that forms a connection to AWS over a single public IP but needs to update dynamic DNS entries for both of its public interfaces. That is not possible without some source routing magic on the router side with the current implementation.

[masberta]

I use an older revision, from 2020, so looks like commit 373a366. I have a few different devices in my house, and I use it to set the DHCP assigned IP address to a name. This allows me to then have DNS resolve for services: server101.dyn.domain.com

Fast forward to a few years later I was trying to implement another server and realized you updated the code. In trying to bring my setup in to the future, I realized I could not use your updated code. So I am continuing to use the older version from 2020, which works great.

@bmcdonough > I would suggest you should rely on a local DNS server or use a router offering local DNS mappings.

I am also looking to have this functionality restored. The use case is to update a dynamic DNS entry for a dual-WAN router that forms a connection to AWS over a single public IP but needs to update dynamic DNS entries for both of its public interfaces. That is not possible without some source routing magic on the router side with the current implementation.

@pswired > If I understand correctly you have 2 public IPs accepting inbound connection but only 1 IP is used for outbound? You would like to be able to update some DNS records with the inbound only IP? Wouldn't you be able to solve this in your local network once the dual-WAN router receive a request? Can you share more on the router you're using?

[pswired]

@masberta Yes, that understanding is correct. The routing table on the device running the script will have only one active default route, and it will correspond to the primary ISP in use at the time. My use case is to have one dynamic DNS hostname in Route53 for each WAN interface on the router, regardless of whether the interface is active or standby. Then I use CloudWatch to have a third DNS record point to one of the two interface records based on its reachability observation. The router is a Ubiquiti EdgeRouter, but nearly all dual-WAN routers will experience this same behavior.

The benefit of having one DNS record per interface is that an administrator on the outside can reconfigure the device from the outside in a situation where the primary WAN interface is in a degraded state, but not degraded enough to trigger failover to the alternate WAN.

[masberta]

Not planning to implement this but happy to review any pull request addressing dual wan support.