Use reverse proxy. You certainly do NOT want to run any DNS server on WAN.

Enable the DNSSEC related hardening options in unbound and stop forwarding to OpenDNS that does not support DNSSEC at all. Preferably, just stop forwarding (period).

Ok, if I desactive "DNSSEC support", test failed.

In order to make the plugin work in Chrome, we have to install a bin: https://www.dnssec-validator.cz/pages/download.html#package

thanks :-)

@johnpoz:

Don't be hijacking threads… Create your own.

This is MY thread and I thought my question is related to DNS, so I posted here. Anyway, I'll just transfer the contents of this thread to a new thread.

Thank you for your help. I am feeling a little sheepish now and should have my eyes checked.

just to validate dok's great answer

2.2-RELEASE][root@pfSense.local.lan]/root: unbound-control -c /var/unbound/unbound.conf lookup pfsense.org
The following name servers are used for lookup of pfsense.org.
;rrset 82095 5 0 2 0
pfsense.org.    82095  IN      NS      dns1.registrar-servers.com.
pfsense.org.    82095  IN      NS      dns2.registrar-servers.com.
pfsense.org.    82095  IN      NS      dns3.registrar-servers.com.
pfsense.org.    82095  IN      NS      dns4.registrar-servers.com.
pfsense.org.    82095  IN      NS      dns5.registrar-servers.com.
Delegation with 5 names, of which 5 can be examined to query further addresses.
It provides 0 IP addresses.
[2.2-RELEASE][root@pfSense.local.lan]/root:

I have a similar setup (One PPPoE WAN, one DHCP WAN) and it works for me with a variety of providers (Namecheap, HE.net).

Does pfSense actually have the public IP address from either of those WANs? Or is each WAN also doing NAT of some sort (and pfSense has a private IP)?

It could also be something specific to No-IP, do you have some other provider to try?

I finally got this sorted out.  In an obscure location the syslog server revealed that DNS lookup is disabled in their basic package, the pro version is needed.  Or a separate static host file can be pre-loaded.  So for now I reformatted the host file for the syslog server to load and all private IP's are being resolved by both PfSense internally and the external syslog server. Yes, all privates are RFC1918. By 20.x I mean 192.168.20.x.

Whew!  Glad this is resolved, pun intended.  Been working off and on for weeks trying to get this going. Thanks again John for all your help.

Not really, but your call.

I think it's good for me to do it.

@sloppy:

Ok, so right now there is just a second entry for static but the first entry is showing me the current ip of the server.
Btw. is the edit link broken for static mappings? For me it points always to http://xy.xy.xy.xy/services_dhcp_edit.php?if=lan&id=0

Thx

Yes, if there are multiple static entries without IP address, the Edit points to "id=0" for all of them.
This fixes it for me: https://github.com/pfsense/pfsense/pull/1503
This is better, handles the case when there are static entries on multiple interfaces with the same MAC address: https://github.com/pfsense/pfsense/pull/1504

So it happened again this evening, I guess Virgin use 7 day leases.
Gateway goes down, dhcp broadcasts for an address and one isn't found.
Eventually tries cached one which doesn't get accepted by the gateway as no traffic flows between the superhub and pfsense. FML! Can't figure out how to get these to re sync. Tried static IP, tried disabling gateway monitoring but not joy.

