@johnpoz: What I am here for ;)  So can you not resolve your machine by its fully qualified name.  Did you get your host override setup? Setup and working fine!  Now, if I can just figure out how to set FQDN for my RPi's, I'm golden!

You have some logs as showed above ?

The best answer (for the moment) is to use an external switch. +1

Yeah that sort of use at 30$ would be well worth it.  Its not a bad little switch for home/lab use and the money.  Seems to be made nice, metal case and all.  And it hasn't flaked out on me as of yet.  Had an old netgear gs108t(v1) that now and then would just loose its config.. I grabbed both the netgear gs108e and the tplink sg108e to test with and know how they work since they seem to be very common here on the forums.  So it helps in being able to actually test and see the interface when users have questions. But wow are they lacking on features - vlans is about it.. Seems the zyxel line seems to be getting some play as well.  Might pick one of those up to have in the lab as well since they are also really reasonable priced and seem to have more features but only few dollars more.  Even the poe one is only like $70

Great glad could be of help.. I just set mine to b-node.. Little use of any of the other nodes.. But broadcast still comes in handy now and then.  Normally default is H-node.. Unless your talking old school which use to default to b if I recall correctly - lot of years ago playing with this stuff.. Kind of walk down memory lane ;)

I took this paragrahp from https://tools.ietf.org/html/rfc2131 : DHCP defines a new 'client identifier' option that is used to pass an   explicit client identifier to a DHCP server.  This change eliminates   the overloading of the 'chaddr' field in BOOTP messages, where   'chaddr' is used both as a hardware address for transmission of BOOTP   reply messages and as a client identifier.  The 'client identifier'   is an opaque key, not to be interpreted by the server; for example,   the 'client identifier' may contain a hardware address, identical to   the contents of the 'chaddr' field, or it may contain another type of   identifier, such as a DNS name.  The 'client identifier' chosen by a   DHCP client MUST be unique to that client within the subnet to which   the client is attached. If the client uses a 'client identifier' in   one message, it MUST use that same identifier in all subsequent   messages, to ensure that all servers correctly identify the client.

@jpns: Great, I see the pull request has been approved too, does that mean the fix will make it into the next update? I rely quite heavily on this feature working properly, so it would be great if it is  8) That's a good question, but I imagine it'd probably be in the next point release or update. Since it's the first time I've contributed to the development of pfSense in any fashion, I have no idea how long it'll take to see this get bubbled up.

@tortue: Just to close the loop on my issue with Dynamic DNS, I found that some AWS services, Route53 being one of them, use a global scope for the region under the ZoneID. Which unfortunately is not the region I primarily deal with and had configured in pfSense. Once I updated the region in the ZoneID to us-east-1, the DDNS updated properly to R53 without errors. I was also getting the Route53 but now it is working. Thanks man

Looks like lots of people are having this problem: https://forum.pfsense.org/index.php?topic=131242.0

You could write some sort of script to run through your popular fqdn… I recall someone around here being obsessed with such nonsense. He was trying to load like 100's if not 1000's of them..  He posted his "solution" I do believe.. I don't see such a need, the difference between a cached lookup and none cached should be a few ms..  If your on a connection where doing a full lookup from roots down, ie resolving is so slow you have issues then maybe use of a forwarder is better suited for your connection.  Or manipulate the max and min ttls unbound works with.. What is the time to resolve your popular sites, vs a cached response..  Lets say its crazy 300ms to fully resolve.. Your talking .3 of second - how is that an issue?  Normally since NS and the tld servers are cached..  So you most likely only need to look up the actual A record from the authoritative NS anyway.  So what 30 ms vs the 1-3 ms from cache.  So .03 seconds ;)

Sorry to let this go for so long… the cause was due to DHCP server trying to register the clients in the zone, and it was locking up the .jnl file.  Restarting BIND after deleting the .jnl file was the solution (and turning off the attempt to auto-register things in DNS>

@johnpoz: You can assign a reservation but leave the IP blank so it will pull from pool but then you would have your description of the device via that mac address. I've tried this a few times but I can't get it to work.  I add a static entry with the hostname and mac address and leave the IP address blank.  Then I delete the existing dynamic lease for that host and when it comes back onto the list it has a new dynamic IP address while the static entry still has a blank IP address. Any thoughts?

yes you can check the clients if windows with ipconfig /all

Run this command to create an empty unbound include file: touch /var/unbound/pfb_dnsbl.conf

BBcan is right I really would just switch over to pfsense for your dns and dhcp.. But no you don't really need the full zone forwarded, 10.in-addr.arpa would be fine.

How are things working for you knebb? Any issues with this setup? So I actually tried this exact setup back in June of 2016 and things broke. I used dnsmasq (forwarder) for the internal network and then unbound (resolver) for the guests. But with my setup I actually had a couple of host overrides I needed for the quest side (access to a printer) and we have a ton of host overrides on the internal network. Problems came about because, at least back then, dnsmasq and unbound BOTH stored their host overrides in /etc/hosts. So I could start unbound first and things worked on guest. Then I could start dnsmasq and things worked on the internal network. But give it several hours (12-48) and they both start trampling on /etc/hosts and things break on one or both networks.