Re: Suspecious DNS queries dropped by Firewall
In this case, do you think that internal users trying to send emails directly to internet? Email delivery is taken care by Email Gateway device, obviously, DKIM verification (if enabled) can only be done by Email gateway of my company... How does internal client make DKIM query which uses the TXT record in DNS ? Can you tell me list of URL which size exceed 514 bytes to verify whether my internal server truncate/return failure code when query such URL using UDP query? Regards Babu --- On Tue, 13/12/11, SM s...@resistor.net wrote: From: SM s...@resistor.net Subject: Re: Suspecious DNS queries dropped by Firewall To: bind-users@lists.isc.org Date: Tuesday, 13 December, 2011, 9:12 PM At 04:46 13-12-2011, babu dheen wrote: In what situation, DNS packet size can exceed more than 512 bytes. In fact, my gateway DNS TXT records used for DKIM, for example. Regards, -sm ___ 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 ___ 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: Suspecious DNS queries dropped by Firewall
Hi there, On Wed, 14 Dec 2011 babu dheen wrote: Can you tell me list of URL which size exceed 514 bytes to verify whether my internal server truncate/return failure code when query such URL using UDP query? You really ought to be able to do this for yourself. Find any domain using DNSSEC and for example dig -t any domain -- 73, Ged. ___ 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: Suspecious DNS queries dropped by Firewall
On 14.12.11 17:21, babu dheen wrote: In this case, do you think that internal users trying to send emails directly to internet? Maybe, maybe not. DNS queries can come from many other applications. Email delivery is taken care by Email Gateway device, obviously, DKIM verification (if enabled) can only be done by Email gateway of my company... How does internal client make DKIM query which uses the TXT record in DNS ? The client simply sends dns query that results in bigger response than 512 bytes. The client only must set EDNS flag in outgoing Can you tell me list of URL which size exceed 514 bytes to verify whether my internal server truncate/return failure code when query such URL using UDP query? We can not. There are millions of DNS zones and millions of responses that can cross the 512B limit. simply fix your firewall and stop dropping DNS packets bigger than 512 bytes. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Save the whales. Collect the whole set. ___ 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: Suspecious DNS queries dropped by Firewall
At 03:51 14-12-2011, babu dheen wrote: In this case, do you think that internal users trying to send emails directly to internet? No. Email delivery is taken care by Email Gateway device, obviously, DKIM verification (if enabled) can only be done by Email gateway of my company... How does internal client make DKIM query which uses the TXT record in DNS ? The internal client (MUA) does not make such queries. Can you tell me list of URL which size exceed 514 bytes to verify whether my internal server truncate/return failure code when query such URL using UDP query? See http://netalyzr.icsi.berkeley.edu/ Regards, -sm ___ 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
bind as a service on windows -c option not working
Bind 9.8.1 P1 installed in D:\bind9. Config files and other zone files and log files in D:\bind_config Service configuration: Path to executable D:\bind9\bin\named.exe -c D:\bind_config\etc\named.conf named.conf has the line: directory D:\named.conf; If the registry key HKEY_LOCAL_MACHINE\SOFTWARE\ISC\BIND\InstallDir is present, then at the start the named.conf is searched under the folder etc of InstallDir folder. If I delete this key, the the named.conf file is searched in system32/etc folder or something under system32 folder. In both cases the -c option is not taken by the service. As starting bind from command line, the -c option is taken in account and named.conf is read from the specified path. How to tell the named running as a service to read the config file from the path specified with -c option? Some one please. ___ 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
BIND for Active directory with secure update
Hello. I've setup BIND to serve the requests to lan instead of Microsoft DNS by first setting bind as a secondary dns server for Microsoft DNS, copy the zones, and making the BIND the master. In order for domain member hosts to update the records of the their names in dns, I allow unsecure updates from the lan computers. It's a security thread of poisoning the dns. I would like to setup up a secure by the domain servers. On the internet I read about using allow-update with a key file. But I didn't found a page on how to get the key from the Active Directory kerberos system. Could any one point on setting the secure update to bind with key from the already deployed Active Directory? The BIND is running under the windows. Please someone help me. ___ 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: Suspecious DNS queries dropped by Firewall
On Wed, Dec 14, 2011 at 3:51 AM, babu dheen babudh...@yahoo.co.in wrote: In this case, do you think that internal users trying to send emails directly to internet? Email delivery is taken care by Email Gateway device, obviously, DKIM verification (if enabled) can only be done by Email gateway of my company... How does internal client make DKIM query which uses the TXT record in DNS ? Can you tell me list of URL which size exceed 514 bytes to verify whether my internal server truncate/return failure code when query such URL using UDP query? Babu, You are missing the point. DKIM records were only provided as an example of responses that will exceed 512 bytes. Any query might get such a response. There is no way of knowing exactly how much data will be returned with modern DNS servers, especially with DNSSEC. But, even a simple address query might return over 512 bytes of data. The removal of the 512 byte limit on DNS packets is well over a decade old and dancing around it is a losing proposition. You must either fix your firewall (the right solution) or set your servers to NOT set the EDNS flag (a work-around that will probably continue to be fragile). -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: bind as a service on windows -c option not working
On 12/14/2011 2:35 PM, Vbvbrj wrote: Bind 9.8.1 P1 installed in D:\bind9. Config files and other zone files and log files in D:\bind_config Service configuration: Path to executable D:\bind9\bin\named.exe -c D:\bind_config\etc\named.conf I haven't looked at this part of the code in a long time but it should work. Though the registry key should be ImagePath. Did you use BINDInstall to install it? named.conf has the line: directory D:\named.conf; Unless you actually have a folder called D:\named.conf\ then I suspect this is wrong. It should be the directory containing your files not the name of the config file. If the registry key HKEY_LOCAL_MACHINE\SOFTWARE\ISC\BIND\InstallDir is present, then at the start the named.conf is searched under the folder etc of InstallDir folder. If I delete this key, the the named.conf file is searched in system32/etc folder or something under system32 folder. Yes. that's what it's designed to do. In both cases the -c option is not taken by the service. Debugging this is not easy but having the arguments on the ImagePath registry should be okay. As starting bind from command line, the -c option is taken in account and named.conf is read from the specified path. That's expected. How to tell the named running as a service to read the config file from the path specified with -c option? Some one please. Is there a reason that you want to look for it in a different place from where it is currently looking? What's the real issue behind your question. Danny ___ 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
