(the feature does sound nice,
Thank you.
... altough lack of authentication makes using it pretty pointless IMHO),
For most situations, I agree with you. It so happens that updates without authentication are fine for the environment I'm setting up. My focus was on implementing the functionality that I need, although of course I don't want to break anything, or prevent anyone else extending this further. There's no reason why authentication (and the other missing bits) shouldn't be added. But I thought I'd got to a stable enough point to submit. As implemented in the patch, updates are permitted on all zones. In retrospect, and given your comment, I think I was wrong. I should allow updates only in zones specified using my new --*zonefile options. That way there is no change of behaviour whatever for people continuing to use the original --*zone options. I certainly don't want to open up security holes in existing installations. I shall fix this before submitting a new patch to the bug list (as requested by itamar).
this is just unacceptable.
If an exception is raised, the app crashes, or the machine loses power between those two renames, your original zone file has been renamed and your DNS server won't start.
Point taken. I'll do a single os.rename() as you suggest.
Also, nice y2.043k trap there, I don't think many have been able to write ones targeting that exact date.
Hmmm.. Not sure what you mean. If I read the Python 2.4 documentation correctly, these numbers will be handled as long integers. The subtraction just converts the 4-digit year at the start to 'years since 2000'. Am I missing something? If so, please say, and I can handle the year separately. Thanks for the comments. Jeff