Problem with secondary NS using bind9.1.0

Jim Reid jim at rfc1035.com
Tue Feb 6 16:08:51 UTC 2001


>>>>> "Klaus" == Klaus Hackenberg <hackekc6 at sunu513.rz.ruhr-uni-bochum.de> writes:

    Klaus> High, I just started using bind9.1.0 on our central
    Klaus> nameserver and observe that the lines in zone files of
    Klaus> secondary zones generated by bind9.1.0 have a strange
    Klaus> format.
  
    Klaus>   bind9.1.0 generates lines like the following
    Klaus> ===========================================================
    Klaus> $ORIGIN xyz.ruhr-uni-bochum.de.  abacus A 134.147.aa.bb
    Klaus> ===========================================================

    Klaus>   whereas bind8.2.2-P7 generated
    Klaus> ===========================================================
    Klaus> $ORIGIN xyz.ruhr-uni-bochum.de.  
    Klaus> abacus 86400 IN A 134.147.aa.bb
    Klaus> ===========================================================

    Klaus>   So you can not use a secondary data file as a master file
    Klaus> (which is helpful in some situations) Is this a bug or
    Klaus> intended behaviour?

Both formats are perfectly valid syntax for a zone file. See RFC1035.
Either file can be successfully loaded by any name server which
conforms to the zone file syntax described in RFC1035. BTW, slave zone
files can be used master files, though they're never pretty to read.
The way BIND9 writes out slave zone files is just different from the
way BIND8 wrote these files. All that matters is that the zone
contents are the same, no matter the order the resource records are
written or the format of the file. Both BIND implementations get this
right. They differ on irrelevant detail. Who ever needs to look at the
slave zone files apart from the name server?


More information about the bind-users mailing list