@manjotsc said in DNS Zone Tranfer:

@bmeeks Thanks, I have configured it in pfsense.

That should fix it for you. Now, in the future, if you need to manually create any DNS records for a host, do so over in the Windows DNS server. With the configuration you have in place, your pfSense box will still see them.

@viktor_g said in Strange Problem: DHCP Failover after upgrade to 2.5.0 - XMLRPC BUG?:

ok, I can reproduce it
Please try this patch: 151.diff

Perfect! This does the job! Thanks a lot, Viktor!

The inability to ping an IP sounds like a connection issue not a DNS issue. If pfSense can't ping that implies an ISP issue. Can you traceroute out to an IP from the diagnostics menu to see how far you get?

Well numbers of time of recursion could vary for sure - depending on your location and what your looking up.. I don't know exactly what say for example that grc dns tool is using for its testing.. Its clearly a list of xyz.. Which for would could be different times to resolve depending on where your located and how well your isp peers, etc. to where you have to go look those up from the authoritative..

But as long as your not seeing some crazy times for avg and median your all good..

@hieroglyph I will try the direct plug in route at some point just to see - I have configured a workaround for this anomaly. Confirmed still an issue on 21.02...

I got a similar problem with VLANs. My primary vlan runs without any problems. But every morning I boot up a PC within a different VLAN it can't lookup domains. Nslookup ends with a Timeout. After restarting the dns resolver it works immediately.

@making_sense_of_pfsense
Thank you. I found something similar to the suggested solution. The problem did not come back after I changed the laptop name a second time. There was no .local behind the name. It was a MacBook Pro. Anyway, I will follow the suggest solution the next time it happens again.

@hispeed
This Topic can probably be closed. The solution was reboot the core switch after a 270 Days uptime.

Yes that's all and it was one of the last things I did and I spent 20 hours or more into that problem.
Remember: If you have any strange problems with not recieving an IP-Adress and other devices are working fine. Reboot all devices which are connected and look into settings like ACL. If you recieve different WLAN Reason Code concerning rejecting then you probably better restart everything first.

@brucexling You can setup a local resolver (bind/unbound) or use the PFSense Resolver and have dns queries forwarded to google (8.8.8.8) or cloudflare (1.1.1.1) using TLS port 853 they wont intercept that. In a nutshell, the local resolver caches and responds to queries from your network and uses google/cloudflare for root

Capture.PNG

Additional config:

server: aggressive-nsec: yes forward-zone: name: "." forward-tls-upstream: yes forward-addr: 1.1.1.1 forward-addr: 8.8.8.8 forward-addr: 8.8.4.4

@johnpoz said in Client DNS doesn't resolve when using VIP in place of interface IP:

First one I don't see, unless you were wanting to offer your guest clients a way to use your dns, and don't provide other protection from other clients on your wifi, ie your wifi is completely unencrypted..

It's more about business cases here (hospitality like hotels, coffee shops, etc) which have to cater to the lowest common denominator clients.

The new option combines some older GUI options and offers a new choice.

The "Use local DNS 127.0.0.1, ignore remote DNS servers" option will prevent the firewall itself from using alternate DNS servers if the local resolver is not responding. There are some cases where that could lead to DNS leaks for queries originating from the firewall when you want to force things like DNS over TLS to upstream servers.

@bmeeks thanks! will follow the other thread

OK I'm dumb... 🤦 🤦

It's obvious that this gateway will be used to reach 192.168.255.254 DNS since it is a direct attached subnet... There is no risk that it uses any other gateway...

I sticked too hard to the rule "at least one DNS must be set per gateway in a multiwan environment" In the case of a DNS in a WAN subnet, selecting none is fine because routing through this interface is implicit.

My use case is not the most widespread but maybe a clarification could be made in the documentation. Meanwhile answer can now be found here 😊

Yup you can see them in the gui..

yupcanseehereinthegui.png

Like said you would really have to try hard to mess this up ;) Since it defaults to 4096..

You wouldn't be able to use like something-test.testdomain.tld where -test is part of the host name.

test.domain.tld where you have whatever hosts.test.domain.tld would be the best way yeah.