Hi Thib, thanks, this is much better and I can now safely say, this has been already reported and tracked as https://gitlab.isc.org/isc-projects/bind9/-/issues/2911
The only thing weird is: > Then, I tried switching from > check-names master warn; > to > check-names primary warn; This should be the right workaround at this moment, so I wonder why it didn’t work. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 23. 9. 2021, at 13:51, Thib D <thibmac0...@gmail.com> wrote: > > 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 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ý <ond...@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) > ond...@isc.org > > > On 23. 9. 2021, at 10:54, Thib D <thibmac0...@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@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
