Re: URIBL_BLOCKED while using local BIND
On 16.09.15 09:50, Bowie Bailey wrote: The SA config is probably a better solution than the bind exemptions. I would say just the opposite. For example, MTA at SMTP level can look up RBLs, and SA would benefit from having records in local cache. -- 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. The only substitute for good manners is fast reflexes.
Re: URIBL_BLOCKED while using local BIND
On 9/18/2015 4:25 PM, Matus UHLAR - fantomas wrote: On 16.09.15 09:50, Bowie Bailey wrote: The SA config is probably a better solution than the bind exemptions. I would say just the opposite. For example, MTA at SMTP level can look up RBLs, and SA would benefit from having records in local cache True. I was thinking more in terms of the amount of work needed in setup and maintenance. Whenever SA changes it's RBL list (which is, admittedly, not that often), you need to update the exemption list in bind. And if you make a typo in the domain name, it is not immediately obvious since you are still getting results from the query. On the other hand, if you point SA to it's own non-forwarding DNS server, it just works and you don't have to touch it again. -- Bowie
Re: URIBL_BLOCKED while using local BIND
Hi Adam, that's a great workarround and perfectly fits my needs! Thank you for that! :) I'll use this if I cannot find out why my exemptions do not work in a reasonable amount of time. Best regards, Marc Am 15.09.2015 um 20:14 schrieb Adam Major: Hi. If you don't want change DNS resolver for all DNS queries from your server you can add in SA config line: dns_server x.y.z.k:53 where z.y.z.k is IP DNS server using to resolve only by SA. Then in resolv.conf you can use different (ex. ISP) DNS server. More info: http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port Best Regards.
Re: URIBL_BLOCKED while using local BIND
Hi Dave, you are right: That is a measurement of "how fast is my ISP's cache?". But literally, that's all I want: I do not want "better" DNS results than I got from my ISPs DNS servers so far. I'd like to keep up the benefit of using a large DNS cache, without blocking these resources on my host. My ISPs DNS servers are dedicated to resolve and cache the results. Why shouldn't I make use of these cached data, but build up an own pool of cached data for a second time, blocking resources on my machine, which can make good use of these resources for another workload? Also, this caches are preserved when my machines are restarted. And WHY these results are faster provided is technically an unfair comparison, yes, but summed up to what's important for my case it isn't. All I want is to make queries to the DNSBL services on my own and not using my ISPs servers, since these have drained their free contingent all the time. That's why I have tried to configure bind as suggested at http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding , but this seems not to work. Best regards, Marc Am 15.09.2015 um 16:41 schrieb Dave Funk: However you did not empty your ISP's dns server cache. That 2 msec response time is from his cache, the 543 msec for your server is when it's not in your server's cache. So you're not making a fair comparison. A response from a cache is always going to be faster, that's why people use caching servers. However with everybody & his cat using your ISP's server it gets query blocked and thus is caching the bad (blocked) response. So either you get bad data fast or good data slowly. Once you get a second spam with similar contents, queries for that copy will be in your cache and be fast. Given that a modern SA parallelizes DNS queries a somewhat slow DNS response (hundreds of Msecs) won't have too much overall affect on the spam processing time. On Tue, 15 Sep 2015, Marc Richter wrote: Yes Am 15.09.2015 um 13:30 schrieb Axb: On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query?
Re: URIBL_BLOCKED while using local BIND
Am 16.09.2015 um 11:36 schrieb Marc Richter: I am - it's the very same setup you describe like I'm using. The only difference is that I do not rely on a dedicated DNS resolver I setup myself, but the centralized nameserver of my ISP, which works exactly like any nameserver I'd setup myself. no it does not ISP nameservers have proven all sort of troubles over the years like ignoring TTL, spit out random expired responses, from one day to the next decide to answer wildcard instead NXDOMAIN which kills any mailservice from one moment to the next and so on Although, the intended setup with exemptions by defining empty forwarders for DNSBL zones was not my idea - this scenario is described on the SA wiki as a working solution: http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding This seems to not be working, so I'm heading for this ML to find out why. well, that would be a question for the bind-ML you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. obviously it don't work That's right - so let's work out the reasons for it and not fight against each other. This setup is described in the official SA wiki and not working. So let's improve this public resource together. until now it is not sure that your setup is correct (only using 127.0.0.1 as nameserver) What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... but it does forward otherwise the problem would be solved You are right. I double-checked in the meantime (and awaited some spams to arrive) by disabling forwarding completely. It does work then. I do and did not doubt this - but the issue remains: I'd still like to forward all of my requests to take the advantage of my ISPs DNS caches. But those queries to the DNSBL zones should be resolved exceptionally by my local recursion nameserver. Why is the example in the SA wiki not working? maybe you did not tell SA directly or the OS in /etc/resolv.conf *only* use 127.0.0.1 as DNS server I do - and you are right with what you described. But all you mentioned is not important for my setup and specific application. Fast resolution and a huge DNS cache is. I know, that those aren't the times achieved when my ISPs DNS servers initiate a recursive query on the data, but deliver what they already have cached, only. But that is OK for me. I only need these cached data well, you only benefit from the ISP cache when another customer within the TTL did the same request, in any other case the response would be slower because one hop more you are still missing the whole picture! When I would do the recursive resolvings on my own, not only my initiate queries would take quite a long time compared to those my ISPs does, but I would "waste" a lot of resources needed to provide these caches on my own servers. My setup simply isn't big enough to reasonably dedicate a box on it's own or use that resources of my apps host, only to provide nearly the same my ISP already serves. you just need 64-128 MB RAM for a reasonable cache and when it comes to ressources i would use unbound instead named as caching-only resolver *all* blacklist services have a very low TTL, with unbound you even cache *much* better than any ISP resolver because you can sepcifiy that responses are cached for at least 10 minutes instead ask every 5 seconds again and again - they are doing that to enforce hit their limits by intention msg-cache-size: 64m neg-cache-size: 64m rrset-cache-size: 128m cache-min-ttl: 600 cache-max-ttl: 10800 signature.asc Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
Hi Axb,
yes, I did c the config block from the wiki 1:1 into my BIND setup.
I have added that zone - exemption you suggested into my config.
I'll wait for a few spams to arrive to see the results.
Thank you for sharing your thoughts.
Best regards,
Marc
Am 16.09.2015 um 11:41 schrieb Axb:
On 09/16/2015 11:36 AM, Marc Richter wrote:
Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
This seems to not be working, so I'm heading for this ML to find out why.
are you doing this:
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
if yes try adding:
zone "uribl.com" { type forward; forward first; forwarders {}; };
Re: URIBL_BLOCKED while using local BIND
if you are trying to insult people at all costs really? you would recognize it when i intend to do so Please read your previous reply again. You will find that you used a very harsh tone against someone who comes here asking questions in a reasonable and moderate tone. Yes - maybe I *am* doing something wrong - that's even likely, since otherwise I'd be not the first to find such an issue in such a widely used software. But I expect the same reasonable tone in the answers to my question like I'm writing my questions in. *any* expierienced mailadmin out there has a local recursion nameserver on his MTA or at least somewhere in his LAN to use a central local cache but only you can't do it? I am - it's the very same setup you describe like I'm using. The only difference is that I do not rely on a dedicated DNS resolver I setup myself, but the centralized nameserver of my ISP, which works exactly like any nameserver I'd setup myself. Although, the intended setup with exemptions by defining empty forwarders for DNSBL zones was not my idea - this scenario is described on the SA wiki as a working solution: http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding This seems to not be working, so I'm heading for this ML to find out why. you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. obviously it don't work That's right - so let's work out the reasons for it and not fight against each other. This setup is described in the official SA wiki and not working. So let's improve this public resource together. What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... but it does forward otherwise the problem would be solved You are right. I double-checked in the meantime (and awaited some spams to arrive) by disabling forwarding completely. It does work then. I do and did not doubt this - but the issue remains: I'd still like to forward all of my requests to take the advantage of my ISPs DNS caches. But those queries to the DNSBL zones should be resolved exceptionally by my local recursion nameserver. Why is the example in the SA wiki not working? > and *no* the ISP nameserver is *not* a lot faster in most cases Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. *lol* yes, the second hit already in your local cache when you don't clear it before, you never ever have 2 ms with a forwarding reslover on the internet asked - never ever! for *that* one specific request if you have the luck it's in his cache it *can* be faster, otherwise the ISP would need to do the whole recursion itself and then answer to your cache with one additional hop what you also ignore is the fact that you get the lowered TTL depending on how old the cache entry on the forwarder is while you own cache entry with recursion would be valid the whole TTL of the SOA in other words: you don't look at the whole picture I do - and you are right with what you described. But all you mentioned is not important for my setup and specific application. Fast resolution and a huge DNS cache is. I know, that those aren't the times achieved when my ISPs DNS servers initiate a recursive query on the data, but deliver what they already have cached, only. But that is OK for me. I only need these cached data. When I would do the recursive resolvings on my own, not only my initiate queries would take quite a long time compared to those my ISPs does, but I would "waste" a lot of resources needed to provide these caches on my own servers. My setup simply isn't big enough to reasonably dedicate a box on it's own or use that resources of my apps host, only to provide nearly the same my ISP already serves. anyways 543 msec is high ;; Query time: 121 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Di Sep 15 13:27:59 CEST 2015 ;; MSG SIZE rcvd: 57 That's correct and one of the reasons I'd like to rely on my ISPs data, since changing this is out of my hands. Best regards, Marc
Re: URIBL_BLOCKED while using local BIND
Hi Bowie, thanks for your reply. I would suggest temporarily removing the forward completely as a test and see if this fixes the problem. If so, then your exemptions are not working correctly. If not, then double-check that you are actually using the local server and not still querying the ISP's server. I did exactly this the last hours and let spam reach my box during that time. When forwarding is disabled completely, the DNSBL services work. So, as you said, something's not OK with the exemptions. This makes me wonder a bit, since these are described on the SA wiki site http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding and they were copied 1:1 into my setup. I'll try to find out what's wrong in the Bind-community, too. Best regards, Marc
Re: URIBL_BLOCKED while using local BIND
Hi Axb,
Am 16.09.2015 um 11:41 schrieb Axb:
Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
This seems to not be working, so I'm heading for this ML to find out why.
are you doing this:
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
if yes try adding:
zone "uribl.com" { type forward; forward first; forwarders {}; };
looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)
Best regards,
Marc
Re: URIBL_BLOCKED while using local BIND
Am 16.09.2015 um 13:38 schrieb Marc Richter:
Am 16.09.2015 um 11:41 schrieb Axb:
Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
This seems to not be working, so I'm heading for this ML to find out
why.
are you doing this:
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
if yes try adding:
zone "uribl.com" { type forward; forward first; forwarders {}; };
looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)
you need to maintain this everytime domains / subdomains are changing
and probably new lists are added - you need to take care about all of
this when rule-updates arrive
* what about barracuda RBL
* what about mailspike
both used in SA and not mentioned there
a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes
would save you a lot of headache and result in even better caching
signature.asc
Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
Reindl Harald skrev den 2015-09-16 15:35: "cache-min-ttl" is AFAIK a unbound-only feature because it violates RFC's but in case of a mailserver it's your decision and if you don#t set it for days normally not a problem so configure unbound to listing only on 127.0.0.2 and in named.conf use forward only to that ip, make sure bind does not bind to 127.0.0.2 then one can have ttl ignored for spamassassin dns but rfc ok for others or just set dns_servers in local.cf for 127.0.0.2 even it for did all that right both bind and unbound will work together wehn dns servers enforce small ttl and not tell there orher servers with a soa notify thay make there own problems
Re: URIBL_BLOCKED while using local BIND
The SA config is probably a better solution than the bind exemptions. As was pointed out elsewhere in this thread, URIBL is not the only DNS-based blacklist that enforces usage limits and it may not be as easy to tell that you are being blocked with some of the others. If you add in the 'dns_server' entry to the config, then SA will use the local nameserver for everything and you don't have to worry about keeping track of which blacklist queries you need to exempt from forwarding. Set your resolv.conf back to your ISP, remove forwarding from your local name server, and add 'dns_server 127.0.0.1' to your local.cf. Bowie On 9/16/2015 5:44 AM, Marc Richter wrote: Hi Adam, that's a great workarround and perfectly fits my needs! Thank you for that! :) I'll use this if I cannot find out why my exemptions do not work in a reasonable amount of time. Best regards, Marc Am 15.09.2015 um 20:14 schrieb Adam Major: Hi. If you don't want change DNS resolver for all DNS queries from your server you can add in SA config line: dns_server x.y.z.k:53 where z.y.z.k is IP DNS server using to resolve only by SA. Then in resolv.conf you can use different (ex. ISP) DNS server. More info: http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port Best Regards.
Re: URIBL_BLOCKED while using local BIND
Am 16.09.2015 um 15:22 schrieb Marc Richter:
All this is true.
As you already pointed out in a previous post, resolving is quite slow
on that host. I have no influence on the networking arround that box. So
I did not want other things starting to go slow by this.
well, and there unbound with "cache-min-ttl: 3600" on 127.0.0.1 will
save you a ton of DNS requests outside your network for repeatly
hammering clients / urls, the ones which ar enot very active are most
likely in no cache anyways
"cache-min-ttl" is AFAIK a unbound-only feature because it violates
RFC's but in case of a mailserver it's your decision and if you don#t
set it for days normally not a problem
you just need to outweight caching/timing and how much junk slips
because you cache a NXDOMAIN for a DNSBL/URIBL while 10 minutes later it
may be listed
you need also to look very careful if it always is that slow or just for
some domains - the slowdown can also be caused by the DNS server
responsible for a domain/PTR-zone and you would only benefit from the
ISP cache if another user already asked the same question there, if not
you have to wait the same time because the ISP cache can't make the SOA
server faster
Am 16.09.2015 um 13:43 schrieb Reindl Harald:
Am 16.09.2015 um 13:38 schrieb Marc Richter:
Am 16.09.2015 um 11:41 schrieb Axb:
Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is
described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
This seems to not be working, so I'm heading for this ML to find out
why.
are you doing this:
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
if yes try adding:
zone "uribl.com" { type forward; forward first; forwarders {}; };
looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)
you need to maintain this everytime domains / subdomains are changing
and probably new lists are added - you need to take care about all of
this when rule-updates arrive
* what about barracuda RBL
* what about mailspike
both used in SA and not mentioned there
a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes
would save you a lot of headache and result in even better caching
--
Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/
http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
All this is true.
As you already pointed out in a previous post, resolving is quite slow
on that host. I have no influence on the networking arround that box. So
I did not want other things starting to go slow by this.
But you convinced me - I now also thing that the other way bears too
much stumbling blocks.
Marc
Am 16.09.2015 um 13:43 schrieb Reindl Harald:
Am 16.09.2015 um 13:38 schrieb Marc Richter:
Am 16.09.2015 um 11:41 schrieb Axb:
Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
This seems to not be working, so I'm heading for this ML to find out
why.
are you doing this:
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
if yes try adding:
zone "uribl.com" { type forward; forward first; forwarders {}; };
looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)
you need to maintain this everytime domains / subdomains are changing
and probably new lists are added - you need to take care about all of
this when rule-updates arrive
* what about barracuda RBL
* what about mailspike
both used in SA and not mentioned there
a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes
would save you a lot of headache and result in even better caching
Re: URIBL_BLOCKED while using local BIND
Hi. If you don't want change DNS resolver for all DNS queries from your server you can add in SA config line: dns_server x.y.z.k:53 where z.y.z.k is IP DNS server using to resolve only by SA. Then in resolv.conf you can use different (ex. ISP) DNS server. More info: http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port Best Regards.
Re: URIBL_BLOCKED while using local BIND
On 9/15/2015 6:51 AM, Marc Richter wrote: Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? I would suggest temporarily removing the forward completely as a test and see if this fixes the problem. If so, then your exemptions are not working correctly. If not, then double-check that you are actually using the local server and not still querying the ISP's server. -- Bowie
URIBL_BLOCKED while using local BIND
Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? Best regards, Marc
Re: URIBL_BLOCKED while using local BIND
On 09/15/2015 12:51 PM, Marc Richter wrote: Hi everyone, I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster, but created the exemptions as listed at the very bottom of that site, to make sure my bind don't forward requests on these services to my ISP's DNS, but resolve them using DNS Root servers. But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? remove the forwarding to your iSP . unless a wider range is being blocked, your problem should be solved btw: adding a hop to every query isn't faster.
Re: URIBL_BLOCKED while using local BIND
Yes Am 15.09.2015 um 13:30 schrieb Axb: On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query?
Re: URIBL_BLOCKED while using local BIND
Marc Richter skrev den 2015-09-15 13:23: That's 271 times faster than root-servers's lookup. hmm maybe your server is heavy loaded of spam ?, and your isp is not ? lets check this so: dig +trace uribl.com show me how it is for you note +trace do not care of forwards at all what version of bind and bind-tools are you using ? did you ask of help on bind maillist ? is threads enabled or disabled in compile time for your bind ?, eg does it use all cores when running ?, if not its forking with slows things down a little, this does not help if you are still on a single core cpu
Re: URIBL_BLOCKED while using local BIND
Marc Richter skrev den 2015-09-15 12:51: But even the IP of my server was sending just 2 requests for incomming spam since I have integrated BIND, these messages contain this ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2 requests? https://www.google.dk/search?q=dnswalk dig +trace uribl.com do NOT add forwards in named.conf in the options section its ok pr zone if needed, but not global and make sure resolv.conf ONLY have nameserver 127.0.0.1
Re: URIBL_BLOCKED while using local BIND
Hey Reindl, if you are trying to insult people at all costs, you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... > and *no* the ISP nameserver is *not* a lot faster in most cases Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. Marc Am 15.09.2015 um 12:55 schrieb Reindl Harald: Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard
Re: URIBL_BLOCKED while using local BIND
Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard signature.asc Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
On 09/15/2015 01:23 PM, Marc Richter wrote: Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. did you EMPTY cache after each query?
Re: URIBL_BLOCKED while using local BIND
Am 15.09.2015 um 13:23 schrieb Marc Richter: if you are trying to insult people at all costs really? you would recognize it when i intend to do so *any* expierienced mailadmin out there has a local recursion nameserver on his MTA or at least somewhere in his LAN to use a central local cache but only you can't do it? you should read and understand their posts in full before doing so at least, to not look like a jackass additional to an impolite person. obviously it don't work What I wrote is: >> ... but created the exemptions as listed at the very bottom of that >> site, to make sure my bind don't forward requests on these services >> to my ISP's DNS ... but it does forward otherwise the problem would be solved > and *no* the ISP nameserver is *not* a lot faster in most cases Also, you shouldn't make assumptions without measuring something: 1. without forwarding: ;; Query time: 543 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 2. with forwarding to my ISP's servers: ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) That's 271 times faster than root-servers's lookup. *lol* yes, the second hit already in your local cache when you don't clear it before, you never ever have 2 ms with a forwarding reslover on the internet asked - never ever! for *that* one specific request if you have the luck it's in his cache it *can* be faster, otherwise the ISP would need to do the whole recursion itself and then answer to your cache with one additional hop what you also ignore is the fact that you get the lowered TTL depending on how old the cache entry on the forwarder is while you own cache entry with recursion would be valid the whole TTL of the SOA in other words: you don't look at the whole picture anyways 543 msec is high ;; Query time: 121 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Di Sep 15 13:27:59 CEST 2015 ;; MSG SIZE rcvd: 57 Am 15.09.2015 um 12:55 schrieb Reindl Harald: Am 15.09.2015 um 12:51 schrieb Marc Richter: I recently read the following in all my filtered Mail: 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. So I read what's written there and setup a local DNS server, as described at http://wiki.apache.org/spamassassin/CachingNameserver . I did choose to forward the requests to my ISP's DNS servers, since it is a lot faster WTF - and all your requests are coming from the ISP resolver and not from your IP which is the reason that you should setup your own *caching and recursing* nameserver and *no* the ISP nameserver is *not* a lot faster in most cases PEBCAK - problem exists between chair and keyboard signature.asc Description: OpenPGP digital signature
Re: URIBL_BLOCKED while using local BIND
However you did not empty your ISP's dns server cache.
That 2 msec response time is from his cache, the 543 msec for
your server is when it's not in your server's cache.
So you're not making a fair comparison.
A response from a cache is always going to be faster, that's why people
use caching servers.
However with everybody & his cat using your ISP's server it gets query
blocked and thus is caching the bad (blocked) response.
So either you get bad data fast or good data slowly.
Once you get a second spam with similar contents, queries for that copy
will be in your cache and be fast.
Given that a modern SA parallelizes DNS queries a somewhat slow DNS
response (hundreds of Msecs) won't have too much overall affect on the
spam processing time.
On Tue, 15 Sep 2015, Marc Richter wrote:
Yes
Am 15.09.2015 um 13:30 schrieb Axb:
On 09/15/2015 01:23 PM, Marc Richter wrote:
Also, you shouldn't make assumptions without measuring something:
1. without forwarding:
;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
2. with forwarding to my ISP's servers:
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
That's 271 times faster than root-servers's lookup.
did you EMPTY cache after each query?
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
