"named-checkconf -z" exit status reflects only the last view loaded

Summary

When processing a named.conf with views, the exit status of 'named-checkconf -z' only reflects whether there were errors whilst loading the final view, even though all zones in all views are processed and errors printed as appropriate.

BIND version used

BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Darwin x86_64 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
built by make with '--prefix=/usr/local/Cellar/bind/9.16.2' '--with-json-c' '--with-openssl=/usr/local/opt/openssl@1.1' '--with-libjson=/usr/local/opt/json-c' '--with-python-install-dir=/usr/local/Cellar/bind/9.16.2/libexec/vendor/lib/python3.8/site-packages' '--with-python=/usr/local/opt/python@3.8/bin/python3' '--without-lmdb' 'CC=clang' 'PKG_CONFIG_PATH=/usr/local/opt/json-c/lib/pkgconfig:/usr/local/opt/libuv/lib/pkgconfig:/usr/local/opt/openssl@1.1/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:/usr/local/opt/xz/lib/pkgconfig:/usr/local/opt/python@3.8/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/10.15'
compiled by CLANG 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.59)
compiled with OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled

default paths:
  named configuration:  /usr/local/Cellar/bind/9.16.2/etc/named.conf
  rndc configuration:   /usr/local/Cellar/bind/9.16.2/etc/rndc.conf
  DNSSEC root key:      /usr/local/Cellar/bind/9.16.2/etc/bind.keys
  nsupdate session key: /usr/local/Cellar/bind/9.16.2/var/run/named/session.key
  named PID file:       /usr/local/Cellar/bind/9.16.2/var/run/named/named.pid
  named lock file:      /usr/local/Cellar/bind/9.16.2/var/run/named/named.lock

Steps to reproduce

Given the configuration files listed later on, and intentionally creating an error by not creating a missing.net zone file:

Running named-checkconf -z against named-missing-last.conf gives an exit status of 1 as expected:

$ named-checkconf -d -z named-missing-last.conf 
loading "example.net" from "example.net" class "IN"
zone example.net/IN: loaded serial 1
loading "missing.net" from "missing.net" class "IN"
zone missing.net/IN: loading from master file missing.net failed: file not found
zone missing.net/IN: not loaded due to errors.
missing/missing.net/IN: file not found
$ echo $?
1

Running named-checkconf -z against named-missing-first.conf should also give an exit status of 1, but does not:

$ named-checkconf -d -z named-missing-first.conf 
loading "missing.net" from "missing.net" class "IN"
zone missing.net/IN: loading from master file missing.net failed: file not found
zone missing.net/IN: not loaded due to errors.
missing/missing.net/IN: file not found
loading "example.net" from "example.net" class "IN"
zone example.net/IN: loaded serial 1
$ echo $?
0

What is the current bug behavior?

The exit status of named-checkconf -z reflects whether there was an error loading the zones in the final view.

What is the expected correct behavior?

The exit status of named-checkconf -z should reflect whether there was an error loading the zones in any view.

Relevant configuration files

named-missing-first.conf:

view "missing" {
    zone "missing.net" {
        type master;
        file "missing.net";
    };
};

view "example" {
    zone "example.net" {
        type master;
        file "example.net";
    };
};

named-missing-last.conf:

view "example" {
    zone "example.net" {
        type master;
        file "example.net";
    };
};

view "missing" {
    zone "missing.net" {
        type master;
        file "missing.net";
    };
};

example.net zone file:

$TTL 5

@ SOA ns1.example.net. hostmaster.example.net. 1 300 300 300 300
@ NS  ns1.example.net.
ns1 A   127.0.0.1

and no missing.net zone file

Possible fixes

bin/check/named-checkconf.c: load_zones_fromconfig() - 'result' (taken from 'tresult') variable appears to be reset by each call to configure_view.