@lifeboy
I used alias type IP networks, @johnpoz already solved the mystery.

@gertjan said in Add description to DHCP Leases???:

so the MAC is a random string.

In my environment i have only older android and the mac is from hardware! Thanks for enlightenment!

solved: the culprit appears to be the resolvconf script (which resolvconf)

sha1sum /usr/sbin/resolvconf 4bfee7ac4e855ae48e35ab9ac37ebb8c2d37d210 /usr/sbin/resolvconf

I haven't had an unbound stop message since I commented out

#unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf

in /etc/resolvconf.conf, this on raspberry pi 3b, Raspberry Pi OS Lite, Release date: May 7th 2021.

You can read the full story here

summary of the events I noticed:

stop message in unbound: May 14 06:15:26 unbound[790:0] info: service stopped (unbound 1.13.1) matching syslog error : May 14 06:15:26 raspberrypi dhcpcd[562]: eth0: part of Router Advertisement expired setup monitoring in screen: sudo strace -tt -ffo /tmp/trace-unbound -e trace=%signal -p "pidof unbound" logging script in screen (the topic also describes a method using audit): #!/bin/bash file="/home/pi/ps-test.txt" while : do while IFS=" " read -r USER PID CPU MEM VSZ RSS TTY STAT START TIME COMMAND; do if ! grep -q "${PID}" "${file}"; then if [[ ( "${COMMAND}" != 'ps aux' ) && ( "${COMMAND}" != *"ps-test"* )]]; then echo "$(date),${PID},${COMMAND}" | sudo tee -a "${file}" fi fi done < <(ps aux) done

result in log:

Sun 30 May 18:48:15 CEST 2021,32610,/bin/sh /usr/sbin/resolvconf -a eth0.ra

commenting out the unbound entry in /etc/resolvconf.conf eliminates the unbound stops.

For the first time, since I started monitoring errors and warnings in my logs, the unbound log doesn't contain any errors / warnings.

OK, so i dsabled the DHCP server on the LAN interface, turned off the TV turner, turned on the pakcet capture with the interface Set to LAN and the MAC address of the tv turner and then turned on the tv turner. After about 30 seconds this is the only output i got

05:14:49.710584 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300

As you can see, not only the activity was minor but it happened at 05:14 am. The DHCP logs shows nothing after 05:06 am. This tells me that this tv turner is not requesting an IP address (just like the NEST that @KOM mentioned).

I also went to the arp table and, sure enough, there was the tv turner with the ip 10.0.0.10 saying it will expire in 371 seconds.
arptable.jpg

But, the device was not reachable when i tried to ping 10.0.0.10.
arptable2.jpg

Now, at this point i have not enabled the DHCP server yet, so that might have explained why it wasn't reachable.

Anyway, since the IP was supposed to expire in 371 seconds, i just waited 10 minutes to see what was going to happen. I started the package capture again, restarted the DHCP server and the results are as follows:

The package capture got nothing.
The DHCP logs showed that the tv turner requested a new IP and obtained the address 10.0.0.100 which is in the range of the DHCP server.
arptable3.jpg

Now the tv turner is obtaining its IP address from the PFSense's DHCP server as expected. I guess the only thing that i needed to do was to "bounce" the tv turner and disable/enable the DHCP server to fix this situation.

Thanks to all for the pointers on how to fix this.

@provels That is exactly what is happening. Thanks for the help.

Hi @cenal!
I am facing the exact same problem, could you please detail a bit more how you fixed it?
Regards.
Faustin

From what I have been reading esni will never become a viable thing.. ech is the current direction, will that ever come to fruition is anyone's guess.

either method esni or ech or whatever else might come about is really a major task. Because its not only the client that has to do it - its also every resource you would be going to.

Its kind of how dnssec has never really gone full mainstream, while its been about for years and years. It depends on the domain to implement it.. This is the problem - many domains don't do it, and then there are ones that do it - and borked it up in their implementation to the point its only causing them issues.

And every registrar is suppose to support dnssec for the tlds that support it to be accredited - but sadly this is not true.. There are many registrars that do not actually have anyway to start using dnssec with domains you have registered with them, or their implementation is so bad that makes it almost impossible for your average joe to jump through the hoops required to get it to function..

@mamsds said in Multiple Check IP Services:

do you mean by "These test[s] really can't fail."

As it is not a complicated thing.
Your browser does the same thing : "GET www.facebook.com".
This can fail, of course, but most often because he network is down or some other 'external' reason.

@mamsds said in Multiple Check IP Services:

Perhaps an IP checking service is discontinued for lack of funding

