21 Bře
2021
21 Bře
'21
22:04
Apologies if this has been asked before, but I was unable to find
informative resources about this topic except this[1].
What are the downsides of having a recursive DNS server in front of an
authoritative DNS Server? I'm wondering if all the points listed in the
linked article are relevant for small scale installations.
Is anyone running such a setup and can share some advice with regards to
rate limiting?
[1]: https://www.whalebone.io/separate-dns-servers/
--
Alex JOST
21 Bře
21 Bře
22:36
Hello.
On 3/21/21 10:04 PM, Alex JOST wrote:
What are the downsides of having a recursive DNS
server in front of an
authoritative DNS Server? I'm wondering if all the points listed in
the linked article are relevant for small scale installations.
"in front"? That sounds like some misunderstanding, either on your side
or mine - perhaps I didn't get what you want to achieve?
Authoritatives and recursives provide a different kind of service and to
different "clients"; on a quick look I see that in the article though.
Historically I think both functions were commonly done by a single
service - BIND/named can still do it - but nowadays it's recommended to
run them separately. (Well, injecting a few "authoritative"
modifications of DNS inside a recursive server seems OK, but that's a
bit different.)
--Vladimir
23:19
Am 21.03.21 um 22:36 schrieb Vladimír Čunát:
Hello.
On 3/21/21 10:04 PM, Alex JOST wrote:
I'll try to rephrase: The idea is to have Knot Resolver listening on
port 53 as an open resolver and forwarding queries for specific domains
to Knot DNS (as authorative DNS).
What are the downsides of having a recursive DNS
server in front of an
authoritative DNS Server? I'm wondering if all the points listed in
the linked article are relevant for small scale installations.
"in front"? That sounds like some misunderstanding, either on your side
or mine - perhaps I didn't get what you want to achieve? Authoritatives and recursives provide a different kind
of service and to
different "clients"; on a quick look I see that in the article though.
Historically I think both functions were commonly done by a single
service - BIND/named can still do it - but nowadays it's recommended to
run them separately. (Well, injecting a few "authoritative"
modifications of DNS inside a recursive server seems OK, but that's a
bit different.)
AFAICT BIND and PowerDNS can do this and some (or many?) people are
combining authoritative+recursive resolvers. So far I've not found many
compelling reasons not to do this besides "it's not recommended".
--
Alex JOST
22 Bře
22 Bře
9:25
Hello Alex,
On Sun, 2021-03-21 at 23:19 +0100, Alex JOST wrote:
I'll try to rephrase: The idea is to have Knot Resolver listening on
port 53 as an open resolver and forwarding queries for specific domains
to Knot DNS (as authorative DNS).
PowerDNS Authoritative and Recursor cannot do this, and never could.
But https://dnsdist.org/ might be what you are looking for. It allows
you to forward queries to different backends (in your case, Knot DNS
and Knot Resolver) based on source subnet, queried domain name,
Recursion Desired bits, etc.
I don't think "many" people are combining auths and resolvers.
Authoritatives and recursives provide a different
kind of service and to
different "clients"; on a quick look I see that in the article though.
Historically I think both functions were commonly done by a single
service - BIND/named can still do it - but nowadays it's recommended to
run them separately. (Well, injecting a few "authoritative"
modifications of DNS inside a recursive server seems OK, but that's a
bit different.)
AFAICT BIND and PowerDNS can do this and some (or many?) people are
combining authoritative+recursive resolvers. So far I've not found many
compelling reasons not to do this besides "it's not recommended".
Speaking from 10 years of experience talking to PowerDNS users, mixed setups quite often
end up causing confusion and surprises. It's hard to give you a specific reason
because there are many different reasons this ends badly.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
9:45
Am 22.03.2021 um 09:25 schrieb Peter van Dijk:
The lack of resources on the internet about this topic implies that this
setup isn't very common but I had hoped to hear some concrete examples.
--
Alex JOST
Hello Alex,
On Sun, 2021-03-21 at 23:19 +0100, Alex JOST wrote:
This post mentions that it is possible to do this with PowerDNS (at
least the other way around):
https://mailman.powerdns.com/pipermail/pdns-users/2012-June/020980.html
Thanks for the link to dnsdist. It's not what I was looking for, but it
sounds interesting and I will have a closer look.
I'll try to rephrase: The idea is to have Knot Resolver listening on
port 53 as an open resolver and forwarding queries for specific domains
to Knot DNS (as authorative DNS).
PowerDNS Authoritative and Recursor cannot do this, and never could.
But https://dnsdist.org/ might be what you are looking for. It allows
you to forward queries to different backends (in your case, Knot DNS
and Knot Resolver) based on source subnet, queried domain name,
Recursion Desired bits, etc. Authoritatives and recursives provide a different
kind of service and to
different "clients"; on a quick look I see that in the article though.
Historically I think both functions were commonly done by a single
service - BIND/named can still do it - but nowadays it's recommended to
run them separately. (Well, injecting a few "authoritative"
modifications of DNS inside a recursive server seems OK, but that's a
bit different.)
AFAICT BIND and PowerDNS can do this and some (or many?) people are
combining authoritative+recursive resolvers. So far
I've not found many
compelling reasons not to do this besides "it's not recommended".
Speaking from 10 years of experience talking to PowerDNS users, mixed setups quite often
end up causing confusion and surprises. It's hard to give you a specific reason
because there are many different reasons this ends badly.
9:48
On Mon, 2021-03-22 at 09:45 +0100, Alex JOST wrote:
This post mentions that it is possible to do this with PowerDNS (at
least the other way around):
https://mailman.powerdns.com/pipermail/pdns-users/2012-June/020980.html
Yes, the other way around -was- supported. We removed it a few years
ago because it quite often did not do what people expected, leading to,
agin, confusion and surprises.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
10:05
Am 22.03.2021 um 09:48 schrieb Peter van Dijk:
On Mon, 2021-03-22 at 09:45 +0100, Alex JOST wrote:
That makes sense, thanks for clarifying.
--
Alex JOST
This post mentions that it is possible to do this with PowerDNS (at
least the other way around):
https://mailman.powerdns.com/pipermail/pdns-users/2012-June/020980.html
Yes, the other way around -was- supported. We removed it a few years
ago because it quite often did not do what people expected, leading to,
agin, confusion and surprises. 
0:39
On 2021-03-21 14:04, Alex JOST wrote:
Apologies if this has been asked before, but I was
unable to find
informative
resources about this topic except this[1].
What are the downsides of having a recursive DNS server in front of an
authoritative DNS Server? I'm wondering if all the points listed in the
linked
article are relevant for small scale installations.
Is anyone running such a setup and can share some advice with regards to
rate limiting?
There is *zero* concern for running your own recursive DNS, so long
as
*you* and ONLY you have access to it. It has the added advantage that YOU
get to determine who is authoritative for the root zone "." and others
you are concerned about. As it is likely for you now. All your clients
queries
are sent to your upstream (ISP?) for answers, for which you have no control.
Using the knot recurser, and priming it against a known safe root authority
gives you the advantage of better control. Another advantage is that you now
have
the ability to create filters that block places you don't want to go, and
other such things. SO, in short; if you only grant queries from yourself
(think 127.0.0.1/localhost). There is little to no reason for concern
creating
a local recurser.
HTH
--Chris
[1]: https://www.whalebone.io/separate-dns-servers/
--
Alex JOST
8:41
Am 22.03.21 um 00:39 schrieb Chris:
On 2021-03-21 14:04, Alex JOST wrote:
I've been running resolvers (Unbound) for mail servers and office
clients for years, but they have all been restricted to specific IP
ranges. And I've been running authoritative DNS servers (Knot DNS) with
some TLDs accessible from the world.
The scenario I was thinking about is:
* Have some real world TLDs (example.com) NS entry point to server A
and server B
* Server A and B both have Knot DNS installed but listening on
localhost port 5053
* Server A and B both have Knot Resolver installed and listening on a
public IP port 53
* Queries for example.com are received by Knot Resolver and forwarded
to Knot DNS
* Any other queries are resolved and answered by Knot Resolver
* There are no access restrictions for specific IP ranges
My concerns are:
* Is it feasible to run such a setup? Are there any drawbacks?
* Is it possible to (more or less) safely run Knot Resolver as an
open resolver?
--
Alex JOST
Apologies if this has been asked before, but I
was unable to find
informative
resources about this topic except this[1].
What are the downsides of having a recursive DNS server in front of an
authoritative DNS Server? I'm wondering if all the points listed in
the linked
article are relevant for small scale installations.
Is anyone running such a setup and can share some advice with regards
to rate limiting?
There is *zero* concern for running your own recursive DNS, so
long as
*you* and ONLY you have access to it. It has the added advantage that YOU
get to determine who is authoritative for the root zone "." and others
you are concerned about. As it is likely for you now. All your clients
queries
are sent to your upstream (ISP?) for answers, for which you have no
control.
Using the knot recurser, and priming it against a known safe root authority
gives you the advantage of better control. Another advantage is that you
now have
the ability to create filters that block places you don't want to go, and
other such things. SO, in short; if you only grant queries from yourself
(think 127.0.0.1/localhost). There is little to no reason for concern
creating
a local recurser.
9:27
With the previous message I wasn't sure but this one made it clear to me:
On 3/22/21 8:41 AM, Alex JOST wrote:
The scenario I was thinking about is:
* Have some real world TLDs (example.com) NS entry point to server A
and server B
* Server A and B both have Knot DNS installed but listening on
localhost port 5053
* Server A and B both have Knot Resolver installed and listening on
a public IP port 53
* Queries for example.com are received by Knot Resolver and
forwarded to Knot DNS
This won't fully work, as Knot Resolver only provides recursive
service. Some of the authoritative queries would therefore be answered
"wrong".
We don't plan to change this, probably not even to provide a "proxying"
mode which you had in mind for this plan. The policy.STUB mode looks
similar but it's also designed to provide a recursive service only (and
meant to be pointed at recursive server, too).
* Any other queries are resolved and answered by
Knot Resolver
* There are no access restrictions for specific IP ranges
My concerns are:
* Is it feasible to run such a setup? Are there any drawbacks?
The only "advantage" I can see in combining both kinds of servers is
that you could save a public IP address, assuming you want to run a
public resolver for some other reason.
* Is it possible to (more or less) safely run Knot
Resolver as an
open resolver?
It's perhaps not relevant for you now, but Knot Resolver should be fine
as a public resolver (i.e. intentionally open resolver). We also run
such a service ourselves: https://nic.cz/odvr/
--Vladimir
10:04
Am 22.03.2021 um 09:27 schrieb Vladimír Čunát:
The idea is to reduce resources in general. Operating 2 independent
authoritative servers for a few domains which might not be queried more
than 10000 times per day seems like a waste.
I already thought that it would be possible as Cloudflare is using Knot
Resolver for its 1.1.1.1 service. But I wasn't sure how much effort it
would take to minimize attack surface and if it is worth it.
Anyways, thanks to everyone for chiming in an sharing your thoughts! I
will abandon this idea and think of another solution.
--
Alex JOST
With the previous message I wasn't sure but this
one made it clear to me:
On 3/22/21 8:41 AM, Alex JOST wrote:
That's what I was worrying about, thanks for the confirmation.
The scenario I was thinking about is:
* Have some real world TLDs (example.com) NS entry point to server A
and server B
* Server A and B both have Knot DNS installed but listening on
localhost port 5053
* Server A and B both have Knot Resolver installed and listening on
a public IP port 53
* Queries for example.com are received by Knot Resolver and
forwarded to Knot DNS
This won't fully work, as Knot Resolver only provides recursive
service. Some of the authoritative queries would therefore be answered
"wrong". * Any other
queries are resolved and answered by Knot Resolver
* There are no access restrictions for specific IP ranges
My concerns are:
* Is it feasible to run such a setup? Are there any drawbacks?
The only "advantage" I can see in combining both kinds of servers is
that you could save a public IP address, assuming you want to run a
public resolver for some other reason. * Is it
possible to (more or less) safely run Knot Resolver as an
open resolver?
It's perhaps not relevant for you now, but Knot Resolver should be fine
as a public resolver (i.e. intentionally open resolver). We also run
such a service ourselves: https://nic.cz/odvr/ 
10:51
Hi,
The idea is to reduce resources in general. Operating 2 independent
authoritative servers for a few domains which might not be queried more
than 10000 times per day seems like a waste.
Maybe you could run knot and knot-resolver on the same IPs on the same
box, with the resolver only listening on DoT/DoH and use corresponding
clients.
Regards
Bjoern
18:46
Am 22.03.21 um 10:51 schrieb Bjoern Franke:
Hi,
While I generally like the idea this requires DoT/DoH clients installed
and running on all machines which is a no-go at the moment.
--
Alex JOST
The idea is to reduce resources in general. Operating 2 independent
authoritative servers for a few domains which might not be queried more
than 10000 times per day seems like a waste.
Maybe you could run knot and knot-resolver on the same IPs on the same
box, with the resolver only listening on DoT/DoH and use corresponding
clients.
18:56
On 3/22/21 10:04 AM, Alex JOST wrote:
The idea is to reduce resources in general. Operating
2 independent
authoritative servers for a few domains which might not be queried
more than 10000 times per day seems like a waste.
You don't need two servers. You need two IP addresses for the two
daemons. For authoritative server you certainly need a public IP; for a
resolver you often don't need it.
20:24
Am 22.03.21 um 18:56 schrieb Vladimír Čunát:
On 3/22/21 10:04 AM, Alex JOST wrote:
Wow! Now that you came up with such a simple and easy solution I need to
wonder why I haven't thought of that myself ...
--
Alex JOST
The idea is to reduce resources in general.
Operating 2 independent
authoritative servers for a few domains which might not be queried
more than 10000 times per day seems like a waste.
You don't need two servers. You need two IP addresses for the two
daemons. For authoritative server you certainly need a public IP; for a
resolver you often don't need it.
1371
days inactive
1372
days old
knot-resolver-users@lists.nic.cz
14 comments
5 participants
participants (5)
-
Alex JOST -
Bjoern Franke -
Chris -
Peter van Dijk -
Vladimír Čunát