@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 [image: 1724971013847-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. [image: 1724973192529-screen-shot-2024-08-29-at-7.12.17-pm-resized.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. [image: 1724788170681-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 : [image: 1724335192390-e48ac14a-a64d-44b7-b223-3ec12e8570b1-image.png] and the "search", third, line comes from here : [image: 1724335238779-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 : [image: 1724336105284-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.

@johnpoz You are right, pfsense box gets the public IP. I get internet directly from my pfsense box (wan) and share the internet over lan of pfsense. I don't do any interception at least by doing it on purpose. Reinstalling pfsense box fixed the issue about resolving domain/hostnames. Thank you... @Gertjan @johnpoz @SteveITS for your help. I wish, you all get help in the world that you live in more than you did!

@guybrush2k4 Long story short [image: 1724159796894-screenshot_2024-08-20-16-13-21-074-edit_com.realvnc.viewer.android.jpg] And then you see [image: 1724159938167-screenshot_2024-08-20-16-18-06-688-edit_com.realvnc.viewer.android.jpg]

@gkokkinis You've missed the very important Netgate Blog post. Read that first. Netgate Adds Kea DHCP to pfSense Plus Software Version 23.0 Now visit the pfSense GUI and read this one, as it is a follow up : [image: 1724149499383-8477993a-3a79-49c7-9485-fd2218ecdab3-image.png] As stated : this will be the future as 24.08 isn't out yet ... Now, look up the top 10 KEA post on the forum ... and you'll notice that KEA somewhat works, but no options, gadgets or special requests. It servers leases and doesn't take your needs into account. This will change in the future, of course. To make a long story short : don't use KEA, use ISC. KEA doesn't support "DHCP Static MAC leases" yet. @gkokkinis said in How can I automatically assign Kea DHCP leases to reservations?: the lease table is cleared and they all try to obtain another address in the pool range (subsequently getting a different IP than they were initially given) A device on a LAN will recognize a DHCP by its interface MAC addresses. If it already used that DHCP ones before, it will request for the 'prefered' IP, the IP it had before. That's why you see : [image: 1724149736022-2ef13369-2782-496d-8a19-3da879c2769a-image.png] This says that my PC wants to have 192.168.1.6, if possible. Even if the remove the lease file from the DHCP server- this file is actually the DHCP server's memory - the DHCP server will grant that request, if - only one condiotion - if that IP wasn't already assigned to some device.

@M0L50N - Update Just for info, If I switch back to ISC DHCP, everything works normally and I can update and start my DHCPD service ... When I was in Kea mode, I was unable to start Kea-DHCP4 service To be operationnal for tomorrow, I just forget the idea to change DHCP mode to Kea for now ... but if you have idea to help me diagnose this, this would be really appreciate! Thanks!

for clarification, on DHCP server -> GUEST (static IP 192.168.42.1) i set DNS servers : 192.168.42.1 Gateway: 192.168.42.1 Domain name: homelab.cu