@bearhntr Yes, sorry I missed that you weren't sure where to add the static entry in DNS. And as long as the DHCP scope options are giving out your DNS server IP as the DNS server- you don't have to add it on the general tab in PFSense, or set forwarding on the DNS tab. I have nothing set on the General tab for DNS, and it works fine. In DNS Resolver, General Settings, if you scroll all the way down to the bottom, there is a Domain Override section, where you can add your domain name and point it to your server's IP.
As for RADVD, that's the Router Advertisement service. I know it is used when you setup IPV6, on the Services/DHCPv6 Server & RA/LAN/Router Advertisements.
@nocling Thanks for this, much appreciated.
Seem to have this now working stable. So far so good. The WebGui still times out when saving any Dynamic DNS configuration changes, but the changes do save correctly and updates are happening for the DNS.
The fact that you WAN IP is the same for 'ages' (from a purely network functionality perspective) and then changes to another IP,
It stays the same for even longer, or even indefinitely.
has no influence on DNS operations.
What needs to be tested :
Look at the DNS logs, can you see any serfail or NXDomain messages ?
Your "Nintendo Switch" is using pfSense as the DNS ?
What did OpenDNS receive from you as DNS requests ? Did it 'refuse' any ?
Sorry for bringing back a 4 year old thread, but I think I got this working for me in OPNSense using Unbound and I wanted to update the thread with a solution in case anyone else is looking. This is the only useful result that comes up when searching for making Mobility Print work with Unbound.
This hint about using typetransparent seems to make it work without doing anything else special. I set that through the GUI in OPNSense but I believe the relevant config line it results in is:
local-zone: "mydomain" typetransparent
I think these are the other relevant parts of the config files - in OPNSense I created a custom config file to add the entries as they removed the "advanced" box on the current release. (the OPNSense config file has a include: /var/unbound/etc/*.conf where custom entries go)
root@OPNsense:/var/unbound/etc # cat mobilityprint.conf
local-data: "b._dns-sd._udp.mydomain IN PTR pc-printer-discovery.mydomain"
local-data: "lb._dns-sd._udp.mydomain IN PTR pc-printer-discovery.mydomain"
local-data: "pc-printer-discovery.mydomain IN NS lxc-print.mydomain"
I didn't add the A record here, since I have a static DHCP lease for my Mobility Print server called lxc-print, but that record is just:
local-data: "lxc-print.mydomain IN A 10.10.5.17"
Everything passes in the Mobility Print DNS setup page and I get the correct results from nslookup:
@nicolas-pissard if your having problems with dhcp you need to make sure pfsense is actually seeing the dhcp discover or request.. And then it should offer, or provide some info to why it can not..
Maybe dhcpd has stop running? Maybe client is asking for IP it can't use on this network, and won't accept offer?
There are many things that could cause problems sure - but an expired lease should not prevent it from being offered up if there are no other free IPs from the pool to hand out.
dhcpd should use up all of its IPs first, and then once it has handed them all out. It will use those leases that have expired.. Where you run into problem is no expired leases, and no free IPs - then yeah nothing to hand out.
Maybe you have a client asking for specific IP back, and some other client has active lease for that IP.. And the client will not accept different offer of different IP?
I am currently doing exactly as you said, putting Unbound in forwarding mode and forwarding to the Mullvad servers. The one you listed is I guess the non HTTPS version, they now have DNS over HTTPS at doh.mullvad.net (220.127.116.11), so I am using that now.
I would much prefer to run Unbound in "normal" mode, and act as my own DNS server. Is there any way for me to do this without leaking my IP? So far the only solution I have found is to run OpenVPN in parallel and then send my queries over the OpenVPN interface. It just feels quite overkill to have OpenVPN and Wireguard running on the box.
The next time you 'rent' a domain name, check the quality of the registrar's services.
Issues like "ns1.carle.com" and "ns2.carle.com" are using the same AS, and are even in the same network. That's not ok.
You can correct this, by adding a third one (or remove the second and replace it for another, elsewhere). Slave DNS name services can be found for free on the Internet.
Issues like :
is also something that had to be dealt with, many years ago.
Who is this registrar, the local hobby club ? ;)
You're aware now that there are 13 'main root servers'. These know where to find all the top name severs, the ones know all about 'com', 'org', 'net', etc.
These top level name servers have many 'clones'.
The bottleneck are the (minimum) two domain name servers, your "ns1.carle.com" and "ns2.carle.com". These two have, of course, firewall rules that to filter out 'abuse'.
And guess what, what is the third reason why people use VPN's ? Right : to abuse a max.
( the third reason : just to loose some money, and the second : hiding their public WAN IP )
Which means : when you connect to your VPN, and you get an IP that was 'used' for some abusive activity, the IP will get blacklisted for a while.
At that moment, you, withthat VPN WAN IP, will have issues when resolving domain name that are registered (known to) "ns1.carle.com" and "ns2.carle.com".
There are some DHCP-client settings that might be useful here :
Check the 'Advanced Configuration' to see them.
Click on the blue "here" link for guidance.
Strange that, after a interface UP event on "09:35:34", more then 3 minutes later, on "09:38:52" there is still no answer.
The DHCP client assigns a previous used IP 18.104.22.168. It would be better if it assigned itself a NaN IP like "0.0.0.0".
When you set up pfSense, there is no need to enter any where '22.214.171.124' or '126.96.36.199'.
These two - or any others - are mentioned no where in the Pfsense manual.
Again : the default Resolver doesn't need any setting to be altered : it works out of the box.
But : if you have some sort of contract with Alphabet cooporation - (aka Google) that you have to hand over all your 'private' DNS request, then, ok, why not.
I don't think an ISP exists that actually blocks you from accessing basic Internet servers like the 13 root servers. And even if they exist, because, after all, it's a free world, so why not. It will be the ISP without clients, that's for sure.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.