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

Thu Sep 23 13:27:47 UTC 2021

> This should be the right workaround at this moment, so I wonder why it
didn’t work.

It seems like it does after all, I messed up my checks. Thanks.

However our procedure runs named-checkconf before restarting named, and no
error is brought up when running it, I'm guessing this should be mentioned
that the use of master/slave [in this specific option] is obsolete?

Should I also anticipate moving all of the master/slave options from the
zone configuration asap?

Thanks,

Thibaud

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

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210923/46f1fa05/attachment-0001.htm>