Bug 1744081
| Summary: | bind-9.11.4-9.P2.el7.x86_64 doesn't allow same file for multiple zone | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sham Antony <santony> |
| Component: | bind | Assignee: | Petr Menšík <pemensik> |
| Status: | CLOSED ERRATA | QA Contact: | Robin Hack <rhack> |
| Severity: | high | Docs Contact: | Mariya Pershina <mpershin> |
| Priority: | unspecified | ||
| Version: | 7.8 | CC: | knemcova, mpershin, pemensik, rhack, rwahyudi, sbalasub, tcrider, thozza |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | thozza:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | bind-9.11.4-19.P2.el7 | Doc Type: | Bug Fix |
| Doc Text: |
.The same zone file can now be included in multiple views or zones in BIND
BIND 9.11 introduced an additional check to ensure that no daemon writable zone file is used multiple times, which would result in creating errors in zone journal serialization. Consequently, configuration accepted by BIND 9.9 was no longer accepted by this daemon. With this update, the fatal error message in configuration file check is replaced by a warning, and as a result, the same zone file can now be included in multiple views or zones.
Note that using an in-view clause is recommended as a better solution.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-29 19:25:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1780577 | ||
This issue cannot be working fine in any version. It would just overwrite the files at random. Slave zones contain no longer relative names but always absolute. That would make offered data depent on whatever was updated last. It does not start for a very good reason. If the customer use it this way, he should definitely stop doing that. Server refuses it for a good reason. what would return?: $ dig @server-ip -t SOA -q example.com $ dig @server-ip -t SOA -q redhat.com Whould it serve different data? It is still possible to share common file with zone data. But it must be read-only. That means type has to be master, dynamic updates and dnssec-maintain has to be disabled on such zone. If it is different, there has to be different files. I think I would close this bug with Not a bug, just have to recheck behaviour in old version. I do not think this should or would be fixed. Customer configuration , they have same set of zones both in internal and external view,
view "internal"
{
match-clients { internal_clients; }; <---------- acl
zone "example.com" IN {
type slave;
file "slave/example.db";
masters { 10.10.10.10; };
};
};
view "external"
{
match-clients { external_clients; }; <-------------- acl
zone "example.com" IN {
type slave;
file "slave/example.db";
masters { 10.10.10.10; };
};
};
Version bind-9.11.4-9.P2.el7.x86_64 fails to start with this configuration , but it works fine with prior version bind-9.9.4-74.el7_6.1.x86_64
Workaround with bind-9.11.4-9.P2.el7.x86_64 , having different "file" location
As customer has huge number of zones, they are not ready to go with workaround.
=================
what would return?:
$ dig @server-ip -t SOA -q example.com
$ dig @server-ip -t SOA -q redhat.com
Version bind-9.9.4-74.el7_6.1.x86_64 <=====
# dig @127.0.0.1 -t soa -q example.com
;; ANSWER SECTION:
example.com. 86400 IN SOA redhat.com. root.example.com. root 42 10800 900 604800 86400
$ dig @127.0.0.1 -t SOA -q redhat.com
;; ANSWER SECTION:
redhat.com. 86400 IN SOA redhat.com.example.com. root 42 10800 900 604800 86400
In 9.11, new in-view zone parameter could be used second time. It creates just link to original view, using the same file with the same data. As an advantage, it fetches the zone just single time.
view "internal"
{
match-clients { internal_clients; }; <---------- acl
zone "example.com" IN {
type slave;
file "slave/example.db";
masters { 10.10.10.10; };
};
};
view "external"
{
match-clients { external_clients; }; <-------------- acl
zone "example.com" IN {
in-view "internal";
};
};
This way, it is well defined which is primary view ("internal") and which is just using the same data. This is not workaround, this is clear fix.
Only possible fix would be emitting warning instead of hard error. And if zone parameters are the same, use in-view without configuration file change. Not sure this should be changed automatically.
When using in-view, data are loaded into memory just once and share also in-memory structures. It saves memory usage compared to previous versions, where the same file would be loaded multiple times to separate structures. Simple yum update should not crash a system. Its very fortunate that we have a fleet of DNS server running a mix of RHEL6&7 which saves us from having a sitewide outage. But this also means that we will need to accommodate different configuration branch for different bind version If this feature is that important then maybe backport it to older bind?? For now, can we please proceed with producing a warning instead of hard error? (In reply to Rianto Wahyudi from comment #7) > Simple yum update should not crash a system. > > Its very fortunate that we have a fleet of DNS server running a mix of > RHEL6&7 which saves us from having a sitewide outage. > But this also means that we will need to accommodate different configuration > branch for different bind version > If this feature is that important then maybe backport it to older bind?? > > For now, can we please proceed with producing a warning instead of hard > error? Oh yes, that is quite possible. Just fix wrong configuration and it would run well even on a new system. Please migrate your configuration for both versions, ensure every view writing the zone has unique file it writes into. All other configurations are broken and were broken also before. They worked just sometime and unreliably. New features not possible on older releases, according to our policy. Such configurations would fail on newer versions anyway, proper way is fixing the configuration. But I guess it would be possible emitting just warning instead of hard error in RHEL 7, since it worked somehow originally. *** Bug 1762359 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (bind bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3871 |
Description of problem: bind-9.11.4-9.P2.el7.x86_64 doesn't allow same file for multiple zone Version-Release number of selected component (if applicable): bind-9.11.4-9.P2.el7.x86_64 How reproducible: Configure named with following configuration zone "example.com" { type slave; file slaves/example.db <======= }; zone "redhat.com" { type slave; file slave/example.db; <=========== }; Actual results: /etc/named.conf:xx: writeable file 'slave/example.db': already in use: /etc/named.conf:xx Expected results: Bind should start Additional info: It's working fine with "bind-9.9.4-74.el7_6.2.x86_64"