#1692 closed defect (invalid)
Zero level domain
| Reported by: | 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:2 by , 6 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
follow-up: 4 comment:3 by , 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
follow-up: 5 comment:4 by , 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
follow-up: 6 comment:5 by , 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?
comment:6 by , 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.
Sorry... This
to redirect example.com, but i can access example.com. (with dot)