Re: dig to a nameserver from a host in particular subnet fails
On Wednesday, December 14, 2011 4:36:24 PM UTC-8, Barry Margolin wrote: In article mailman.542.1323902502.68562.bind-us...@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.. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig to a nameserver from a host in particular subnet fails
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? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig to a nameserver from a host in particular subnet fails
In article mailman.542.1323902502.68562.bind-us...@lists.isc.org, blrmaani blrma...@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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
