Timeline for Do we want to humor "how do I intentionally provide an insecure service" questions?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 7:34 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| Oct 7, 2021 at 7:24 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/draft with https://datatracker.ietf.org/doc/html/draft
|
|
| Jan 6, 2017 at 20:39 | comment | added | kasperd | @Alnitak Of course you can implement more sophisticated rate limiting, but it soon gets more complicated than the other solutions. And even with the most sophisticated algorithms for rate limiting, there can still be legitimate requests which you don't respond to. What will you do for such requests? If you are going to tell those clients to retry over TCP, you will have a solution which is very complicated and most of the time will behave the same way for the user as the simpler solution of enforcing TCP on every request. | |
| Jan 6, 2017 at 20:35 | comment | added | kasperd | @Alnitak When evaluating the usefulness of enforcing TCP don't forget that the proposed alternative I was reacting to was to not have the server responding at all. A server which enforces TCP will be more useful to the end user than one which does not respond to any request. A quick search suggests DNS can have an amplification factor of as much as 70. If rate limiting is your primary method to fend off such attacks you may have to drop 69 in every 70 requests. I don't know of any client which will retry enough to still be useful under such circumstances. | |
| Jan 6, 2017 at 9:50 | comment | added | Alnitak | Notwithstanding my own efforts to increase the usability of TCP for DNS (see e.g. RFCs 7766 and 7828), universal TC=1 is not the answer. DNS cookies aren't enough unless combined with more aggressive RRL for non-cookie requests. | |
| Jan 6, 2017 at 9:04 | comment | added | Andrew B | My last comment did not state that all requests would be replied to. All I'm saying is don't drag TCP retries (or anything else that hasn't been vetted before a larger body of professionals) into it. | |
| Jan 6, 2017 at 8:09 | comment | added | kasperd | @AndrewB DNS cookies won't be worth anything if the server still replies to all requests without cookies. The goal would be a scenario where all requests without cookie support can be silently dropped. But less extreme measures are possible. | |
| Jan 6, 2017 at 0:22 | comment | added | Andrew B | Put another way: DNS cookies are a step in the right direction, but as you touched on it takes discarding/limiting the other traffic or [nebulous something else] to make it work. I'm fine with acknowledging the cookies+discard/limit approach, but proposing the [nebulous something else] is inviting too much discussion in comments. (which isn't encouraged outside of meta) | |
| Jan 6, 2017 at 0:16 | comment | added | kasperd | @AndrewB I'm not sure what you are trying to say. RFC 7873 already exists, but it hasn't been around for long enough yet for everybody to support it. Is there anybody who is actively working against RFC 7873 support? | |
| Jan 6, 2017 at 0:02 | comment | added | Andrew B | True, if you don't care about the experience of anything that misbehaves, that makes it slightly more workable. (patent problem aside) Regardless, I think it's best to avoid hypothetical future states unless we're going to invite the larger professional body to participate. I'm liking the approach of what it takes right now as it is much more quantifiable, and less likely to devolve into obscene hand gestures between R&D people. This isn't to say it couldn't be tossed at the dns-operations mailing list for initial vetting, but I favor reasoning that is more difficult to dispute. | |
| Jan 5, 2017 at 23:52 | comment | added | kasperd | @AndrewB I suppose one open question is how large a percentage of DNS clients need to support cookies before server operators are willing to let clients without cookie support have a worse experience. The answer to that question will certainly depend on what the operator's intend with the server is. The fact that DNS cookies is now an official standard certainly changes my opinion on that matter. | |
| Jan 5, 2017 at 23:49 | comment | added | Andrew B |
(and yeah, I glossed over the cookies+TC=1 approach, but that's because you and I have been down this road before and multiple people who I trust far more than both of us have squashed the TC=1 approach more times than I can count)
|
|
| Jan 5, 2017 at 23:32 | comment | added | Andrew B | Yeah, the existing canonical Q&A for open resolvers is targeted at people interested in creating them, which is why I didn't VC it as a dupe. A middle line approach isn't bad, but I'd caution against saying "the problem can be solved" as such. Google hasn't solved it, they just have more money to throw at operating one more responsibly. Ultimately that is the problem; >95% of the people who come to about this aren't prepared to invest in what is needed to meet that standard of support. Going into detail as you propose can work, but it should be with the intent of selling that message. | |
| Jan 5, 2017 at 23:19 | history | answered | kasperd | CC BY-SA 3.0 |