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
