Gwyneth Llewelyn
2015-Feb-06 15:44 UTC
[nsd-users] NSD + unbound on production nameserver (not internal nameserver)
Hi, For the past week I've been unsuccessfully trying to replicate on a FreeBSD nameserver our old BIND configuration, replacing it with with NSD + unbound instead. Apparently, this is not possible, since it looks like unbound doesn't work as an 'proxy/cache' front-end. But... let me tell you about our configuration first. This is a pair of FreeBSD servers, running several jails. Each server runs a jail with a real, public IP address on a nameserver for external (not internal) nameservices. Several other jails, each with a private address space, run the customers' websites. So we host both DNS name service as well as hosting services on behalf of our customers. With BIND, the configuration was as following: - Be authoratitative for external requests. Deny recursion for those. - Act as a caching nameserver for internal requests (from the many jails). Allow recursion only for them. - Internal requests for the domains we're authoritative for would also go to BIND as well, since, from BIND's perspective, it matters little where the request comes from (e.g. public/private addressing is irrelevant for authoritative requests) Now for unbound + NSD. When I first started to read about unbound + NSD, I thought it would be simple ? like a Varnish/Apache configuration. NSD would remain on a non-accessible port (say 53530) on the nameserver jail, while unbound would forward requests to it. For internal requests from the other jails, unbound would act as a recursive caching server ? easy to setup. To avoid unnecessary requests to external nameservers when requesting information from domain names we are authoritative for, unbound would simply forward requests to NSD. Easy-peasy. That works quite well for *internal* requests. Now the final and crucial step: how to allow the general public to retrieve domain information that we're authoritative for by contacting unbound? Apparently, this is impossible to do. Jan-Piet asked this same question in 2008: http://unbound.net/pipermail/unbound-users/2008-February/000021.html And Oliver Peter did the same, five years later: https://unbound.net/pipermail/unbound-users/2013-November/003075.html None ever received a single answer. Indeed, by carefully reading the principles behind the unbound + NSD configuration, it seems that it has been designed to deal only with the scenario of a corporate network that requires both some DNS caching (provided by unbound) and a few internal, private domains being served by NSD, which, however, are never accessible by the public at large. In contrast, on its own, NSD can be (and definitely is) used as an authorative nameserver for publicly available domain records ? but without the added 'protection' of having unbound in front of it. Thus, although it *seems* that unbound + NSD is *similar* to Varnish + Apache for the web, in fact it's a *different* solution. If I'm completely wrong about this, then how can unbound + NSD be configured so that unbound is able to act as a 'proxy/caching' nameserver as a frontend to NSD for public domains for which it is authoritative? Thanks in advance for any insights! - Gwyn -- "I'm not building a game. I'm building a new country." -- Philip "Linden" Rosedale, interview to Wired, 2004-05-08
John Peacock
2015-Feb-06 15:59 UTC
[nsd-users] NSD + unbound on production nameserver (not internal nameserver)
It isn't possible. Authoritative servers set the AUTH bit; caching
resolvers do not. The only service that should be publicly accessible is the
Authoritative server (i.e. nsd). The caching resolver (unbound) should be bound
to some other IP address and accessible only to the servers you control. You do
not need or want to provide a resolver for the world.
This is one of the many things where the design of BIND fails.
John
________________________________________
From: nsd-users [nsd-users-bounces at NLnetLabs.nl] on behalf of Gwyneth
Llewelyn [gwyneth.llewelyn at gwynethllewelyn.net]
Sent: Friday, February 06, 2015 10:44 AM
To: nsd-users at NLnetLabs.nl
Subject: [nsd-users] NSD + unbound on production nameserver (not internal
nameserver)
Hi,
For the past week I've been unsuccessfully trying to replicate on a FreeBSD
nameserver our old BIND configuration, replacing it with with NSD + unbound
instead.
Apparently, this is not possible, since it looks like unbound doesn't work
as an 'proxy/cache' front-end. But... let me tell you about our
configuration first.
This is a pair of FreeBSD servers, running several jails. Each server runs a
jail with a real, public IP address on a nameserver for external (not internal)
nameservices. Several other jails, each with a private address space, run the
customers' websites. So we host both DNS name service as well as hosting
services on behalf of our customers.
With BIND, the configuration was as following:
- Be authoratitative for external requests. Deny recursion for those.
- Act as a caching nameserver for internal requests (from the many jails). Allow
recursion only for them.
- Internal requests for the domains we're authoritative for would also go to
BIND as well, since, from BIND's perspective, it matters little where the
request comes from (e.g. public/private addressing is irrelevant for
authoritative requests)
Now for unbound + NSD.
When I first started to read about unbound + NSD, I thought it would be simple ?
like a Varnish/Apache configuration. NSD would remain on a non-accessible port
(say 53530) on the nameserver jail, while unbound would forward requests to it.
For internal requests from the other jails, unbound would act as a recursive
caching server ? easy to setup. To avoid unnecessary requests to external
nameservers when requesting information from domain names we are authoritative
for, unbound would simply forward requests to NSD. Easy-peasy. That works quite
well for *internal* requests. Now the final and crucial step: how to allow the
general public to retrieve domain information that we're authoritative for
by contacting unbound?
Apparently, this is impossible to do.
Jan-Piet asked this same question in 2008:
http://unbound.net/pipermail/unbound-users/2008-February/000021.html
And Oliver Peter did the same, five years later:
https://unbound.net/pipermail/unbound-users/2013-November/003075.html
None ever received a single answer.
Indeed, by carefully reading the principles behind the unbound + NSD
configuration, it seems that it has been designed to deal only with the scenario
of a corporate network that requires both some DNS caching (provided by unbound)
and a few internal, private domains being served by NSD, which, however, are
never accessible by the public at large.
In contrast, on its own, NSD can be (and definitely is) used as an authorative
nameserver for publicly available domain records ? but without the added
'protection' of having unbound in front of it. Thus, although it *seems*
that unbound + NSD is *similar* to Varnish + Apache for the web, in fact
it's a *different* solution.
If I'm completely wrong about this, then how can unbound + NSD be configured
so that unbound is able to act as a 'proxy/caching' nameserver as a
frontend to NSD for public domains for which it is authoritative?
Thanks in advance for any insights!
- Gwyn
--
"I'm not building a game. I'm building a new country."
-- Philip "Linden" Rosedale, interview to Wired, 2004-05-08
_______________________________________________
nsd-users mailing list
nsd-users at NLnetLabs.nl
http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
W.C.A. Wijngaards
2015-Feb-06 16:03 UTC
[nsd-users] NSD + unbound on production nameserver (not internal nameserver)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Gwyneth, On 06/02/15 16:44, Gwyneth Llewelyn wrote:> Hi, > > For the past week I've been unsuccessfully trying to replicate on a > FreeBSD nameserver our old BIND configuration, replacing it with > with NSD + unbound instead. > > Apparently, this is not possible, since it looks like unbound > doesn't work as an 'proxy/cache' front-end. But... let me tell you > about our configuration first. > > This is a pair of FreeBSD servers, running several jails. Each > server runs a jail with a real, public IP address on a nameserver > for external (not internal) nameservices. Several other jails, each > with a private address space, run the customers' websites. So we > host both DNS name service as well as hosting services on behalf of > our customers. > > With BIND, the configuration was as following: > > - Be authoratitative for external requests. Deny recursion for > those. - Act as a caching nameserver for internal requests (from > the many jails). Allow recursion only for them. - Internal requests > for the domains we're authoritative for would also go to BIND as > well, since, from BIND's perspective, it matters little where the > request comes from (e.g. public/private addressing is irrelevant > for authoritative requests) > > Now for unbound + NSD. > > When I first started to read about unbound + NSD, I thought it > would be simple ? like a Varnish/Apache configuration. NSD would > remain on a non-accessible port (say 53530) on the nameserver jail, > while unbound would forward requests to it. For internal requests > from the other jails, unbound would act as a recursive caching > server ? easy to setup. To avoid unnecessary requests to external > nameservers when requesting information from domain names we are > authoritative for, unbound would simply forward requests to NSD. > Easy-peasy. That works quite well for *internal* requests. Now the > final and crucial step: how to allow the general public to retrieve > domain information that we're authoritative for by contacting > unbound? > > Apparently, this is impossible to do.Yes, the unbound set-up is fine. What you do is put NSD on port 53 and make it the server for external requests. Internal requests go to unbound (on another ip-address, for example an internal ip-address, for example a 127.0.0.x freebsd-jail with unbound in it), and set unbound to send queries to NSD with stub configuration (better than forwards in case the customer's zones have delegations or indirection to the outside internet). Best regards, Wouter> Jan-Piet asked this same question in 2008: > http://unbound.net/pipermail/unbound-users/2008-February/000021.html > >And Oliver Peter did the same, five years later: https://unbound.net/pipermail/unbound-users/2013-November/003075.html> > None ever received a single answer. > > Indeed, by carefully reading the principles behind the unbound + > NSD configuration, it seems that it has been designed to deal only > with the scenario of a corporate network that requires both some > DNS caching (provided by unbound) and a few internal, private > domains being served by NSD, which, however, are never accessible > by the public at large. > > In contrast, on its own, NSD can be (and definitely is) used as an > authorative nameserver for publicly available domain records ? but > without the added 'protection' of having unbound in front of it. > Thus, although it *seems* that unbound + NSD is *similar* to > Varnish + Apache for the web, in fact it's a *different* solution. > > If I'm completely wrong about this, then how can unbound + NSD be > configured so that unbound is able to act as a 'proxy/caching' > nameserver as a frontend to NSD for public domains for which it is > authoritative? > > Thanks in advance for any insights! > > - Gwyn > > > -- "I'm not building a game. I'm building a new country." -- Philip > "Linden" Rosedale, interview to Wired, 2004-05-08 > > > _______________________________________________ nsd-users mailing > list nsd-users at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/nsd-users >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU1OXeAAoJEJ9vHC1+BF+NDMgP/2QsWOrkHxfWD7eOXE5DE/YU W0lJT27USlz++Bg24rITBPMGMV3jACYpVSSvnJfLDx4vAIjcGegjrIYgAlGJ2NXu HPphm41p5+2cuEAkPRtyLSF+e51xRXgFAwx6NS3PzokFv0uY3zdD0EWULZKFtx3w 9AViw/luiJP43duqbtt7yGKH2Vdk11gX3qHhiv2jXRNTRAMqlnSrf5rM3SyWF16d PkiJZUP1pdjjDDjHOxTZInh4TZGUf1j9kAMusyi74sQmzwazuGfIjEL6OxZ9wVMH W5kX1akPwiUzTdU6dcxzd89AtmUtZNS1WVW08fAIB3xBhk/hEXEvUuSGUrgjJWSB j03t2lWGJn+NcIdjE/ZwwR50lA42ShCCivrQk8gD+8RxsSsek7d767xYsLujX3Ke gW0FRl4xlCyQgF5M33QwRXobcSNSHl+zIjLMugzIo9GRSFQs/Xy+i09H+APZ2uvx p86MZzIz4DX9uBi1aW+4t4Z8AcSvEKdtMgSZkF/fPk3FJQV3C9hLGjC6uRYWqLrX JvweN0N3OOipPmw9O9H5AC1keYsiE9ir7ZfmxqYZQx0o/U/oLKj68MJ7xRP0Sz1J 2VQQVp28+6Nwu/y9zt2eAxqRRWrFewEkHWGCNvar6qPbgIn+XZIZa1wQxf4zHg1+ 1Z2HIV5cl2daGrM80d1a =5sH5 -----END PGP SIGNATURE-----