In the GUI I have disabled  the logging checkbox, and in the named.conf I see this line: logging { category default { null; }; }; If I add my custom options, lines are added to named.conf but last lines is always logging { category default { null; }; }; and named fails to restart I don't understand how to force PFSENSE to add only my lines and not add its line at the end  :-\ :-\ :-\

This just came up the other day.. You can add multiple entries for a domain override and put as many ns you want for the domain.  If one does not answer the others will be asked, etc.  Let me see if can dig up the thread.. I just posted about it the other day. edit:  See the bottom part of my post here https://forum.pfsense.org/index.php?topic=136436.msg756393#msg756393 Gave example of point 2 entries for a specific domain, and even show attached sniff showing pfsense asking both NS listed in the domain override.

Yeah I actually figured out what happened. I had just set up a whole network VPN and the traffic between VLANs was being routed through the VPN link… lmao

Found this post looking for the same answer. I have the same person icon for one of my inactive leases. I also have no static mappings. In my case the icon appears on the only entry in my dhcpd.leases that is marked as abandoned. You've got several abandoned leases, none of which are even in your leases.conf file. No insight into what it all means, so I guess I'm equally confused.

You can get info directly from unbound about how it's resolving as well. Normal resolver mode example (I just looked up google.com): : unbound-control -c /var/unbound/unbound.conf dump_infra 216.239.34.10 google.com. ttl 894 ping 9 var 71 rtt 293 rto 293 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 2001:500:12::d0d . ttl 894 ping 0 var 94 rtt 376 rto 376 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 2001:503:d414::30 com. ttl 894 ping 0 var 94 rtt 376 rto 376 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.58.128.30 . ttl 894 ping 47 var 136 rtt 591 rto 591 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.36.148.17 . ttl 894 ping 5 var 81 rtt 329 rto 329 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 216.239.38.10 google.com. ttl 894 ping 11 var 59 rtt 247 rto 247 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 216.239.32.10 google.com. ttl 894 ping 9 var 71 rtt 293 rto 293 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.12.94.30 com. ttl 894 ping 12 var 94 rtt 388 rto 388 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.52.178.30 com. ttl 894 ping 29 var 129 rtt 545 rto 545 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 : unbound-control -c /var/unbound/unbound.conf lookup . The following name servers are used for lookup of . ;rrset 86383 13 1 8 0 . 518383 IN NS a.root-servers.net. . 518383 IN NS b.root-servers.net. . 518383 IN NS c.root-servers.net. . 518383 IN NS d.root-servers.net. . 518383 IN NS e.root-servers.net. . 518383 IN NS f.root-servers.net. . 518383 IN NS g.root-servers.net. . 518383 IN NS h.root-servers.net. . 518383 IN NS i.root-servers.net. . 518383 IN NS j.root-servers.net. . 518383 IN NS k.root-servers.net. . 518383 IN NS l.root-servers.net. . 518383 IN NS m.root-servers.net. . 518383 IN RRSIG NS 8 0 518400 20171031140000 20171018130000 46809 . Ue/V7yyrQirgsXdZIAoYcx2u20SdhJxhhXuCVZt90SQI1GvulljiLeqr/bF+RNnrKrDJQBnc5c3CDwjffAYUz9Bcx0n7+oEoK+yfVoPSbqwTqcTUL9pyYDb9i4ClMKTW/y8+qKvKd8qBJYEJxcfMVxm2BsPIm0dmioPr2cRwN98m5EVNO8HoGXbx7sC5te7VUoxwOnl8r0gdeJo9f8YLUZAlNzwwQzMCwzHtbweechzrDj3JSi0cIKrKLuEXK6Rvsw12w/fiNk5l9drgmpgW65aKNsDgLP8HhmSaV8BH9P9jh7vH7uElDQEN50jZjuM1wqCOG8JMpyhNKV/kyQmQng== ;{id = 46809} ;rrset 86383 1 0 3 0 m.root-servers.net. 518383 IN A 202.12.27.33 ;rrset 86383 1 0 3 0 m.root-servers.net. 518383 IN AAAA 2001:dc3::35 ;rrset 86383 1 0 3 0 l.root-servers.net. 518383 IN A 199.7.83.42 ;rrset 86383 1 0 3 0 l.root-servers.net. 518383 IN AAAA 2001:500:9f::42 ;rrset 86383 1 0 3 0 k.root-servers.net. 518383 IN A 193.0.14.129 ;rrset 86383 1 0 3 0 k.root-servers.net. 518383 IN AAAA 2001:7fd::1 ;rrset 86383 1 0 3 0 j.root-servers.net. 518383 IN A 192.58.128.30 ;rrset 86383 1 0 3 0 j.root-servers.net. 518383 IN AAAA 2001:503:c27::2:30 ;rrset 86383 1 0 3 0 i.root-servers.net. 518383 IN A 192.36.148.17 ;rrset 86383 1 0 3 0 i.root-servers.net. 518383 IN AAAA 2001:7fe::53 ;rrset 86383 1 0 3 0 h.root-servers.net. 518383 IN A 198.97.190.53 ;rrset 86383 1 0 3 0 h.root-servers.net. 518383 IN AAAA 2001:500:1::53 ;rrset 86383 1 0 3 0 g.root-servers.net. 518383 IN A 192.112.36.4 ;rrset 86383 1 0 3 0 g.root-servers.net. 518383 IN AAAA 2001:500:12::d0d ;rrset 86383 1 0 3 0 f.root-servers.net. 518383 IN A 192.5.5.241 ;rrset 86383 1 0 3 0 f.root-servers.net. 518383 IN AAAA 2001:500:2f::f ;rrset 86383 1 0 3 0 e.root-servers.net. 518383 IN A 192.203.230.10 ;rrset 86383 1 0 3 0 e.root-servers.net. 518383 IN AAAA 2001:500:a8::e ;rrset 86383 1 0 3 0 d.root-servers.net. 518383 IN A 199.7.91.13 ;rrset 86383 1 0 3 0 d.root-servers.net. 518383 IN AAAA 2001:500:2d::d ;rrset 86383 1 0 3 0 c.root-servers.net. 518383 IN A 192.33.4.12 ;rrset 86383 1 0 3 0 c.root-servers.net. 518383 IN AAAA 2001:500:2::c ;rrset 86383 1 0 3 0 b.root-servers.net. 518383 IN A 192.228.79.201 ;rrset 86383 1 0 3 0 b.root-servers.net. 518383 IN AAAA 2001:500:200::b ;rrset 86383 1 0 3 0 a.root-servers.net. 518383 IN A 198.41.0.4 ;rrset 86383 1 0 3 0 a.root-servers.net. 518383 IN AAAA 2001:503:ba3e::2:30 Delegation with 13 names, of which 0 can be examined to query further addresses. It provides 26 IP addresses. 2001:503:ba3e::2:30 not in infra cache. 198.41.0.4      not in infra cache. 2001:500:200::b not in infra cache. 192.228.79.201  not in infra cache. 2001:500:2::c  not in infra cache. 192.33.4.12    not in infra cache. 2001:500:2d::d  not in infra cache. 199.7.91.13    not in infra cache. 2001:500:a8::e  not in infra cache. 192.203.230.10  not in infra cache. 2001:500:2f::f  not in infra cache. 192.5.5.241    not in infra cache. 2001:500:12::d0d rto 376 msec, ttl 883, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 192.112.36.4    not in infra cache. 2001:500:1::53  not in infra cache. 198.97.190.53  not in infra cache. 2001:7fe::53    not in infra cache. 192.36.148.17  rto 329 msec, ttl 883, ping 5 var 81 rtt 329, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:503:c27::2:30 not in infra cache. 192.58.128.30  rto 591 msec, ttl 883, ping 47 var 136 rtt 591, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:7fd::1    not in infra cache. 193.0.14.129    not in infra cache. 2001:500:9f::42 not in infra cache. 199.7.83.42    not in infra cache. 2001:dc3::35    not in infra cache. 202.12.27.33    not in infra cache. Forwarding mode example: : unbound-control -c /var/unbound/unbound.conf dump_infra 8.8.4.4 . ttl 274 ping 12 var 32 rtt 140 rto 140 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 8.8.8.8 . ttl 295 ping 29 var 39 rtt 185 rto 185 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 198.51.100.1 . ttl 274 ping 23 var 39 rtt 179 rto 179 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 203.0.113.1 . ttl 274 ping 17 var 30 rtt 137 rto 137 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 : unbound-control -c /var/unbound/unbound.conf lookup . The following name servers are used for lookup of . forwarding request: Delegation with 0 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 198.51.100.1    rto 179 msec, ttl 270, ping 23 var 39 rtt 179, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 203.0.113.1    rto 137 msec, ttl 270, ping 17 var 30 rtt 137, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 8.8.4.4        rto 140 msec, ttl 270, ping 12 var 32 rtt 140, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 8.8.8.8        rto 185 msec, ttl 291, ping 29 var 39 rtt 185, tA 0, tAAAA 0, tother 0, EDNS 0 probed.

