recursion for reverse/in-addr.arpa zones
ben.croswell at gmail.com
Thu Dec 11 22:14:46 UTC 2008
Are there NS records and/or zone forwarding for the 10.131.10.0?
If there is the servers will look to the most specfic domain.
On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder <tsnyder at rim.com> wrote:
> Good day,
> We are working on an odd issue. I can provide more detail as necessary,
> but don't want to fill this email with snips of useless stuff. All
> IP's/names provided are made up, as they don't matter in this problem as
> far as I can tell. This is more a functional question than a specific
> operating question.
> We have 2 servers acting as a slave for the zone "10.in-addr.arpa". The
> master(s) for this server are 2 Windows AD servers. Our servers (all
> bind9.4 of some variety) are doing zone transfers fine, and we're
> getting whatever is in the zone.
> We've run in to a couple IP's that when we dig them on these slaves,
> they are timing out. They are in a specific location, which we have
> determined are firewalled differently.
> For example, we are doing a dig for 10.131.10.1 against these 2
> different locations. In one location, we get an answer quickly. In the
> other, it times out. The problem in our case is that in one location,
> the slave we're querying can't reach anything but the masters.
> What we've figured out is that the 10.in-addr.arpa zone doesn't contain
> EVERY 10. address we thought, but is missing some. In this case, our
> slaved zone doesn't have 10.131.10.1. But, instead of the slave server
> (which should be authortative) returning an "I don't know" error, it
> appears to be doing a recusive query. Against what, we're not 100% sure
> of yet. Well, we know which server, because DIG tells us, but we aren't
> sure why that one.
> When I look at the 10.in-addr.arpa zone, there are approximately 20 NS
> records for other AD servers. My speculation is that the slave we're
> querying is recusively looking to one of the servers returned in the
> additional section? This behaviour seems odd to us, and therein lies my
> Does doing a reverse lookup (dig -x) cause the queried server to behave
> differently than a forward lookup? My slave server is technically
> authoritative for the 10.in-addr.arpa zone, but it is still recusively
> going to another server to find an answer. Why? Is this because we
> have defined the zone as 10.in-addr.arpa instead of creating/slaving
> more specific zones (ie: 10.131.10.in-addr.arpa)? How can we control
> this behaviour?
> Thank you for any light you can shed on this - we're confident we know
> what is going on, but we can't figure out why the server behaves
> differently for reverse zones than it would for forward zones.
> Todd Snyder
> Data Networks Tools
> Always On, Always Connected.
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> bind-users mailing list
> bind-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users