Am 05.02.2011 19:27, schrieb /dev/rob0: > Perhaps so. And on average the TTL for cache hits will be roughly > half what you'd have when doing the recursion yourself.
but it's only ONE request and your are not the onnyl one refreshing his caches >>> * 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. And my two nameservers in the network are cahcing the ansers from the forwarder too - so what is the problem? > Fewer: definitely not, because as above, on average you will see > roughly half the TTL. does not matter, se above >>> * 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. there are not only root-servers involved It makes a differnce fpr the tld-servers and finally for the authoritative servers - you have only the half of all what happens in your mind > 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. nothing is perfect > 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. cismet > 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 so these are idiots > 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? spmahus *loool* are there really peopole outside using them? sorry, but since they blocked "nic.at", the registry for austrian domains because spamhaus meant nic.at have to delete a domain form where comes spam they are persona non grata > 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. http://www.barracudanetworks.com/ns/?L=de Get a (virtual) appliance, their filters are fine and their one blacklist does never block anybody > 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! again: everybody who configures a namesever this way is stoopid > Will your forwarder do something like this to you? if my ISP would touch any dns-answer he would not be my ISP > Will they notify you in advance of if if they do? no, but i would notify them! > Will they warn you before Spamhaus starts blocking them? again: it is braindead using blacklists from people which are blocking a tld-registry without understand nic.at can not delete a domain because some guy say "soma is coming from there"
signature.asc
Description: OpenPGP digital signature
