Re: DNS-cache with custom gTLDs
2011/9/23 Kevin Darcy k...@chrysler.com: 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. On 23.09.11 08:49, Drunkard Zhang wrote: No, I got 2 layers of DNS, recursive resolution DNS and dns-cache which forward all it's queries to recursive DNS. Why? Can't your recursive resolution DNS cache records? I want the spoofing of root servers happened on dns-cache (still not by now), Why do you want to do the spoofing at all? if you want to implement local TLD or any king of zone visible locally, you can define it on recursive servers, or on different servers and forward requests for that zone from caches to those different servers. -- 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. The only substitute for good manners is fast reflexes. ___ 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
Re: DNS-cache with custom gTLDs
2011/9/26 Matus UHLAR - fantomas uh...@fantomas.sk: 2011/9/23 Kevin Darcy k...@chrysler.com: 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. On 23.09.11 08:49, Drunkard Zhang wrote: No, I got 2 layers of DNS, recursive resolution DNS and dns-cache which forward all it's queries to recursive DNS. Why? Can't your recursive resolution DNS cache records? There're a lot of abnormal queries from user (We got about 0.4 millon users), to avoid script kids' attack or buggy program, I designed 2 layers. And the dns-caches took most of the traffic. And again, spoofing of root-servers on dns-cache is for the same reason. Here's the high traffic hour's queries of root-servers, which looks normal, it could be billon times when attacked. log2 /gwbn/dns/20110925 # grep \.root-servers.net 20110925_21 1981381 a.root-servers.net A 2 m.root-servers.net A 1 k.root-servers.net A 1 j.root-servers.net A 1 g.root-servers.net A 1 f.root-servers.net A 1 c.root-servers.net A ___ 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
Re: DNS-cache with custom gTLDs
2011/9/23 Kevin Darcyk...@chrysler.com: 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. That was my thought as well. Sometime NXDOMAINs also could simply be inconsistent authoritative data at the other end. Once again, building a kluge to work around such a thing wouldn't be a good strategy. John ___ 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
Re: DNS-cache with custom gTLDs
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.7200IN 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
Re: DNS-cache with custom gTLDs
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 ___ 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
Re: DNS-cache with custom gTLDs
On 9/22/2011 6:03 AM, 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. Thanks for your patient. So I can just wait for the recovery, or flushname by hand? Guess I have to face client's complains all the time :-( See my other message. I think you're creating those NXDOMAINs by spoofing root nameservers in your hints file. If my speculation is correct, use the real roots and the problem should go away. - Kevin ___ 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
Re: DNS-cache with custom gTLDs
2011/9/23 Kevin Darcy k...@chrysler.com: 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. No, I got 2 layers of DNS, recursive resolution DNS and dns-cache which forward all it's queries to recursive DNS. I want the spoofing of root servers happened on dns-cache (still not by now), I certainly won't spoofing root-servers on recursive DNS. The NXDOMAIN returned from one group of recursive DNS is temporary failure, while it's successed from another group of recursive DNS. But I want the dns-cache return successed all the time, so I hope the dns-cache ignore NXDomain from one, and forward the same query to another recursive DNS again, guess this can't be done with bind :-( Just go with the standard root nameservers and think harder about the real problem you're trying to solve here. ___ 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
Re: DNS-cache with custom gTLDs
2011/9/20 Drunkard Zhang gongfan...@gmail.com:
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__?
This is not working... I did some test, and if dns-cache got a
NXDomain response, it won't go any far. Is it intended? or I missed
something? I'm using 9.7.3-P3. Here's my configuration on dns-cache.
options {
directory /var/;
pid-file file-named.pid;
dump-file file-dumpfile;
statistics-file file-stat;
max-cache-size 3000M; # 3 GB
allow-query { any; };
max-ncache-ttl 600;
max-cache-ttl 86400;
recursive-clients 100;
tcp-clients 50;
interface-interval 0;
cleaning-interval 3600;
recursion yes;
};
zone . IN {
type hint;
file named.cache;
};
zone . {
type forward;
forward first;
forwarders {
211.161.192.1;
211.161.192.13;
};
};
Put forward section to option clause not working too.
Is there any other solution I can hack?
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.
Look forwarding to your kind responses :-)
When I query a name, the dns-cache queries forwarders for gTLDs
instead of using local hint file, why? And the dns-cache does not
trust forwarder returned result when set forward first, is it
possible to fake it?
___
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
Re: DNS-cache with custom gTLDs
2011/9/20 Drunkard Zhang gongfan...@gmail.com: 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__? On 21.09.11 19:33, Drunkard Zhang wrote: This is not working... I did some test, and if dns-cache got a NXDomain response, it won't go any far. Is it intended? or I missed something? I'm using 9.7.3-P3. Here's my configuration on dns-cache. It IS indented. The NXDOMAIN means that the requested name does not exist. It is a correct DNS answer and DNS client should not search any further. If there is a domain name for which some servers return an positive answer, and some negative one, then there is something broken with that domain. 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? I think you should not hijack others' DNS requests. Blocking them would be much more correct. Note that there are more root servers than just a.root-servers.net - if someone queries this one server, something is apparently broken at their side. When I query a name, the dns-cache queries forwarders for gTLDs instead of using local hint file, why? local hint file? I'm not sure what you mean here. And the dns-cache does not trust forwarder returned result when set forward first, is it possible to fake it? Why do you think it does not trust what forwarder returned? -- 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. Depression is merely anger without enthusiasm. ___ 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
Re: DNS-cache with custom gTLDs
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 ___ 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
Re: DNS-cache with custom gTLDs
When I query a name, the dns-cache queries forwarders for gTLDs instead of using local hint file, why? local hint file? I'm not sure what you mean here. This file just replace the original root-servers with all my 4 recursive DNS's domain name and IP, nothing other. And the dns-cache does not trust forwarder returned result when set forward first, is it possible to fake it? Why do you think it does not trust what forwarder returned? When using forward first, it discards forwarders's response and did a rscursive resolution. ___ 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
Re: DNS-cache with custom gTLDs
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? 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? ___ 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
DNS-cache with custom gTLDs
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__? Is there any other solution I can hack? 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. Look forwarding to your kind responses :-) ___ 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
