@johnpoz: While I will be first to admit to the point of having to forget ipv4 when thinking about ipv6.. It really is a whole new ball game.  But to me a ULA is not same as link local, link local does not route across L2 boundaries, while a ULA can.. ULA is more like ipv4 rfc1918 address.  You can route it across your local private network all you want - but the addresses do not route across the global network. And I will also admit I have not spent much time working/playing or even investigating ULA.. Will for sure take a look at the rfc linked too.  How does the device determine that it should use its global vs its ULA address.  I assume it could think well the dest address is global so use a global address, oh the address is ula so use my ula address would be my guess at it.  But again will admit I have not investigated that sort of scenario.  This points directly to your good statement of "IPv4 network there is no source address selection mechanism" I had not run into a scenario where you could just not use your global IPv6 address across the board..  Both for internal local networks and global access.. ULAs are used pretty much the same as RFC1918 addresses and, as you say, they're routeable but not to the Internet.  One thing I spend a lot of time doing is using Wireshark to see exactly what's happening on the wire.  When choosing between GUA and ULA, if you provide a ULA address, then that's what will be used.  Basic routing rules etc.  IPv4 and IPv6 link local addresses are similar in that they are confined to the local link (I guess that's why they're called "link local".  ;) ) While I have experimented with IPv4 link local, the only use I've ever had for it is with my TP Link switch I mentioned in the other thread.  I configured it with a static link local address (yeah, I know that violates the RFC) so that when I use the switch to monitor a circuit, it won't send out frames that might interfere with the network.  The computer runs duplicate address detection when first connected to the switch and keeps quiet after that.  So, I connect to the switch first and then connect the switch into the circuit. I also have TP Link's version of spanning tree turned off, for the same reason.

Alright, found this ticket and believe my issue is related… https://redmine.pfsense.org/issues/7145

What happens if you assign a static IP for your device?

I am going to try and increase the lease time on DHCP, found it was set to 2 hours.

Update: bind was causing the problem.  I had installed the bind package, and somehow bind was running even though I didn't turn on the service,. Solution: uninstall bind. Not sure why bind was running.  I didn't have the time to debug that problem, so the uninstallation worked and everything is fine now. Thanks for the pointers.

Yes, thank you. I fell also into this trap. Default Address Space was /32 and I didn´t see it. Trying and searching for 4 hours…

First :  Disable DNS Forwarder Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall Do not check that - enable the (local) DNS Resolver (or forwarder). No DNS means : no resolving (as you already found out). @trinitech: …. However, If I emable the captive portal on the DMZ interface, I loose all access to the internet and I cannot ping google anymore.. ..... and then : @trinitech: The CP has no authentification for now as I want to get the basic to work first so in affect the only box that is ticked on the CP page is 'Enable Captive Portal' Note : NO AUTHENTIFICATION => Nothings passes through (except DNS - but that was broken ;) ).

So nothing to do with 2.3.4. OK.

I had a similar problem when I was running 2.3.3, upgraded to 2.3.4, seems to have fixed the issue so far.  There are some entries in the release notes about DNS Resolver, but nothing specific to this.  Also installed service watchdog just in case.

@johnpoz: "If it doesn't support ipv6 on windows" It does support ipv6 on windows - nobody ever said it didn't - there is just a bug currently with it pulling the IPv6 address from windows with the -6 option.  As you saw I could query pfsense via ipv6 with it no problem just using @ipv6 address is all. Your issue would of been easy to figure out of you could of just done some basic troubleshooting.. if it quacks like its stupid, and walks like its stupid and walks like its stupid - its most likely stupid ;)  Sorry just couldn't help myself after you started the quack nonsense after doing zero actual troubleshooting to the problem as presented!!! I misread your post about getting dig to work on windows, so I stand corrected about that. However, with regards to your "zero actual troubleshooting" remark, I'm still without words that wouldn't get me banned…

I am not sure what that media player uses, is using dlna or plex's gdm? Not sure why its not about plex ;)  Your wanting to watch your media from your plex are you not?  Across a subnet these discover protocols fail.  They are designed for your typical home network that is flat - one broadcast domain, ie 1 layer 2 network.. Trying to get it work is going to be PITA most of the time. The simple solution is to just go direct to the plex server IP or fqdn and open the 32400 between the segments you want to allow to access.  This takes all of 10 seconds to setup, and works all the time, every time ;) If you don't want to do that - then just put the plex on the same L2 that your devices you want to "discover" it are on.

Your whole subnet could be static if that is what you wanted.  But need to know the size of your network, and do you want/need pool addresses at all? What size of subnet are you working with, how many actual clients in this network?

Hmmm, I tried that and set it to log but the traffic just goes out of the interfaces I have set in unfound

I believe ISC-DHCP-Server is limited to a single subnet per interface.

@kpa helped answer part of my question with this post (https://forum.pfsense.org/index.php?topic=132910.0) So to re-phrase: If the pfsense is behind another router/private network, will this prevent (or significantly delay) unbound from working? I have considered that it could be the Firewall rules on the higher-level pfsense, and permitted all access. However this still didn't fix the problem. To clarify the initial post: pfsenseA 192.168.2.1 (LAN)/192.168.1.2 (WAN) cannot resolve DNS pfsenseB 192.168.1.1 (LAN)/PPPoE with static Public IP (WAN) resolves DNS correctly (with same setup as 'A'). (The only obvious difference is that 'A' is running 2.4.0 on lower powered hardware) Many thanks.