I got it figured out. IOT interface was not set in Network Interfaces in DNS Resolver. Although it doesn't explain why some devices on IOT could still access internet. Maybe they had cached info.

I can redo the Reject rule to go before Allow.

Many thanks to all for helping out!

Perhaps this may help someone in future, I made 2 changes to my network and things have been very stable with Instagram and IPv6.

Router Advertisements for the WLAN VLAN changed to Unmanaged.
If you have an access point that is on a tagged VLAN, check IGMP snooping is not blocking IPv6 multicast. On my edge switch, this command was the trick for my AP that was tagged.

(UBNT EdgeSwitch) #config (UBNT EdgeSwitch) (Config)#set mld

This by no means will work for everyone but it sure seems to have resolved my issue.

Glad you got it sorted!

grateful to you. for your help

If it makes any difference, I have Unbound in Resolver mode. I specified the Network Interfaces and Outgoing Network Interfaces. After disabling the DSL interface (OPT1WAN2), changing those 2 interface settings to both read "ALL", and re-enabling the interface the problem seems to have stopped. I'll check again in the morning but that seems...odd...to me.

@Cool_Corona Sounds good. In the future it may just be as simple as stopping the boot cycle and running fsck just to verify the file system. At 6GB I would think it would only take a few seconds. If you haven't done it before read up on it. The process is quite simple and quick. That way you may be able to save yourself some time in the future. Another possibility is that the file system was mounted as read-only instead of read-write. Anyway, glad you got it back up and running.

While it should be OK, it is safer to run it from a shell prompt (console or ssh) and not via the GUI.

Found a solution.. I got caught up on why the last DCHPDISCOVER logged the hostname of A with the MAC of B.

This ended up being because of the client identifier in the DHCP request. The requests still had the proper, unique hostnames, but the Ubuntu template image I was deploying the VMs from actually send /etc/machine-id as the client ID. Since this was defined in the template, the DHCP server was identifying the machines as the same image with different MACs. This is the default behavior for Ubuntu 18.04 onward.

This blog post pointed out that zeroing out that file in the template (truncate -s 0 /etc/machine-id) will ensure a new ID is created when the cloned template boots. Alternatively, enabling the Ignore client identifiers option in pfSense's DHCP server settings will accomplish the same result.

@bjk002 said in DNS Resolver - DHCP registration - Multiple Interfaces - not registering in DNS:

not allowing DHCP to occur across interfaces.

What? Sorry but no..

For what it's worth. I wasn't able to catch what was happening in any log. However, that could be partially due to not setting it up correctly. Though I wanted to comeback and say that, at least for my hardware, I'm running a G4400 and disabled one of the cores which so far seems to have alleviated the issue.

Hi,

Read https://nlnetlabs.nl/documentation/unbound/unbound.conf/
and also, have a look at the pfSense unbound.conf in /var/unbound/

The thing is - line 14 :

use-syslog: yes

which, according to the unbound manual, overrides settings like : logfile
See, for example, here : https://snippets.khromov.se/enable-logging-of-dns-queries-in-unbound-dns-resolver/ - the usage of "logfile".

So everything will get send to the syslog, and wind up in the circular 'resolver.log' file.

Yep, confirmed :

[2.4.5-RELEASE][root@priv.brit-hotel-fumel.net]/root: host 1.1.1.1 1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.

x3rl ? wasn't that also a domain name that vanished from the Internet a couple of days ago ?

edit : yep https://forum.netgate.com/topic/153717/dns-resolver-issues

Answer : restart Unbound / the Resolver and the cache will be gone.
Might be a solution for you, but a problem for us all.

Btw : call your ISP and have them doing the same thing.
You are using 8.8.8.8 (or others) ? Call them to dump their cache also.
Etc.

Note : the latter two might not be willing to do so ....

Hi,

root servers are used to prime the tld part, like "gime a server that knows about dot com ?!"
With the answer coming back, the Resolver will question that server, and ask where are the name servers of google.com ?!".
With that answer coming back, the Resolver will question one of these name servers of google.com, and ask : "gime the A or AAAA records of google.com ?!"
After all, these name servers of google.com are the only ones that the ones that can be trusted to answer that question.
root server do not cache every possible zone (domain info) of the planet earth. They couldn't do that.

So, yes, it's normal that you see many DNS servers being used.
VPN or not, "DNS" doesn't chance.

Example : ask if a root server - let's take 'a') knows the IPv4 of the domain forum.netgate.com :

dig @a.root-servers.net forum.netgate.com A +short

It can't ....
It will tell you where to find the guys that know all about dot com zones.
Etc.

@ipeetables said in Enabled DoT but still see 53:

imgur is blocked at work

You're not the only one.

@amrogers3 : you can paste image right into the forum message. No need to paste in an image URL using the picture foru command at all :


Just hit Ctrl V when the forum edit window is in focus, if you have the image copied just before.

Hi,
I have the same issue. i have modified an interface group of 3 physicals interface into 1 Bridge interface (LanThomas Assignements).

With my interface group (LAN + OPT2 + OPT1) the configuration (IP and DHCP) was on the interface LAN

With my actual bridge configuration LanThomas (LAN + OPT1 + OPT2) the configuration (IP and DHCP) is on the Interface that i have configure on assignments.

As you can see on the DHCP leases the DHCP has some configuration on the old Interface LAN instead of the bridge interface (LanThomas).

xaeeUmEvXr.png

ZFkDXswEev.png

Hi,

Do a more general DNS check for that domain. Or even the www subdomain.

Use a tool like https://www.zonemaster.net/domain_check - and that domain, and one that you it exists - liek your own web site.

Its close to non-existent. Or the domain name maintainer has some DNS issues. Maybe he forget to renew the domain rent ?

So yes, pihole and pfSense can't make something from nothing ;)