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
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
