23

tl;dr

I'm a DNS admin who has seen numerous DNS attack strategies evolve over the past few years, and I'm uncomfortable with encouraging Q&A's that try to split hairs on how an (intentionally) insecure configuration can be run "more securely" in a constantly evolving threat landscape. I do not consider the questions or the answers responsible in this context. I'm just one person though. How does the community want to approach this?

Long version

Today I saw the following question: How to prevent an openly recursive DNS server from being abused for DNS amplification

This is the latest rehash of the "I am determined to be an open resolver and don't care what anyone has to say about it" Q&A that we see a few times per year. While the intentions are good, the Q&A basically boils down to how to minimize a company's negative contributions to the internet while still knowingly being a bad netizen.

How do we want to deal with questions like this? We have existing precedent for helping people who are forced to maintain insecure legacy environments, but I'm personally much less comfortable with questions that are deliberately embracing bad behavior. These questions feel bad to me for the same reason why product recommendation question are bad; they don't scale well with time, particularly when DDoS mitigation is involved.

3 Answers 3

19

There is already a close reason defined for this sort of thing:

Questions should demonstrate reasonable business information technology management practices. Questions that relate to unsupported hardware or software platforms or unmaintained environments may not be suitable for Server Fault - see the help center.

3
  • 1
    If that's the route we want to go, that's fine. I just haven't seen it put into practice with these very often.
    – Andrew B
    Jan 3, 2017 at 7:36
  • 3
    I can't force people to vote. Jan 3, 2017 at 7:36
  • 3
    @AndrewB I did the same vtc yesterday, the question was to publish a open proxy on the internet..I left a comment, but more than that its lost energy IMO. Those ppl will only learn the day they got hacked and get billed a fortune for the over usage of their services
    – yagmoth555 Mod
    Jan 3, 2017 at 17:42
10

While I generally agree with Michael Hampton (vote to close), I really think this should be done on a case-by-case base: sometimes a new sysadmin inherit a bad configuration, or the requirements are fixed by peoples with limited IT understanding; in these cases, any help will be greatly appreciated.

On the other hand, if the question denotes total uninterest about the tech problems being raised with a bad configuration (or denotes total unknowledge of the matter by the OP), it should be immediately closed.

3
  • 1
    I don't find myself agreeing with "requirements are fixed by peoples with limited IT understanding" in this instance. Even if we buy into that, answers about mitigating the risk of improperly exposed software are snapshots in time. As a DNS example, PRS attacks didn't even exist until fairly recently. You end up with several answers that partially cover the scope of the problem ("the answer" does not exist), none of which age well with time. Both are the same reasons why shopping questions are off topic.
    – Andrew B
    Jan 3, 2017 at 20:09
  • 1
    I partially agree with your point of view, however (and unfortunately) I saw many times bad tech decisions taken by someout with very questionable tech skills. If a sysadmin is charged to somewhat ameliorate the situation, the SF community can/should support it.
    – shodanshok
    Jan 3, 2017 at 20:29
  • 2
    If the question is appropriately prefaced so as to not be an XY problem (in this case, the goal being to avoid discussing X at all), perhaps. We definitely don't want to get into the business of aiding people who just want to do the low effort thing with no respect for consequences, which is our primary search engine audience.
    – Andrew B
    Jan 3, 2017 at 20:50
7

The person who asked that question does demonstrate some lack of understanding of what it is he is getting himself into. But I don't think that in itself is enough to justify closing the question as off-topic.

I would much rather see it closed as a duplicate of a good canonical question with a useful answer.

With an answer which simply says: "don't do it", we run the risk that some of the people reading that answer are simply going to ignore it, and run insecure resolvers which is bad for the internet.

In short people are more likely to pay attention to what you say if you give them an answer explaining how to solve the problem they want to solve than they are if you tell them they are unprofessional and they should not even try.

The problem can be solved

I believe it will be more effective to actually explain what it takes to operate a secure recursive resolver. Some will be able to use those answers to operate a secure service. Some will be scared by the answers and decide not to operate an open resolver.

The main threat from open resolvers is amplification. But if every open resolver would implement DNS cookies and force fallback to TCP for all clients without DNS cookies support, that problem would be more or less solved.

Rather than trying to get rid of all open resolves, I think it would be more realistic to get all of them to enforce DNS cookies, and I think that would be better for the internet.

Another threat

Apart from reflection there is another threat, which is flooding authoritative DNS servers with queries for non-existing records. However that threat is not inherent to open resolvers.

Almost every machine participating in such an attack has legitimate access to multiple resolvers which they could use in the attack. An absence of open resolvers would not prevent such an attack.

There is a draft standard intended to address that threat. And it applies to all resolvers whether they are open or not.

Advocating these two solutions (and possibly others which I didn't think of), would in my opinion be a much better strategy than trying to stop everybody from running open resolvers.

11
  • 2
    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.
    – Andrew B
    Jan 5, 2017 at 23:32
  • (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)
    – Andrew B
    Jan 5, 2017 at 23:49
  • @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.
    – kasperd
    Jan 5, 2017 at 23:52
  • 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.
    – Andrew B
    Jan 6, 2017 at 0:02
  • @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?
    – kasperd
    Jan 6, 2017 at 0:16
  • 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)
    – Andrew B
    Jan 6, 2017 at 0:22
  • @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.
    – kasperd
    Jan 6, 2017 at 8:09
  • 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.
    – Andrew B
    Jan 6, 2017 at 9:04
  • 1
    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.
    – Alnitak
    Jan 6, 2017 at 9:50
  • @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.
    – kasperd
    Jan 6, 2017 at 20:35
  • @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.
    – kasperd
    Jan 6, 2017 at 20:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .