Skip to content

August 11, 2015

PDNS Recursor: Forwarding DNS queries to local DNS Server

by Joe Kuan

I have setup two PDNS servers running in the same host; pdns_server (the authoritative server) and pdns_recursor (a recursive server).

Here are the configurations for both PDNS servers settings:

pdsn.conf

launch=gpgsql

loglevel=10
log-dns-queries=yes

gpgsql-host=127.0.0.1
gpgsql-user=xxxxxx
gpgsql-password=xxxxxxx
gpgsql-dbname=xxxxxx

recursor=127.0.0.1:5678

recursor.conf

forward-zones=.=10.10.10.1;8.8.8.8
local-port=5678
trace=on

Basically, pdns_server is listening on port 53 and trying to resolve the incoming DNS queries by FIRST looking up at the DB. If no match found, it will forward the queries internally to the pdns_recursor server via specific port number, 5678. The pdns_recursor can forward query to multiple DNS servers with different filters. In this example, it is forward queries to the local primary DNS server, 10.10.10.1, and then forward to 8.8.8.8 which is the secondary DNS server.

We have setup a name entry, 10.10.10.250, in the local 10.10.10.1 DNS server. Then we issue a nslookup command expecting the pdns_recursor to forward the query to 10.10.10.1 and returning with the DNS answer. However, for some reasons the reverse name lookup doesn’t work at all. Here is the output of the command:

root@Joe:/usr/local/etc# nslookup 10.10.10.250 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find 250.10.10.10.in-addr.arpa: NXDOMAIN

Here are the trace logs:

pdns[25422]: Remote 127.0.0.1 wants '250.10.10.10.in-addr.arpa|PTR', do = 0, bufsize = 512: packetcache MISS
pdns_recursor[25514]: 0 [1] question for '250.10.10.10.in-addr.arpa.|PTR' from 127.0.0.1
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: Looking for CNAME cache hit of '250.10.10.10.in-addr.arpa.|CNAME'
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: No CNAME cache hit of '250.10.10.10.in-addr.arpa.|CNAME' found
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: No cache hit for '250.10.10.10.in-addr.arpa.|PTR', trying to find an appropriate NS record
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: Cache consultations done, have 1 NS to contact
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: Nameservers: (0ms)
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: Domain is out-of-band
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: checking auth storage for '250.10.10.10.in-addr.arpa.|PTR'
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: auth storage has data, zone='10.in-addr.arpa.'
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: nothing found so far in '10.in-addr.arpa.', trying wildcards
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: trying '*.10.10.10.in-addr.arpa.' in 10.in-addr.arpa.
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: trying '*.10.10.in-addr.arpa.' in 10.in-addr.arpa.
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: trying '*.10.in-addr.arpa.' in 10.in-addr.arpa.
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: no NS match in zone '10.in-addr.arpa.' either, handing out SOA
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: accept answer '10.in-addr.arpa.|SOA|localhost. root. 1 604800 86400 2419200 604800' from '10.in-addr.arpa.' nameservers? YES!
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: determining status after receiving this packet
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: got negative caching indication for RECORD '250.10.10.10.in-addr.arpa.' (accept=1)
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: status=NXDOMAIN, we are done (have negative SOA)
pdns_recursor[25514]: [1] 250.10.10.10.in-addr.arpa.: failed (res=3)
pdns_recursor[25514]: 0 [1] answer to question '250.10.10.10.in-addr.arpa.|PTR': 0 answers, 0 additional, took 0 packets, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3

As we can see from the above log messages, the pdns_recursor is not forwarding any queries to any DNS servers. However, if we directly query the local DNS server, the resolved name is returned as expected which indicates the name lookup entry on 10.10.10.1 is correct.

root@Joe:/usr/local/etc# nslookup 10.10.10.250 10.10.10.1
Server:		192.168.200.5
Address:	192.168.200.5#53

250.10.10.10.in-addr.arpa	name = fred.

Interestingly, it also works when we perform a normal name lookup on the recursor, just not the reverse lookup. This got me really puzzled until I added a serve-rfc1918 setting to the recursor.conf. According to RFC1918, it defines a number of IP domains as private network and 10.0.0.0/24 is part of the setup. Since the default value for serve-rfc1918 is on, that means the recursor’s default behaviour is treating 10.10.10.250 as a private network address. Therefore the recursor server won’t send the query to another server.

We turn off the serve-rfc1918 setting in the recursor.conf and restart the recursor server.

 
forward-zones=.=192.168.200.5;8.8.8.8
local-port=8699
serve-rfc1918=no
trace=on

The nslookup reverse lookup command works fine with the new setting:

root@Joe:/usr/local/etc# nslookup 10.10.10.250 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
250.10.10.10.in-addr.arpa	name = fred.

Authoritative answers can be found from:

Note that serve-rfc1918 is only necessary if you require recursor server (to support multiple DNS servers) to communicate to your local DNS server which happens to be a private address. If you need only to forward queries to a single DNS server, then runs the PDNS authoritative server without the recursor server and set the recursor line to 10.10.10.1 in pdns.conf.

Read more from Networking

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: