[Pdns-users] recursor - pdns authoritative and axfr problem

[Bernd Krueger-Knauber]

Hi,

I didn't found a solution for our problem online. So I'm here now.

We try to migrate an official ns from bind to powerdns, since we want to
give access the domain useres to their entries via web ui.
As written online, I placed the recursor infront of the pdns on the same
host with a mysql/maria db.
In general it is working: I can query own domains and foreign ones.
But ...
If I querry the pdns directly (localhost 5300) with dig, I get the AA flag.
If I querry via the recursor from 'outside' I don't get it.
Ok, auth-zones. But I can not provide them manually, because I don't
know when someone adds a new zone via web.
I thought the recursor can also access the database, but it don't looks
like.

I also get no AXFR working in this construct.

I also found some examples (not official) on the net where the pdns is
infront of the recursor.
Ok, this would solve the AA problem. But I don't think that this is the
correct way.

At the moment we use Debian Stretch with the 'inbuild' PowerDNS parts
pdns 4.0.3 and recursor 4.0.4

Any hints/informations ?

Best regards

[Brian Candler]

This post might be inappropriate. Click to display it.

[Bernd Krueger-Knauber]

Post by Brian Candler

Post by Bernd Krueger-Knauber
In general it is working: I can query own domains and foreign ones.
But ...

Presumably through the recursor??

Yes.

Post by Brian Candler

Post by Bernd Krueger-Knauber
If I querry the pdns directly (localhost 5300) with dig, I get the AA flag.
If I querry via the recursor from 'outside' I don't get it.

Note that open recursors are routinely discovered and exploited for
DoS attacks.  So if your recursor is open to the public Internet, you
need to ensure that it only answers recursive queries from trusted IP
ranges.
should get a REFUSED response.  If you get a real answer, you are
vulnerable)

Post by Bernd Krueger-Knauber
Ok, auth-zones. But I can not provide them manually, because I don't
know when someone adds a new zone via web.

If you are following a guide which suggests putting recursor in front
of auth, this would have been a workaround for people migrating from a
setup with a mixed authoritative + recursive server (e.g. default BIND
that's why PowerDNS now comes as separate authoritative and recursive
servers.
Therefore, you should simply put the authoritative server on one IP
address (accessible to the Internet), and the recursor on a different
IP address, both listening on port 53.  You can either bind the two
processes to two different IP addresses on the same host, or put them
in different VMs or containers.
The NS records for your authoritative domains then point to your
authoritative servers - your local one plus your off-site
secondaries.  (You do have off-site secondaries don't you? See RFC
2182). 

We have more then one ns :)

Post by Brian Candler
And everything Just Works™.  All the recursors who query your
authoritative domains will get the AA flag, since they're querying an
authoritative server directly.

Yes, and the pdns is also open for the complete internet, since it is
the SOA and have to be reachable for all, and also open for all DoS attacks.
So what is the difference to the 'open' recursor ?

Post by Brian Candler
Another approach is to treat your internal authoritative server as a
"hidden primary".  You build two or more auth servers on the public
Internet, and list them in NS records, but *don't* list your hidden
primary.  These servers then replicate their mysql databases from the
one in your auth server.
HTH,
Brian.

I understand the concept as follows:
SOA points to the a server which can answer the request with AA flag,
since it is the master of this zone.
The NS records points to servers which can give fast answers for this
zone, but also for foreign zones.

In general I still have no answer to the question why I get no AA flag
via the recursor.
Even if I split it to ifferent IPs I get only an AA flag from the pdns.
And still the problem: how can I tell the recursor from the database
which domains are reachable via our own pdns.
(to avoid that it calls an other nameserver)

[Brian Candler]

Post by Bernd Krueger-Knauber

Post by Brian Candler
All the recursors who query your
authoritative domains will get the AA flag, since they're querying an
authoritative server directly.

Yes, and the pdns is also open for the complete internet, since it is
the SOA and have to be reachable for all, and also open for all DoS attacks.
So what is the difference to the 'open' recursor ?

powerdns-authoritative is not a recursor (recursive queries are refused).

For details of why open recursors are bad, see
http://openresolverproject.org/

Authoritative nameservers obviously must answer queries from anyone, but
they are harder to use as DoS amplifiers.

Post by Bernd Krueger-Knauber
SOA points to the a server which can answer the request with AA flag,
since it is the master of this zone.

No.  SOA is not use in resolution.  It's the set of *NS* records within
the zone which are authoritative for the zone, and which recursors can
send queries to.

The SOA record contains a "master" nameserver and a contact E-mail
address, but these are really just for human debugging purposes. (Well
actually, NOTIFY and UPDATE requests should go to the master, but
recursive resolution ignores this and follows the NS records only)

Post by Bernd Krueger-Knauber
The NS records points to servers which can give fast answers for this
zone, but also for foreign zones.

That makes no sense.  The NS records for a zone point to authoritative
servers for the zone.  Whether they are "fast" or not is irrelevant;
they are the *only* servers which may be queried.

"Foreign" zone is meaningless.  An authoritative server will only answer
for zones which it is authoritative for, and will respond with a REFUSED
response for anything else.

Post by Bernd Krueger-Knauber
In general I still have no answer to the question why I get no AA flag
via the recursor.

By definition, any answer from a recursive nameserver is not
authoritative, because it did not come directly from the authoritative
server.  Recursors are caches.  Cached data is not authoritative - it
may be stale.

Post by Bernd Krueger-Knauber
Even if I split it to ifferent IPs I get only an AA flag from the pdns.

From the pdns-authoritative server, correct.  That's how it's supposed
to work.

Post by Bernd Krueger-Knauber
And still the problem: how can I tell the recursor from the database
which domains are reachable via our own pdns.
(to avoid that it calls an other nameserver)

Your recursor will follow the NS records, just like any other recursor,
and therefore will it will find your authoritative nameserver(s) and get
the answers from there.

If you really want, you can use domain forwarding rules in your recursor
to tell it where to forward the queries; but why do that when the NS
records do it automatically?

Regards,

Brian.

[Brian Candler]

[please reply to list]

At our customers routers we give them 2 IP adresses of recursers as NS
entries, which have no official NS entries pointing to them self (no
real NS).

Yes: recursors don't have NS records pointing at them.  The clients
learn the IP addresses of the recursors through DHCP, or manual
configuration.

We restrict the recursors to the IP-ranges of our network addresses.

Yes.  This avoids abuse of your recursors.  (Or you can keep your
recursors on a private network, or behind a firewall which doesn't allow
inbound connections).

We place our 'real' pdns directly in the internet.

If by 'real' you mean pdns-authoritative, yes.

Alternatively, don't put it on the Internet, but make your domain's
public authoritative nameservers slave or replicate from it.

Even if you do put it on the Internet, you still need at least one other
nameserver to replicate from it, on a different network and ideally a
different continent (RFC 2182).

We tell the recursor to ask first our pdns, then someone else.

No.

Your recursor will automatically follow the delegations from nameservers
on the Internet.  If the recursor wants to resolve www.example.com:

- first it queries the root nameservers, which will return a delegation
(NS records) pointing to .com nameservers
- it asks one of them, which will return a delegation to example.com
nameservers
- it asks one of them, which gives the final answer
- all the answers, intermediate and final, are cached

This works the same for your own domains as for anybody else's domains. 
To see a demo of this in action, try:

$ dig +trace www.google.com  # or domain of your choice

You don't need to configure the recursor to do this - unless the domain
is private (unregistered, or not delegated).

As an example: if you want to do reverse DNS for private IP addresses,
you will need to forward the domains like 168.192.in-addr.arpa or
10.in-addr.arpa to your authoritative servers, because you can't get
real delegation in the public DNS for this.

As another example: if you have the domain foo.com, and you want to
create a domain int.foo.com which is *only* resolvable on your network
and not in the public Internet, then you can create int.foo.com but
*not* add NS records for it.  Then the recursor must be configured to
forward int.foo.com to the auth server.

Regards,

Brian.

[s***@nethelp.no]

Post by Bernd Krueger-Knauber
In general I still have no answer to the question why I get no AA flag
via the recursor.

With a BIND resolver you get an authoritative answer from the resolver
the *first* time this resolver receives an answer directly from the
authoritative server (presumably because this answer is *not* from the
resolver cache). For the second and later answers, you don't get an
authoritative answer (because the answer comes from the resolver's
cache).

PowerDNS recursor gives you a non-authoritative answer even if it has
just received this answer from the authoritative server. IMHO this is
just as correct as the BIND behavior.

Personally I find the BIND behavior moderately confusing, and the
PowerDNS recursor behavior less surprising.

Steinar Haug, AS2116