$INCLUDEing an SOA record

[Mark.Andrews at nominum.com]

	DNS_R_SEENINCLUDE was failing to propogate back up the calling
	stack to the zone maintence level.

	The following is from 9.2 but will apply to 9.1.1 with some
	fuzz reported.

	Mark

Index: lib/dns/db.c
===================================================================
RCS file: /proj/cvs/isc/bind9/lib/dns/db.c,v
retrieving revision 1.67
diff -u -r1.67 db.c
--- db.c	2001/01/09 21:50:43	1.67
+++ db.c	2001/04/10 02:54:38
@@ -328,7 +328,8 @@
 	 * result if dns_master_loadfile() succeeded.  If dns_master_loadfile()
 	 * failed, we want to return the result code it gave us.
 	 */
-	if (result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE)
+	if (eresult != ISC_R_SUCCESS &&
+	    (result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE))
 		result = eresult;
 
 	return (result);
Index: lib/dns/zone.c
===================================================================
RCS file: /proj/cvs/isc/bind9/lib/dns/zone.c,v
retrieving revision 1.316
diff -u -r1.316 zone.c
--- zone.c	2001/03/28 23:36:53	1.316
+++ zone.c	2001/04/10 02:54:58
@@ -4732,7 +4732,8 @@
 	ENTER;
 
 	tresult = dns_db_endload(load->db, &load->callbacks.add_private);
-	if (result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE)
+	if (tresult != ISC_R_SUCCESS && 
+	    (result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE))
 		result = tresult;
 
 	LOCK_ZONE(load->zone);


> >>>>> "chris" == chris  <chris at monmouth.com> writes:
> 
>     chris> The serial HAS changed.  The SOA is in the included file.
>     chris> If it was one bog file, it would have reloaded.  That's
>     chris> what's so perplexing.
> 
> Just a guess.....
> 
> You have a zone file which $INCLUDEs another file containing the SOA
> record (yuk!). When BIND loads a zone file, it remembers the time it
> did that and the date the file was last changed. It probably doesn't
> see the changed SOA record because it's not in the zone file given in
> the coresponding zone{} statement in named.conf. As far as the name
> server is concerned the zone hasn't changed because the zone file
> hasn't been updated since the last time the server loaded it.
> 
> You probably should stick to having exactly one zone file for each
> zone. Life is a lot easier for everyone that way. I suspect the above
> scenario explains one of the reasons why one zone, one file is a good
> idea. Having all your zone files share the same SOA record is messy
> and clumsy, but you probably know that now. :-)
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com