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