By injecting responses for server1.yourco.com, server2.yourco.com, you could MITM someone's backend servers without leaving any traces, which is an even more serious concern if they're terminating TLS at the NGINX server, which is a very common use case.

DJB has been warning against non-randomized port numbers for DNS resolvers for more than 15 years.[1] This is not a new issue.

NGINX's response here is quite disheartening.

1. https://cr.yp.to/djbdns/forgery.html

This post is from last year, so I checked the nginx source to see if they had fixed things since then.

Nope! Still using ngx_random to generate packet IDs:

http://hg.nginx.org/nginx/file/tip/src/core/ngx_resolver.c#l...

And ngx_random is still #defined to random:

http://hg.nginx.org/nginx/file/tip/src/core/ngx_config.h#l57

You are correct. They never fixed issues #2, #3, and #6 (as stated under "Vendor response".) Any half decent resolver properly randomizes both ports and txid not using the predictable libc random(), but nginx developers have staunchly refused to do so...

Thanks for posting this publicly!

I suggest updating your post to say that the issues are still unfixed as of today's date.

Done.

This is something djbdns excelled at in it's initial implementation. DJB, always impressive. These vulnerabilities don't seem all that hard to fix. This also points out why DNSSec is so important IMO. I know many don't see as much value in it, but it can be very useful for defending against inauthentic records. It's a big reason why I've been working on TRust-DNS.

On a separate note; I'd love feedback on these areas of my code if anyone would care to... In TRust-DNS, at least to my best ability, I implemented them in these two locations:

randomized port (UDP only): https://github.com/bluejekyll/trust-dns/blob/master/client/s...

randomized msg id (TCP & UDP): https://github.com/bluejekyll/trust-dns/blob/master/client/s...

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.