recursion for reverse/in-addr.arpa zones

[Todd Snyder]

On our slave, there are no specific declarations for the 10.131.10 zone,
or even 10.131, just 10.
 
On the server we're slaving off of, there would probably be more, but I
don't know as I'm not in control of that server/servers.
 
Will reverse lookups by default continue to look for more specific
domains, recursing as necessary?  If so, how far will it go?  I'm
slaving an "A" class, and it went and found a "C".  If we'd had the "B"
declared, would it have stopped there, or kept going?
 
This behaviour seems odd to me, and I've not been able to find
information about this behaviour in the book(s).
 
Merci!
 
Todd.

________________________________

From: Ben Croswell [mailto:ben.croswell at gmail.com] 
Sent: Thursday, December 11, 2008 5:15 PM
To: Todd Snyder
Cc: bind-users at isc.org
Subject: Re: recursion for reverse/in-addr.arpa zones


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
	






---------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20081212/0be8d2a2/attachment.html>