need help for bind 8.2.3.

Jim Reid jim at rfc1035.com
Mon Apr 9 19:57:03 UTC 2001


>>>>> "Werner" == Werner Spirk <Werner.Spirk at lrz-muenchen.de> writes:

    Werner> With bind 8.2.3 RRs are now stronger checked: Records
    Werner> belonging to a child zone but are placed within the parent
    Werner> zone are no longer allowed and an error message will be
    Werner> written into the logfile like that:

    Werner> Feb 26 15:16:26 dns1 named[21716]: zone:
    Werner> 187.129.IN-ADDR.ARPA/IN: non-glue record below bottom of
    Werner> zone: 254.90.187.129.IN-ADDR.ARPA/PTR

    Werner> And the parent zone will be blocked ( may be that is
    Werner> called "zone cut" within the source ns_maint.c where this
    Werner> is done ) so zone transfers for the secondaries cannot be
    Werner> done.

Correct. Get rid of the data that should never have been in the zone
file(s) -- the non glue resource records that live under the zone cut
-- and the problem will go away.

    Werner> We are using scripts for maintaining a lot of zones that
    Werner> produce automatically PTR records for parent zone. Many of
    Werner> child zone especially reverse zones are delegated to other
    Werner> name servers. So we have troubles as described above.

So fix those scripts.

    Werner> We have to restruct our database which cannot be done easily.

Too bad. It's a pity you didn't start out with a correct design of
your database and scripts. If you had, you wouldn't be generating
illegal zone files.

    Werner> My question is: is there a workaround for our site that
    Werner> only warning messages without consequences for the parent
    Werner> zones come up.

No. What you've been doing has been illegal. BIND8 used to tolerate
that. It doesn't any more. There is no config file option to enable
this illegality. And hacking the BIND8 source code will take you
longer than fixing the underlying problem: your broken scripts for
creating zone files. Who's to say what other errors might be
introduced by your modifications? Why give yourself a software
maintenance headache? Why not solve the real problem?


More information about the bind-users mailing list