On 09/27/2016 03:46 PM, David Jones wrote:
/etc/resolv.conf has just got:
nameserver 173.203.4.9
nameserver 173.203.4.8
Unless something is borked in Rackspace's networking config (certainly
not impossible), I don't know why that would ever end up pointing to
localhost.
Setup BIND, unbound, or PowerDNS recursor on localhost and do your
own full DNS lookups.
The server uses Rackspace's default DNS servers
you should use own nameserver, not rackspace serveres shared with other
clients (and thus likely blocked by blacklists)
Would you recommend actually running a bind9 or unbound instance on
these servers? Or just pointing resolv.conf at something like Google's
DNS servers, or something like that?
Don't point a mail server running SA to anyone else's DNS servers that
will combine your BL lookups with others that can push your queries over
the free usage limit of the BL causing the URIBL_BLOCKED rule to be hit.
This issue seems to come up over and over again on this list. Is there a way
something could be added to an SA future release to do a DNS query upon
startup/hourly and log/output something about this URIBL_BLOCKED issue
to point admins to a wiki page explaining the proper DNS configuration? It's
not a straight forward issue that people are finding on the mailing list
archives
or the SA wiki pages. I know it took me a while to figure out what was going
on with URIBL_BLOCKED only after watching this mailing list for a long time.
It's not a problem you think you have until you see odd things happening that
don't seem to be related until after you ask the question on this list.
Dave
The rule's description says it all:
describe URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists\#dnsbl-block for more
information.
+ google "URIBL_BLOCKED" > first hit should also point in the right
direction.
If that's too hard to handle, should we question SA or the person's
competence at deploying/managing SA?
Axb