stub zones

[Kevin Darcy]

To detect content changes, an SOA query *after* the NS query makes sense. But this
doesn't really explain the 2 SOA queries *before* the NS query, does it?

As for semantics, I'm afraid I don't grasp how SOA/SOA/NS/SOA is supposed to match
SOA/AXFR.


- Kevin

Mark.Andrews at nominum.com wrote:

>         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