ttl for negative responses is not following rfc2308
I test BIND 9.7.2-P2 and thus find the ttl for negative responses is not following rfc2308, and instead check the $TTL. If the TTL is smaller than 3h, negative ttl is set to the TTL, otherwise to check mimum TTL. If the value is smaller than 3h, negative ttl is set to the ttl, otherwise set to 3h(10800) 2011-08-19 Mingxing ___ 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: ttl for negative responses is not following rfc2308
On Aug 19 2011, 刘明星：） wrote: I test BIND 9.7.2-P2 and thus find the ttl for negative responses is not following rfc2308, and instead check the $TTL. If the TTL is smaller than 3h, negative ttl is set to the TTL, otherwise to check mimum TTL. If the value is smaller than 3h, negative ttl is set to the ttl, otherwise set to 3h(10800) Why do you say this is not following RFC 2308? To quote from that document (end of section 5) | As with caching positive responses it is sensible for a resolver to | limit for how long it will cache a negative response as the protocol | supports caching for up to 68 years. Such a limit should not be | greater than that applied to positive answers and preferably be | tunable. Values of one to three hours have been found to work well | and would make sensible a default. Values exceeding one day have | been found to be problematic. BIND's default cutoff value of 3 hours can be altered by using max-ncache-ttl option if you need to. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: client ... query (cache) './NS/IN' denied:
I know... That is why I have been posting the IP address. I now block 3980 IP address from our NS servers. Most of them attempt to ssh to our www server and fail, when they do that, I block the IP. Some the same IP's must have been running the DoS since they are no longer able to do so on NS1. I have replicated the block list to NS2 to see, I should know by tomorrow, if NS2 stops getting them as well. On a related topic: Is there anyway to test for poisoning? How can you tell if you are or are not poisoned. Date: Fri, 19 Aug 2011 09:33:29 +0800 Subject: Re: client ... query (cache) './NS/IN' denied: From: short...@gmail.com To: shashan...@hotmail.com CC: bind-users@lists.isc.org On Fri, Aug 19, 2011 at 3:24 AM, Shawn Bakhtiar shashan...@hotmail.com wrote: Hi all, For the first time my primary name server is not reporting any more client XXX.XXX.XXX.XXX query (cache) './NS/IN' denied: 1 Time(s) This is a DNS attacking. Many DNS Servers are meeting this kind of attack each day here. The traffic is huge, once I noticed the traffic to one of my NS host is 1.6G. It's a DDoS that will make your DNS can't serve at all. Regards. ___ 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
