<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.5583" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>On our slave, there are no specific declarations for the
10.131.10 zone, or even 10.131, just 10.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>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?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>This behaviour seems odd to me, and I've not been able to
find information about this behaviour in the book(s).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>Merci!</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=700593418-12122008><FONT face=Arial
color=#0000ff size=2>Todd.</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Ben Croswell
[mailto:ben.croswell@gmail.com] <BR><B>Sent:</B> Thursday, December 11, 2008
5:15 PM<BR><B>To:</B> Todd Snyder<BR><B>Cc:</B>
bind-users@isc.org<BR><B>Subject:</B> Re: recursion for reverse/in-addr.arpa
zones<BR></FONT><BR></DIV>
<DIV></DIV>Are there NS records and/or zone forwarding for the <A
href="http://10.131.10.0">10.131.10.0</A>?<BR>If there is the servers will look
to the most specfic domain.<BR><BR>-- <BR>-Ben Croswell<BR><BR>
<DIV class=gmail_quote>On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder <SPAN
dir=ltr><<A href="mailto:tsnyder@rim.com">tsnyder@rim.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Good
day,<BR><BR>We are working on an odd issue. I can provide more detail as
necessary,<BR>but don't want to fill this email with snips of useless stuff.
All<BR>IP's/names provided are made up, as they don't matter in this
problem as<BR>far as I can tell. This is more a functional question than
a specific<BR>operating question.<BR><BR>We have 2 servers acting as a slave
for the zone "10.in-addr.arpa". The<BR>master(s) for this server are 2
Windows AD servers. Our servers (all<BR>bind9.4 of some variety) are
doing zone transfers fine, and we're<BR>getting whatever is in the
zone.<BR><BR>We've run in to a couple IP's that when we dig them on these
slaves,<BR>they are timing out. They are in a specific location, which
we have<BR>determined are firewalled differently.<BR><BR>For example, we are
doing a dig for <A href="http://10.131.10.1" target=_blank>10.131.10.1</A>
against these 2<BR>different locations. In one location, we get an
answer quickly. In the<BR>other, it times out. The problem in our
case is that in one location,<BR>the slave we're querying can't reach anything
but the masters.<BR><BR>What we've figured out is that the 10.in-addr.arpa
zone doesn't contain<BR>EVERY 10. address we thought, but is missing some.
In this case, our<BR>slaved zone doesn't have <A
href="http://10.131.10.1" target=_blank>10.131.10.1</A>. But, instead of
the slave server<BR>(which should be authortative) returning an "I don't know"
error, it<BR>appears to be doing a recusive query. Against what, we're
not 100% sure<BR>of yet. Well, we know which server, because DIG tells
us, but we aren't<BR>sure why that one.<BR><BR>When I look at the
10.in-addr.arpa zone, there are approximately 20 NS<BR>records for other AD
servers. My speculation is that the slave we're<BR>querying is
recusively looking to one of the servers returned in the<BR>additional
section? This behaviour seems odd to us, and therein lies
my<BR>question.<BR><BR>Does doing a reverse lookup (dig -x) cause the queried
server to behave<BR>differently than a forward lookup? My slave server
is technically<BR>authoritative for the 10.in-addr.arpa zone, but it is still
recusively<BR>going to another server to find an answer. Why? Is
this because we<BR>have defined the zone as 10.in-addr.arpa instead of
creating/slaving<BR>more specific zones (ie: 10.131.10.in-addr.arpa)?
How can we control<BR>this behaviour?<BR><BR>Thank you for any light you
can shed on this - we're confident we know<BR>what is going on, but we can't
figure out why the server behaves<BR>differently for reverse zones than it
would for forward
zones.<BR><BR>Cheers,<BR><BR>Todd.<BR><BR><BR>------------------------------<BR>Todd
Snyder<BR>Data Networks Tools<BR>bb.226.338.2617<BR>Always On, Always
Connected.<BR><BR><BR>---------------------------------------------------------------------<BR>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.<BR>_______________________________________________<BR>bind-users
mailing list<BR><A
href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</A><BR><A
href="https://lists.isc.org/mailman/listinfo/bind-users"
target=_blank>https://lists.isc.org/mailman/listinfo/bind-users</A><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR><BR>--------------------------------------------------------------------- <br>
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.
</BODY></HTML>