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