[Pdns-users] PDNS recursive problem - NXDOMAIN - CNAME resolving

[Brian Candler]

On 13/11/2017 09:50, Mislav | SysAdmin wrote:
> Yes, "ns1.private.ch" is a made-up name, that's correct. I'm running 
> Debian 9 with pdns-recursor-server installed via apt, version 4.1.0-rc2.
>
> Before I do all the tests you mentioned, let me explain my setup, I 
> think there is something wrong there - I configured "allow-recursion" 
> inside pdns.conf (so pdns_server), I didn't define anything inside 
> recursor.conf - I took this configuration from old environment where 
> we were running version 3.1. (also same problem there, but since I 
> can't receive support on 3.1, we decided to migrate to 4.1) I read 
> somewhere this should be possible to define in pdns.conf since certain 
> version (option allow-recursion) and if I don't define there my IP, 
> I'm not able to recurse at all. But I also see now in docs this is 
> removed in 4.1.0?
>

There are two types of DNS server: recursive/caching servers (which 
clients talk to), and authoritative servers (which contain the actual 
zone information, and which the recursive/caching servers talk to).

Clients are statically configured with the IP address(es) of local 
recursive/caching servers.

NS records point to the hostnames of authoritative servers (which in 
turn resolve to the IP addresses of the authoritative servers).

If you want to run both types of server, then you should be running them 
on different IP addresses.  Don't make your authoritative server be 
recursive - that is bad practice, and causes various problems as you've 
found, which is why it has been removed entirely from the pdns 
authoritative server.

For resilience, you will want two local recursive servers.  If you are 
serving your own zone information then you will also need at least two 
authoritative servers, but one should be local and one should be remote 
on a completely different Internet backbone (see RFC2182)

> Shall I try to configure this somehow on recursor.conf? My pdns_server 
> is currently listening on publicIP on port 53 and recursor is 
> listening on 127.0.0.1 on port 53. Please note that both are on same 
> IP / same server. I also noticed that if I do such this:
>> # netstat -tlpn | grep 53
>> tcp        0      0 127.0.0.1:53 0.0.0.0:*               LISTEN      
>> 1036/pdns_recursor
>>
>> # nslookup www.mobile-universe.ch 127.0.0.1
>> Server:        127.0.0.1
>> Address:    127.0.0.1#53
>>
>> Non-authoritative answer:
>> www.mobile-universe.ch canonical name = 
>> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com.
>> Name: elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com
>> Address: 52.58.17.141
>> Name: elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com
>
> directly on the server, it works.

Yes, it works because you are sending the client query to the recursive 
server (pdns_recursor), which is its job.

> But when I do it from outside, it doesn't work. 

Because you are sending a recursive query to an authoritative server, 
which is not its job (albeit older versions of the authoritative server 
*did* have a recursor option you could turn on)

> So, from my understanding, it works internally, because I do recurse 
> from 127.0.0.1 and that goes through pdns_recursor, but if I do it 
> from outside, recursing goes through pdns_server and that is the problem.
>
Yes.

Bind them to two different external IP addresses; point your clients at 
the recursor; and point your NS records at the authoritative server.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20171113/cbaa28a3/attachment.html>