DNS-cache with custom gTLDs

[Matus UHLAR - fantomas]

>> 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, uhlar at 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.