If you have gotten to the point that your worried about dns failure for the internal domains.. You have pretty much moved beyond a caching forwarder/resolver setup.  Neither dnsmasq or unbound is designed to be authoritative.. So no you would not use them if you require actual internal dns vs a handful of records to resolve, etc. Your mention of AD.. be it you like it or not.. If you are a MS shop running AD.. Then your DNS is already covered and designed to not fail for your AD.. Multiple servers in your AD would and could provide dns.. And they auto sync any changes to all ns in the setup. Clients only point to your internal AD for dns, these servers would then be setup to forward to some that can resolve external or resolve external themselves.  Normally in such a setup they would forward to something else that has external access.  In such a setup they could forward to pfsense that could do the external resolving via unbound. So your 3 requirements are met really out of the gate.. If your not running Microsoft.. Then normally you would use bind for your authoritative setup but there are alternative authoritative dns products out there.. Which sure if you wanted you could run on pfsense via the bind package..  But yes you would run multiples.  Authoritative servers by design share info.. This is why there is a SOA and then secondaries.. You create/edit a record in SOA, it is then via zone transfer updated to any of your slaves, etc.  So you could have 2, you could have 200 all depending on how big your network is..  Since your clients would only ever point to these internal servers that are authoritative for your internal domains.  Again your requirements are met.. In such a setup where you have need of delegation of dns for other internal domains to other NS internal to the network.. Again that is a simple delegation you would do on your SOA and this can be automatically shared to all the other NS you run inside your network. As long as your clients list more than 1 of these internal NS.. then you have no issues since all of these servers have the same records for your internal domains.  If you worried about the server itself going down then you run that box running NS for your internal domains in a HA or CARP setup.  You could setup pfsense as carp, running bind for your authoritative dns for your internal domains. If you have money to spend and your wanting high end dns functionality… You could run say something like infoblox.. Its really just BIND at its heart with a lot of gui and code wrapped around it.. It does and can do more than just dns.. Ipam, your dhcp, network controls even, etc. etc.  Love it when customers use this - since I like to manage it ;)  But it can be a hard sell sometimes because its not cheap ;)  And if the shop is MS they kind of already paid for their dns reliability and redundancy... It just has to be configured and managed correctly is all. "To me, this means that we can't really use the simple 'domain override' in Unbound in pfSense as that only allows for one server." Says who?  You can have multiple entries for a domain override.  All of these servers will be queried if one does not answer, etc.  So here I put in a domain override for test.com… I then queried pfsense running unbound for a record in that test.com domain.  Via sniffing on pfsense you can see that pfsense then attempts to ask these IPs listed for what I asked..  Until such time that timed out.. Because neither of them are actually running dns at all.. Just wanted to show that they would both be asked.. So sure you could point your clients at pfsense.  You could run pfsense in a carp..  you could have multiple pfsense setup, etc.  point your clients to either of them..  With your domain overrides setup to point to your internal dns for your internal domains. "When the internal domain server for the internal domain fails, it should not take down DNS lookups completely, only for the internal domain" "DNS should be able to fail over across replicated servers" This really goes hand in and.. If you setup internal authoritative servers.. Then yes the data would be replicated and your clients could point to more than 1 of them if you do not want your internal dns to go down..  So if you have redundant internal, and these can all forward or resolve external then you kill both of those birds. One thing to remember.. Clients should only ever point to NS that can resolve the same thing..  This is common problem with internal dns.. They point client to external server and an internal server..  This is failure waiting to happen.. Your isp, google, opendns, etc.  not going to have clue 1 to your internal.. They will most likely send back NX.. Once client gets back NX.. they not going to go ask any other NS they have listed.  They got told that doesn't exist.. Why should I ask some other NS if he has a record for it, etc.  While they might list NS as 1 and 2, 3 etc..  Once you point a client to more than 1 NS you can never be sure which one it uses or latches on too.. So pointing to multiple NS that can not resolve the same thing is broken config.  If you have internal dns then point your clients to your internal dns..  If you have no need to resolve internal stuff.  Then point them to multiple ns that can resolve external.. So you can point clients to multiple public that is fine.. so that if one is down or can not be reached they try another and another, etc.  But do not point a client to external and internal at the same time.. This is going to cause you grief.. [image: overrides.png] [image: overrides.png_thumb]

@johnpoz: Yeah should just work.. Things can always go wrong sure.. But without any info hard to try and find out where it might be. When you say this is test lab stuff - is it VM?  Or on actual hardware?  If you just installed this not sure why you just didn't install 2.4 directly?  Its been out for a few days now.. When you go to download you would get the 2.4 iso, etc. No VM, actual hardware.  Quite a dated piece too.  Doesn't even have AES-NI Processor, but it took the install and fired right up. I got really confused with the downloads iso's vs memstick etc.  Couldn't get it to boot off of one version then I went back and got memstick.  I'll take another look and see if I can get 2.4.0 on memstick and install it straight away and see what happens.  That just might save me some time.  Thanks.  I'll let you know what happens.  Get out the popcorn.

Yes with a reverse proxy.. Which couple packages on pfsense can do that.. But you do not need that to have multiple FQDN on 1 server.. You need that if you want that on more than 1 server.. You have IP 1.2.3.4 on your public wan.. you could send www.domain.tld ftp.domain.tld host.otherdomain.tld www.something.tld All to 1.2.3.4, you forward 80 and 443 to 192.168.1.100 for example.. The server would know what page to serve up.  You could have hundreds of FQDN that resolve to 1.2.3.4 and get sent to .100 and have it serve up them all. You only need a reverse proxy if you want to send say host.otherdomain.tld www.something.tld Of that listing to 192.168.1.101… vs the .100 Pfsense just knows to send 80/443 to .100.. It can not read the FQDN part it just sees traffic to a port.. To know to send to different machines behind your public IP you need a reverse proxy to read the FQDN trying go to.. And then make a call to what rfc1918 address to send it to..

did you ping the devices from the firewall?  Did the devices talk to the firewall?  As Derelict mentions only when the device and the firewall have actually talked will they show in the table.

Yeah I show that resolving just fine.. With dnssec valid all the way through. If your forwarding somewhere and its not working - then they are the issue.. httpredir.debian.org.          IN      A ;; ANSWER SECTION: httpredir.debian.org.  3600    IN      CNAME  static.debian.org. static.debian.org.      3600    IN      A      130.89.148.14 static.debian.org.      3600    IN      A      149.20.4.15 static.debian.org.      3600    IN      A      5.153.231.4 static.debian.org.      3600    IN      A      128.31.0.62 ;; AUTHORITY SECTION: debian.org.            28800  IN      NS      dnsnode.debian.org. debian.org.            28800  IN      NS      sec2.rcode0.net. debian.org.            28800  IN      NS      sec1.rcode0.net. ;; ADDITIONAL SECTION: dnsnode.debian.org.    28800  IN      A      194.146.106.126 dnsnode.debian.org.    28800  IN      AAAA    2001:67c:1010:32::53 ;; Query time: 126 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Mon Oct 16 03:24:08 Central Daylight Time 2017 ;; MSG SIZE  rcvd: 248 http://dnsviz.net/d/httpredir.debian.org/dnssec/

