Breaking change between 9.16.20 and 9.16.21 (check-names) ?
Ondřej Surý
ondrej at isc.org
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
>
More information about the bind-users
mailing list