stub zones

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Tue Feb 1 02:15:19 UTC 2000


	It performs the second SOA query to match the semantics of
	AXFR and changes to zone contents while the "transfer" is
	occuring.

	Mark

> Tim Maestas wrote:
> 
> > When you set up a zone of type stub, when the zone is loaded what method
> > does named use to get the NS records and any corresponding glue from the
> > server listed as master?  In the zone file that is created on the stub
> > server after starting the server, it says:
> >
> > ; zone 'foo.com' first transfer
> > ; from 192.168.1.1:53 (local 192.168.1.2) using AXFR at <date>
> >
> > This would lead me to believe that it used AXFR to transfer the records.
> > But AXFR would transfer the whole zone, not just the NS records.  Besides
> > which I see nothing in the master server's logs to indicate any
> > kind of zone transfer took place.  And if I don't allow the stub server's
> > IP in
> > allow-transfers, it still is able to get the NS records.  Is it just doing
> > an SOA query on the master and getting the NS and glue records from that?
> > If this is what's happening, why does it say "using AXFR" above?
> 
> I think it's just a case of a misleading comment. The named-xfer code that
> generates this is:
> 
>                         fprintf(dbfp, "; from %s:%d (local %s) using %s at
> %s",
>                                 t, ntohs(sin.sin_port),
>                                 inet_ntoa(local.sin_addr),
>                                 (methode == ISIXFR) ? "IXFR":"AXFR",
>                                 ctimel(tt.tv_sec));
> 
> As you can see (you don't have to be a programmer to comprehend this, I don't
> think), it's reporting everything not an IXFR as an AXFR, not bothering to
> check first whether the mode is "stub" or not; the "stub" versus
> non-"stub" distinction doesn't really kick in until a little later in the
> code, in the main send-query-and-parse-response(s) loop of the program.
> 
> For completeness, the comment should probably be improved to distinguish
> "IXFR" from"AXFR" from "ZXFR" from "SOA/NS" (for stub zones).
> 
> While looking at this, I stumbled on (what I consider) a bug wherein
> named-xfer in "stub" mode performs an additional -- that is to say, second --
> SOA query before the NS query, even in situations where it's unnecessary.
> 
> 
> - Kevin
> 
> 
> 
> 
> 
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com



More information about the bind-users mailing list