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.

On 22.09.11 10:01, Drunkard Zhang wrote:
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?

We have told you already. Id server returns NXDOMAIN, then the host name does not exist and you have nothing more to try. unless you break your DNS clients which is dangerous thing to do.

news.qq.com.            86400   IN      NS      ns-os1.qq.com.
news.qq.com.            86400   IN      NS      ns-cnc1.qq.com.
news.qq.com.            86400   IN      NS      ns-cnc2.qq.com.
;; Received 174 bytes from 125.39.202.108#53(ns4.qq.com) in 5037 ms

news.qq.com.            7200    IN      CNAME   www.qq.com.
www.qq.com.             300     IN      A       60.28.14.190
www.qq.com.             300     IN      A       125.39.127.22
www.qq.com.             300     IN      A       125.39.127.25
www.qq.com.             300     IN      A       60.28.14.149
;; Received 111 bytes from 60.28.1.157#53(ns-cnc2.qq.com) in 5244 ms

this is the error: news.qq.com. has a delegation NS in qq.com zone and is CNAME in news.qq.com. - that is invalisd, because CNAME cannot be used
qq.com seems to delegate *.qq.com to those same servers:

*.qq.com.               86400   IN      NS      ns-os1.qq.com.
*.qq.com.               86400   IN      NS      ns-cnc1.qq.com.
*.qq.com.               86400   IN      NS      ns-cnc2.qq.com.

and they provide CNAME for 'news' (and maybe others).

the qq.com zone is broken. There's nothing to fix on your side.

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.

It's an ISP, hard to track down every one, I just want to suppress it
that the misbehaving can't go further. Is it safe to hijack on
dns-cache?

no, it is not. If it's an isp, they should track the broken client.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol. _______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to