rndc addzone and file name

[Kalman Feher]

On 14/01/11 9:57 AM, "Peter Andreev" <andreev.peter at gmail.com> wrote:

> 2011/1/13 Alan Clegg <aclegg at isc.org>:
>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>> 
>>> I've executed
>>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1"; };'
>>> 
>>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>>> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>>> 
>>> The question was: can I force rndc addzone to use specific file (for
>>> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>> 
>> No.  The file is a hash of the view in which the data resides.
>> 
>> "it's automated, just leave it alone and it won't hurt anyone"  :)
>> 
>> AlanC
> 
> Thank you very much, Alan. Could you describe why it was made so?
> I asking because this feature could be very helpful for me, but such
> restriction does its completely useless.
I believe it was related to the difference between legal file names and
legal view names. Thus to avoid problems, the view name is hashed.

I can't think of a situation where you would not know your view name and
that view name would change over time. So if you wish to edit the file in a
script, you can still do so, just use the hashed name. But there seems to be
a general preference not to change anything in that file by hand or script.
And the file naming scheme may change in future releases, if my change log
memory is correct.

However, I'm curious regarding your requirements and why this restriction
causes them to be broken? For myself I can think of some occasions:
1. Moving from secure to insecure (due to operational changes like transfers
between registrars).
2. ACL changes

Ideally there would be an "rndc editzone" with similar syntax to addzone.
Thus allowing you to update the zone statement without hand/script editing
the file. And protecting you from future file name changes.
>> 
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
> 
> 

-- 
Kal Feher