The POC seems to require some semi-esoteric stuff. In the absence of a more general exploit technique, it might be better to more explicitly say "these are configurations you should not use" than being as sweeping as this is (as for some configurations it does look super-frightening). From reading this, my impression is that there are two things people need to do:
1. Switch off untrusted DNS (e.g. Google's) regardless of any POC. Nginx views using these as insecure (fair enough), so they may decline to issue security advisories for any exploit that doing so allows (less fair).
2. In certain circumstances (1) is insufficient; the post details at least some of these. But you need to do (1) regardless.
The first paragraph of the article says which configurations the author says you should not use (and which the nginx team agrees with from the e-mails)? I'm not sure a less sweeping recommendation would be good, especially since the details can be seen as "esoteric" (and thus you should make sure to understand them to judge a scenario more precisely)
I think the post is great, just that its not really clear what users need to do going forward (unsurprisingly; that should really be on nginx). In particular:
> Even pointing to a resolver on your internal local network may be a bad idea. Running a resolver on localhost is the only safe option.
In many cases, going to a localhost-only DNS is going to be way more complicated than getting off e.g. Google's open DNS, and thus conflating them likely means way more people giving up and sitting on untrusted DNS.
1. Switch off untrusted DNS (e.g. Google's) regardless of any POC. Nginx views using these as insecure (fair enough), so they may decline to issue security advisories for any exploit that doing so allows (less fair).
2. In certain circumstances (1) is insufficient; the post details at least some of these. But you need to do (1) regardless.