@Gertjan Thank you for your response. I tested with the custom options as you suggested, but it gave me the same results as previously with domain overrides.

I realised however what the problem was - the CNAME in question was pointing to a completely different domain (a DNS name of an ALB in AWS). I first confirmed that CNAMEs pointing to records within the same domain do actually resolve correctly. Adding another override for the domain of the ALB resolved the problem for me.

@viragomann Once again thanks for the kind help!! I got my question solved, I gave a thumbs up to both of you, and I guess this marks the question as solved:)

@Gawzirabaws said in Unbound Not Resolving ANYTHING:

sadly i guess i cannot access any of the zero domains known to me with their authoritative nameservers only available via ip6

I guess these exist only for testing purposes.

i was having similar symptoms for months after an isp change. elusive, intermittent failures. certain sites faring well, others almost unusable. then a day later, seemingly random redistribution of problematic sites and working sites.

figured out my isp was handing out ip6 and ip4 addresses to dhcp clients, while only allowing port 53 traffic over ip4 for some ungodly reason.

SOLVED: putting "do-ip6: no" in unbound.conf cleared everything right up. AAAA records still come back but everything port 53 up and downstream of my resolver now happens over ip4.

sadly i guess i cannot access any of the zero domains known to me with their authoritative nameservers only available via ip6 unless i use my isps cache (lazy bums actually only offer up google's in the dhcp response anyway; no thank you)

@Gertjan all good, screw ACME i just signed a cert myself and works fine

@johnpoz

Q. where are you seeing this??

I'm actually see that in Graylog but the source of the data is pfSense / pfblocker Unified log, sent in real time. The data is not wrong, I was just trying to clarify the distinction of those named resolver. Sample screen shot of the log file on pfSense

Screen Shot 2024-08-29 at 6.35.57 PM.png

Q. And your forwarding in unbound.
Yes, I'm forwarding in unbound.

Q. What are you doing a query for? microsoft - from where??
A1. for microsoft.com (but it could be and is anything)
A2. in this case from the pfSense box with and without the server specified.

the response showing as resolver is the default dig microsoft.com the response is to and from 127 addresss and does a round trip next door (server in this reply shows as 127.0.0.1) the second screen capture with the reply/cache is simply dig microsoft.com (at)192.168.0.1 The responding server is just that 192.168.0.1 which is what clients would hit. in this case only the reply caused a query next door the other came from cache didn't even open the door.

Q. Where are you seeing this log that says resolver in it???
A. see first answer unless you mean something else.

Statement: there is no different between asking loopback or the IP unbound is listening on.
A. clearly there is

unbound-control -c /var/unbound/unbound.conf lookup forum.netgate.com The following name servers are used for lookup of....

and I said (and maybe not clearly enough) all of mine are

unbound-control -c /var/unbound/unbound.conf lookup sample_in_question "the following name servers are used for lookup of .... and it list the upstreams

the list of upstreams is different than the responding servers format you are showing.

so then
What I think the definition for the original question Resolver vs. Reply/Cache is:
when you specify a forward to (and maybe only if it is local) the query on the netgate with localhost (or 127.0.0.1) will always resolve by reaching upstream when the query is against itself on that interface and it reports that as "resolver" (perhaps because in the unified log 127.0.0.1 implies simply I'm going to resolved this, not questions asked about or regarding cache)

However when you hit the same unbound on the non-local IP (so 192.168.0.1) -- it says ah here is a query, let me look that up for you, I don't have it go upstream get it, cache the result- next query again = I have that in cache.

the dig structure as shown above is exactly the same except for explicit server on the 192.
no magic query or anything like that. The results are exactly the same except one says it came from 127.0.0.1 and the other from 192.168.0.1 -- queries against 127.0.0.1 in this setup are most assuredly going upstream every time (but I'm not worried about the response time) it's actual not any better or worse than those that return on 192.168.0.1 when it is asked and returns them via cache.

the only reason for the question in the first place was to determine the correct filters on the Graylog dashboard. Not really a question about the DNS query or answer. Just to confirm what the difference was. In talking to you and testing I okay with the answer what I think.

Screen Shot 2024-08-29 at 7.12.17 PM.png

As you can see the pfSense box, on its own does a bunch of queries by and for itself (so stuff running on the box, be that pretty much anything that hit 127.. (itself) of blocker, other stuff anything that runs their queries there.

the queries by and for clients is exactly that 55.1% go upstream and 38.6% are cache.
with the pfsense queries in there the numbers are wacked.

Clearly in this setup, I'm actually ok with the stuff to and from localhost being isolated and in fact talking upstream every time.. There is no issue with the performance and none of that pfsense dns traffic actually counts against a specific client IP anyway.. That is just the various pfsense bits doing their thing looking stuff up as they need to.

Even if my definition is wrong, and therefore based solely on the observation of what goes up and by whom, I'm really ok with the way it is working.

Thanks, even though you may not realize it a couple of things you said gave me some clues of things to look at. I needed that sounding board. So much appreciated.

@johnpoz Yes i removed pihole from the equation since i want using it for ad-blocking, just dns. Seems easier to just do that in pfsense with the previous suggestions.

@johnpoz I forgot to modify settings in my second dhcp pool I created some years ago ... 😕

Thanks for your help!

@linuxtechstuff Please could you tell me how you resolved this?
regards
cyber7

@ryan-goodfellow I am having what seems to be the same issue you had. Were you able to find the cause of your issue?

@thezfunk said in DNS Resolver Host Overrides:

When I attempt to use my domain internally, that's the problem.

With a browser - you sure your browser isn't using doh..

Host overrides are pretty straight forward, test with say nslookup or dig or any of the other tools to actually do a dns query. This will tell you if your host override is working or not.

If you query directly to pfsense IP and you don't get the answer you put in for host override then you didn't put in the host override correctly, etc..

But stuff not working in a browser - can pretty much tell you its because its using doh.. These browsers love to point you to them for dns, without really telling you they are doing it - you know for your own good < rolleyes>

Here - just created a test host override, and you can see pfsense (unbound) is answering the IP in I put in when I ask it.

hostover.jpg

@azdeltawye

tail -n 4 /var/db/dhclient.leases.ix3

😊

@Gertjan So I gave up and just reinstalled pfsense (after copying out the config.xml).
Everything started working fine without any changes.

Still not sure what happened. My over confidence in the reliability of my setup has gone down alot.

Thanks @hensiek

I had to change

OLD_IP=cat cache_ip.txt

by

OLD_IP="$(cat cache_ip.txt)"

And a 1st line with a "cd" to the directory where the script was.

Regards
Carlos

@Gertjan

Thanks, I tried to ping with another ISP (and router) and it works.

So I tried to ask my original ISP to look at the problem and at the moment it is still not solved .

@stgeorge said in DNS question:

understand what ::1 stands for?

To make things a bit more 'visible' : have a look at this file /etc/resolv.conf
Every OS - even microsoft windows, has that file.
Typically, it contains :

nameserver 127.0.0.1 nameserver ::1 search your-domain.tld

The first two come from here :
e48ac14a-a64d-44b7-b223-3ec12e8570b1-image.png

and the "search", third, line comes from here :
62e7cf8b-0872-4f00-b18d-c9bfb65b869b-image.png

Unbound, the resolver, listens on this 127.0.0.1 (= ancient IPv4 local host) or the more modern version (invented recently, somewhere around 2006 ^^), the IPv6 equivalent ::1 = also local host.

Now, for an example :
pfSense execute ones in a while a task that checks if there any updates / upgrades avaible.
Here it is :

c5aa7bf2-0bf3-4f98-a54e-d561c3d27b5f-image.png

This process will use a host name like 'pkg.pfsense.org' and as always, traffic over the Internet doesn't work with names like that. It wants IP addresses.
So, somewhere in 'pkg-static', the upgrade process, the host name 'pkg.pfsense.org' is converted (== resolve)= into an IP addresses. It could be an IPv4, or an IPv6 (Modern OSes like freebsd prefers IPv6), so our 'pkg-static' uses a system call gethost(), a function offered by FreeBSD**, and this gethost() function will use /etc/resolv.conf to find out where it can find a "DNS server" : it finds 127.0.0.1 or ::1, so it will contact this DNS server at that address, which is where our our unbound, running on the same system ( ! ) , is listening on 127.0.0.1 port 53 UDP and TCP.

Now, you'll say : hey, that seems fine, but rather complicated.
The bad news and the good news is : every device around you that uses an OS, so it might as well be your cigarette lighter, or light bulb, and also routers, your watch, PC's, phones, TVs and the list will be long ... uses exactly this method.
It was invented somewhere in the second half part of the last century, and never really never changed since.
So, all this isn't a pfSense thing. This way of handling of 'DNS' is done like this everywhere.

** more exact : a C system library I guess.

Just for info if someone has the same problems. I went back to ISC. I had more issues with leases not showing in the gui. Crash of kea but nothing in the log etc. So KEA has some years still in pfsense before i go back...

@johnpoz John, I feel your pain. Wording manuals and designing UIs is indeed hard. I've been doing it for almost half a century professionally.

I think many pfSense users are pros, but others are learning as they go. Based on some of the questions I see you respond to, some don't really understand their own setups. The docs are generally good and so some people are literally learning networking as they go. As a result, I think you have readers that span a pretty wide range.

The suggestions I made above are made in that spirit: tiny tweaks that don't add length, but may help to close off some inadvertent blind alleys by making the language just a tad more precise.