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 <tsny...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users