Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1692 closed defect (invalid)

Zero level domain

Reported by: Highter87@… Owned by:
Priority: major Milestone:
Component: other Version: 1.14.x
Keywords: Cc:
uname -a: Linux deb-9-1-0 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.14.2
built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
built with OpenSSL 1.1.0f 25 May 2017 (running with OpenSSL 1.1.0j 20 Nov 2018)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.2/debian/debuild-base/nginx-1.14.2=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

Description

Why is open domain: "nginx.org." - point at the end of the line?

I try redirect write regular expression:

server_name  ^example.com$

but it did't work...

Change History (6)

comment:1 by Highter87@…, 6 years ago

Sorry... This

server_name  ^example\.com\.$

to redirect example.com, but i can access example.com. (with dot)

Last edited 6 years ago by Highter87@… (previous) (diff)

comment:2 by Maxim Dounin, 6 years ago

Resolution: invalid
Status: newclosed

The example.com and example.com. domains are syntactically equivalent, much like example.com and EXAMPLE.COM. Before matching against server names configured, nginx normalizes the name obtained from the client - converts it to lowercase, and removes trailing dot if any. Regular expressions in server_name will see the normalized name, not the one originally sent by the client.

If you want to process differently some of the equivalent forms of domain names, consider additionally testing variables with original information from the client, notably $http_host and $request.

comment:3 by Highter87@…, 6 years ago

"The example.com and example.com. domains are syntactically equivalent" - NO!

If I logged in to the domain "example.com", then when I go to the domain "example.com." - authorization will not be! These are different sites, like example.com and www.example.com

Last edited 6 years ago by Highter87@… (previous) (diff)

in reply to:  3 ; comment:4 by Maxim Dounin, 6 years ago

"The example.com and example.com. domains are syntactically equivalent" - NO!

The trailing dot is only significant at the user interface level, where it basically differentiates fully qualified domains (with trailing dot) and domains which are subject to search list-based lookup. At the HTTP level, it can appear as a result of this distinction on the user interface level. Quoting RFC 3986:

   The rightmost domain
   label of a fully qualified domain name in DNS may be followed by a
   single "." and should be if it is necessary to distinguish between
   the complete domain name and some local domain.

From the server point of view the difference is not important, but clients may request both names, with and without trailing dot, depending on whether there is a conflicting local name or not. And all servers responding on "example.com" are expected to respond on "example.com." as well. Hence nginx does not try to distinguish such names, but rather normalizes them both to the form without a trailing dot.

This behaviour is also in line with what RFC 6066, which explicitly requires domain names without trailing dots to be used in Server Name Indication:

   "HostName" contains the fully qualified DNS hostname of the server,
   as understood by the client.  The hostname is represented as a byte
   string using ASCII encoding without a trailing dot.

You may also find these links useful:

http://www.dns-sd.org/trailingdotsindomainnames.html
https://github.com/curl/curl/issues/716
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html

in reply to:  4 ; comment:5 by Highter87@…, 6 years ago

Replying to mdounin:

This behaviour is also in line with what RFC 6066, which explicitly requires domain names without trailing dots to be used in Server Name Indication:

   "HostName" contains the fully qualified DNS hostname of the server,
   as understood by the client.  The hostname is represented as a byte
   string using ASCII encoding without a trailing dot.

Ok. "google.com." -> redirect to "google.com"
How can I do the same in nginx?

in reply to:  5 comment:6 by Maxim Dounin, 6 years ago

Replying to Highter87@…:

Ok. "google.com." -> redirect to "google.com"

Not really. Both google.com. and google.com redirect to www.google.com. And both "www.google.com." and "www.google.com" return actual content:

$ nc www.google.com 80
HEAD / HTTP/1.0
Host: www.google.com.

HTTP/1.0 200 OK
Date: Thu, 10 Jan 2019 16:07:45 GMT
...

That is, google treats domains with and without trailing dot as equivalent, much like nginx does.

How can I do the same in nginx?

If you still want different processing - as already suggested in comment:1, you can do so by testing $http_host and $request variables.

Note: See TracTickets for help on using tickets.