In article <mailman.659.1372170794.20661.bind-us...@lists.isc.org>,
John Horne <john.ho...@plymouth.ac.uk> wrote:
> So I think my question is what is the resolver doing? Does it use cached
> NS records seen in the AUTHORITY section, or does it use NS records seen
> in an ANSWER section? Or is it working its way down until it receives an
> authoritative answer ('aa' flag set), and then query one of those name
> servers?
Neither. It never queries for a parent domain, all queries contain the
full name being looked up.
When starting from an empty cache, the query is sent first to the root
servers, a la
dig x.y.163.141.in-addr.arpa @a.root-servers.net
If this returns an authoritative answer, the answer is used and cached.
If not, it should contain a delegation in the Authority section; the NS
records in the delegation are cached, and then it repeats the query to
one of those nameservers. This process repeats until it gets an
authoritative answer or an error.
In addition, the authoritative answer may contain an Authority section.
These nameservers take precedence over the NS records from the
delegation -- the assumption is that the authoritative server knows its
domain's nameservers more reliably than the parent domain's servers.
That seems to be where your problem is -- the NS records you're handing
out are not appropriate for public consumption. But they replace the NS
records coming from the delegation. You MUST fix this. Configuring views
would be a solution: one version of the zone for internal use, another
for external. The external view should contain the public NS records and
other records for publicly-accessible servers; the internal view can
contain internal NS records and all the machines on your LAN.
--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
