Do we want to humor "how do I intentionally provide an insecure service" questions?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.