I had a similar situation here, on 2.1.5 i ran dnsmasq, and all went well with resolving, to internet and to my two connected vpn sites. When i upgraded to 2.2 and unbound came in sight, it didn't function anymore.
The clue is in the outbound interface (as stated in the post: https://forum.pfsense.org/index.php?topic=84184.0 )
When you want to resolve certain domain overrides who are connected by vpn the outgoing interface has to be part of your vpn domain ( e.g. your lan interface )

why do people test with a browser for some as simple a dns query?

From a cmd line use your fav tool.. nslookup, dig, drill or just ping - what does it resolve too for your fqdn query?

Browsers can be using proxy, could be highjacked, use their own cache, etc..

So your fqdn is camdriveway.zebra ?  not really of single label domains.  about zebra.lan or zebra.net, etc.  Single labels while they should be fine tend to have weirdness depending on OS, application, etc. etc.

So from a cmdline do - see attached

simpleoverridetest.png
simpleoverridetest.png_thumb

You're not comparing the same thing.

The 127.0.0.1 replies are the only thing that actually uses unbound or dnsmasq, the others are querying those servers directly. The variance on the ones other than 127.0.0.1 is just variance in your Internet connection and/or the response time of whichever server you hit when going to those anycasted DNS IPs.

With Unbound in its default configuration, it does its own recursion. That's going to require additional queries if your cache is completely empty, so the initial query for a domain will be slower than where you forward queries to a public DNS resolver that's already going to have every popular domain cached. You can enable forwarder mode if you want the same behavior as dnsmasq in that regard.

Your dnsmasq results for google.com is 1 ms because it was already in the cache, it had to do nothing but reply from its local cache. Unbound would come back the same if it was replying from cache. The Amazon results are atypical given the way dnsmasq resolved that is by sending the same query that took 14-18 ms sending separately, just happened to have less jitter at the time that query was issued (more along the lines of the response times for google.com).

There isn't a measurable performance difference between them where you're measuring the same thing.

I had a look at that code that implements "Do not forward private reverse lookups" and made it smarter.
Pull request: https://github.com/pfsense/pfsense/pull/1498
With that change, you can check "Do not forward private reverse lookups" and also have a working domain override for some chunk(s) of private IPv4 address space like:

10.in-addr.arpa 168.192.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa ... 31.172.in-addr.arpa

@voncloft:

How do I apply the patches? Sorry I'm moderately new to modems I'm trying to migrate from commercially made to open source do it yourself.

Any help is appreciated, thanks.

To apply patches you can install the System Patches package and that lets you apply patches from Github or other sources in a controlled manner.

It seems the 2 bugs that I noticed were not ones that particularly effected you. If you do not use underscore in host names, and do not have the special reverse lookup domain overrides then you would not notice either of those.

Sorry to bother, I think I figured this one out.  I can choose Lan1 and localhost as the resolvers network interfaces. So nothing should change in my rules or Lan DHCP server DNS addy.  It's just simply adding resolution for the localhost in addition to Lan1.  I thought it would have to be one or the other and it mandates that localhost be one of them.

Consider this resolved.

Sorry… didn't press notify on this thread

The cable modems do get the offer. But if the offer is not formatted the right way (that is DOCSIS standard used by CMTS and cable modems) then the cable modems will wait a short while and do another discovery.

But I did make it work! Using the pfsense. It was not correct according the DOCSIS standard to add a tftp server as a tftp server... it had to be done under "Enable network booting".

But don't put any more thought into it. The CMTS and DOCSIS is nothing like normal network using LAN cables and switches. My findins are, that the pfsense can only be used if all cable modems can use the same config boot file. If there is need for different config files per client or per subnet then some manual work need to be added or another DHCP server should be used on LAN.

Alternatively a modified tftp-server that can generate a custom config file per device based on client ip (given by the pfsense)

All this only makes sense to those working with CMTS and DOCSIS standard.

So pfsense is your first solution that isn't broken ;)

You can not have reservations for 2 different macs for the same IP.  This could cause a duplicate IP issue..

This concept of putting same IP on either a wired or wireless is pointless..  Why would anyone want or need to do that??  For one - wireless should really be on its own segment in any real setup.  If you want to run with broke setup then change either your wired or wireless to have the same mac - there you go problem solved ;)

If on the same segment, then they should have or get different IPs because they have different macs what does it matter if when wired 192.168.1.100 and when wireless 192.168.1.200 ?  If you need firewall rules use both IPs and setup 2 different reservations.  If need be change your segment to /23 and wireless get 192.168.0.100 and wired get 192.168.1.100 makes it easy.

Why is it you think these 2 different interfaces need to have the same IP address?  Dynamic dns registration removes the issue of having 2 different names, etc.  If they are wired host.yourdomain.tld points to the wired IP, if wireless host.yourdomain.tld points to wireless IP.