Bug #1768
closed
DNS Forwarder of Tinydns
0%
Description
Hello,
just playing around with the TinyDNS package on pfs and found some "issues":
As far as I got it, the idea is to connect (create a socket) the TinyDNS Server to a loopback device (lo) and then use port forwarding to connect the "outer world" to the Server. That's fine.
The Forwarder will be listening on the interfaces one selects in the config page. If the LAN interface is selected, the tinydns server and forwarder come up - both listening on the configured devices, but the access to the forwarder is still denied.
I was wondering why and checkt /var/etc/dnscache${index}/root/ip and the only entry there is "127.0.0.1". Using this entry for the DNS Server seems ok, but for the forwarder?
I manually added my local subnet and the forwarder responded to my requests but was not delivering any data, so I searched on...
When enabling the TinyDNS Server, it adds itself as primary nameserver to /etc/resolv.conf. So all queries of the forwarder go to the server that only answers requests for it's SOA domain. Removing 127.0.0.1 from /var/etc/resolv.conf and restarting tinydns and the forwarder solved that problem.
Is this the expected behaviour or is there a bug in all of this? Or is the idea to assign the forwarder to another loopback interface and then use port forwarding for this as well?
I assume it's a bug and would like to patch the code to make it work again. If so, please just tell me :)
KR,
Oliver (Grimeton)
Files
Updated by Oliver Loch over 12 years ago
Any news on this?
I would really like to patch the stuff and make it work. All I'm waiting for is some response on this to know how it is expected to work.
Thanks!
KR,
Grimeton
Updated by Nico Rat over 12 years ago
Hello,
I have the same problem as well.
I need to manually create the file in /var/etc/dnscache${index}/root/i for the forwarder to respond.
I don't think assign the forwarder to the loopback interface and use port forward is the good solution.
Thank you for your help
-Nico
Updated by Joshua Weage about 12 years ago
Similar problem here. I had a post in the forums about this also: http://forum.pfsense.org/index.php/topic,36823.0.html
With pfSense 2.0.1, I get both 127.0.0.1 and my LAN IP in /var/etc/dnscache0/root/ip/ and servers/@ is empty. After fixing both of these manually, dig works correctly when ran on pfsense, but a client machine gets no response. I don't know why this is as there are no firewall rules preventing access to DNS from the LAN.
It seems like the dnscache portion of dns-server is broken.
Updated by Jim Pingle about 12 years ago
You might try switching to manual outbound NAT, and make sure you have a NAT rule for traffic leaving each interface that covers 127.0.0.1, such as:
Interface: LAN
Source: 127.0.0.1
Destination: any
Translation: Interface address
If it's trying to source the replies from 127.0.0.1 and there is no NAT, it could be breaking. See #1528
Updated by Joshua Weage about 12 years ago
I just found this post in the forums with patches to fix some of these issues: http://forum.pfsense.org/index.php/topic,44413.0.html
My non-response problems is because I had my LAN IP in root/ip/ rather than the LAN subnet. If I use the "Respond to IP" configuration field and add my LAN subnet it works.
Now the forwarder works, but I'm not getting any response from TinyDNS.
Updated by Joshua Weage about 12 years ago
- File tinydns.inc.diff tinydns.inc.diff added
I've attached a patch for dns-server 1.0.6.17 (pfSense 2.0.1).
This patch basically does two things:- Calls tinydns_create_zone_file() in tinydns_custom_php_command() otherwise dnscache is not configured to use tinydns to resolve local domains or DHCP registered addresses.
- Removes the root servers from the tinydns data file. I'm not sure if this matters one way or the other, but it doesn't seem like it should be there since dnscache should handle this.
- Changes a printf() call to log_error()
You still need to manually create /var/etc/nameserver_something to assign your upstream name servers to dnscache.
There is still a problem with dynamic DHCP leases. They are not added to the tinydns data file unless the DNS server service is restarted.
Updated by Felipe Santos about 12 years ago
I found that if you check the option "Allow DNS server list to be overridden by DHCP/PPP on WAN" on pfsense GUI, you dont need to manually create /var/etc/nameserver_something.
Is there a way to make dnscache reads /etc/resolv.conf to gets the name servers instead of nameserver_something? (or anyway else)
Updated by Kill Bill almost 9 years ago
The patches from https://forum.pfsense.org/index.php?topic=44413.msg236701#msg236701 have been merged, looking at the relevant tinydns.inc part concerning dnscache pretty much nothing from the OP applies to current code, the interface(s) to listen on and IPs to which the the recursive resolver should respond are configurable in the GUI [1]. Dnscache servers are configurable via /var/etc/nameserver_*
[1] https://github.com/pfsense/pfsense-packages/blob/master/config/tinydns/tinydns.inc#L231
[2] https://github.com/pfsense/pfsense-packages/blob/master/config/tinydns/tinydns.inc#L1156
What's identifiable from the comments here has been fixed, for anything else, best to file a new bug.
Updated by Chris Buechler almost 9 years ago
- Status changed from New to Resolved