Re: [dns-operations] Enom's name server broken?
On Tue, Jan 15, 2013 at 11:19 PM, Matthew Ghali mgh...@snark.net wrote: In an ideal world, you'd get exactly what you pay for. In reality you get less. Most people are definitely not paying for inter-provider coordination and a seamless service cutover. Heck, they're paying barely enough for service that answers *most* queries. I'm willing to pay for seamless service cut over - no problem with that. My provider (Enom) does even have a hosted DNS product, but they cannot activate it when they domain is registered with them. Now, I'm considering transferring my domains away from Enom as this might be the easiest solution. Some providers don't even offer the option to pay more and get better service, which is a pity. You can argue why Enom was chosen in the first place as a registrar and provider for DNS. I honestly don't know - they were big enough I guess. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ID of IPv4 fragments and DNS and the future RFC
Stephane Bortzmeyer bortzme...@nic.fr wrote:
Florian Weimer f...@deneb.enyo.de wrote:
1000 responses per second doesn't seem that much, though.
To the *same* destination? (The ID only has to be unique per each tuple
{src, dst, protocol}.) It looks a lot.
It is not a lot for a recursive server with busy clients.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Perhaps the ratio could be a dynamic whitelist -- if it's 1.5 or less, then allow the response to go out. Frank -Original Message- From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of Vernon Schryver Sent: Sunday, January 13, 2013 4:52 PM To: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] responding to spoofed ANY queries From: Jim Reid j...@rfc1035.com I suppose a name server could keep a (small?) cache of recently marshalled answers and use that to either rate limit responses which are too large or identical to one that has recently been sent to the same IP address(es). [For some definition of large and recent.] A problem with that thought is what I tried to state before, that there is no definition of large that is small enough to permit an exemption from rate limiting but not so small that it keeps mininimal DNS responses rate limited. For example, seems that random.rfc1035.com to your 93.186.33.42 is good for a 2X amplified stream of NXDMOAINS. 2X is small but too high for DoS victims to tolerate. I trust you will eventually turn on DNSSEC, which will probably boost your amplification of random requests well above 5X. It could be good to have something which rate limits outgoing responses in addition to what's done with incoming queries. Please recall that RRL stands for *response* rate limiting and neither *query* rate limiting nor *client* rate limiting. The differences are significant. Among those differences is one that wrecks the goal of turning off RRL for those mythical small enough to not be amplified responses. Because RRL is about rate limiting responses instead of clients, there is few or no good reasons to turn it off for large or small legitimate responses. Legitimate responses are not frequently repeated and so don't get dropped except in rare or dubious scenarios. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: Frank Bulk frnk...@iname.com Perhaps the ratio could be a dynamic whitelist -- if it's 1.5 or less, then allow the response to go out. What would be gained by spending the code complexity and CPU cycles such a mechanism would require? What bad things would be avoided or good things achieved? (Please do not mention false positives, because that notion of false positive is irrelevant and does not happen with RRL.) Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
