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

[Mislav | SysAdmin]

This all finally makes sense. Thank you very much Brian, big time.


On 13.11.2017 11:01, Brian Candler wrote:
> 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.
>

-- 

Srdacan pozdrav | Best regards
Mislav Orsolic | sysadmin
https://www.mislav.eu / https://www.linkedin.com/in/mislavorsolic

___________________________________________

*T * +385 91 444 0275
*Skype:* mislav.orsolic

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