@cjbujold That isn't much information to deal with.

are you running the forwarder or resolver? if it's the resolver, do you actually resolve or have the option for forwarding active? are you forwarding to a secure service (DoT)? why do you have that much DNS servers configured? what is the setting in System/General about DNS servers and fallback strategy? how is the forwarder/resolver configured? are multiple WANs in play? how about host/domain overrides and what is your configured domain in System/General? does your DHCP server advertise a domain and domain search list?

DNS resolution may be slow for some domains or all, that depends on a lot of things. If the resolver is in use and it is slow for some domains but not for others - that's the internet. The DNS resolver is completely resolving the way to the upstream DNS server of that domain e.g. blah.example.com would mean it needs to head over to the ROOTs for .com, then to a .com nameserver for example.com and then ask the nameserver for example.com whoTF is blah.example.com. That's the complete tree and how resolving is done. That can result in the first query as slow but the subsequent calls are cached and therefore very fast. The other point is if a DNS forwarder is down or (geo)blocking or censuring, you completely ignore that as unbound will resolve the domain via the ROOTs, the domain etc. and ask the authoritative nameserver of the domain itself after the IP. Not a big forwarder that can be altered.

If you do forwarding all calls are forwarded to those name servers you've listed in the screenshot. That may be a bit faster but you send all DNS traffic that way. If they are down - you are down (have no resolution). Multiple servers may help but often DNS calls aren't working in parallel (or not very good) so if the first or both first and second forwarders are down or VERY slow, you'll often be stranded.

The localhost entry may also be slow if MultiWAN is in play and you have problems switching between the uplinks or is flapping etc. etc.

So as said, there can be many thing afoot that can play into slow resolution. Even windows itself can play a stupid part in it. If you have multiple domains in your Windows search path, Windows tries those first adding it to every DNS call. So you ask "blah.example.com" and have a search path of "my.local.home" and Windows stupidly asks your DNS for "blah.example.com.my.local.home"! - getting nothing but creating a question for the upstream DNS, then even asks for "blah.example.com.local.home" (parent domain) before asking about the correct. All that useless questions add up and make DNS resolution slow. So one can add a few lines to unbounds configuration and add/change it from transparent mode to static so it won't relay those useless questions to upstream DNS servers but immediatly reply with "nope!" and not waste much time.

So perhaps that can already shed some light into internals until you can add a few more info tidbits :)

Cheers

@steveits said in Namecheap Dynamic DNS seems to be broken again:

@occamsrazor said in Namecheap Dynamic DNS seems to be broken again:

why do the existing Namecheap dyndns services I set up long ago still work fine, and it's only the new one I created recently that has the issue

If you look at your system log does it actually succeed? Or are you assuming it's working because it's green? :) I have a daily 1am entry with "Unknown Response." I suspect (without looking) that "Unknown Response" != "fail" in the code...? If the IP didn't change no one would know it was failing.

You could be right on that. My IP never actually changes (!) these DDNS services are really just in case it does. See my post here:
https://forum.netgate.com/topic/173646/namecheap-dynamic-dns-seems-to-be-broken-again/9?_=1667925480997

No, with the existing ones I still get "unknown response" but then I DO get a "Configuration Change" message. With the new ones I don't get that. I'm not sure what it all means.

@gertjan @johnpoz @viragomann @SteveITS I seem to have fixed the issue over the weekend. I am not sure what was wrong but re-installing with the newest version allowed me to use the DNS Resolver. I was using an older version. But installing with 2.6.0 fixed the issue for me. I did notice, however, that when rebooting with the older version, the DNS Resolver service was taking a while to start up. I never actually chekced the services running on the router so its possible that the service was just not able to start. I did "Restart" the service through the Web GUI a few times and it never gave me any indication that it didn't work. Its possible the service was not actually started or in a hung state. Thanks for all your help though, really appreciate all the responses!

Just a quick update on this, over this last weekend, I finally implemented pfSense with the forwarding of DNS/DHCP to one of my Linux systems where I configured the DHCP with static IP assignments, and to my initial shock, I got everything right and everything is "just working".

Thanks for the information and pointers on how to get this configured.

Now to figure out how to get the hostnames I have configured in the DHCP static assignments to populate instead of the hostname that the devices are reporting...

@dominikhoffmann You're welcome.

@markn6262 Not defensive just stating facts.. If you setup dns, any dns be unbound, be bind, be powerdns, be dnsmasq.. And you clients ask it and it gives the answer you put in. But then something else gets some other answer - then is blatantly obvious this other thing isn't asking it..

Unless you on purpose setup a view, which if you had - you would of known you did this.

Maybe you are just unaware of the goal of these apps and browsers and even OSes to bypass what you tell it to use for dns, and use them, or their partners via doh..

But you set something to give X back as an answer when you ask for some fqdn, and you don't get that answer - and other things that do get the answer you put in. Not sure what sort of snake needs to bite you on the nose for you to see that you didn't ask the thing you setup..

the first answer to you question telling you this

many browsers and devices use DNS over HTTPS (DoH) and bypass local DNS servers by default, nowadays.

You then stated

One mobile device gets a reply to pings and routes from the Lan gateway and the other mobile device gets a reply from the Wan gateway

This clearly shows that your whatever is not asking unbound.. If other devices that ask it get what you put in.

The is no need to "troubleshoot" your setup, if clients get what you put in, then what you put in is working. You can look around, this is not a uncommon issue where users whatever was using doh for the reason they were not getting the expected answer they put in.

@gertjan Thanks a lot for the detailed feedback. I will try that, as soon as I can. I have now experienced the same problem on a total other network, so this points at MacOs network as the problem. Will test and get back.

Thanks again

@gertjan said in Batch-force DynDNS updates for all accounts?:

Or execute
/etc/rc.dyndns.update all

Thanks man, that is a life saver!

@gertjan said in Batch-force DynDNS updates for all accounts?:

Also : this is a must-have : install the pfSense cron package.

Yeah, I had done that already.

@gertjan said in Batch-force DynDNS updates for all accounts?:

You see that one minute past every day the same script is used :

Add (do not modify the cron entry that already exists) another one :

Well, I had modified the original entry so that it would check every fifteen minutes, but I had made a mistake to the effect that it only checked every fifteen minutes during the first hour of the day.

You example helped me identify this mistake. Hopefully the updating will now take place more regularly.

In that context: Do you happen to know whether the client checks, if the IP has actually changed before it posts the IP address to the nameservers? Or will it always post the current IP no matter whether this is necessary or not?

Thanks again, you saved my day!

My last post should read version 2.5.1 and 2.6.0 (not 4.5.1 and 4.6.0)

I kept at this and finally figured out a way to make it work. I had to add this to Domain Overrides:

in-addr.arpa 8.8.8.8

Because we use Active Directory at some locations, I may also need to check "Do not forward private reverse lookups" or add overrides for the local IPs we use for AD.

I would love to know why this fixes the problem. What IPs is pfSense doing reverse lookups on for the Update and ACB features?

@sensewolf said in Dynamic DNS update failing every couple of days:

How can I debug this?

By setting :

93ea0a15-1e20-4aa2-8a69-3ace97791b4d-image.png

and now the resulting logs will be more verbose.

Normally, when you set up a dyndns entry, you have to select an interface :

7d36557b-eeba-4c5b-923f-42ab3e41c0cf-image.png

so, when pfsense tests this interface for the 'real' WAN' ip, it uses

3015d53d-4dd0-404d-959a-698d8b2adcde-image.png

http://checkip.dyndns.org

You can 'see' it doing so in the logs.

The thing is, I'm a 'solo WAN guy' so I don't know what it is to have more then one WAN.
As you have to select a WAN type interface in the dyndns settings, it should use the right one to use.
But when you group them up : what happens ??

Thank you for the reply, greatly appreciated.👍

It seems that pfsense has a BIND package. I might see how I can get BIND running with views and use BIND as a forward only DNS server with a pair of views.

@gertjan Thank you my friend.

with openvpn remote access tunnels, I'm using the default "OpenVPN" ta for firewall rules, so i don't have to assign interfaces for each remote access tunnel.
I have to assign interfaces for site to site only.

I get the DNS working for remote clients by pushing a DNS server the IP of pfsense. Assuming that the firewall can perform the forwarding succesfully, remote users have a routing to LAN, but not DNS or internet gateway. (We have used VPN only for remote access to servers).

So under advanced client settings in Open VPN Server configuration, i just push a DNS server, the pfsense address, like below:

b8472410-f012-4133-a21e-54860390c989-image.png

Simple thing but i didn't knew that , because i never needed that until today.

@munchie
The OP was using earlier pfSense version.
What is your version ?
What does your /var/unbound/root.key contain ?

During boot, look at the the console, any non normal messages ?

Btw : this root.key is the DNSSEC root key. It can change upstream, that that would be extremely rare.
It is updated regularly, and the time stamps in the file reflect this.
pfSense should use the exact time. This is mandatory, for DNSSEC to work.

@nan0tech this thread is quite old.. the no AAAA thing is now here for easy consumption

noaaaa.jpg

Per @bruor comment.. I find pictures are easier for some users.

@zinder a 60 second TTL on their nameservers.. That is nuts!!! And then you can see doing a directed query to the server at 1 point works, and then another time fails with the server responding with error for its own domain its authoritative for.

Maybe they are working through a problem? But as you can see from that link, even when working their dnssec has issues.. If you know someone that manages that dns for them.. Yeah have them check out that link..

If your not going to do dnssec correctly - then you shouldn't be doing it..

edit: just checked on this - both of their NS are failing right now. 10/29 5:45 CDT

It appears that Apple has added adaptive DNS to Ventura. I'm seeing these queries on my network since upgrading two Mac's to Ventura.