Bug 2230642

What is the nature and description of the request?
Considering the change introduced in BIND v9.11 enforcing that no writable zone files be duplicated (REF: https://bugzilla.redhat.com/show_bug.cgi?id=1744081 for context) the end-user strongly believes that the example RFC1912 zone file provided by the RPM(/usr/share/doc/bind/sample/etc/named.rfc1912.zones) is incorrect as it references the same file name multiple times. While not an issue as written as the example file is not configured to make the zone file writable, the customer contends that when configuring a secondary server the zone files should be made writable, which causes an error starting named if the file names are not also changed. Customer requests that the example file be updated to use unique file names to avoid this issue. 


The lines of interest are 19 and 25 then 31 and 37 in this example taken from bind-9.16.23-13.el9.x86_64.rpm


[tminor@tminor pkg_extract]$ cat -n usr/share/doc/bind/sample/etc/named.rfc1912.zones | grep -E 'file|allow'
    10    // See /usr/share/doc/bind*/sample/ for example named configuration files.
    19        file "named.localhost";
    20        allow-update { none; };
    25        file "named.localhost";
    26        allow-update { none; };
    31        file "named.loopback";
    32        allow-update { none; };
    37        file "named.loopback";
    38        allow-update { none; };
    43        file "named.empty";
    44        allow-update { none; };
[tminor@tminor pkg_extract]$ 
The customer believes these lines should reference unique file names in the event that these entries are made writable. If the user makes the files writable but does not change the file names for uniqueness, the following error is thrown when starting named:


Jun 30 13:52:11 rhel9.vm systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
Jun 30 13:52:11 rhel9.vm bash[14847]: /etc/named.rfc1912.zones:25: writeable file 'named.localhost': already in use: /etc/name>
Jun 30 13:52:11 rhel9.vm systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE
Jun 30 13:52:11 rhel9.vm systemd[1]: named.service: Failed with result 'exit-code'.

The inability to duplicate file names is discussed in KCS:

  The Bind Service Does Not Allow Same File For Multiple Zones
  https://access.redhat.com/solutions/4569171

The correct method used there is to define the zone once within a view, then for any additional zones that use the same file, place them in a separate view and reference the original view with the in-view option.

Reference sources:

https://www.mail-archive.com/bind-users@lists.isc.org/msg20554.html
https://kb.isc.org/docs/aa-00851

However, this methodology is likely not appropriate to the example file. 

Proposed modified file:

/usr/share/doc/bind/sample/etc/named.rfc1912.zones
-------------
zone "localhost.localdomain" IN {
	type master;
	file "named.localhost.localdomain";
	allow-update { none; };
};

zone "localhost" IN {
	type master;
	file "named.localhost";
	allow-update { none; };
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
	type master;
	file "named.loopback.ipv6";
	allow-update { none; };
};

zone "1.0.0.127.in-addr.arpa" IN {
	type master;
	file "named.loopback";
	allow-update { none; };
};

zone "0.in-addr.arpa" IN {
	type master;
	file "named.empty";
	allow-update { none; };
};
-------------


Why does the customer need this?
Requests this change to ease deployment. 

How would the customer like to achieve this? 
Update to package-provided example file establishing file name uniqueness at installation. 

For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Trivial text update, testing likely not required. 

Is there already an existing RFE upstream or in Red Hat Bugzilla?
No.

Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)?
All forthcoming releases of bind.

Is the sales team involved in this request and do they have any additional input?
No. 

List any affected packages or components.
bind-VERSION.ARCH , no other packages currently supply the file in question. 

Would the customer be able to assist in testing this functionality if implemented?
Testing is likely not required, but the customer would be happy to test if my assessment is incorrect.