I'm experiencing this as well. Setting the link speed didn't do it for me. My first attempt was to pass 192.168.100.1 (my modem) to 192.168.100.20 67/68 UDP. Noticed in the logs, but doesn't make sense as there are no other devices. Set top box perhaps? Now I am getting Rule (12000) blocking source 10.240.160.225:67 destination: my public ip:68 So, I deselected Block private networks on WAN and rebooted. Looks like the dhcp requests are not being blocked now, but I am still getting latency alerts. recently upgraded to 2.3.4-release-p1 Overnight, another latency error and dpinger sendto error 65. Noticed this in firewall log. Oct 12 07:10:02 WAN block bogon IPv6 networks from WAN (11000) 0.0.0.0:68 255.255.255.255:67 UDP Has my ISP changed the way they are doling out addresses? Update: Had cable dude come out and string a new line to the pole and have had no drops for 24 hours. Update 2: It's back. Not as bad but this is definitely getting annoying. Time to dump Optimum Cable for FIOS perhaps. Oct 16 15:24:28 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 68.196.96.1 bind_addr 68.196.101.146 identifier "WAN_DHCP " Oct 16 15:24:23 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 68.196.96.1 bind_addr 68.196.101.146 identifier "WAN_DHCP " Oct 16 15:24:18 dpinger WAN_DHCP 68.196.96.1: sendto error: 65 Oct 16 15:24:17 dpinger WAN_DHCP 68.196.96.1: sendto error: 65

Well no they wouldn't ;)  You must have a dhcp server running on this layer 2 the phones are on that are giving out that IP.  Did you have your ipsec setup as layer 2? Ie L2TP/IPsec? where they could of gotten the IP from the dhcp server on the other end of your L2 tunnel?

I thought I would follow up with some testing I did and see if any one has any additional thoughts: I kept my "General Setup" as stated below. In my DNS Resolver i.e. Services → DNS Resolver → General Settings I changed my “Network Interfaces” from "ALL" to my "internal interfaces" and "Localhost" only, this includes VLANs and Interfaces with dedicated NICs. I am not using IPv6 (System -> Advanced -> Networking -> Allow IPv6 is NOT CHECKED) and did not select those interfaces, nor WAN or VPN interface I changed my “Outgoing Network Interfaces” from "ALL" to "WAN" and my "VPN Interface" only Even though I use pfBlockerNG I did NOT select the "10.10.10.1 pfB DNSBL - DO NOT EDIT" interface for either the “Network Interfaces” nor the “Outgoing Network Interfaces”…I thought this would break my DNSBL blocker functionality but I am still getting alerts. I kept DNSSEC Checked. I found a website that claims to check your DNSSEC functionaility: https://dnssec.vs.uni-due.de/ and I appear to be using DNSSEC. Thanks Germany! I kept my rules as is with my "DNS rule" rule set to "VPN Gateway" I will follow up if anything breaks...open to any thoughts! V

Hi, You need a package called "Cron", must use DNS Resolver, and a bit of coding. To achieve your desired results, you need to create two files. One file for te 8.8.8.8 and the other is for the 208.67.222.222. No need to use wildcards. Domain overrides will get only the root domain for the rest of the FQDN/subdomains etc. By default the "/var/unbound/domainoverrides.conf" is empty. We will going to use this file. First create a folder for the "Day" and "Night" folders and put it on the "root" directory. Day folder: Create a file and name it "domainoverrides.conf": forward-zone: name: "facebook.com" forward-addr: 208.67.222.222 forward-zone: name: "yahoo.com" forward-addr: 8.8.8.8 Night folder: Create a file and name it "domainoverrides.conf": forward-zone: name: "apple.com" forward-addr: 8.8.8.8 forward-zone: name: "yahoo.com" forward-addr: 8.8.8.8 Create this file and name it like "dayandnightDNS" and put it on your root directory: ********* to be continued later im too sleepy *********

Discussed in several threads already. https://forum.pfsense.org/index.php?topic=137418.0

Yeah its called the unbound documentation ;) https://www.unbound.net/documentation/