Re: Deny MX queries for dynamic IP pools
On 1/31/2010 4:18 PM, SM wrote: At 05:25 31-01-10, Wael Shaheen wrote: As a solution the routing team was thinking to block port 25 for outgoing as some ISPs do. However, I do not see this to be a valid solution for many reasons such as clients that have email servers outside, or if decided to be redirected to spam filters then that will just cost the company too much. Mail submission is done over port 587 and not port 25. MTA-to-MTA traffic uses port 25. Also, older MUAs will still often use port 25 even for message submission, and so will spammers, if they think it will help them bypass anti-spam protections built into the MSA. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Odd Crash
I'm running Fedora 12 version bind-9.6.1-15.P3.fc12.x86_64 (that's the RPM.) Every once and a while when one of my coworkers updates a zone file and runs rndc reload, about 20 seconds later Bind randomly crashes. Here's the debug from the last crash: Feb 1 15:05:45 dns named[16455]: mem.c:918: INSIST(ctx-stats[i].gets == 0U) failed Feb 1 15:05:45 dns named[16455]: exiting (due to assertion failure) It has yet to do it to me once, yet it has done it to him three times now. Any ideas? Thomas E. Casartello, Jr. Staff Assistant - Wireless/Linux Administrator Information Technology Wilson 105A Westfield State College (413) 572-8245 Red Hat Certified Technician (RHCT) smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deny MX queries for dynamic IP pools
At 05:25 31-01-10, Wael Shaheen wrote: As a solution the routing team was thinking to block port 25 for outgoing as some ISPs do. However, I do not see this to be a valid solution for many reasons such as clients that have email servers outside, or if decided to be redirected to spam filters then that will just cost the company too much. On 1/31/2010 4:18 PM, SM wrote: Mail submission is done over port 587 and not port 25. On 01.02.10 13:29, Kevin Darcy wrote: MTA-to-MTA traffic uses port 25. Also, older MUAs will still often use port 25 even for message submission, and so will spammers, if they think it will help them bypass anti-spam protections built into the MSA. those are exactly the reasons why some ISPs block port 25 access. however this is really off-topic here. and I think DNS is really bad place to solve this problem, as it is for failover switching and helping http clients to find out correct site in case of mistake. -- 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. A day without sunshine is like, night. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY logging problem
On February 1, 2010 1:12:56 PM +1100 Mark Andrews ma...@isc.org wrote: In message ed6e4c848e8fef4b16e71...@181.sub-97-18-81.myvzw.com, Frank Cusack writes: On February 1, 2010 11:35:15 AM +1100 Mark Andrews ma...@isc.org wrote: You need to be looking a debug 3. notify_log(notify-zone, ISC_LOG_DEBUG(3), sending notify to %s, addrbuf); ouch, debug 3 is probably way TMI. I guess I'll just patch the above to log at info. Why isn't that the default anyway? Seems to me that you aren't likely to have too many servers and the info level is already pretty verbose so you would expect (or at least *I* would expect) to have that amount of information. When you have 10+ zones with 10's of servers it gets noisy. quite. I hadn't considered there would be a log entry per zone. -frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deny MX queries for dynamic IP pools
There have been quite some posts since my first answer to Wael. I just wanted to rephrase some stuff etc. On Tue, February 2, 2010 00:43, Peter Dambier wrote: Noel Butler wrote: Firstly, I feel this really belongs on mailops not bind list :) secondly... On Mon, 2010-02-01 at 00:00 +0300, Wael Shaheen wrote: Blocking port 25 is much worse IMHO because it forces users out of the service, by restricting their ability to use their own mail servers that can be hosted externally. I believe good mail administrators will force SMTPS Blocking DNS belongs here. I don't think blocking DNS is a good idea. You are blocking access to zones using strictly internal DNS that is not published but only AXFRed and you are blocking alternative DNS. In germany alternative DNS is a must as many ISPs are stumbling over their own feet when implementing or testing censoring. Maybe some of the DNS blackouts here have been DNSSEC as well. Dear fellow pirate, the local situation in Germany might not be relevant here for Wael, esp. if he works at some ISP and there are no plans to manipulate DNS otherwise. Yet I do agree as I stated in my first post, I don't think, filtering/blocking/modifying requests in any way whatsoever is an appropriate approach to a non-technical problem (as I said before). Let it be DNS or directly blocking port 25. Here we do block port 25 within our own network - to put it in short, if a customer thinks this policiy is appropriate, let the customer deploy it, don't do the customers job and don't give the customer options of taking legal actions because you break the customers setups. Oh, how about DNSSEC? How do you handle signatures? And you are breaking dnsbl because dnsbl is DNS at an alternative address. So some of your clients might accidently drop all mail as spam and it takes long to find such a bug if somebody else does maintain the mailer. That is indeed true, I did forget about those in my first post. That brings me back to my first argument: Don'T use technical methods for a non technical problem, there many good reasons not to do this. The bigger question is why are you not blocking, suspending, or terminating the accounts of those who you know are spamming, be it deliberate, or not (as the end result is the same) Cheers Cheers Peter and Karin -- 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= fd80:4ce1:c66a::/48 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Now Andrew said it pretty catchy already, let me rephrase my thoughts: Why do you want to use some technical approach like filtering/blocking, to solve a social problem. You as an ISP should have an agreement/contract with your customers. It's the right place, to enforce, that customers take action against spam. If they do not comply, willingly or due to incompetence, it is at your hand, to disconnect them and terminate the agreement, if necessary. And of course you can take additional legal action when needed. This is just plain simple social engineering and imho the only valid solution. Wael, you said something about mail hosts on dynamic IP Pools being 'illegal' - If it is under your jurisdictional system, well, you already had the answer/solution, to all your problems, if not, work out an appropriate contract. Regards -Sven ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to setup a local root nameserver?
Thats the baptista vortex. I've used it to clean up root servers of traffic.
Where every name resolves to the same IP address. I don't know if it still
works under bind. You can try.
You simply setup a root zone file with a wildcard pointing to the A record.
Or you can build a server to do that.
regards
joe baptista
If you need help get back to me privately.
On Mon, Feb 1, 2010 at 6:50 PM, fddi f...@gmx.it wrote:
Hello,
I need to setup a local named configuration so that ANY request will be
resolved
to a specific single IP only.
I mean any kind of DNS resolutin request
www.luth.se
www.isc.org
www.anything.tld
should be resolved in 172.16.30.30 for example
I need this because I need to redirect users to a local web portal
authentication page and I need
to do it using DNS.
is there any kind of named configuration which can allow me to achieve this
result ?
I tryed hard but without any success
for example I tryed this:
in named.conf:
zone . IN {
type master;
file named.root;
};
then in named.root:
$TTL86400
$ORIGIN .
@ 1D IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ); minimum
1D IN NS@
1D IN A 172.16.30.30
but it works only for .
and not recursively for anydomain issued in the request.
thank you
Rick
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.4-ESV is now available
BIND 9.4-ESV is now available. BIND 9.4-ESV is a extended release version for BIND 9.4. BIND 9.4-ESV can be downloaded from ftp://ftp.isc.org/isc/bind9/9.4-ESV/bind-9.4-ESV.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.4-ESV/bind-9.4-ESV.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/bind-9.4-ESV.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/bind-9.4-ESV.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at https://www.isc.org/about/openpgp. A binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.zip ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.debug.zip The PGP signature of the binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.zip.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4-ESV/BIND9.4-ESV.debug.zip.sha512.asc Changes since 9.4.0. --- 9.4-ESV released --- 2831. [security] Do not attempt to validate or cache out-of-bailiwick data returned with a secure answer; it must be re-fetched from its original source and validated in that context. [RT #20819] 2828. [security] Cached CNAME or DNAME RR could be returned to clients without DNSSEC validation. [RT #20737] 2827. [security] Bogus NXDOMAIN could be cached as if valid. [RT #20712] 2797. [bug] Don't decrement the dispatch manager's maxbuffers. [RT #20613] 2790. [bug] Handle DS queries to stub zones. [RT #20440] 2772. [security] When validating, track whether pending data was from the additional section or not and only return it if validates as secure. [RT #20438] --- 9.4-ESVb1 released --- 2698. [cleanup] configure --enable-libbind is deprecated. [RT #20090] 2697. [port] win32: ensure that S_IFMT, S_IFDIR, S_IFCHR and S_IFREG are defined after including isc/stat.h. [RT #20309] 2690. [bug] win32: fix isc_thread_key_getspecific() prototype. [RT #20315] 2689. [bug] Correctly handle snprintf result. [RT #20306] 2688. [bug] Use INTERFACE_F_POINTTOPOINT, not IFF_POINTOPOINT, to decide to fetch the destination address. [RT #20305] 2681. [bug] IPSECKEY RR of gateway type 3 was not correctly decoded. [RT #20269] 2672. [bug] Don't enable searching in 'host' when doing reverse lookups. [RT #20218] 2525. [experimental] New logging category query-errors to provide detailed internal information about query failures, especially about server failures. (backported as a special exception to the general policy) [RT #19027] 2670. [bug] Unexpected connect failures failed to log enough information to be useful. [RT #20205] 2649. [bug] Set the domain for forward only zones. [RT #19944] 2648. [port] win32: isc_time_seconds() was broken. [RT #19900] 2646. [bug] Incorrect cleanup on error in socket.c. [RT #19987] 2642. [bug] nsupdate could dump core on solaris when reading improperly formatted key files. [RT #20015] 2640. [security] A specially crafted update packet will cause named to exit. [RT #2] 2637. [func] Rationalize dnssec-signzone's signwithkey() calling. [RT #19959] 2635. [bug] isc_inet_ntop() incorrectly handled 0.0/16 addresses. [RT #19716] 2633. [bug] Handle 15 bit rand() functions. [RT #19783] 2632. [func] util/kit.sh: warn if documentation appears to be out of date. [RT #19922] 2623. [bug] Named started seaches for DS non-optimally. [RT #19915] 2621. [doc] Made copyright boilterplate consistent. [RT #19833] 2920. [bug] Delay thawing the zone until the reload of it has completed successfully. [RT #19750] 2618. [bug] The sdb and sdlz db_interator_seek() methods could loop infinitely. [RT #19847] 2617. [bug] ifconfig.sh failed to emit an error message when run from the wrong
