From: mdb@regal.cisco.com (Mark D. Baushke)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Problem: SOA record in INCLUDE file
Date: 16 Dec 92 02:23:00
Organization: cisco Systems Inc., Menlo Park, CA, USA
Distribution: comp
NNTP-Posting-Host: regal.cisco.com
In-reply-to: verghese@apollo.hp.com's message of Mon, 14 Dec 1992 20:02:21 GMT

On Mon, 14 Dec 1992 20:02:21 GMT, verghese@apollo.hp.com (Ben Verghese) said:

ben> I have observed a problem with the namserver when the SOA record
ben> for a domain is included from another file using $INCLUDE. An
ben> error message is generated through syslog saying that no SOA
ben> record was found. All queries for records in that domain are
ben> answered as non-authoritative. I looked at the BIND code (version
ben> 4.37?) and this is what the code does. It seems to me that SOA
ben> records should not be shared across named database files for
ben> different domains. Can someone tell me if there is a written or
ben> unwritten convention about SOA records and INCLUDE files.

ben> thanks in advance for any help,

The following patch may be of help to you if you have 4.8.3 sources.
It may also work with older versions of the bind sources.

	-- Mark
	mdb@cisco.com

	   --------------- archive message ---------------

From: merlin@PONY.CIS.SMU.EDU (David Hayes)
Subject: SOA records in $INCLUDE files
Date: 30 Oct 90 05:47:00 GMT

I have acquired Bind 4.8.3, and am running this on a NeXT under
their Mach 1.0 OS.  I have noted the following problem:

In our configuration, we use a single SOA record in a separate
data file.  This SOA file is incorporated through a $INCLUDE
directive into each of our DNS data files.  This allows us to keep
a consistent serial number throughout all our different domains.
It also means that there is only one SOA serial number for the
staff to change when they make an update.

The distributed form of db_load.c does not support this.  The
problem is in the db_load() function, which checks for SOA
records.  It counts them in the variable read_soa, and checks on
exit to be sure that only one SOA record.

Unfortunately, read_soa is an automatic variable.  When an
$INCLUDE file is processed, db_load is called recursively.  A new
copy of read_soa is created in the process, and it is this copy
which counts the $INCLUDE-ed SOA record.  The count is lost when
the inner db_load function returns.  The main db_load still does
not have a count in read_soa, and indicates an error on its exit.

The following patch solves this problem.  I have made read_soa a
static variable.  I clear it when db_load is entered without the
flag argument doinginclude.  In this fashion, the SOA record read
withing the $INCLUDE file is maintained, and available to the
top-most db_load for the error check prior to function return.

	David Hayes, Manager of Computer Operations
	SMU School of Engineering & Applied Science

*** named/db_load.c.orig	Mon Oct 29 21:13:30 1990
--- named/db_load.c	Mon Oct 29 21:19:05 1990
***************
*** 117,128 ****
  	char *op;
  	int c;
  	int class, type, ttl, dbflags, dataflags;
!         int read_soa = 0;	/* number of soa's read */
  	struct databuf *dp;
  	FILE *fp;
  	int slineno, i, errs = 0, didinclude = 0;
  	register u_long n;
  	struct stat sb;
  
  #ifdef DEBUG
  	if (debug)
--- 117,131 ----
  	char *op;
  	int c;
  	int class, type, ttl, dbflags, dataflags;
!         static int read_soa;	/* number of soa's read */
  	struct databuf *dp;
  	FILE *fp;
  	int slineno, i, errs = 0, didinclude = 0;
  	register u_long n;
  	struct stat sb;
+ 
+ 	if (!doinginclude)
+ 	    read_soa = 0;
  
  #ifdef DEBUG
  	if (debug)