dig to a nameserver from a host in particular subnet fails

blrmaani blrmaani at gmail.com
Sun Sep 16 23:47:05 UTC 2012


On Wednesday, December 14, 2011 4:36:24 PM UTC-8, Barry Margolin wrote:
> In article <mailman.542.1323902502.68562.bind-users at lists.isc.org>,
> 
:
> 
> 
> 
> > 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

Thanks.  The difficult part here is to co-ordinate with external party. The external sysadmin says its the problem in our network i.e we are dropping incoming DNS packet. I guess I should check with our network team to dig into this..




More information about the bind-users mailing list