Bug 667 - Inconsistent behavior when loading zone.list manually _and_ using database:
Inconsistent behavior when loading zone.list manually _and_ using database:
Status: ASSIGNED
Product: NSD
Classification: Unclassified
Component: NSD Code
4.1.x
x86_64 Linux
: P5 major
Assigned To: NSD team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-20 18:03 CEST by Bjørnar Ness
Modified: 2017-06-15 11:57 CEST (History)
2 users (show)

See Also:


Attachments
IXFR of the first zone that reported issues (9.94 KB, text/plain)
2017-06-15 11:57 CEST, Anand Buddhdev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bjørnar Ness 2015-04-20 18:03:24 CEST
When loading zone.list manually (because it is not possible to bulk-load using
nsd-control, and loading one zone at a time is too slow) together with using
database nsd seems to lock up in a axfr loop, never acually beeing able to serve a single zone, even tho the zones are transferred correctly.

I also tried stopping nsd, removing database and xfrd.state, then starting
again, but does not work. Only "fix" I have found to this is disabling the
database. Then everything works as expected.

I would tho like better scheduling of zone-refresh when having a huge amount
of zones.
Comment 1 Wouter Wijngaards 2015-04-21 09:02:43 CEST
Hi Bjørnar,

I think what is happening is disk activity with that database.  Did you know that NSD has a mode where you put database: "" in nsd.conf.  Then it does not use the database at all (it writes the zonefile text files periodically, if you want).  That uses less memory and less disk access, and perhaps that will speed things up?

NSD will schedule zone transfers and this does not actually lock up the zone service process, so what I understand from what is happening to you is that things are slow.

Best regards,
   Wouter
Comment 2 Bjørnar Ness 2015-04-21 15:07:09 CEST
(In reply to Wouter Wijngaards from comment #1)
> Hi Bjørnar,
> 
> I think what is happening is disk activity with that database.  Did you know
> that NSD has a mode where you put database: "" in nsd.conf.  Then it does
> not use the database at all (it writes the zonefile text files periodically,
> if you want).  That uses less memory and less disk access, and perhaps that
> will speed things up?

Yes. When I said "disable database", I ment setting database: ""
This however does look like a bug. We have had it running for a long time,
and it never seems to catch up. It does the AXFR's, but repeats them over
and over in a seemingly endless loop, without ever writing a file (even when nsd-control write) or answering queries.
 
> NSD will schedule zone transfers and this does not actually lock up the zone
> service process, so what I understand from what is happening to you is that
> things are slow.

Its not all that slow, its just a lot of zones, and a endless loop, for some
reason. Disabling the database makes all these problems disappear.
Comment 3 Wouter Wijngaards 2015-04-21 15:10:24 CEST
Hi Bjørnar,

It sounds like the zone transfers are not completing successfully.  That is why NSD would retry, and keep retrying because there is no succesfull completion.

Are the TSIG keys configured wrong, or the source-address of the outgoing AXFR is not correct and thus AXFRs are denied?   Is that the issue?  Are there clues is syslog (or the log file) about what is going wrong (errors?)?

Because, you are right that after an initial flow of many transfers it should stop with that and run.

Best regards,
   Wouter
Comment 4 Anand Buddhdev 2017-06-15 11:57:59 CEST
Created attachment 407 [details]
IXFR of the first zone that reported issues