DDNS Queries IP From "Hostnames" Instead of DNS

Hey Guys -

A few months ago I purchased a WRT1900ACS and just recently put LEDE on it as haven't had time to do so until then. I've got almost everything set up including DDNS, but ran into an issue.

I have a domain name that is tied to my home network - let's call it mydomain.com. One of the reasons I use LEDE is so that I can easily edit the hosts file on it's DNS so when I access mydomain.com from my home network, it goes directly to the local IP instead of routed over the WAN from it's public IP (without having to change the hosts file on each individual system).

After setting up DDNS in LEDE with my service and if reading the log correctly, it seems that it's querying mydomain.com seemingly against the LAN interface as it's returning a local IP every time - not a WAN IP. This causes it to see that the IP is incorrect and performs and unnecessary IP update to the host. I looked through all the settings, but haven't found anything that states what it queries the domain name against.

I tried adding a snippet of the log below, but it detected the IPs as links so wouldn't let me post as I'm a "new user". Here's a link to the snippet if needed.

Any Suggestions? Thanks!!

Bump...

Any suggestions on this? I just looked at DDNS logging and its still forcning an update each time it checks since it's resolving to my local IP. Thanks!

# Normally the current (in the internet) registered ip is detected using the
# local defined name lookup policies (i.e. /etc/resolve.conf etc.)
# Specify here a DNS server to use instead of the defaults.
# you can use hostname or ip address
# i.e. "google-public-dns-a.google.com"
# default: none
option dns_server "google-public-dns-a.google.com"

Why did you change the host file and add a local IP in for your hostname?

Why don't you just allow the redirect from LAN to the WAN IP and port (you place the packet in LAN with destination IP of the Private IP of the server, it then routes at normal)?

That would fix all your issues.

I have a somewhat similar issues with DNS on LEDE. No fix yet.
Please see: Odd DNS issue, different IP returned with nslookup for my DDNS hostname

If you mean allow NAT reflection then that is precisely the WRONG way to go about it. Its a nasty hack and only to be used when there is no other option.

With NAT reflection you can easily bring your router to its knees as whenever you access the client from its WAN IP while on the LAN it will go as quickly as the router is capable. If your LAN is faster than the router can handle (it usually is) then it will max out the routers CPU, this will bring broadband traffic to a standstill as the latency to the LAN is lower than the Internet so it will completely monopolise the router. (trust me, I've done it when I had a router that did NAT reflection but not DNS overrides)

A host/DNS override is absolutely THE correct way to do it and I believe chris5560 has the fix for the particular problem the OP was experiencing.

You are not using your WAN. The device is on LAN. You are not utilizing your WAN connection. Completely lost here.

And what if the OP utilizes a service that cannot?

Also...the OP already stated that he receives a local IP.

NAT reflection is done on the router CPU so takes up similar resources to normal routing.

Therefore if your router can only handle routing of 400Mbit and you are accessing from a Gigabit LAN, it will cap out at 400Mbit maxing the router CPU, leaving no resources left for actual WAN to LAN routing.

So the only way to use NAT reflection safely is to have a router capable of NAT at your LAN speed + your WAN speed combined. The only thing I am aware of that can run OpenWRT and is fast enough to handle this is an actual x86 PC.

My comment was not directed at the OP, it was directed at you, as it seemed you were suggesting they were doing it wrong when in fact they were not.

The only puzzling thing here is why the DDNS monitor was querying DNS in the first place. Usually DDNS services use their own API to talk to the server to check what the IP address is set to, rather than using DNS itself. As obviously DNS can be wrong if the changes haven't propagated yet and they don't want a flood of requests asking to update the IP every minute when in fact its already set correctly but not reached your ISPs DNS servers yet.

Is this a flaw in how the OpenWRT DDNS updater is functioning?

1 Like

AAAH..I understand now...I've never experienced that, or never properly measured; but of course the IP headers are being changed, so some CPU is used. "Actual bandwidth" used though, not observed.

I notice that the services uses DNS...why would it use the API, that would be chicken-in-the-egg...I think there's another thread where the OP noted this (that the service uses DNS), see Post #7:

Adding a hostname under Network > Hostnames on the web GUI (for example) should cause the nslookup to present the IP you desire (after restart of the service, of course).

Like I said, its not a good idea to use DNS to check if your DynDNS setting is correct as you only get your ISPs DNS result which makes it look like the DynDNS IP is wrong, when in fact it may be correct but not updated on your ISPs DNS servers yet.

I use NOIP and their own update client works like that I believe, as constantly sending IP changes to their DNS servers when not necessary is clearly not great for their infrastructure.

Then that means the ISP is improperly cashing the result beyond the TTL. If my ISP does this, I use different servers.

Not sure what that has to do with the lookup check. All of my DDNS instances send the WAN IP update, and the providers respond no change needed/same IP.

I guess you are right, it makes sense to query DNS as if it IS correct, that means no load at the DDNS provider at all. But clearly its flawed if its going include stuff from the hosts file in that lookup.

My goodness by brain clearly hasn't been working the last few days, lol.