dig to a nameserver from a host in particular subnet fails

[Barry Margolin]

In article <mailman.542.1323902502.68562.bind-users at lists.isc.org>,
 blrmaani <blrmaani at gmail.com> wrote:

> Our email group have been complaining about a issue of email sent by
> certain users bouncing and I started debugging and found out that
> those users are using email-servers in subnet1. Emails sent out by
> users in subnet2 were OK.
> 
> The email-client-hosts use dns-recursive-resolvers depending on their
> location. The names being queried by email-client-hosts are external
> names (not in our named config) and our recursive resolvers recurse
> and gets response to these queries as expected.
> 
> Summary of my investigation:
> ============================
> # dns-recursive-resolver1  is in subnet1
> # I execute this on dns-recursive-resolver1 and the query times out
> 
> dig @other-auth-nameserver name1.com. A    # TIMEOUT
> dig @other-auth-nameserver name1.com. MX   # TIMEOUT
> 
> 
> # dns-recursive-resolver2 is in subnet2
> # I execute the following dig command on dns-recursive-resolver2 and
> it returns response (A record) as
> # expected.
> 
> dig @other-auth-nameserver name1.com. A    # OK - responds correctly
> dig @other-auth-nameserver name1.com. MX   # OK - responds correctly
> 
> I spoke to the sysadmin who maintains 'other-auth-nameserver' and he
> responded that they are NOT 'black-hole'ing or 'bogus'ing subnet1 in
> named.conf on 'other-auth-nameserver'. Also, they don't have any
> network ACL or firewall config to block DNS queries from subnet1.
> 
> Question:
> What else should I be looking?

Do packet captures on both networks, and see where the DNS request and 
response packets are getting lost.  That won't explain the cause, but it 
will narrow down where you should be looking for the problem.

-- 
Barry Margolin
Arlington, MA