DNS-cache with custom gTLDs
Kevin Darcy
kcd at chrysler.com
Thu Sep 22 16:45:58 UTC 2011
On 9/21/2011 10:01 PM, Drunkard Zhang wrote:
>> 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.
>>
> Oops, I misunderstood. But I want to resolve this problem: take
> news.qq.com for example, I DID saw that it's unresolvable to one group
> (they returned NXDomain), at meantime it's no problem to another
> group, and "dig news.qq.com +trace" returned correct answer on both
> group. It seems like it's just a temporary failure, but I want to
> correct. Any other choices?
NXDOMAIN is a *permanent* response; at least it's "permanent" in the
absence of any change the relevant DNS RRset or zone.
You're almost certainly getting the NXDOMAIN because you're spoofing the
root servers, and your "fake" root servers don't have the same knowledge
as the real ones, so they'll return NXDOMAIN for some queries (whereas
dig +trace does not, because it follows the hierarchy down and asks
different nameservers). In other words, you're shooting yourself in the
foot with your hints-file trickery.
Just go with the standard root nameservers and think harder about the
real problem you're trying to solve here.
- Kevin
More information about the bind-users
mailing list