On Sat, Feb 05, 2011 at 03:24:01PM +0100, Matteo Cazzador wrote: > hello, the nature of the problem that causes temporary lookup > failure is not dns like i thinking of, the problem is caused > by mysql backend. Some spam has strange charset that caused > mysql error, see previous mail about it. Thank's a lot.
Right, but since your question in the OP was based on this misdiagnosis, and the Subject line is regarding DNS, we are talking about DNS here. :) The charset conversion issue came up recently, 2011-01-24 to be exact, and your answer is likely to fix the data in your database (which is to say, it's directly not a Postfix issue.) See this thread for details: http://www.mail-archive.com/postfix-users@postfix.org/msg31736.html > Il 05/02/2011 13:55, Reindl Harald ha scritto: > >Am 05.02.2011 12:37, schrieb Benny Pedersen: > >>On Fri, 04 Feb 2011 08:44:39 -0600, Noel > >>Jones<njo...@megan.vbhcs.org> wrote: > >> > >>>At least set up a local caching resolver with 8.8.8.8 as the > >>>forwarder. > >>in case of bind this is bad to use any forwarder since it > >>disables hint zone, forwarders is more usefull pr zone, so keeep > >>forwards out of options containter in named.conf > >And where is the problem? Nobody needs the "hint zone" in his LAN > >because some reasons: > > > >* A big external forwarder has many requests in his cache > >* This cached requests are much faster and fewer as full recursion > >* It reduces the load of the root-Servers I'm not a DNS expert, far from it, but I know more than most people I know, so sometimes I play one on the Internet. Here I go again, so enjoy. :) My understanding from BIND/DNS experts is that those three points are false or moot. > >* A big external forwarder has many requests in his cache Perhaps so. And on average the TTL for cache hits will be roughly half what you'd have when doing the recursion yourself. > >* This cached requests are much faster and fewer as full recursion Faster: possibly a bit. But if you have one locally-connected recursive nameserver serving your network, its cache hits will be quite a bit faster than any external nameserver. Fewer: definitely not, because as above, on average you will see roughly half the TTL. > >* It reduces the load of the root-Servers Maybe a little bit, yes. But most of those records have very long TTL, which is designed to reduce the load. Don't go predicting gloom and doom and the collapse of the Internet: it won't happen. The global root is able to handle it. Yes, a local caching nameserver using external forwarders might present a few benefits. It's also potentially subject to cache poisoning, and that being a cache which you do not control. Recently I knew a NetworkSolutions-registered domain which expired because of the registrant's oversight. NetSol redirects NS for expired domains to some ns1/ns2.pendingrenewaldeletion.com. They set a very long TTL for these NS records, at least 3 days, IIRC. ns1.pendingrenewaldeletion.com. and its partner have a wildcard A record for zone "." Try it, query any name you can think of: this.is.fun.but.TLD.does.not.exist. 7200 IN A 209.62.105.19 The registrant was reached while on holiday and the domain renewed. And yet, for days afterward, people were still asking why they were getting that silly redirect page. They were all using forwarders. Me, I flushed my DNS cache (rndc(8)'s "flushname" subcommand) and got on with business as usual within an hour after the payment went through. To bring this almost back on topic, use of forwarders for zone "." will mean, in many if not most cases, that queries to Spamhaus are blocked, as Charles pointed out. Try it: $ dig 2.0.0.127.zen.spamhaus.org. any @4.2.2.2 # Level3 $ dig 2.0.0.127.zen.spamhaus.org. any @8.8.4.4 # Google Maybe *your* forwarder is not blocked yet. Have you seen what happens when your Zen queries suddenly stop working? A few years back I had MX on Comcast cable, and their nameservers were blocked without warning, while I was gone for a few days. I returned to a massive spam mess, of course. Comcast, another good BAD example: they hijack all NXDOMAIN, returning a wildcard A record. Wham, suddenly your DNSBL queries return positive, and you're blocking everything! Will your forwarder do something like this to you? Will they notify you in advance of if if they do? Will they warn you before Spamhaus starts blocking them? Would they even know or care that they were blocked? My mail is too important to be left to chance. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
