recursion for reverse/in-addr.arpa zones

[Ben Croswell]

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.

-- 
-Ben Croswell

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
> question.
>
> 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.
>
> Cheers,
>
> Todd.
>
>
> ------------------------------
> Todd Snyder
> Data Networks Tools
> bb.226.338.2617
> 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
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20081211/6adc1ce6/attachment.html>