
No, that dot in the domain name of the URL is not a mistake (2004) - Tomte
http://jdebp.info./FGA/web-fully-qualified-domain-name.html
======
MaxBarraclough
He makes a 'technically correct' case for fully qualified domain names, but
I'm not sure this a real problem. Under what circumstances are things really
improved by using them? If your DNS server is untrustworthy, this doesn't
help. If your DNS server _is_ trustworthy, do fully qualified domain names
help you?

There's almost nothing on the web about 'Common Internet Scheme'. [0]

Also, it's a little ironic that we're reading a page on spoofing, from a site
which doesn't support HTTPS.

[0]
[https://www.google.com/search?q="Common+Internet+Scheme"](https://www.google.com/search?q="Common+Internet+Scheme")

~~~
throw0101a
> _Under what circumstances are things really improved by using them?_

Not necessarily "improved", but it could add to predictability. A lot of
places probably use(d) "dev" as an internal sub-domain, and then ICANN went
and approved Google's .dev TLD:

* [https://en.wikipedia.org/wiki/.dev](https://en.wikipedia.org/wiki/.dev)

* [https://www.iana.org/domains/root/db/dev.html](https://www.iana.org/domains/root/db/dev.html)

Also, Google's .prod:

* [http://www.iana.org/domains/root/db/prod.html](http://www.iana.org/domains/root/db/prod.html)

* [https://icannwiki.org/.prod](https://icannwiki.org/.prod)

~~~
bityard
A similar thing happened where I work. Say our domain name was `example.com`,
we had a fleet of hosts at `foo.build.example.com`, `bar.build.example.com`.
The internal network handed out `example.com` as the DNS search string but web
browsers always try the FQDN first. On the day the `.build` gTLD went live,
people who use short names in their URLs (just about everyone) could no longer
access these hosts and I was the one who got to figure out why.

~~~
bluejekyll
When creating test domains these RFCs should be followed:
[https://tools.ietf.org/html/rfc6761](https://tools.ietf.org/html/rfc6761)

Which updated:
[https://tools.ietf.org/html/rfc2606](https://tools.ietf.org/html/rfc2606)

Basically, there are only a few reserved TLDs, .example.[com.|org.|net.],
.test., .invalid., and .localhost. (rfc2606).

RFC6761 clarifies how each should be used.

~~~
Sylamore
His issue wasn't the domain they used becoming a TLD, his issue was a
subdomain they used became a TLD and the DNS resolvers of his clients were not
configured to append the parent domain first, probably the search list wasn't
populated.

~~~
bluejekyll
Oh. I misunderstood that. Thanks for clarifying.

------
undebuggable
Joke's on you. Once spent a whole morning failing to obtain a signed SSL
certificate from one of the certificate authorities. The field description in
a web form was clearly stating to enter _the_ FQDN, yet the form was not
passing through with a very general error description (it appeared later that
the URL with a dot at the end was not validating, someone copy-pasted a regex
of an URL?). On help request, the IT operations guys looked with disdain at
the webdev unable to produce "a stupid certificate". The disadvantages of
reading the instructions and field hints ¯\\_(ツ)_/¯

------
kuschku
And this is why projects like caddyserver, traefik, and similar tools are
simply broken by default, e.g.:

[https://github.com/caddyserver/caddy/issues/1632](https://github.com/caddyserver/caddy/issues/1632)

nginx, btw, does automatically support FQDNs for all your virtual hosts, as
does apache.

~~~
thibautg
I get the following error when I add a dot at the end of the address for a
virtual host in Apache:

 _Misdirected Request

The client needs a new connection for this request as the requested host name
does not match the Server Name Indication (SNI) in use for this connection.

Apache/2.4.25 (Debian) Server at example.com Port 443_

~~~
kuschku
You don't add dots in the config file.

If you configure the virtual host to be e.g. "example.com", Apache will listen
at "example.com" and "example.com."

------
ttctciyf
Glad to see that [http://pn/](http://pn/) and [http://pn./](http://pn./) are
both apparently working.

I'm pretty sure that at one point I had to supply the trailing dot to make the
browser (or resolver) believe it was a real hostname.

~~~
baddox
When I click on the first link in iOS Safari I get sent to a search results
page served by my (read: my parents’) ISP. That’s pretty disturbing.

The second link appears to work. It’s a page that says “It works!” but it’s
not HTTPS so of course I have no way of knowing whether that’s the ISP playing
tricks as well. ;)

~~~
oplav
Why is that disturbing? For me, the name doesn't resolve
([http://pn/](http://pn/)).

Assuming you are using your parents' ISP's default DNS servers, isn't it a
safe, though less-than-desirable, result for the ISP to forward you to a
search page when resolution fails?

~~~
barsonme
No, the DNS should return NXDOMAIN and that’s it.

------
muterad_murilax
"You've come to this page because you've asked a question similar to the
following:

I omitted the trailing dot in the domain name in the
[http://example.com./](http://example.com./) URL because it was a
typographical error."

That is not a question, though.

------
ben_w
I find it wonderful that a link to a page talking about stripping a trailing
period from a domain has been linked to with descriptive text from which the
trailing period has been stripped from the domain

~~~
chrismorgan
It was present when it was posted; I suppose moderators removed it for
consistency with HN style.

------
petee
One issue I noticed is how browsers and sites handle the dot inconsistently;
Edge browser used to "fix" the url, for example.

Google used to do a weird combination of rewriting and/or using the dot,
depending on what part of the site you were on. What ended up happening
roughly is that you could log into the FQDN, google would do logins for both
dot/nodot, if you logged out of one, the other would still work (probably also
a combination of Chrome keeping 2 sets of cookies)

I probably can't, but if I find my original notes I'll add a reply...I recall
both Edge and Google fixing the problem, but there are other sites & browsers
i'm sure that are still affected

------
hadrien01
Well congratulations, you're blocked by my adblocker because of that dot
(uBlock Origin with EasyList Liste FR)

~~~
stevenjohns
Why would that list be blocking fully qualified domain names? Seems more like
a bug than a feature, but if there is a good reason for it I'd be interested
to learn

~~~
kadoban
I would imagine the reason is that some ad provider used a fqdn to get around
some badly written rule, and then someone added an even worse rule to block
all fqdn to negate that trick.

------
TruffleLabs
An interesting effect is [http://jdebp.info/](http://jdebp.info/) displays
“not secure” in the browser and [http://jdebp.info./](http://jdebp.info./)
does not.

~~~
OrgNet
Firefox tells you that both connections are not secure... are you using
Chrome?

------
jmiserez
Sadly many libraries get RFC and standards implementations wrong. I've run
into similar edge cases before, and it's always frustrating to see it either
not implemented at all (best case), or overlooked due to simplified
implementation (e.g. regex instead of parsing), or that there's a bug report
that's closed as wontfix because it would be too complicated to fix.

------
gumby
I have been surprised that some _domain registrars_ reject FQDNs when they ask
for your DNS servers. Sad.

------
whatsmyusername
I feel dumber for having read this article. Tbf it’s from the early 2000s but
it reads like a nasally academic trying to lecture people who work for a
living about theory with little to no practical benefit.

~~~
314
The level of passive-aggression in the side-swipe at djb is quite impressive
though.

