-------- Original-Nachricht --------
> Datum: Mon, 19 Apr 2010 20:52:57 -0500
> Von: Noel Jones <njo...@megan.vbhcs.org>
> An: postfix-users@postfix.org
> Betreff: Re: DNS RBL error
> On 4/19/2010 8:22 PM, Steve wrote:
> >
> > -------- Original-Nachricht --------
> >> Datum: Mon, 19 Apr 2010 21:03:51 -0400
> >> Von: donovan jeffrey j<dono...@beth.k12.pa.us>
> >> An: Ralf Hildebrandt<ralf.hildebra...@charite.de>
> >> CC: Postfix users<postfix-users@postfix.org>
> >> Betreff: Re: DNS RBL error
> >
> >>
> >> On Apr 19, 2010, at 3:07 PM, Ralf Hildebrandt wrote:
> >>>
> >>> Rather test with:
> >>> 2.0.0.127.zen.spamhaus.org
> >>>
> >>> which should return:
> >>> 2.0.0.127.zen.spamhaus.org has address 127.0.0.2
> >>> 2.0.0.127.zen.spamhaus.org has address 127.0.0.4
> >>> 2.0.0.127.zen.spamhaus.org has address 127.0.0.10
> >>
> >> yes this is working now.
> >>
> >> question on my setup. my primary MX server sits inside my network, with
> a
> >> NATed IP. my postfix config references only the inside network.
> >> should i move this MX server outside and use it's public address in the
> >> config ? inbound mail gets checked and relayed to a content filter on
> another
> >> server.
> >>
> >> mynetworks = 127.0.0.1/32,192.168.0.10/32,10.135.0.0/16
> >>
> >> or am i fine leaving it behind the NAT ?
> >> to help fix the dns problem i want to run a cache only dns on the
> primary
> >> mx. Not sure i wanted that inside or outside. i'm leaning to outside.
> >> tips flames welcome
> >>
> > You can run that caching DNS where ever you want as long as you secure
> that DNS. If you use BIND and are using forwarders to your ISP name servers
> then that caching will not necessarily help much if your ISP's NS are the
> problem.
> >
> > If this would be the case then instruct your BIND to forward queries for
> spamhaus.org directly to their name servers instead going over your ISP's
> name servers. Something like that here below might be helpful to you:
> > ------------------------------------------
> > zone "spamhaus.org" in {
> > type forward;
> > allow-query { 127.0.0.1; };
> > forwarders {
> > 82.94.216.239; // ns8.spamhaus.org
> > 194.82.174.6; // ns20.ja.net
> > 149.20.58.65; // ns.dns-oarc.net
> > 194.109.9.101; // ns3.xs4all.nl
> > 207.241.224.5; // ns2.spamhaus.org
> > 192.150.94.200; // ns3.spamhaus.org
> > 195.169.124.71; // ns3.surfnet.nl
> > };
> > ------------------------------------------
> >
>
> Much simpler to just turn off forwarding for that zone. Bind
> can figure it out itself without you having to update manually.
> zone "spamhaus.org" in {
> type forward;
> forwarders {};
> };
>
That is right. I just wanted to be extra verbose. You remember the time when
spamhaus.org got removed from some big DNS servers because of some obscure
juristic thing going against them in the states? Well way back then one of the
ways to still use spamhaus.org was to directly hardwire those forwarders into
the zone definition.
Off course omitting those forwarders inside the zone definition will force BIND
to figure out the name servers of the domain and use that.
Just yesterday I had one user on a mailing list that is hosted on SourceForge
and where I have admin rights complaining that he could not send mail to the
list. He was claiming that he has subscribed weeks ago and that out of the blue
he is not able to send mails to the list. He was able but he needs to subscribe
in order to be able to post.
Anyway... to make the story short: He got removed by mailman after a bunch of
NDR. Looking at his name servers showed a (in my viewpoint catastrophic) mess.
This is a part of the mail text from me to him:
=================================================
I see as well that your domain is on the DNS level not set up correctly. Maybe
on purpose?
If I query the NS entries of your domain from my infrastructure then I get (I
masked his domain with XxXxX):
-----------------------------------
theia ~ # dig +short in ns XxXxXxX.com
ns1.setupsite.com.
ns5.eapps.com.
ns1.eapps.com.
ns2.eapps.com.
ns6.eapps.com.
theia ~ #
-----------------------------------
Doing the same from an cable provider in Switzerland I get:
-----------------------------------
netbox ~ # dig +short in ns XxXxXxX.com
ns1.setupsite.com.
ns2.setupsite.com.
netbox ~ #
-----------------------------------
Doing the same from an hoster in Germany I get:
-----------------------------------
janosch ~ # dig +short in ns XxXxXxX.com
ns2.setupsite.com.
ns1.setupsite.com.
ns1.eapps.com.
janosch ~ #
-----------------------------------
Even their serial is not in sync (from my system):
-----------------------------------
theia ~ # dig +short in ns XxXxXxX.com|sed "s:\.$::"|while read foo;do echo
"${foo}:
$(dig @${foo} +short in soa XxXxXxX.com)";done
ns6.eapps.com: ns1.eapps.com. root.cp.eapps.com. 2009050101 7200 3600 604800
3600
ns1.setupsite.com: ns1.setupsite.com. admin.setupsite.com. 2007010130 3600 600
1209600 3600
ns2.eapps.com: ns1.eapps.com. root.cp.eapps.com. 2009050101 7200 3600 604800
3600
ns1.eapps.com: ns1.eapps.com. root.cp.eapps.com. 2009050101 7200 3600 604800
3600
ns5.eapps.com: ns1.eapps.com. root.cp.eapps.com. 2009050101 7200 3600 604800
3600
theia ~ #
-----------------------------------
>From the Swiss cable provider:
-----------------------------------
netbox ~ # dig +short in ns XxXxXxX.com|sed "s:\.$::"|while read foo;do echo
"${foo}: $(dig @${foo} +short in soa XxXxXxX.com)";done
ns2.setupsite.com: ns1.setupsite.com. setupsite.com. 2005120809 3600 600
1209600 3600
ns1.setupsite.com: ns1.setupsite.com. admin.setupsite.com. 2007010130 3600 600
1209600 3600
netbox ~ #
-----------------------------------
>From the German hoster:
-----------------------------------
netbox ~ # dig +short in ns XxXxXxX.com|sed "s:\.$::"|while read foo;do echo
"${foo}: $(dig @${foo} +short in soa XxXxXxX.com)";done
ns1.setupsite.com: ns1.setupsite.com. admin.setupsite.com. 2007010130 3600 600
1209600 3600
ns2.setupsite.com: ns1.setupsite.com. setupsite.com. 2005120809 3600 600
1209600 3600
netbox ~ #
-----------------------------------
=================================================
And now back to that spamhaus.org zone file. Yes. You are absolutely right that
you don't need to specify those forwarders. But since the OP had issues with
DNS it could be well possible that he would have better result/success by
hardwiring those forwarders.
> -- Noel Jones
>
Steve
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
