[ /dev/rob0 wrote on Wed 22.Aug'12 at 8:47:06 -0500 ] > On Wed, Aug 22, 2012 at 01:23:12PM +0530, DN Singh wrote: > > I never realized that I had this issue too. But, after running > > the tests, I found out that my queries were indeed blocked by > > spamhaus. > > > > So, I changed the servers as pointed out and bingo, spam was > > successfully being blocked. > > > > Thanks /dev/rob0 > Hehe, glad to hear it! And best of all, from someone with the > initials, "DNS"! ;) > > Many people think that using forwarders rather than recursion is > somehow more effective or "net-green" (conserving of the network > resources provided by others.) It's really not, and it carries an > added risk of external cache poisoning. > > If you query a record from a forwarder, and the forwarder has it > cached, yes, you get a quick response from said forwarder. But you > get a cached record, which means the TTL is ticking away. You get, on > average, half the published TTL, which means you'll do, on average, > twice the number of queries. > > If you query a record from a forwarder, and the forwarder does NOT > have it cached, you have introduced extra latency in getting your > reply whilst the forwarder recurses. (But you end up with the full > TTL minus the latency.) > > Google Public DNS seems to look up records again before the TTL > expires in their cache, so you are indeed likely to see a slight > improvement in your DNS response time without the doubling of your > external queries, when using their service. But is that in any way > something you could call "net-green"? Since they're ignoring the > published TTL, I think not. > > Other benefits of running your own nameserver, not to be overlooked: > > 1. You're shielded from the impact of decisions of greedy business > types who don't understand DNS. Every so often one of them gets the > idea to replace NXDOMAIN responses with an IP address pointing to > their own web server. For a mail server doing DNSBL/DNSWL lookups, > the result of that can only be a disaster. And it can happen at any > time. Lots of ISPs do this, and they usually won't warn you in > advance of such a change. > > 2. You are in control of your own DNSSEC policy. You can strictly > validate all signatures, you can allow expired signatures, or you can > choose to ignore DNSSEC altogether. If a zone you know exists > suddenly comes up as SERVFAIL, you know what to check. Conversely, if > DNS for a signed zone is hijacked while you are checking signatures, > you are not going to fall for the bogus data. > > 3. You control your own cache. If you are aware of cached data being > wrong, you can flush that data and move ahead; whereas you cannot > flush your forwarder, and you have to wait for the TTL to expire. > "Propagation" is a myth propagated by and for people who don't > understand DNS.
I experienced this issue earlier this week when I was setting up my DNS server on my FreeBSD machine. Their Handbook article[1] kind-of implied (at least to me) that using a forwarder was a good idea; however, it was immediately clear after setting it up that it wasn't doing me any favours. The article itself is good and would be worthwhile reading if you're setting your own DNS server up for the first time but everything /dev/rob0 has advised rings true for me. My local network works much more smoothly now since setting up BIND/named on my FreeBSD server. 1 - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html
