Invalid domains are resolving to existing ones

Hi All,

It appears that nginx is resolving invalid domains to existing ones, and
I’m
not entirely sure why. Any help would be much appreciated. :slight_smile:

As an example, I have deployed an application and when I go to the link
of
the app, it works as expected (for example:
MuleSoft | Automate anything. Empower everyone.). I also have valid
test
apps with the numbers 2, 3, and 4, and those links work as expected as
well.
However, when I go to MuleSoft | Automate anything. Empower everyone.
, it
still resolves instead of throwing an error. Even a completely random
pattern, such as MuleSoft | Automate anything. Empower everyone. resolves to
an
existing one and it shouldn’t (there’s not even a config file for
abc.unit-test.muleion.com or all of the other invalid domains) – the
server_name field below should be looking for an exact match for the
name
(according to the nginx docs), so why are other ones resolving?

Here is the relevant part of the nginx config for one of the apps (X’d
out
both the IP and ports but those are valid):
server {
listen 80;
server_name swetatest1.unit-test.muleion.com;
location / {
proxy_pass http://swetatest1.unit-test.muleion.com_http;
include /etc/nginx/proxy.conf;
}
}
server {
listen 443;
server_name swetatest1.unit-test.muleion.com;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
location / {
proxy_pass https://swetatest1.unit-test.muleion.com_https;
include /etc/nginx/proxy.conf;
}
}
upstream swetatest1.unit-test.muleion.com_http {
server XX.XXX.XX.XX:PORT;
}
upstream swetatest1.unit-test.muleion.com_https {
server XX.XXX.XX.XX:PORT;
}

Has anybody else seen this issue before, and if so, how did you fix it?
Any
suggestions or feedback would be greatly appreciated.

Thanks!
-Sweta

Hello!

On Wed, Jul 13, 2011 at 11:55:20AM -0700, Sweta Vajjhala wrote:

still resolves instead of throwing an error. Even a completely random
pattern, such as MuleSoft | Automate anything. Empower everyone. resolves to an
existing one and it shouldn’t (there’s not even a config file for
abc.unit-test.muleion.com or all of the other invalid domains) – the
server_name field below should be looking for an exact match for the name
(according to the nginx docs), so why are other ones resolving?

If there is no server_name match found, nginx will use default
server (either first one defined, or explicitly marked with
“listen … default_server”) for a listen socket in question to
process a request.

Please refer here for details:

http://nginx.org/en/docs/http/request_processing.html

Maxim D.