Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Thib D]

Hi Ondrej,

Thanks for your reply,

I'm afraid I am unable to share any more detail regarding the zone content
because it's customer data. I will use example.com and try to make the most
sense out of the issue.

Our upgrading procedure is to recompile the binaries provided in
https://ftp.isc.org/isc/bind9/9.16.21/bind-9.16.21.tar.xz , named is
compiled on a Debian Buster OS here.
After the successful compilation, named is restarted (systemd service).

After zones are loaded, a few errors can be seen on zones with these
check-names error

> Sep 23 10:42:07 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> loading from master file dbase/m/com/e/named.example.com failed: bad
> owner name (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> not loaded due to errors.
>

This causes our server to answer SERVFAIL for a few of the affected zones.

At line 36 of the zonefile of example.com, there is this record (under
*example.com
<http://example.com/> *origin) :

*._sip._tls A 12.34.56.78


On the secondary server hosting that same zone, I am not seeing any unusual
behaviour after 9.16.21 upgrade:

Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:20: _tcp.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:22: *._tcp.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:25: *._sipfederationtls._tcp.example.com: bad owner
> name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:27: _tls.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:29: *._tls.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:32: *._sip._tls.example.com: bad owner name
> (check-names)
>

Note that the content of the zone is a bit different, since AXFR does alter
the zone format a little bit (both version "read" the same though (?))

> $ORIGIN _sip._tls.example.com
> * A 12.34.56.78
>

I guess this is a wrong kind of record here,but fine, since I'm not able to
fix these, I'm using the option I mentioned earlier :

check-names master warn;


After seeing this the first time, I decided to rollback to 9.16.20
following the same procedure, which is first compile then restart with
systemd.
After loading all the zones we can see that the "loading from master file
dbase/m/com/e/named.example.com failed" is gone and the zone loaded, just
like on secondary-host:


> Sep 23 10:42:35 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:38: *._tcp.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:39: *._tls.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:51: _tcp.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:52: _tls.example.com: bad owner name (check-names)


First thing I had in mind was to double check the changelog to see if I
misunderstood anything.

Then, I tried switching from

> check-names master warn;

to

> check-names primary warn;

or

> check-names master ignore;


but nothing changed.

Hope that helps, even with the anonymized data. I understand running zones
configured like this is not quite recommended, but that's a different topic.
I will update this mail thread if I find anything else worth mentioning.

Regards,
Thibaud



Le jeu. 23 sept. 2021 à 11:47, Ondřej Surý <ondrej at isc.org> a écrit :

> Hi,
>
> we cannot really help you if anonymize everything and don’t provide any
> details at all.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at isc.org
>
> > On 23. 9. 2021, at 10:54, Thib D <thibmac0241 at gmail.com> wrote:
> >
> > Hello,
> >
> > I am currently rolling the 9.16.21 on a few bind servers. Most of the
> servers rolled the update correctly except for one in particular (this is a
> primary server of 2 other secondaries).
> >
> > Here is the issue logged
> >
> > Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
> master file [...] failed: bad owner name (check-names)
> > Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
> master file [...] failed: bad owner name (check-names)
> >
> > I am aware of the issues with these zone configuration, this is why my
> named.conf has this parameter, which I believe is useful to tell named to
> keep loading the affected zone and log an issue, am I correct ?
> >
> > check-names master warn;
> >
> > Correct me if I'm wrong the 9.16.21 CHANGES do not mention any change on
> this behaviour ? More surprisingly, it's only affecting one particular
> server, one with a pretty similar config than the others on the zone load
> policies.
> >
> > Did I miss something in the changelog here ?
> >
> > Thanks !
> >
> >
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210923/d5fea1e4/attachment-0001.htm>