rndc addzone and file name

[Kalman Feher]

On 14/01/11 12:51 PM, "Peter Andreev" <andreev.peter at gmail.com> wrote:

> 2011/1/14 Kalman Feher <kalman.feher at melbourneit.com.au>:
>> 
>> 
>> 
>> 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.
> 
> You haven't understood. I have several includes within one default
> view and I need to add zones to them. Different zones to different
> includes. For me name of view doesn't matter.
Bear in mind that includes make no sense in the context of rndc addzone
functionality. Since include functionality is only relevant when
parsing/reparsing the configuration file. Since the addzone feature bypasses
this to make adding zones not require parsing named.conf, it is circular to
use the include feature applicable to said parsing.

You can still use both methods to add a zone. Just not both to add the same
zone. 

Consider why you use those includes, then reconsider those reasons in light
of the addzone function. Most people use includes to:

1.organise files and configs to keep them sane.
2.allow an external system to drop/<make changes to> configs in a directory
without touching the main config file.

With rndc addzone:
1. Is somewhat improved and worsened. Your zone statements are together and
formatted neatly in a separate file. But comments are absent and zones are
all listed together, without any groupings you may find convenient.
2. The external system would now have to use rndc addzone/delzone to add and
remove the domain. 
2.a Since the domain is now dynamic, editing the zone file is now replaced
with nsupdate. The caveat being that the zone statement itself is not
editable as far as I can see. At least not in a manner guaranteed to work in
future releases.

If using nsupdate to edit zone contents or adding domains using rndc, break
your current system or way of doing things, then the feature is not for you.

What were you hoping this feature would give you? Perhaps there is already a
way to achieve it without using the addzone feature..

> I believe that much more flexible and convenient way is to allow users
> to specify file than such non-transparent mechanism which has been
> realised.

> 
> And I don't like idea that bind user must have permissions to write to
> namedb directory. For now without such permissions I get "permission
> denied" error when trying to delete zone.
> 
>> 
>> 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
>> 
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
> 
> 

-- 
Kal Feher