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

Thu Sep 23 12:41:28 UTC 2021

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)
ondrej at isc.org

> On 23. 9. 2021, at 13:51, Thib D <thibmac0241 at 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ý <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
> 