DNS-cache with custom gTLDs

Kevin Darcy kcd at chrysler.com
Wed Sep 21 21:47:25 UTC 2011



On 9/20/2011 5:08 AM, Drunkard Zhang wrote:
> I got 4 DNSs doing recursive resolution, which splited into 2 groups,
> and a couple of dns caches. Each group of recursion DNS using their
> own net link, which is different.
>
> Here's problem: I want a dns-cache to use one group of recursion DNS
> as their forwarders, and use another group as backup. ( I have to,
> because 2 groups of recursion DNS get different results, and sometimes
> one of them can't resolves, while another can. ) All solution I can
> find out is "forward first" to one group, and use all 2 groups as
> gTLDs, is this __safe__?

Why are you going through all of these gyrations? The forwarding 
algorithm in BIND has for a long time been based on RTT, so if one 
forwarder, or a set of forwarders, stops working, the other(s) will be 
used automatically. In other words, forwarder failover works without any 
special configuration.

I don't even understand your "forward first" solution. "Forward first" 
says to use iterative (non-recursive) resolution if forwarding fails 
(i.e. all the forwarders are non-responsive). How then can you use it to 
fail over from one set of forwarders to another? I don't get it. If you 
send a non-recursive query to a forwarder, you're at the mercy of 
whatever happens to be in its cache at that particular time. You can't 
get reliable resolution that way.

> Another problem: there's a lot of resolution on dns-cache querying
> a.root-servers.net, is it safe that i hijack a.root-servers.net to my
> own DNS? If it's safe, I can cut down queries to a.root-servers.net by
> millions of times per hour.
If you're getting a lot of recursive queries for a.root-servers.net, you 
have a misbehaving client that you need to track down and vaporize.

                                                                         
                                                                         
                                     - Kevin





More information about the bind-users mailing list