BTW i am using 2.3.4

I figured this out. In my TLD I'm blocking "arpa"…so when unbound tries to "validate" the TLD's I guess it gets blocked form doing a reverse lookup and it returns a block on the reverse lookup because it ends in ".arpa" LOL. I'll have to remove .arpa from my TLD block I guess.  I don't want to though.  If you're doing local DNS resolution for reverse lookups it will work because it'll look at your local servers for the answer and they'll answer it...they won't ever ask unbound on PFSense for this answer.  You'd only have a problem with the .arpa TLD if you used PFSense / Unbound as your sole DNS server.  That's not my case. Thanks!  Hope this helps someone!

What you're probably not aware of is that the system uses the so called "stub resolver" *) for the DNS resolution of locally running services and applications and this stub resolver only forwards to the name servers specified in /etc/resolv.conf, it can't do resolution on its own. The DNS forwarder or the DNS resolver services are completely separate to this and can be used as one of the forwarders specified in /etc/resolv.conf, the 127.0.0.1 entry is just for that. Whatever the DNS forwarder or DNS resolver services do to actually resolve the queries is a separate matter and querying of roots and so on or forwarding the queries to let's say Google's forwarders is done independently of the system's own stub resolver. The LAN clients that use the pfSense's DNS services connect directly to the DNS forwarder or resolver, they don't connect to the stub resolver. *) https://www.freebsd.org/cgi/man.cgi?query=resolver&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

For posterity, it looks like the last patch in that redmine bug made it into 2.3.4_1. My last post said our router only logged one "waiting" message but since then I've seen days where it logs a dozen, give or take, so it varies due to something.  I think the 30 second loop should be long enough though.

It seems others are having the same issue. https://forum.pfsense.org/index.php?topic=108531.0 I'm wondering if it's a timing issue from the cable/dsl modem coming on line and being able to issue an IP address and the appliance. If its a major issue and you have the capability you could try delaying the boot of the router by 30 seconds or something like that to give the modem time to book and connect.

@ink: I (re)wrote most of the r53.class that appears in 2.3.4 and at the moment it only supports IPv4 addresses. Adjusting the code to support AAAA records is the setting of a variable instead of a hard-coded A. The real work is all of the hooks into dyndns.class to support a Route53 IPv6 flavor, which is work that hasn't been done yet. I was thinking about doing it, but haven't had the time yet. That explains it, thank you.  At least that means I am not doing something wrong.

Did you ever figure what was causing this. I have the same problem. Charter Internet cable modem. On a power failure no DCHP from cable modem. Not sure about the blacklist thing as it takes me more than 2 hours to get to the device. When I do I power down cable modem and firewall. Wait for modem to boot up and connect to network then power up firewall. It gets DHCP address.

The purpose of not showing a REAL IP is to provide my customer with some discretion.  That is why I provided the info the way I did.  Nonetheless, I found out it is how Verizon Wireless provides IP spacing to customers.  Similar to an MPLS by providing a WAN/LAN space for routing.  Still they do not allow for inbound connectivity.  A VPN service must be used.  Cradlepoint now offers a cloud service we are going to try.  Thanks.

they are to show dns lookup response times so with this data [49264:0] info:    0.065536    0.131072 1 [49264:0] info:    0.032768    0.065536 28 [49264:0] info:    0.065536    0.131072 22 1 lookup took in between 65ms and 131ms 28 lookups took up in between 32ms and 65ms 22 lookups took in between 65 and 131ms you will get stats for each thread, it is very useful information.

@johnpoz: "(including the DNS Forwarder/DNS Resolver)." No the resolve will not use what is in general unless you set it to forward mode. Not sure where you go the idea its better for pfsense to use public dns set by hand or by your wan. If you use resolver out of the box it will list 127.0.0.1 first, itself - in the case the resolver fails then pfsense could use what you got from your isp or what you set for dns..  I don't see this as having a point.. If your going to use the resolver then it should resolve and pfsense should use it - end of story.  There would be zero reason to allow dns to be set by dhcp for pfsense.  It has no use.  If your going to use the forwarder then that is what will get forwarded too, or turn if off and setup your own public to be forwarded too.  Dhcp on pfsense will default to send clients to talk to it for dns, then it forwards to what is set in general be it by hand or by upstream dhcp on its wan. Where did I say that "I" thought it was better for pfsense to use the dns "set by hand or by your wan"? All I did was point out that the default in general setup is to allow dns servers to be overridden by the wan dhcp. Presumably, this is the default either because someone thought it should be or erroneously, which is why I asked. You seem to be confirming what I thought, which is it's the latter.

that is exactly what rebind protection does.. To the forwarder getting back a rfc1918 from something it forwarded to (normal public domain) would be a rebind attack.  If you want to forward to an internal dns that will return rfc1918 then either turn off rebind protection or set the domain your doing to query for as private. https://doc.pfsense.org/index.php/DNS_Rebinding_Protections If your using forwarder rebind-domain-ok=/mydomain.com/ Using resolver unbound server: private-domain: "example.com"

Oh hey! I was able to fix it. I'm really not sure how i missed it, but i now have added a server: line above my_blocks It now reads as server: local-data: "www.SomeHostToBlock.com. A 127.0.0.1" I no longer need to have web hosts overridden through the webUI :)

I just changed that, but the address fields still appear on the DHCPv6 tab.

That is correct.

I was able to figure out what was wrong. I had been using my own account, i.e. not admin, so I got hit with a new permission. I found that there was a permission applied called "User - Config: Deny Config Write" which is described as "If present, ignores requests from this user to write config.xml." Personally, I think an error message of some sort would be more helpful than silently ignoring the change. I was thinking this was a DHCP service configuration issue, but it is broader than that. According to this posting: https://forum.pfsense.org/index.php?topic=119244.0, this permission was already present, there was a bug in previous version of pfSense that had not enforced it on LDAP accounts.

How exactly did you do that, pfsense does not allow you to create reservations for IPs "inside" the pool range.. [image: dhcpreservation.png] [image: dhcpreservation.png_thumb]