It would be nice if we could add the line
allow-notify: 127.0.0.1 NOKEY
to the server: section instead of in each zone: section. Especially, since
it is a requirement for nsdc update. Or even make it implicit to always
allow this from localhost (f you can't trust localhost, you have more
problems)
Paul
Upgrading to nsd-3 on a production server, I noticed:
Sep 14 12:52:51 ns0 nsd[25801]: could not open file /etc/nsd/ixfr.db for append: Permission denied
Checking the original configure script, I also noticed the setting for
xfrd.state is located in /etc/nsd/.
Since in normal setups, nsd drops permissions from root to nsd, and the
user nsd should not be allowed to write configuration files in /etc/nsd
for security reasons, this is not an ideal default. Also, these files are
not configuration files, but state files, and should really be located
in /var/lib/nsd or /var/cache/nsd.
This would then also make it play better with technologies like SElinux.
I've changed the Fedora spec file to place the files in those directories,
but its worth considering changing the defaults in the configure script
as well.
Paul
Hey Paul,
Thanks for your feedback!
Paul Wouters wrote:
It would be nice if we could add the line
allow-notify: 127.0.0.1 NOKEY
to the server: section instead of in each zone: section. Especially, since
it is a requirement for nsdc update.
We understand how this would make your life "easier".
On the other hand this is not something that is impossible without
changing NSD.
In general we prefer not to add functionality that makes the config file
simpler. It creates more code in NSD (and we have the risk that we end
up creating a full language parser for the config file). So for advanced
config file management we could say use an external macro preprocessor.
The good news is that in this case we consider to create a flag with
limited functionality. We could create a flag in the "server" section,
"allow-localhost-notify" that turns allowing notifies from localhost on.
We will discuss this a bit more internally and let you know what the
concensus is.
Or even make it implicit to always
allow this from localhost (f you can't trust localhost, you have more
problems)
For security reasons, and no really good reasons in favour of it, we
won't make it trust localhost by default.
Regards,
Mark
- --
Mark Santcroos
NLnet Labs
http://www.nlnetlabs.nl/
Mark Santcroos wrote:
Or even make it implicit to always
allow this from localhost (f you can't trust localhost, you have more
problems)For security reasons, and no really good reasons in favour of it, we
won't make it trust localhost by default.
can you explain it a little bit more detailed?
Hi Farkas,
Farkas Levente wrote:
Mark Santcroos wrote:
Or even make it implicit to always
allow this from localhost (f you can't trust localhost, you have more
problems)For security reasons, and no really good reasons in favour of it, we
won't make it trust localhost by default.can you explain it a little bit more detailed?
On multiuser systems you can't (always) trust access from localhost.
In theory, accepting notifies should indeed not be a problem, but
because it accepts packets from the wire there is always a chance that
there is a bug in the handling of it.
Therefore we don't want to make that the default for everyone.
Does this make it more clear?
Regards,
Mark
- --
Mark Santcroos
NLnet Labs
http://www.nlnetlabs.nl/
Hi Paul,
Paul Wouters wrote:
Upgrading to nsd-3 on a production server, I noticed:
Sep 14 12:52:51 ns0 nsd[25801]: could not open file /etc/nsd/ixfr.db for append: Permission denied
Checking the original configure script, I also noticed the setting for
xfrd.state is located in /etc/nsd/.Since in normal setups, nsd drops permissions from root to nsd, and the
user nsd should not be allowed to write configuration files in /etc/nsd
for security reasons, this is not an ideal default. Also, these files are
not configuration files, but state files, and should really be located
in /var/lib/nsd or /var/cache/nsd.This would then also make it play better with technologies like SElinux.
I've changed the Fedora spec file to place the files in those directories,
but its worth considering changing the defaults in the configure script
as well.
You are right that these locations are not the ideal place. It is caused
by the fact that these files were not written to in the previous
versions of NSD.
The downside of changing it is that it has been the default for ages and
that we don't want to surprise users too much with files in other locations.
We will rethink the locations, come up with sensible alternatives and
apply it. We will do it only to the 3.1 feature branch, and not the 3.0
bugfix branch. We will then communicate clearly what is changed so that
users won't be surprised.
Regards,
Mark
- --
Mark Santcroos
NLnet Labs
http://www.nlnetlabs.nl/
Mark Santcroos wrote:
Hi Farkas,
Farkas Levente wrote:
Mark Santcroos wrote:
Or even make it implicit to always
allow this from localhost (f you can't trust localhost, you have more
problems)For security reasons, and no really good reasons in favour of it, we
won't make it trust localhost by default.can you explain it a little bit more detailed?
On multiuser systems you can't (always) trust access from localhost.
In theory, accepting notifies should indeed not be a problem, but
because it accepts packets from the wire there is always a chance that
there is a bug in the handling of it.Therefore we don't want to make that the default for everyone.
Does this make it more clear?
hmm;-) ok i know that, but you assume someone how run nsd on a server
which has user how send so much fake notify to which can cause problem?
and if it's accept notify from anywhere than if the handling is buggy it
still the same problem since the remote system is also can be multiuser
what's more probably this system owner has less control/knowladge over
the other system than his own system.
If I understand this thread correctly:
1. "nsdc notify" requires that localhost has permission to send notify.
2. localhost does not have permission to do this by default.
Have I understood this correctly?
Arnt
Hi,
Arnt Gulbrandsen wrote:
If I understand this thread correctly:
1. "nsdc notify" requires that localhost has permission to send notify.
Well, yes, strictly speaking, the server needs to be enabled to
receive/accept notifies from localhost.
2. localhost does not have permission to do this by default.
Correct.
Regards,
Mark
- --
Mark Santcroos
NLnet Labs
http://www.nlnetlabs.nl/
Hi all,
Not replying to one message in particular.
In this thread we learned that people are still using nsd-notify
directly, or indirectly via "nsdc update".
As mentioned in the release notes of NSD 3.0.0 NSD now has all this
functionality build in. Therefore we at that time deprecated nsd-notify
and planned to remove it in the future.
So we are eager to find out why people are still using it, to see
whether there are good reasons to keep it or to possibly make life
easier for users.
Thanks for your response in advance!
Regards,
Mark
- --
Mark Santcroos
NLnet Labs
http://www.nlnetlabs.nl/
I occasionally use it as a debugging tool. Would be nice if it could
send the SOA serial, too (not sure this is covered by RFC 1996).
-Peter
Peter Koch wrote:
>> So we are eager to find out why people are still using it, to see
>> whether there are good reasons to keep it or to possibly make life
>> easier for users.
It's basically the same reason why people still drive manual cars. We
mistakingly think we know better 
I use it to explicitely send NOTIFY's when I see the primary is still
behind on what I have.
> I occasionally use it as a debugging tool. Would be nice if it could
> send the SOA serial, too (not sure this is covered by RFC 1996).
And for that too.
ldns-notify (from the ldns examples) takes -s soa-serial as option.
Oh, i didn't know that. Does nsd act on that information when it
receives such a notify such as not do an AXFR if it already has the zone
with that serial?
I also use nsd-xfer to grab zones that are not maintained by the local
nsd and then process the zones (add DS, SSHFP, etc and sign) and inject
the signed zones back into the local nsd.
Paul
Paul Wouters wrote:
ldns-notify (from the ldns examples) takes -s soa-serial as option.
Oh, i didn't know that. Does nsd act on that information when it
receives such a notify such as not do an AXFR if it already has the zone
with that serial?
Yes it does.
Best regards,
Wouter