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 ¯\_(ツ)_/¯
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
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.
1. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [0]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [1].
2. As someone here already mentioned, it prevents ads/trackers/malware being injected into the page by unscrupulous ISPs (this really has happened [2])
3. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad.
4. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though.
5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just two reasons: firstly, reduced admin overhead not having to bother with certs, and secondly, it enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3]
Why can’t I use my own self-signed certificate, it’s the same thing.
It is not. I don't think you understand the role of CAs. Self-signed certs do not provide protection against connecting to an impersonator.
I’ll agree to disagree, because otherwise the conversation would be moot.
I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. A medical site is different to a static html site like listed in the post.
ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application.
“run acme encryptbot”
no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration.
I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.
The computational overhead is negligible. This simply isn't a credible argument against HTTPS.
Netflix send petabytes of data over HTTPS. There's no excuse for anyone else.
A medical site is different to a static html site like listed in the post.
Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you.
ISP regardless of SSL know which sites I’m visiting
They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal.
It’s there in the HTTP host header regardless of SSL or not.
That's not the case. HTTPS encrypts all headers.
transit security can easily be encrypted without SSL
The easy solution is HTTPS.
people are too lazy to encrypt their content within the application.
A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0].
When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app.
Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript.
When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration.
It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages.
I don’t dismiss that HTTPS is important but I feel platform is flawed.
You've not presented a single good argument against the technical merits of HTTPS.
Owned by corporate greed. It’s security based upon pay us money or else model.
As I stated I will agree to disagree. I have my own views based on my own experiences as you have yours. This ain’t new to me.
Security is always number one. I wasn’t trying to pitch “these are good arguments”. I am expressing my own, whether right or wrong, secure or insecure. No successful hacking attempts so far on my watch.
Everyone feels so safe using HTTPS but when it cracks we are going to be screwed. let’s not forget about HeartBleed and all the others.
What’s stops a corporation/CA from revoking a certificate because you threaten their business?
It’s moot.
I wouldn’t touch let’s encrypt with a barge poll. If I want a SSL i’d rather fork out in a paid cert as at least there is insurance behind.
When google can create their own CA authority how is that secure? Look at google certs, they’ve planted their own global root cert in your OS without you even approving it.
HTTPS is lazy, might be easy but poor mans security. But to end this debate some is better then none.
I just disagree that we should “HTTPS” everything and that’s partly because of the overhead.
The overhead in any modern CPU is negligible. If you're worried about negligible overhead then why are you using an entire operating system to serve up web pages?
ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not.
The host header is encrypted over HTTPS. Furthermore, SSL isn't used in 2019 as it's insecure and was replaced with TLS. That might be pedantic but it seems to align with what this post is about so I'll mention it.
You're confusing the host header with the server name indication sent in the client hello. There is a huge difference between my ISP knowing I went to example.com (with TLS) or example.com/medical/how_to_deal_with_cancer.html (without HTTPS)
And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application.
I'm not sure what you're suggesting here. The industry standard transport security for HTTP is TLS. Trying to re-invent the wheel is counterproductive and dangerous.
“run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration.
Then don't. The specification for the acme protocol is open and available to you. You could automate the entire process and even choose a DNS based challenge. Typical use of cerbot, should you choose to use it, does not "mess with your configuration".
I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.
It literally isn't because Let's Encrypt gives out certs for free. Additionally, so does AWS, Azure, and GCP. If you're paying for a certificate you're doing it wrong.
You have always been free to use self-signed certificates, but then the challenge of convincing your visitors that your certificate really is from you and not someone else who created a self-signed certificate becomes your problem to manage.
You could get one for under $10/y which is not what I’d call a fair bit of money.
I think the problem with HTTPS/SSL was that it tried to solve two problems at once (trust and encryption) without a practical way to separate them. You can argue that’s justified (what’s the point knowing the connection is encrypted if you don’t know who is on the other side), but those panicky browser alerts made self signed SSL certificates all but useless. That’s why we need letsencrypt now.
Even with let's encrypt it still seems odd to me that you need a 3rd party to confirm you own a domain name(and issue a certificate for it). The web trust model is broken.
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:
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.
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.
If you are inside a large corporate network, that spans the globe and has many internal domain names, and a lot of DNS forwarding, it's a very real problem. Especially when trying to debug inconsistent name resolution.
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
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.
Same here. Wrong filter:
/^(https?|wss?):\/\/([0-9a-z\._-]+)\.(accountant|bid|cf|click|club|com|cricket|date|download|faith|fun|ga|gdn|gq|info|link|loan|men|ml|net|network|ovh|party|pro|pw|racing|review|rocks|ru|science|site|space|stream|tk|top|trade|webcam|win|xyz|zone)\.\/(.*)/$document
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
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
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.
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.
It’s just a TLD that actually resolves; Most don’t. For example, http://com./ doesn’t resolve even though it has “subdomains”.
This does though beg the question: can a second level domain (root website) have (what we call) subdomains and not resolve itself? For example, example.example.com would resolve, but example.com wouldn’t?
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. ;)
Why is that disturbing? For me, the name doesn't resolve (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?
Using a different DNS server not provided by the ISP would most likely solve the problem.
You can do so in either the router or your computer/phone. Two well known and performant public DNS servers are found at 1.1.1.1 (CloudFlare) and 8.8.8.8 (Google).
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 ¯\_(ツ)_/¯
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
nginx, btw, does automatically support FQDNs for all your virtual hosts, as does apache.
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
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."
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"
Let's encrypt didn't exist in 2004.
But HTTPS did. You just had to pay to get a certificate.
You had to pay a fair bit of money back then for SSL.
And why does a static html site need https?
I’m all for encryption but we just HTTPS things pointlessly.
Why can’t I use my own self-signed certificate, it’s the same thing.
HTTPS everywhere has other advantages, such as preventing ISPs from injecting scripts or content into HTTP pages. [0]
[0] https://news.ycombinator.com/item?id=21389657
Because without HTTPS, the content can be modified in transit. Some free Wi-Fi access points and evil ISPs, for example, will inject ads and trackers.
There is a good explanation of why your static site need ssl here: https://youtu.be/_BNIkw4Ao9w
HTTPS should be used even for static sites.
1. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [0]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [1].
2. As someone here already mentioned, it prevents ads/trackers/malware being injected into the page by unscrupulous ISPs (this really has happened [2])
3. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad.
4. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though.
5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just two reasons: firstly, reduced admin overhead not having to bother with certs, and secondly, it enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3]
It is not. I don't think you understand the role of CAs. Self-signed certs do not provide protection against connecting to an impersonator.
[0] https://www.theguardian.com/us-news/2016/jan/13/us-library-r...
[1] https://arstechnica.com/information-technology/2015/04/it-wa...
[2] https://doesmysiteneedhttps.com/
[3] https://whydoesaptnotusehttps.com/
I’ll agree to disagree, because otherwise the conversation would be moot.
I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. A medical site is different to a static html site like listed in the post.
ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application.
“run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration.
I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.
The computational overhead is negligible. This simply isn't a credible argument against HTTPS.
Netflix send petabytes of data over HTTPS. There's no excuse for anyone else.
Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you.
They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal.
That's not the case. HTTPS encrypts all headers.
The easy solution is HTTPS.
A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0].
When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app.
Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript.
It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages.
You've not presented a single good argument against the technical merits of HTTPS.
You can get certs for free. This isn't new. [1]
[0] https://justi.cz/security/2019/01/22/apt-rce.html
[1] https://en.wikipedia.org/wiki/Let%27s_Encrypt
Uhh, yes, indeed... manufacturing cars is so cheap these days, even General Motors can do it...
That's not the case. HTTP uses SNI (for now): https://en.wikipedia.org/wiki/Server_Name_Indication
As I stated I will agree to disagree. I have my own views based on my own experiences as you have yours. This ain’t new to me.
Security is always number one. I wasn’t trying to pitch “these are good arguments”. I am expressing my own, whether right or wrong, secure or insecure. No successful hacking attempts so far on my watch.
Everyone feels so safe using HTTPS but when it cracks we are going to be screwed. let’s not forget about HeartBleed and all the others.
What’s stops a corporation/CA from revoking a certificate because you threaten their business?
It’s moot.
I wouldn’t touch let’s encrypt with a barge poll. If I want a SSL i’d rather fork out in a paid cert as at least there is insurance behind.
When google can create their own CA authority how is that secure? Look at google certs, they’ve planted their own global root cert in your OS without you even approving it.
HTTPS is lazy, might be easy but poor mans security. But to end this debate some is better then none.
You are grossly misinformed on this subject.
The overhead in any modern CPU is negligible. If you're worried about negligible overhead then why are you using an entire operating system to serve up web pages?
The host header is encrypted over HTTPS. Furthermore, SSL isn't used in 2019 as it's insecure and was replaced with TLS. That might be pedantic but it seems to align with what this post is about so I'll mention it.
You're confusing the host header with the server name indication sent in the client hello. There is a huge difference between my ISP knowing I went to example.com (with TLS) or example.com/medical/how_to_deal_with_cancer.html (without HTTPS)
I'm not sure what you're suggesting here. The industry standard transport security for HTTP is TLS. Trying to re-invent the wheel is counterproductive and dangerous.
Then don't. The specification for the acme protocol is open and available to you. You could automate the entire process and even choose a DNS based challenge. Typical use of cerbot, should you choose to use it, does not "mess with your configuration".
It literally isn't because Let's Encrypt gives out certs for free. Additionally, so does AWS, Azure, and GCP. If you're paying for a certificate you're doing it wrong.
You have always been free to use self-signed certificates, but then the challenge of convincing your visitors that your certificate really is from you and not someone else who created a self-signed certificate becomes your problem to manage.
I made all these points 2 hours ago.
You could get one for under $10/y which is not what I’d call a fair bit of money.
I think the problem with HTTPS/SSL was that it tried to solve two problems at once (trust and encryption) without a practical way to separate them. You can argue that’s justified (what’s the point knowing the connection is encrypted if you don’t know who is on the other side), but those panicky browser alerts made self signed SSL certificates all but useless. That’s why we need letsencrypt now.
Even with let's encrypt it still seems odd to me that you need a 3rd party to confirm you own a domain name(and issue a certificate for it). The web trust model is broken.
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://www.iana.org/domains/root/db/dev.html
Also, Google's .prod:
* http://www.iana.org/domains/root/db/prod.html
* https://icannwiki.org/.prod
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.
When creating test domains these RFCs should be followed: https://tools.ietf.org/html/rfc6761
Which updated: 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.
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.
Oh. I misunderstood that. Thanks for clarifying.
If you are inside a large corporate network, that spans the globe and has many internal domain names, and a lot of DNS forwarding, it's a very real problem. Especially when trying to debug inconsistent name resolution.
Well congratulations, you're blocked by my adblocker because of that dot (uBlock Origin with EasyList Liste FR)
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
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.
You should get that fixed because it‘s wrong
Works fine here with Firefox, uBlock Origin, and EasyList. Maybe the Fr version has a buggy rule?
Same here. Wrong filter: /^(https?|wss?):\/\/([0-9a-z\._-]+)\.(accountant|bid|cf|click|club|com|cricket|date|download|faith|fun|ga|gdn|gq|info|link|loan|men|ml|net|network|ovh|party|pro|pw|racing|review|rocks|ru|science|site|space|stream|tk|top|trade|webcam|win|xyz|zone)\.\/(.*)/$document
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
"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./ URL because it was a typographical error."
That is not a question, though.
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
It was present when it was posted; I suppose moderators removed it for consistency with HN style.
An interesting effect is http://jdebp.info/ displays “not secure” in the browser and http://jdebp.info./ does not.
Firefox tells you that both connections are not secure... are you using Chrome?
Both show as Not Secure on my Chrome (78.0.3904.108)
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.
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.
The level of passive-aggression in the side-swipe at djb is quite impressive though.
I have been surprised that some domain registrars reject FQDNs when they ask for your DNS servers. Sad.
Glad to see that http://pn/ and 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.
What is the deal with that?
Yeah, how does that work?
I'd guess it's the TLD of the Pitcairn Islands set to resolve to this random page. For example
resolves to the Canadian domain registrar.
Not necessarily a random page, but an “it works” page so you know your server works.
How perplexing that it works at all! I want to know how that works.
It’s just a TLD that actually resolves; Most don’t. For example, http://com./ doesn’t resolve even though it has “subdomains”.
This does though beg the question: can a second level domain (root website) have (what we call) subdomains and not resolve itself? For example, example.example.com would resolve, but example.com wouldn’t?
Should be easy to set up, especially if you have your own authoritative DNS server. Just don't publish an A record for your main domain.
Thanks for the clarification. I see, so an owner can choose to resolve the top-level domain by itself, I didn't know that.
When I visit "com.", indeed it doesn't resolve and the browser falls back to "www.com" (which exists).
That makes me wonder, if I wanted a TLD by itself to resolve to my own site, is it even feasible for a "regular person"?
What's served on "http://pn/" looks like someone's experiment, but I guess they must own the TLD (or have connections to the owner)..?
Yes, this is quite common.
http://ai./ works as well. It's too bad neither has HTTPS set up
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. ;)
Time to change ISP's or check for malware :/
Why is that disturbing? For me, the name doesn't resolve (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?
No, the DNS should return NXDOMAIN and that’s it.
Using a different DNS server not provided by the ISP would most likely solve the problem.
You can do so in either the router or your computer/phone. Two well known and performant public DNS servers are found at 1.1.1.1 (CloudFlare) and 8.8.8.8 (Google).