DNS Resolver
-
Hi - Sorry to be cheeky, I was wondering if anyone had any idea what might be going wrong in my case when using Domain Overrides to send specific domain queries to a different DNS server. (You can see more in my post above…)
It seems strange that DNS resolver has identified this as a query that should be sent via the VPN, but it still sends it to the main DNS servers?
Is anyone else using the Domain Overrides feature and do they also see the requests being sent to the wrong servers before eventually being sent to the correct one?
Thanks, Matt
-
Sorry to ask again but is there news about my issue reported back in page 6? Or is just misconfiguration I'm doing?
-
Hi - Sorry to be cheeky, I was wondering if anyone had any idea what might be going wrong in my case when using Domain Overrides to send specific domain queries to a different DNS server. (You can see more in my post above…)
It seems strange that DNS resolver has identified this as a query that should be sent via the VPN, but it still sends it to the main DNS servers?
Is anyone else using the Domain Overrides feature and do they also see the requests being sent to the wrong servers before eventually being sent to the correct one?
Thanks, Matt
My system happily sends requests for domain override names just to the specified server.
In your log, yours is doing that also - server.vpn goes internally.
But server.vpn.local gets sent externally - you have specified .local as your domain for pfSense/LAN so clients on LAN are getting .local in their DNS suffix searchlist, and trying to append ".local" also when trying name lookups.
You could also add an override for "local" that points to an internal IP address that does not exist (or to pfSense itself? That might make an interesting loop.) so that anything ending in ".local" does not go to the public DNS.
DNS Forwarder has an optoin to put "!" instead of an IP address, and requests for that domain are not forwarded anywhere - if the name is not in the local hosts file, then NXDOMAIN is returned. That option is not in DNS Resolver.
That would be useful to have - I will look in unbound manual and see if it will do it.Edit: Add: I think something in the config like:
local-zone: "local" static
will tell it that "local." is to be responded to just from pfSense itself - whatever host entries happen to be there that end in ".local" - but non-existent names in ".local" are immediately answered with NXDOMAIN.
I tried that quickly, in the Advanced box, but unbound is telling me I have a syntax error.
I also triedlocal-zone "local." redirect
Still get syntax error message.
But it looks like it is possible to create an internal zone in unbound that will just return entries it knows about, and NXDOMAIN for things in the zone that it does not know. -
Thanks Phil
So do you not have a domain set, and therefore your clients are not applying the suffix?
In the log I provided, I only did one NSLOOKUP to server.vpn - so either the client sent a second request without the DNS suffix or pfSense dropped the local domain portion after not getting a response from the public DNS servers.
-
The client will have tried server.vpn and server.vpn.local on your behalf. So the server sees 2 different requests.
My pfSenses have their domain as the same as our internal Windows Server AD domain - e.g. internal.mycompany.com - and then a domain override to point internal.mycompany.com to the nearest Active Directory DNS Server.Having just 1 internal domain will also resolve the issue you see - at the moment you have a ".vpn" domain and a ".local"domain happening. Then your domain override will be for the domain that pfSense itself is in.
-
working fine for me
-
Hmm - strange. I have had to use Phil's trick of directing the server.vpn.local requests to a non-existant server and then letting the server.vpn request go to the correct server. Without this I couldn't avoid the public DNS server being queried.
Maybe the issue is that I am not using AD? amunrara could you describe your set-up?
M
-
I'm a pretty novice user but wanted to provide some feedback and see if there are any suggestions. I'm currently using 2.2-BETA (i386) built on Thu Dec 04 08:23:23 CST 2014
when I check Status->Services several times in a row I see Unbound DNS Resolver running and stopped at various times so it seems like it's constantly stopping and restarting.
in the general setup, I have Allow "DNS server list to be overridden by DHCP/PPP on WAN" unchecked and "Do not use the DNS Forwarder as a DNS server for the firewall" checked.
not sure if I have something configured wrong…..
-
Check the posts near the end of previous page. Might be your issue.
-
Check the posts near the end of previous page. Might be your issue.
Specifically, this one…
https://forum.pfsense.org/index.php?topic=78356.msg464921#msg464921
-
i started using the new dns resolver but im having one issue, i have set to reset the pppoe connection ever night so when this happens, unbound stops working, i get these errors in system log continuously
Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 61031 Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 19660 Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 26847 Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 26531 Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 65308 Dec 11 09:44:44 unbound: [7669:0] error: can't bind socket: Can't assign requested address Dec 11 09:44:44 unbound: [7669:0] debug: failed address 92.98.234.229 port 19113
-
Does the resolver also handle IPv6 dns requests?
-
-
We're running the December 10th build. I can confirm issues with a new WAN address breaking unbound. When our PPPoE WAN link gets a new IP address, the resolver will reply with internal IPs set via DHCP clientIDs, but any external DNS lookup made via a system on the LAN fails.
DNS resolving on the firewall continues to work, so it's clearly an issue with unbound.
-
We're running the December 10th build. I can confirm issues with a new WAN address breaking unbound. When our PPPoE WAN link gets a new IP address, the resolver will reply with internal IPs set via DHCP clientIDs, but any external DNS lookup made via a system on the LAN fails.
DNS resolving on the firewall continues to work, so it's clearly an issue with unbound.
https://redmine.pfsense.org/issues/4095
-
I'm not sure what a message consisting solely of a link to a similar bug report means…
-
I'm not sure what a message consisting solely of a link to a similar bug report means…
I think cmb means "it is a known issue and there is a bug report for it".
It does really need fixing - as you have described, DNS resolution can stop working on a WAN DHCP address change, if you have an "unfortunate" combination of Unbound in forwarder mode… settings. -
I'm not sure what a message consisting solely of a link to a similar bug report means…
I think cmb means "it is a known issue and there is a bug report for it".
Yes, figured that was clear.
-
Latest version broke unbound for me - it did not start after the upgrade. I had to uncheck "Enable DNSSEC Support" to get it to come up.
-
I have DNS resolver setup to use opendns via dnscrypt-proxy.
I then have firewall rules setup to only allow lan clients to query lan address on port 53,
and block requests to remote DNS'; Everything works in this regard (no dns leaks).But, if I query an unknown, none existant name, such as qwertyuiopas.dfghjklzxcvbnm
I get:
drill qwertyuiopas.dfghjklzxcvbnm
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 40495
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; qwertyuiopas.dfghjklzxcvbnm. IN A;; ANSWER SECTION:
;; AUTHORITY SECTION:
. 2918 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014122700 1800 900 604800 86400;; ADDITIONAL SECTION:
;; Query time: 28 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Dec 27 18:05:03 2014
;; MSG SIZE rcvd: 120And if I ping qwertyuiopas.dfghjklzxcvbnm; It resolves to my WAN ip… (I would expect an unknown host response)
I have "NAT Reflection mode for port forwards" set to Pure NAT, could this be the culprit?