[Pdns-users] PDNS recursive problem - NXDOMAIN - CNAME resolving
Mislav | SysAdmin
mislavorsolic at gmail.com
Mon Nov 13 09:50:51 UTC 2017
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?
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. But when I do it from outside, it
doesn't work. 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.
On 13.11.2017 10:30, Brian Candler wrote:
> On 13/11/2017 09:05, Mislav | SysAdmin wrote:
>> Hi. I've noticed some problems with CNAME resolving on our pdns
>> server. Here is the example:
>>> $ nslookup mobile-universe.ch ns1.private.ch
>>> Server: ns1.private.ch
>>> Address: private#53
>>>
>>> Non-authoritative answer:
>>> Name: mobile-universe.ch
>>> Address: 18.194.35.161
>>>
>>> $ nslookup www.mobile-universe.ch ns1.private.ch
>>> Server: ns1.private.ch
>>> Address: private#53
>>>
>>> ** server can't find www.mobile-universe.ch: NXDOMAIN
>
> So I'm guessing that "ns1.private.ch" is a made-up name, right? But
> this is running pdns-recursor? Which version?
>
> Resolving that name works for me using pdns-recursor
> 4.0.6-1pdns.xenial under Ubuntu 16.04:
>
> # dig @192.168.5.53 www.mobile-universe.ch a
>
> ; <<>> DiG 9.8.1-P1 <<>> @192.168.5.53 www.mobile-universe.ch a
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26749
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.mobile-universe.ch. IN A
>
> ;; ANSWER SECTION:
> www.mobile-universe.ch. 3600 IN CNAME
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com.
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com. 60 IN A
> 52.58.17.141
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com. 60 IN A
> 52.57.147.203
>
> ;; Query time: 504 msec
> ;; SERVER: 192.168.5.53#53(192.168.5.53)
> ;; WHEN: Mon Nov 13 09:21:37 2017
> ;; MSG SIZE rcvd: 142
>
>
> So something must be different on your side, although I can't think
> why you'd get NXDOMAIN rather than SRVFAIL.
>
> I suggest you turn on tracing for the mobile-universe.ch and
> eu-central-1.elb.amazonaws.com domains, clear the cache for those
> domains, and then do the query again. See:
>
> https://doc.powerdns.com/recursor/running.html#tracing-queries
> https://doc.powerdns.com/recursor/running.html#cache-management
>
> You could also tcpdump all the DNS traffic which it sends during that
> time.
>
> FYI, here is where the authoritative servers are:
>
> $ dig +trace www.mobile-universe.ch. a
>
> ...
>
> mobile-universe.ch. 3600 IN NS ns1a.plentymarkets.eu.
> mobile-universe.ch. 3600 IN NS ns2a.plentymarkets.eu.
> ;; Received 94 bytes from 130.59.31.41#53(130.59.31.41) in 115 ms
>
> www.mobile-universe.ch. 3600 IN CNAME
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com.
> com. 3600 IN SOA ns1.com. hostmaster.com. 3 86400
> 10800 3600000 172800
> ;; Received 161 bytes from 185.61.8.110#53(185.61.8.110) in 31 ms
>
>
> $ dig +trace elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com. a
>
> ...
>
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com. 60 IN A
> 52.58.17.141
> elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com. 60 IN A
> 52.57.147.203
> eu-central-1.elb.amazonaws.com. 1800 IN NS ns-1326.awsdns-37.org.
> eu-central-1.elb.amazonaws.com. 1800 IN NS ns-1689.awsdns-19.co.uk.
> eu-central-1.elb.amazonaws.com. 1800 IN NS ns-417.awsdns-52.com.
> eu-central-1.elb.amazonaws.com. 1800 IN NS ns-613.awsdns-12.net.
>
> And all four AWS nameservers agree on the results: none is giving
> NXDOMAIN.
>
> # for i in ns-1326.awsdns-37.org. ns-1689.awsdns-19.co.uk.
> ns-417.awsdns-52.com. ns-613.awsdns-12.net.; do echo "=== $i ==="; dig
> +short @$i elb-front-92-10-617833872.eu-central-1.elb.amazonaws.com.
> a; done
> === ns-1326.awsdns-37.org. ===
> 52.58.17.141
> 52.57.147.203
> === ns-1689.awsdns-19.co.uk. ===
> 52.57.147.203
> 52.58.17.141
> === ns-417.awsdns-52.com. ===
> 52.57.147.203
> 52.58.17.141
> === ns-613.awsdns-12.net. ===
> 52.58.17.141
> 52.57.147.203
>
> Regards,
>
> Brian.
>
--
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/aa08cb74/attachment-0001.html>
More information about the Pdns-users
mailing list