That's probably why pfSnse decided to surface the "Check IP Services" facility. The actually default "http://checkip.dyndns.org " might die tomorrow, breaking some functionalities on the firewall.

@mamsds said in Multiple Check IP Services:

returning a wrong IP.

The IP shown is the IP used to send the answer to.
You couldn't receive the result ;)

@mamsds said in Multiple Check IP Services:

part is irrelevant to my question

True.
I've was asking the same question to myself : what gets used when ? Is there an order ? So I created "the other side of the 'Check IP Service''" myself so I could monitor the requests coming from pfSense, thus answering my question.

@jgq85 I think that will work but it's always best to have Windows do your DNS and DHCP if your clients are using AD. Just use pfSense as a routing firewall and VPN remote site. Are you looking to move the existing building DC somewhere else? Otherwise I don't know why you wouldn't just connect the new building to the old one and the clients use the same old DC they always did with the least amount of disruption.

@gertjan said in Frequent restarts of both dhcpd and unbound:

dhcpd service restarts are less common.
Example : It (can) happen when interfaces are going down and up.

This really helped me find the underlying cause: an OpenVPN tunnel with a flaky server that would go away quite frequently. Disabling the OpenVPN client configuration solved the frequent resolver and dhcpd restarts.

Again, thank you for your help. Much appreciated!

@noesberger said in Wildcard with DNS Resolver (unbound) for local Domain:

warning: duplicate local-zone test.local.

Check the unbound.conf file yourself.
Your adding 'custom' lines, so its advisable to have a look at the entire file.
It's here : /var/unbound/unbound.conf

I've checked with :

cdf22d05-4873-4fc4-9652-be36b5c80d5a-image.png

and unbound is happy - no errors. And probably isn't what you want :
wildcard or the leading dot.

This doesn't work for me neither :

3935b644-e135-4a53-9b82-63f8e16f3615-image.png

Maybe

No, unbound is not an authoritative server, and doesn't have all the
authoritative DNS capabilities (you could run a real auth server and
point a stub-zone at it).

apples after all.

Note : https://lists.nlnetlabs.nl/pipermail/unbound-users/2009-April/000560.html and the answer.

@foreigner cool. nice find. You’re right, that seems rather heavy. I might have a look at the log parsers and see if I can rev. engineer some of them into a telegraf log parser format and into my existing influxdb. And replicate the kibana dashboards in grafana… when/if I can find time.

Though… not being on 2.5 yet, no resolver request fqdn/IPs in the dns log to grab anyway if I understand all this correctly.

Hi
I have seen several fellows having the same issue
Suddenly we loose internet connection

In my case after almost exactly 8 hrs of use, pfsense kicks me out of the internet, and I do need to restart my pfsense

I am trying the following:
Set up my modem to use a smaller DHCP range of IPs, and on pfsense I set up WAN interface with a static IP, outside of that range

I will see if that solves the problem, I am posting it before confirming that, if maybe it helps someone

Have a good time

@ofloo said in DNS Resolver not sure how to call it but to me just broken.:

sorry but dns rebind check means

I know what DNS rebind attack is ;)

This is my option : it's an anti shoot in the foot option.
To mitigate against a somewhat broken DNS situation (?).

@tman222 said in Options for Blocking DNS over HTTPS:

https://github.com/jpgpi250/piholemanual

Thank you, the lists by this guy seem to be well-maintained, and he's even written a detailed PDF tutorial to block access to DoH servers with floating rules for pfSense.

@lrs Under "Services > DNS Resolver > General Settings", the checkbox next to "DHCP Registration" was already unchecked on my routers.

@gertjan

As I am rethinking the strategy and at the same time researching pfSense I have second thoughts.
I read many users have issues post updates with pfSense and also Unbound issues starting up etc. I don't and what I have is pretty solid. I will take my time to evaluate pros and cons, but thanks for your input and answers.

-mark

I added that if-clause to dhcpd.conf again.

A QEMU-VM boots successfully with this setup.

A VirtualBox-VM does not.

Well I can not duplicate that.. So I again turned on just normal forwarding, no dot. No dnssec

You can see when I first query there is response time, then if query again response is zero -- because its cached.

cantdup.png

Asking unbound shouldn't have any signification additional latency.. Sure there could be few ms, and there is going to be deviation for any specific 1 off query, etc. But maybe when unbound asked whoever there was a delay in that response.

I suggest you sniff, and up your logging level.. And do more than just query of 1 fqdn.. Your going to have to do more testing to show that unbound is adding latency to that extent.. I think your seeing outlayers, or do not have a full picture of what is happening during the query.