Opened 9 years ago

Closed 9 years ago

#670 closed defect (fixed)

identify a secondary zone

Reported by: jreed Owned by: vorner
Priority: very high Milestone: Sprint-20110419
Component: secondary manager Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 8.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

zonemgr currently considers all of the zones in sqlite3 db as secondary.

We need to configure zones as secondary specifically.

As it is now, a zone could get overwritten. This could be a security issue.

Subtickets

Change History (10)

comment:1 Changed 9 years ago by stephen

  • Milestone changed from A-Team-Task-Backlog to A-Team-Sprint-20110316

comment:2 Changed 9 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:3 Changed 9 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to reviewing

Hello

I think it is ready for review. But I'm not exactly sure inside the zone manager, it seems to be quite chaotic piece of code (or it might be just me, getting lost in python). So, don't spare me.

It loads only the zones listed in secondary_zones variable, instead of everything that is in the database.

I also noticed it kind of relies on sqlite3 data source and completely ignores the class of zone. Is some larger-scale rewrite of zone manager planned?

The changelog could be:

[func]*      vorner
Zone manager no longer thinks it is secondary master for all zones in the
database They are listed in Zonemgr/secondary_zones configuration variable
(in the form [{"name": "example.com", "class": "IN"}]).

comment:4 Changed 9 years ago by stephen

  • Milestone A-Team-Task-Backlog deleted

Milestone A-Team-Task-Backlog deleted

comment:5 Changed 9 years ago by shane

  • Milestone set to Sprint-20110405

comment:6 Changed 9 years ago by jelte

  • Owner changed from UnAssigned to jelte

comment:7 follow-up: Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

While this does seem to fix the stated problem, I don't think it works as one would expect;

Now that there is a secondaries list, I would expect to be able to use that to add zones; i.e. add a zone to said list, specify the master(s), and it should start transferring them (it now returns a seemingly unrelated error about a SOA, which is technically correct if you know what it's doing, but not really helpful). Note that this is not a comment on this ticket, but a suggestion for a 'new' feature :) (which probably involves more substansive changes to zonemgr as your comment already suggests). Other suggestions for improvement; initial testing makes it appear that the refresh interval is only updated on start, and not changed when the SOA value changes, and the logs at least suggest that it actually does a full AXFR, even if the zone has not been changed (have not checked whether this is actually the case). Also not really relevant for this ticket though.

One problem that may be relevant to this ticket is that the zone name one sets in secondary_zones must be an FQDN, if the root dot is missing it'll error on not finding a SOA (it should imo either error on not being an fqdn, or it should add the root dot itself).

Small python nit: dicts have their own copy() method so copy.copy() is not necessary on line 407

Rest of the code looks ok (barring that work mentioned before, shall we open separate task(s) for that? I think we'll find much more work to do, but for now this can be merged.

comment:8 in reply to: ↑ 7 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Hello

Replying to jelte:

Now that there is a secondaries list, I would expect to be able to use that to add zones; i.e. add a zone to said list, specify the master(s), and it should start transferring them (it now returns a seemingly unrelated error about a SOA, which is technically correct if you know what it's doing, but not really helpful). Note that this is not a comment on this ticket, but a suggestion for a 'new' feature :) (which probably involves more substansive changes to zonemgr as your comment already suggests). Other suggestions for improvement; initial testing makes it appear that the refresh interval is only updated on start, and not changed when the SOA value changes, and the logs at least suggest that it actually does a full AXFR, even if the zone has not been changed (have not checked whether this is actually the case). Also not really relevant for this ticket though.

Hmm, right, good point. Or there should be at last a command „import zone“ or something, because having to carry the zone in the first time on floppy diskettes shouldn't be necessary, when it can be transfered at later time over the network.

One problem that may be relevant to this ticket is that the zone name one sets in secondary_zones must be an FQDN, if the root dot is missing it'll error on not finding a SOA (it should imo either error on not being an fqdn, or it should add the root dot itself).

It adds the dot internally if it's missing now.

Small python nit: dicts have their own copy() method so copy.copy() is not necessary on line 407

ACK

Rest of the code looks ok (barring that work mentioned before, shall we open separate task(s) for that? I think we'll find much more work to do, but for now this can be merged.

Yes, would you like to create the tickets?

Are the fixes/changes OK now?

Thanks

comment:9 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

Looks good, please merge.

comment:10 Changed 9 years ago by vorner

  • Estimated Difficulty changed from 0.0 to 8
  • Resolution set to fixed
  • Status changed from reviewing to closed

Ok, thanks, closing

Note: See TracTickets for help on using tickets.