[solved]authoritative local DNS server + recursive resolving (or DNS forwarding)

Eugene

For some reason even if you start forwarder like this```
/usr/local/sbin/dnsmasq --all-servers --listen-address=2.2.3.3 --interface=bge0

it listens on all interfaces, all ips which makes your setup impossible.

bloro989

I've made some progress to have the pfSense box resolve internal dns queries and also forward the other dns queries to the ones defined in the general setup. I found out that to resolve my problem, I conceptually would have to:

make tinyDns listen on the loopback lo0 127.0.0.1
make dnsmasq bind on the lan ip (see the problems section below) or at least not on lo0

After some testing, it seems that by default dnsmasq tries to bind on any interface (i.e. *.53 if you do a netstat -an | grep \.53). Options exist to change this, but pfSense does not use them.

A quick fix would be to edit the /etc/inc/services.inc file, modify the services_dnsmasq_configure() function, to add the –except-interface=lo0 --bind-interfaces, which could be achieved by modifying line 636 (as of pfSense 1.2.3-RELEASE with the dns-package installed)


mwexec("/usr/local/sbin/dnsmasq --all-servers {$args}");

into


mwexec("/usr/local/sbin/dnsmasq --all-servers --except-interface=lo0 --bind-interfaces {$args}");

After that, using pfSense web interface in

System -> General Setup:make sure the configures DNS servers are capable of resolving public addresses. As a test, Google's server 8.8.8.8 or Level3's 4.2.2.1 could be used.
Services -> DNS Server -> Settings: configure "Binding IP Address" to 127.0.0.1 and do not enable DNS-Cache server forwarder.
Services -> DNS forwarder: at the bottom, add or modify a domain override, and use ip address 127.0.0.1. Then tick the "Enable DNS forwarder" check box, and depending on your needs the dhcp related options

Problems:

answers are not authoritative (as far as I understand because dnsmasq acts as a "proxy")
if this setup's goal is to provide dns service to the LAN, dnsmasq should not listen on all interfaces, but could better be started with –listen-address=IP_OF_LAN. I haven't verified it, but should be equivalent to add a line in the services.inc script:
$args .= " –listen-address={$config['interfaces']['lan']['ipaddr']}";
However what happens for example if there is an opt interface which also relies on this service? All kind of such variations/complications could be imagined. The provided modification of services.inc is really the simplest one, and does not change the default behaviour of dnsmasq regarding its binding, except it does not bind on the loopback lo0 anymore
probably a few more I haven't thought about

kpa

@bloro989:

answers are not authoritative (as far as I understand because dnsmasq acts as a "proxy")

That's the way DNS works, if you want authoritative answers you have to query the authoritative server directly.

Eugene

@kpa:

@bloro989:

answers are not authoritative (as far as I understand because dnsmasq acts as a "proxy")

That's the way DNS works…

… and is totally fine -)))

bloro989

@Evgeny:

@kpa:

@bloro989:

answers are not authoritative (as far as I understand because dnsmasq acts as a "proxy")

That's the way DNS works…

… and is totally fine -)))

I agree! :-)
I just meant that dnsmasq might be made to "lie" about being authoritative when "resolving" something from 127.0.0.1. But I guess that's just icing on the cake.

DDCSupport

We have used djbdns for years, but obviously not on pfSense before… I believe there is a simple fix for this, but I can't make it sticky between reboots. Here's what I'm trying to accomplish.

1. TinyDNS bind to 127.0.0.1 and authoritative for local domains and in-addrs.
2. DNSCache bind to LAN IP; use dnscache0/root/servers/
- in-addrs --> forward to 127.0.0.1(TinyDNS)
- locals --> forward to 127.0.0.1(TinyDNS)
- @ --> forward to external cache or root servers

So I'm okay with the dynamic construction of in-addrs and locals, but why shouldn't dnscache be able to populate "@" from System->General Setup, or be explicitly defined in the module config if say you wanted the whole list of root servers.

This setup (manually implemented) works for our purposes as expected and doesn't seem to require dnsmasq, but I haven't tried dynamic registration (from DHCP) if there's a relationship.

I don't necessarily want to 'cat LISTOFSERVERS > /var/etc/dnscache0/root/servers/@' after every reboot.

Any help or ideas? Thanks.

Robert

bloro989

@bloro989:

I've made some progress to have the pfSense box resolve internal dns queries and also forward the other dns queries to the ones defined in the general setup. […]

Problems:

…

probably a few more I haven't thought about

I actually found a big issue, but I'm not sure why it doesn't work. If I define cnames in tinyDNS, they are not resolved properly (i.e. recursively)

example in /var/etc/tinydns/root/data


=test.domain.lan:1.2.3.4
Cntp.domain.lan:test.domain.lan

if I then do a DNS request on this host for ntp.domain.lan


$ nslookup ntp.domain.lan
Server:      pfsense
Address:    9.8.7.6    <- whatever

ntp.domain.lan   canonical name = test.domain.lan.

Where I was expecting


$ nslookup ntp.domain.lan
Server:      pfsense
Address:    9.8.7.6    <- whatever

ntp.domain.lan   canonical name = test.domain.lan.
Name:    test.domain.lan
Address: 1.2.3.4

If any reader has a clue, please reply,

Regards,

Mark

janisve

DNS Forwarder being exposed to internet.
Now I did the same configuration to enable DNS Server and DNS Forwarder on same pfsense box.

To resolve my www pages internally, i did the split-DNS thing (see http://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F) - i`v added records for my www in dns forwarder to point to internal ip addresses.

Howver when i try to reach my site externally, it points to my internal IP address. If i remove that address from DNS Forwarder, it resolves properly.

Also it exposes my internal computer names to internet.

# ps ax | grep dns
 1554  ??  S      1:18.64 supervise dnscache0
 4707  ??  S      0:29.09 supervise dnscache0
17008  ??  S      0:26.89 supervise dnscache0
21363  ??  S      0:00.00 supervise tinydns
21365  ??  S      0:00.01 /usr/local/bin/tinydns
34064  ??  S      0:26.58 supervise dnscache0
36605  ??  S      0:26.28 supervise dnscache0
63552  ??  S      0:00.09 /usr/local/sbin/dnsmasq --all-servers --except-interface=lo0 --bind-interfaces -l /var/dhcpd/var/db/dhcpd.leases -s example.com --server=/example.com/127.0.0.1
21491  p0  D+     0:00.00 grep dns

Whats up with that?

jimp

You are not supposed to run both the DNS forwarder and TinyDNS on the same box at the same time.

If you opened up port 53 to your box from the Internet, and you are running the DNS forwarder, you just told it to expose your internal addressing to the Internet.

Use one or the other, but not both.

Try the output of "sockstat" instead of ps, look for what is bound to tcp/udp port 53.

I think that tinydns binds only to localhost on port 53, so you might need to add a port forward on WAN to direct the traffic that way. The sockstat command should show you what is listening where.

serangku

i use pf 2.0, 9 0ct 2010 …
tinydns package installed ...

if bind to 127.0.0.1, canot go to internet
if bind to LAN IP, it can go internet

is it the right config ?
how about dns cache if dnsmasq disable ? also how to resolve to domain on local LAN ?
im still get confused to setting up

thanks
soory for my poor english

janisve

@jimp: I see. I thought this post about how to do that on the same box. But ohwell, i see. Thank you for response.