Mailman and bounces...
While off-topic to BIND, as a point of list management, I would like to present the following commentary: The topic of bounces was brought up recently and I'd like to expound a bit on some of the issues that the change in mailing list managers has caused. It seems that the previous mailing list software did no list bounce management what-so-ever. If an address was on the list, it was on the list forever, even if it was disabled, removed, put behind a spam-bouncing device, etc. The new software does a very good job of catching bounced e-mail which now includes things like: 554 Sorry, this message appears to be spam (#5.6.0) 550-5.7.1 rejected content, black listed 554 Sorry, message looks like SPAM to me 554 5.7.1 Message failed spam test: Incident ID 1xx0 554 5.7.1 Message scored extremely high on spam scale. No incident created. ALL of the above responses were to legitimate e-mail that were NOT spam, but did contain config files, BIND error messages, output from dig, etc. The combination of messages with high spamity ratings and a list manager that now actually cares about bounces is causing people to have their list memberships disabled, and then their addresses removed from the lists. We (ISC list managers) do our best to keep the list spam-free, but many posts are being tagged as junk by over-sensitive filtering software. If there is anything that you, as users of the list can do to limit the number of this looks like spam bounces that your mailers generate by adding ISC to the appropriate white-lists, we would much appreciate it. This e-mail will probably not make it to the people to-whom it is addressed because it contains things that their filters will not allow to pass. Alan Clegg bind-*/dhcp-* list manager signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unified Root - Domain Configuration Issue
In message 496fb92d.5050...@peter-dambier.de, Peter Dambier writes: Hi ozgurs, can you give me your address so I can settup a zone for you? e.g. ozgursA 127.0.0.1 Then you have the proof that it is working. http://tld and u...@tld can *never* work *reliably* as they would cause namespace clashes. Single label represent local names not global names. Mark Please have a look at http://www.cesidianroot.net/ to find how to settup your DNS for the test. If you have a dynamic ip address things are a little bit more complicated but can be solved too. Cheers Peter ozgurs wrote: We want to buy a unified root domain, but they say we can not use the domain only one word. like ozgurs = so that it opens http://ozgurs = = but we have to use a connected word to this TLD, like example.ozgurs = here, my quetion comes! :) = i bet with my friend that we can not use the domain itself. NOW I NEED A PROOF : = We want to know the reason why we can not use TLD alone itself, without a word in connected to it. = = = ( I mean: instead of the URL = = = ozgurs = = = we have to use = = = example.ozgurs = ) = = = = = We want the reasons, with exact documents (for example a university=92s DNS managerment document from their site link or a scientific article regarding this issue (about the must of usage and reasons why we must use a word connected to the domain.) = = = = = Note: We will buy these products after we are satisified with the explanations and documents=92 reliability about the explained issue above. (the usages, rules of domains, configurations, DNS) = I mean I have to prove this that it is impossible to use the domain as one word (like ozgurs) with very reliable indications and strongly that no one can deny it any way of idea) = = = = = = With best regards, = = OzgurS ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- = Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA=3D fd80:4ce1:c66a::/48 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Avoiding being used as DDoS reflector.
Hi, I've searched around a bit, and noticed some others have similar problems as this but nobody has come up with a decent solution, or at least, I've not found one. I have an Authoritative BIND server. It is configured to only allow recursive queries from localhost, with recursion disabled for any remote clients. If you attempt to perform a recursive query against this server, it will respond with a query refused packet, as this is what BIND does if you try to recursively query a server configured to disallow recursive queries. Kiddies, however, are exploiting this behaviour to provide a level of indirection in their DDoS efforts. Jan 19 10:12:34 mars named[7683]: client 69.50.142.110#40346: query (cache) './NS/IN' denied Jan 19 10:12:35 mars named[7683]: client 76.9.16.171#47713: query (cache) './NS/IN' denied Jan 19 10:12:37 mars named[7683]: client 76.9.16.171#53205: query (cache) './NS/IN' denied Jan 19 10:12:38 mars named[7683]: client 76.9.16.171#2340: query (cache) './NS/IN' denied Jan 19 10:12:39 mars named[7683]: client 76.9.16.171#53417: query (cache) './NS/IN' denied Jan 19 10:12:41 mars named[7683]: client 76.9.16.171#38593: query (cache) './NS/IN' denied Jan 19 10:12:43 mars named[7683]: client 69.50.142.110#61075: query (cache) './NS/IN' denied Jan 19 10:12:43 mars named[7683]: client 76.9.16.171#54721: query (cache) './NS/IN' denied Jan 19 10:12:45 mars named[7683]: client 76.9.16.171#12764: query (cache) './NS/IN' denied Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#59043: query (cache) './NS/IN' denied Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#55282: query (cache) './NS/IN' denied Jan 19 10:12:49 mars named[7683]: client 76.9.16.171#54628: query (cache) './NS/IN' denied Jan 19 10:12:51 mars named[7683]: client 76.9.16.171#34097: query (cache) './NS/IN' denied Jan 19 10:12:52 mars named[7683]: client 69.50.142.110#63662: query (cache) './NS/IN' denied Each of these requests send back a packet to the IP the spoofed query coes from. I've contacted network operators (not necessarily those ones listed for these IPs) and they've confirmed, separately, that they've been under attack for several weeks by these DNS reply packets. Obviously the amount of load here is negligible to me, and if I didn't care about anyone else, then I could just suppress the log messages and move on with my life. But, I don't think thats the appropriate response. Even though my nameserver seems to be correctly configured, there seems to be no way for me to ignore these spurious requests or rate limit them, so therefore I'm aiding the attackers, however obliquely, in their efforts. I've considered using views blackhole recursive requests, but blackholes can only be specified in the global configuration, not in views. I've considered using iptables/netfilter and the u32 extension to match the specific DNS flags that denote a recursive query, and then apply a rate limit; but I really don't know the best way forward. I currently manage these attacks by adding a blackhole entry for each IP that the kiddies try to attack, but this is a stop-gap, and I'd prefer something that can work in an automatic way to deny kiddies the use of my authoritative nameserver as a reflector. The ideal solution for me, would be a bind configuration option that could rate limit responses based on type; so you could specify that a REFUSED reply will only be sent to a given host once per hour, or something like that. Any ideas? Anyone facing this same problem found a solution? I'd be glad to hear it :) -- Nathan Ollerenshaw :: http://www.stupendous.net/ Anyone who has never made a mistake has never tried anything new. - Albert Einstein ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
