Unbound not resolving delegated NS record
-
My setup is:
- Public DNS server at 123.123.123.123 servers mydomain.com
- mydomain.com has a NS record for subdomain.mydomain.com pointing to subns.mydomain.com. and matching GLUE for subns.mydomain.com
- subns.mydomain.com is the external IP of pfSense
- pfSense has a NAT port forward on the WAN interface TCP/UDP from WAN Address:DNS to target IP 192.168.0.10:DNS which is enabled
- DNS resolver service is enabled only on network interfaces LAN and Localhost with outgoing network interfaces of all
Problem:
- The DNS setup works fine all through the Internet. If I set my internal hosts to use 8.8.8.8 as their DNS servers, I have no problem at all with my setup.
- However if I use 192.168.0.1 as my client's DNS server, I get a SRVFAIL from my clients.
- Similarly, I get a SRVFAIL when I use nslookup on the pfSense SSH console
- Interestingly, the DNS query from the pfSense GUI works (DIag_dns.php)
- If I run dig @192.168.0.10 whatever.subdomain.mydomain.com, I do get the proper response.
Help:
- I know the forward is set up right, as it works for external queries
- So it appears that it is struggling to make a query to a local IP, likely to avoid a loop.
Tried:
- I've tried overriding the A record for the nameserver with the internal IP, however that didn't change anything.
- I've tried using 'do-not-query-localhost: no' in the custom options, but that doesn't seem to help.
Any help is appreciated getting unbound to be able to query the external IP of the pfSense system, which is where the NS record if pointing to.
-
Just in case anyone else has this setup, the answer was that a firewall rule on the LAN interface was needed ANY-to-ANY for port DNS (53). Apparently the one I had on the forwarding rule was just on the WAN interface and that wasn't enough. I removed the do-not-query-local part as well so we're back to a normal configuration. With that rule change, this setup works perfectly. DNS for my public site is provided by bind at a domain level and AD and its DNS server is providing my internal network's DNS system properly.
-
Never mind. Appears to not be fixed. It still can't access the local DNS server as dig +trace subdomain.mydomain.com times out.
It appears to be a routing/forwarding issue as 'nslookup subdomain.mydomain.com 123.123.123.123' times out when run on the router, so it isn't forwarding that to the internal IP. Any help is appreciated. Why won't the port forward if accessed via localhost? All of the firewall rules are open.Help!
-
@phyre said in Unbound not resolving delegated NS record:
Why won't the port forward if accessed via localhost
Do you have NAT reflection turned on in the Advanced settings of the router? I'm actually not sure if that works for localhost but it is necessary for traffic from the LAN interface.
-
Read this like 3 times and can not make out wtf your wanting to do?
So you have subdomain.mydomain.com delegated to pfsense..
Which you have a host override setup for host.subdomain.mydomain.com
And your saying clients that ask pfsense lan IP for host.subdomain.mydomain.com it gives you FAIL?
When you client asks for the host.subdmomain.mydomain.com all of your delegation means nothing.. Same with your forwarding. None of that has anything to do with anything... When your clients asks psense for host.subdomain.mydomain.com its just going to serve up his host override - nothing more nothing less.. What you do on the internet has zero to do with that query!! Zero!!!
So what domain is pfsense in? subdomain.mydomain.com... So you have domain override pointing to your public NS or not? What do you have the zone set to in unbound - transparent.. All of much means nothing when your client does a query for host.subdomain.domain.com if you have that setup as a host override in unbound.
-
I read it that he is on the pfSense and/or LAN and trying to, essentially, "dig @WANIP host.subdomain.mydomain.com" and it isn't working. However it is working from outside.
-
Does not matter what IP he queries for it - if there is a host override..
if he wants to query his WAN IP and unbound is listening on that wan IP - fine.. It will answer as long as his lan rules allow him to talk to his wan IP from the lan side..
This comes down to simple what IP unbound is listening on and what rules allow or don't allow to talk to that IP.. Why he would have any sort of port forward setup for this also again just not required..
He if want to allow outside to query his wan IP for dns, all he needs is a rule on wan to allow tcp/udp to his wan address and ACL in unbound to allow the query.
pfSense has a NAT port forward on the WAN interface TCP/UDP from WAN Address:DNS to target IP 192.168.0.10:DNS which is enabled
ZERO reason to do that - ZERO!!! If unbound was answering these queries..
But here is my question - he is running dns on some internal server it seems like then why is he setting up host overrides on unbound on pfsense. He would just setup a domain override to send subdomain.domain.com to his internal NS for this domain..
Like said read this like 3 times and not actually clear to what he he is wanting to do exactly...
He has a delegated sub to a NS on his internal network and he wants outside and inside to resolve this? Is that the actual problem? Is this internal NS running unbound - if so that is wrong choice, unbound is not meant to be an authoritative NS.. etc..
-
The NS record (in a third party DNS provider) points to a host which resolves to the WANIP.
pfSense has a forward for port 53 UDP/TCP pointing to the INTIP which is hosting the windows DNS server.As such, any DNS lookups on the Internet work perfectly. Hosts contact my WANIP, get forwarded to INTIP and the DNS server responds as expected.
If I:
- use nslookup from the SSH console which uses the local DNS server, I get SRVFAIL
- do an nslookup from a host which uses the DNS server on pfSense, I get SRVFAIL
- use dig/nslookup from the SSh console of the server DIRECTLY querying the INTIP, it times out.
Hence it appears that the pfSense box can't access INTIP from itself for unbound to use. This makes me look to a port forwarding issue where local processes accessing EXTIP:53 aren't being forwarded to INTIP.
The purpose of this is as follows:
publiccompany.com and www.publiccompany.com is hosted by an external DNS server
internalnetwork.publiccompany.com is an active directory server that is managed by Windows DNS server on the domain control. That windows server is within the private network of the company. Rather than mirror all the entries, I refer up to it. And yes, internalnetwork should resolve publicly, as many of our staff use public DNS servers on their machines and need name resolution. -
If you want unbound to ask an internal ns... Then setup a domain override, and allow unbound to use your lan IP for queries!
your wanting pfsense to resolve to get told ask itself for this delegation? ie its wan IP? to get forwarded in to internal ns?
If you want pfsense and pfsense clients to resolve this sub domain on your internal network - then setup domain overrride pointing to this internal ns internal IP.
internalnetwork should resolve publicly, as many of our staff use public DNS servers on their machines and need name resolution.
That is BORKED - plain an simple.. Your want some box out on the public to resolve rfc1918 addresses of internal stuff? There is a technical term for that - BORKED!!!! ;)
There is never a valid reason that clients on the public should resolver rfc1918 address space - they can not get to them... And rebind protection to actually prevent them from even getting such a response... Your saying asking google allows for return of rfc1918 space for a FQDN?
-
If I do a host override for the nameserver, this solves the problem for unbound. I'd just rather the forward work properly versus be making exceptions.
This makes UNBOUND work:
Host override: subns
Domain: mydomain.com
IP to return: 192.168.0.10
Description: Private DNSSo it's really more a question of why isn't the port forward working locally I suppose and not an unbound question.
-
@johnpoz said in Unbound not resolving delegated NS record:
That is BORKED - plain an simple.. Your want some box out on the public to resolve rfc1918 addresses of internal stuff? There is a technical term for that - BORKED!!!! ;)
There is never a valid reason that clients on the public should resolver rfc1918 address space - they can not get to them... And rebind protection to actually prevent them from even getting such a response... Your saying asking google allows for return of rfc1918 space for a FQDN?
Yes- Google's DNS returns my internal IP addresses. IETF can bark all they want, but private IPs are all over the public space.
-
And its BORKED..
Good luck I don't help stupid do more stupid shit.. Have fun!
-
@johnpoz said in Unbound not resolving delegated NS record:
He has a delegated sub to a NS on his internal network and he wants outside and inside to resolve this? Is that the actual problem? Is this internal NS running unbound - if so that is wrong choice, unbound is not meant to be an authoritative NS.. etc..
There are many reasons, other than the reason you have concern about, why you might want to delegate a NS to another nameserver. What it serves (private vs external IP) isn't really the point of the question. That nameserver is running on a machine behind a firewall/NAT, and so pfSense's job is to forward the DNS request to the DNS server.
This works for external DNS servers to look up IPs, but doesn't work for pfSense or anything that uses the pfSense DNS server without overriding the host of the internal nameserver manually for each domain this happens on.
