Understanding DNS & DDNS

Sorry to bring this up again…

I am trying to use the FQDN that I set up in the DDNS to connect to my VPN server. But it seems to resolve to some other address than my WAN IP.

I set up the DDNS service to use Cloudflare API. I created a Token API with Zone Zone Read & Zone DNS Edit permissions. I also added an A record in my public DNS called home.domain.net. I manually changed the public DNS to be some random IP. Then I did a Save and Force Update on my DDNS in OPNsense and it correctly updated my WAN IP for the A record in Cloudflare. So that part works…

However, when I try to nslookup the FQDN using Unbound as the name server, I get a different IP

NOTE: I have changed all public IPs in the below logs to hide my domain name as it’s personally identifiable

[~]── - nslookup home.domain.net 192.168.1.1               
Server:		192.168.1.1
Address:	192.168.1.1#53
Non-authoritative answer:
Name:	home.domain.net
Address: 101.87.98.110
Name:	home.domain.net
Address: 172.33.25.119
Name:	home.domain.net
Address: 2606:4700:zzzz::yyyy:ab77
Name:	home.domain.net
Address: 2606:4700:wwww::xxxx:1d6e

[~]── -

If I try it again say with Google’s DNS server, it will give me the other address that is listed :

[~]── - nslookup home.domain.net 8.8.8.8                  
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	home.domain.net
Address: 172.33.25.119
Name:	home.domain.net
Address: 101.87.98.110
Name:	home.domain.net
Address: 2606:4700:zzzz::yyyy:ab77
Name:	home.domain.net
Address: 2606:4700:wwww::xxxx:1d6e

[~]── -

and it keeps switching between these 2 IPv4 addresses

When I try to ping the FQDN, it gives me the same result:

[~]── - ping -c2 home.domain.net
PING home.domain.net (172.33.25.119) 56(84) bytes of data.
64 bytes from 172.33.25.119 (172.33.25.119): icmp_seq=1 ttl=59 time=16.2 ms
64 bytes from 172.33.25.119 (172.33.25.119): icmp_seq=2 ttl=59 time=16.8 ms

--- home.domain.net ping statistics ---
[~]── -

Pinging again will sometimes give me the 172.33 address and at other times will give me the 101.87 address. But neither one is my actual WAN IP. So when I try to use home.domain.net as the FQDN to connect to (in the OpenVPN Connect app) it tries to connect to the IPv6 address which eventually times out.

I get the same IPs with the dig command, never my WAN IP.

How would I make sure that I can connect to my WAN IP and thereby my VPN server using the FQDN (home.domain.net) that I set up in the DDNS service?

What DNS servers do you have setup for forwarding? Or is Unbound checking with the root hint servers? Those are pretty slow for updates sometimes.

If you login to Cloudflare and check the A record, is it updated to the correct IP? If so, you may have to play the waiting game, or it might be possible to flush Unbound’s cache.

None. I am using Unbound as a resolver only. No forwarding.

It is. In fact, I actually set the A record to point to a RFC1918 address. Then enabled the DDNS service from Opnsense and it instantly updated the A record with my WAN IP. I guess I will wait and see if it works. Would it take that long to work each time my IP changes? If so, that sort of defeats the purpose because my VPN would be inaccessible for quite some time each time my WAN IP changes.

The TTL on DNS updates can be up to 48 hours, especially if you’re running your own recursive DNS server. Cloudflare’s 1.1.1.1 usually updates almost immediately and is what I use for my primary. Root hints take a bit to update. Keep in mine that would really only effect you internally, externally you’re likely to pull from DNS that updates more quickly.

1 Like

Ok. I’ll try again in a couple of days and update this post.

I am still trying to understand why it keeps toggling between 2 IPv4 and 2 IPv6 addresses? Why 2 of each?

EDIT: I deleted all DNS entries in the public DNS. Then purged the cache using the Purge everything option in Cloudflare–>Caching. Then waited a few minutes and checked nslookup which didn’t find any entries for home.domain.com. Then I re-added the A record using DNS only instead of Proxied, forced update the DDNS service. This correctly updated the DNS entry with my WAN IP. Tested again using the nslookup command and was finally able to resolve to my WAN IP

There might have been some lingering entries from previous attempts. Also, DNS is a fickle thing. Works great when configured correctly. Not so great if not.

Probably. /shrug

Thanks again for all the help that you gave me. It sure cleared up quite a few DNS related things in my head. Although some questions persist…

Yeah it got a bit derailed - if you have any specific questions let me know :slight_smile: DNS can be a bear to wrap your head around with some aspects