.ai(ai)
ai
.ai
http://www.ai?
100 comments
See also "Shortest URLs on the Internet" https://news.ycombinator.com/item?id=32801359
The submission link is unnecessarily long, http://ai ought to work
Interesting. Using my default DNS settings, this doesn't work for me. I have systemd-resolved running, and the upstream DNS server is my OpenWRT router (which until I changed it a few minutes ago, was configured to use the default DNS servers provided by my ISP as its upstream).
In that configuration, trying to ping ai. yields:
In that configuration, trying to ping ai. yields:
$ ping ai.
ping: ai.: Temporary failure in name resolution
# nameserver 127.0.0.53
nameserver 8.8.8.8
$ ping ai.
PING ai (209.59.119.34) 56(84) bytes of data.
64 bytes from offshore.ai (209.59.119.34): icmp_seq=1 ttl=49 time=71.3 ms
OpenWrt by default enables the --domain-needed option of dnsmasq, which blocks forwarding of queries with one component. You can turn it off at Network → DHCP and DNS → General Settings → Domain required.
However, systemd-resolved may refuse to resolve such queries anyway: https://github.com/systemd/systemd/issues/8967. There’s apparently a ResolveUnicastSingleLabel option to allow them.
Note that there are a number of reasons you might want these queries to remain blocked: https://www.iab.org/documents/correspondence-reports-documen...
However, systemd-resolved may refuse to resolve such queries anyway: https://github.com/systemd/systemd/issues/8967. There’s apparently a ResolveUnicastSingleLabel option to allow them.
Note that there are a number of reasons you might want these queries to remain blocked: https://www.iab.org/documents/correspondence-reports-documen...
Thanks for the heads-up. I've only been running OpenWRT for a couple of weeks and did not know about that.
I tried turning that setting off, and I saw the same behavior. But if I change /etc/resolv.conf to point to the OpenWRT box directly:
EDIT:
Found the corresponding systemd-resolved issue. See here:
https://wiki.archlinux.org/title/systemd-resolved#systemd-re...
I tried turning that setting off, and I saw the same behavior. But if I change /etc/resolv.conf to point to the OpenWRT box directly:
#nameserver 127.0.0.53
nameserver 192.168.1.1
EDIT:
Found the corresponding systemd-resolved issue. See here:
https://wiki.archlinux.org/title/systemd-resolved#systemd-re...
Yes, in an earlier HN thread I remember belatedly tracking down and being disappointed by this behavior. It wrongly led me to believe for a moment that the A record itself had been removed!
As a quick warning to other Linux users, if you're using a Linux system you may well not be able to resolve single-component DNS names with your OS-default DNS settings at all, even when they're valid in the global DNS.
As a quick warning to other Linux users, if you're using a Linux system you may well not be able to resolve single-component DNS names with your OS-default DNS settings at all, even when they're valid in the global DNS.
Is there any safe way to do that? Other than set the DNS to 8.8.8.8?
If you're running systemd-resolved the answer is:
To make systemd-resolved resolve hostnames that are not fully qualified domain names, add ResolveUnicastSingleLabel=yes to /etc/systemd/resolved.conf.
for that part of it. In my case I had to do that AND change my router config since I'm using an OpenWRT based router.
But with both changes made, ai. resolves just fine now for me.
To make systemd-resolved resolve hostnames that are not fully qualified domain names, add ResolveUnicastSingleLabel=yes to /etc/systemd/resolved.conf.
for that part of it. In my case I had to do that AND change my router config since I'm using an OpenWRT based router.
But with both changes made, ai. resolves just fine now for me.
Does a lookup for "ai." work without it? That is (explicitly, even!) a FQDN...
For me, before changing that setting, lookups for ai. were failing. After changing it, they worked. I also had to make that OpenWRT change mentioned above since my router is running OpenWRT.
As to the question of whether or not lookup for ai. should work even without that setting... I dunno. Maybe it's just down to the way the systemd-resolved maintainers interpreted the spec?
As to the question of whether or not lookup for ai. should work even without that setting... I dunno. Maybe it's just down to the way the systemd-resolved maintainers interpreted the spec?
> As recommended by IETF standards track RFCs, existing deployed systems apply a search list to single-label names prior to attempting to resolve them.
Note that it says "prior to" rather than "instead of". This is a reason not to use them from an operators POV, not a reason to block them.
> most users entering single-label names want them to be resolved in a local context
Most users have absolutely no idea how any of this works.
> These include causing traffic intended for local services to be directed onto the global Internet
I've never experienced any system that applies the search list after trying the label by itself.
> The IAB therefore feels compelled to state the following:
Each of their statements apply to people who would operate these domains, not to users blocking them.
Note that it says "prior to" rather than "instead of". This is a reason not to use them from an operators POV, not a reason to block them.
> most users entering single-label names want them to be resolved in a local context
Most users have absolutely no idea how any of this works.
> These include causing traffic intended for local services to be directed onto the global Internet
I've never experienced any system that applies the search list after trying the label by itself.
> The IAB therefore feels compelled to state the following:
Each of their statements apply to people who would operate these domains, not to users blocking them.
Much appreciated! For those not using luci:
--- /etc/config/dhcp 2022-09-12 14:50:14.763209067 +0900
+++ /etc/config/dhcp 2022-09-12 14:49:55.655208527 +0900
@@ -1,6 +1,6 @@
config dnsmasq
- option domainneeded '1'
+ option domainneeded '0'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'http://ai/ doesn't work for me, but http://ai./ does
I get a SERVFAIL from what I presume to be systemd-resolved for both. When querying my router or 8.8.8.8 directly with dig, both work.
Neither works for me in Chrome on Android
This is probably the most edge case url there is.
Both work for me in Firefox on MurenaOS (LineageOS based).
http://ai./ works for me in Chrome with whatever my ISP default is.
Both work in Chrome on Android. Strange we have opposite experiences. I guess it depends on ISP's DNS.
[deleted]
They both work for me. I am using custom nameservers though.
Doesn't work for me either:
> Direct IP access not allowed
> What happened?
> You've requested an IP address that is part of the Cloudflare network. A valid
> Host header must be supplied to reach the desired website.
But http://www.ai/ works.
> Direct IP access not allowed
> What happened?
> You've requested an IP address that is part of the Cloudflare network. A valid
> Host header must be supplied to reach the desired website.
But http://www.ai/ works.
A dot is required at the end. http://ai.
Turns out HN doesn't consider the final dot to be a part of the URL.
[deleted]
[deleted]
Previous thread: https://news.ycombinator.com/item?id=31689505
Comment of note:
n@ai is also a valid email address. Owned by a guy named Ian.
(https://news.ycombinator.com/item?id=31689569)
Comment of note:
n@ai is also a valid email address. Owned by a guy named Ian.
(https://news.ycombinator.com/item?id=31689569)
I bet that fails all email address validation code
“Falsehoods programmers believe about email, volume 2022”
earlier this week a website wouldn't let me create an account with my [email protected] address, but I could use [email protected].
Do they think spam bots have emails with spam in the address? Do they think I won't just filter their spam by sender if I can't buy recipient?
Do they think spam bots have emails with spam in the address? Do they think I won't just filter their spam by sender if I can't buy recipient?
"All models are wrong but some are useful" probably applies here.
s/model/email validation code
s/model/email validation code
TLD's with A records
AI AI http https 209.59.119.34
ARAB ARAB http https 127.0.53.53
BH BH http https 10.10.10.10,88.201.27.211
CM CM http https 195.24.205.60
CPA CPA http https 127.0.53.53
MUSIC MUSIC http https 127.0.53.53
PN PN http https 139.162.17.173
TK TK http https 217.119.57.22
UZ UZ http https 91.212.89.8
WS WS http https 64.70.19.33
I really need to get this running automatically again. Travis broke this a while back - need to migrate to GitHub Pages.
Nice place to vacation. One of the quieter Carribean islands. Great food at the tourist restaurants, though expensive. Kind of jarring when you realize beyond the beaches and resorts, it's a third world country with people who are very poor and want to leave the island. I talked to one guy who worked construction and he desperately wanted to move to the US or the UK, mostly because it was so boring on the tiny island.
The irony, starts a cryptography association and doesn't even use SSL.
Possible (half-serious) counter-point: people who understand cryptography know when it is and isn't necessary and don't need to default it on for everything like the rest of us mortals?
Serious counter-counter-point for anybody interested: HTTPS protects people from ISP-based MITM attacks. This by itself is more than enough reason to always use HTTPS if your website can be accessed by other people, even if it is just a small little innocent static blob of HTML.
> HTTPS protects people from ISP-based MITM attacks
On the infinite list things to worry about, "ISP-based MITM attacks" ranks somewhere around "getting bitten by a shark while fighting a velociraptor" and "accidentally getting abducted by a UFO".
Please, please, let's start solving real problems.
P.S. I know about dishonest ISP's that try to inject ads into pages. Switch to a better ISP, problem solved.
On the infinite list things to worry about, "ISP-based MITM attacks" ranks somewhere around "getting bitten by a shark while fighting a velociraptor" and "accidentally getting abducted by a UFO".
Please, please, let's start solving real problems.
P.S. I know about dishonest ISP's that try to inject ads into pages. Switch to a better ISP, problem solved.
> Switch to a better ISP, problem solved.
There are a lot of people in this world who can choose between exactly one ISP.
There are a lot of people in this world who can choose between exactly one ISP.
There are a lot of people who can choose between exactly one supermarket.
Should you equip everyone in the world with an e-coli tester? You know, it's super-easy for a supermarket employee to infect your food with e-coli!
Some problems don't need a technical solution, okay?
Should you equip everyone in the world with an e-coli tester? You know, it's super-easy for a supermarket employee to infect your food with e-coli!
Some problems don't need a technical solution, okay?
In 2022, the strongest possible argument against using HTTPS is "it's not strictly necessary". That's it. It's not expensive, it's not hard, it's not slow. The worst case is you've done something unnecessary for most people (arguably).
Yeah, if "e-coli testers" were free, easy to distribute, and consumed no resources, including them with every supermarket purchase would be a great idea.
Yeah, if "e-coli testers" were free, easy to distribute, and consumed no resources, including them with every supermarket purchase would be a great idea.
Also if it has been proven that, given a chance, many supermarkets have and still actively do inject e-coli into their foods because they are able to profit off of it somehow, then the "e-coli testers" would be an even better idea.
[deleted]
That might be very new information, but there are 195 countries in the world (194 apart from yours!) with plenty of them forcing internet censorship or gov espionage.
I'm kinda happy that the worst scenario in yours are internet ads, but you can't say that if your country don't force providers to inject fake pages for selective pages, there is not need to protect traffic for the whole world.
And no, you can't switch ISP in the case if the hacking comes from gov censorship agencies.
I'm kinda happy that the worst scenario in yours are internet ads, but you can't say that if your country don't force providers to inject fake pages for selective pages, there is not need to protect traffic for the whole world.
And no, you can't switch ISP in the case if the hacking comes from gov censorship agencies.
You must be a theoretician, because people who actually have to deal with censorship know that government entities mandate certificate MITM or block domains whole-sale.
So https does nothing for censorship unless you're worried about the absolutely unrealistic case of a government entity running search-and-replace on your webpage content at the ISP level. (Unrealistic because they can just send a legal order to whoever is hosting this content instead.)
So https does nothing for censorship unless you're worried about the absolutely unrealistic case of a government entity running search-and-replace on your webpage content at the ISP level. (Unrealistic because they can just send a legal order to whoever is hosting this content instead.)
I'm a holder of Russian passport, so no, I'm not a theoretician.
1) They block the whole-domain only in case of https which reminds you to turn-on the VPN. In case of http you could just have something like 404 response for particular page and you would never know that it's actually not 404, but ISP block (depends on ISP and DPI). So still https is preferable to be able to distinguish between two types of blocks.
2) They don't do "replace" in general, true, but for opposition resources they might be creative.
3) Most of hosters and content providers (if they don't have legal presence in Ru) don't care about legal orders from Russia (as well as from other third-world dictatorship regimes) until it's some real valid stuff to complain about.
1) They block the whole-domain only in case of https which reminds you to turn-on the VPN. In case of http you could just have something like 404 response for particular page and you would never know that it's actually not 404, but ISP block (depends on ISP and DPI). So still https is preferable to be able to distinguish between two types of blocks.
2) They don't do "replace" in general, true, but for opposition resources they might be creative.
3) Most of hosters and content providers (if they don't have legal presence in Ru) don't care about legal orders from Russia (as well as from other third-world dictatorship regimes) until it's some real valid stuff to complain about.
doesn't man in the middle only apply if there were forms or anything requiring user input. I.e. a portion of the website is real, but the user interaction is attacked with MITM.
If the risk is that an ISP would spoof the entire website at AI, then that can be done regardless of HTTPS.
If the risk is that an ISP would spoof the entire website at AI, then that can be done regardless of HTTPS.
> If the risk is that an ISP would spoof the entire website at AI, then that can be done regardless of HTTPS.
No, an ISP cannot spoof a valid certificate for a website
No, an ISP cannot spoof a valid certificate for a website
Can’t the ISP still know what site you are visiting?
Not necessarily. That's a simple question with a complex answer. There's a lot of "ifs" and maybes and it depends a lot on how the site is set up internally.
That’s not really the point. Say the MITM just replaces the phone number with one of their own so that a potential client calls the wrong number and pays the wrong person.
Those who know, know, that selectively using encryption creates metadata that paints targets on more sensitive communications
This is the sort of thing that lay people like me imagine that serious infosec pros would pay attention to.
But to be perfectly honest: between the uncle with TS at a defense contractor, the ex-girlfriend Political Science valedictorian with an Arabic minor who “taught English” in Waziristan, and the pre-IPO Facebook job, I just sort of assume that if the Equation Group wants to know if I watch Internet porn, “I will do nothing, because I can do nothing”.
But to be perfectly honest: between the uncle with TS at a defense contractor, the ex-girlfriend Political Science valedictorian with an Arabic minor who “taught English” in Waziristan, and the pre-IPO Facebook job, I just sort of assume that if the Equation Group wants to know if I watch Internet porn, “I will do nothing, because I can do nothing”.
I was just kidding around folks: obviously TLS is the right default.
Incidentally you can bet your ass that someone at YC has a model of their amortized differential deal flow per page view and that they work harder at keeping it up-to-date than the RustHN discord channel where they call in the Team.
So troll-ass threads like this are pure free-ride.
Incidentally you can bet your ass that someone at YC has a model of their amortized differential deal flow per page view and that they work harder at keeping it up-to-date than the RustHN discord channel where they call in the Team.
So troll-ass threads like this are pure free-ride.
Seemingly none of these TLD-only domains have valid certs. Perhaps no certificate authority will sign this format?
this also works..amazing
https://1.1
goes to cloudflare. how did they register this?
https://1.1
goes to cloudflare. how did they register this?
There is an old (IIRC non-standard) convention from the classful IP times which allows you to write not only X.Y.Z.W but also X.Y.ZW, X.YZW, and occasionally even XYZW with ZW = 256 × Z + W (decimal) etc., all referring to the same host. So 1.0.1, 1.1, and 16777217 are all funny ways to write 1.0.0.1, which is indeed an alternative address for Cloudflare’s 1.1.1.1—also written 1.1.257, 1.65793, and 16843009.
I wonder what will happen when browsers start supporting Handshake (HNS) top-level domains such as “.1”
I neither expect this to happen nor think this is a matter for browsers (rather than system name resolvers), but in any case[1]
[2] https://url.spec.whatwg.org/#host-parsing
top-level domain names [must] not be all-numeric
If asciiDomain [split on periods] ends in a [C-style decimal, octal, or hexadecimal] number, then return the result of IPv4 parsing asciiDomain.
[2] https://url.spec.whatwg.org/#host-parsing
That's a bare ip. The ip is getting extended out to be a full 32 bit ipv4 address. It's not getting DNS resolved.
It's just the IP address 1.0.0.1 in the old "class A notation". (Network address dot host address).
1 is the network address. .0.0.1 is the host address. 1.256 would be 1.0.1.0, etc.
1 is the network address. .0.0.1 is the host address. 1.256 would be 1.0.1.0, etc.
Just use http://16777217 instead.
The same way 127.1 goes to the localhost, and 10.1 to 10.0.0.1.
Another one https://uz/
"potential security risk"
It claims the SSL cert is invalid on Firefox but it appears to be a valid one (just assigned to a high level domain). Looks like a potential DNS parsing issue in FF?
As far as I can see (Chrome’s cert viewer), the cert is for *.cctld.uz, cctld.uz (which doesn’t match uz alone). Do you see different names in the cert?
I see the same thing on Firefox.
What's up with the parked .Ai domain economy. The original bidding system is nice but gets dominated by investors who just park and wait for a valuable resell. I wish there was a use it or lose it clause
Vince Cate also manages the auctions for .ai domains
https://auction.whois.ai/auctions
>Removed Domains
>The Government of Anguilla reserves the right to remove domains that are in its opinion hate speech or breaking any Anguilla law. There has been 1 such domain removed in the history of ".ai".
Curious if anybody knows which domain was removed, the FAQ doesn't elaborate.
>The Government of Anguilla reserves the right to remove domains that are in its opinion hate speech or breaking any Anguilla law. There has been 1 such domain removed in the history of ".ai".
Curious if anybody knows which domain was removed, the FAQ doesn't elaborate.
You can submit just the ai. by the way: https://news.ycombinator.com/item?id=32804251
HN gets confused and doesn't add the domain name after the link title though.
HN gets confused and doesn't add the domain name after the link title though.
Mr Vince Cate belongs on the front page of HN.
Has anyone called that phone number? Crazy
My Anki decks don't have Anguilla (afaik). Guess I need to compile a list of all the colony nations, and then decide whether I'm gonna be able to learn further dozens of spots in the oceans, and to distinguish them from the fully-sovereign sprinklings of islands.
Are we now going to spam HN with all the links from the other “shortest domain” thread? There’s already several.
I love these post burning man posts.
How in the?
Top level domain with an A record.
Can you explain further? That still doesn't make sense to me.
See the link from the previous thread about this. https://news.ycombinator.com/item?id=32801359
.ai is a valid domain name
technically it's `ai.`
Similarly, we’re on
https://news.ycombinator.com./
No, that’s a different hostname. It will almost always resolve to the same IP address, and a large fraction of servers will serve the same content from the dotless and dotted forms, but they can serve something different (e.g. a redirect to the other form, or nothing), and it’s common for dotted versions of sites to be broken. All up, we’re not on the origin you showed.
Nope, that's definitely the same hostname, and will always resolve to the same IP address, barring some real weirdness (someone's system applying the search domain to a domain that already contains dots, and then actually finding a result for `news.ycombinator.com.search.domain.`). And in fact even in the case of that weirdness, `news.ycombinator.com.` would get to the correct place, while `news.ycombinator.com` would NOT.
Now, servers could certainly do the wrong thing when faced with a Host header ending in a `.`, but a) that's a bug in the web server (or browser, arguably - do they tack on a search domain to the Host header?) and b) is not a result of the wrong IP address etc. (It's also an HTTP-layer issue, not a DNS-layer issue, and doesn't apply to most other protocols.)
Now, servers could certainly do the wrong thing when faced with a Host header ending in a `.`, but a) that's a bug in the web server (or browser, arguably - do they tack on a search domain to the Host header?) and b) is not a result of the wrong IP address etc. (It's also an HTTP-layer issue, not a DNS-layer issue, and doesn't apply to most other protocols.)
It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple.
When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS).
Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared.
ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.
When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS).
Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared.
ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.
> It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple.
Except that it is, in fact, the same hostname. "It's that simple." This is defined by DNS. Go open Wireshark and run `dig google.com @8.8.8.8 +nocookie` versus `dig google.com. @8.8.8.8 +nocookie`. Observe that the queries are identical other than the "Transaction ID" (and perhaps some IP or UDP-level randomness).
Application-level software can get it wrong, but it is in fact the same hostname at a level that pretty much everyone uses.
Application-level software getting it wrong does not invalidate that fact.
You can not adopt an identifier from some other protocol, and then use it with a different meaning, without a bug.
(Tangentially, this is why naming shouldn't be handled at the application layer, since it's already handled at lower levels. It's quite sad that no one wants to start moving HTTP towards SRV records.)
> I was referring to search domains as the exception
Yes, I assumed so, but as I pointed out, this would lead to the common one (news.ycombinator.com) being broken while the other (news.ycombinator.com.) would work (or else be broken by an application-layer bug, i.e. processing of the Host header causing it to break)!
> ai and ai. might ... have one redirect to the other, might serve different content
Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
(And, as above, to do so would actually lead to the site being inaccessible for some people with search domains, since `ai` might actually be used as a subdomain, and `ai.` would still work for them but for a faulty application-layer configuration)
Except that it is, in fact, the same hostname. "It's that simple." This is defined by DNS. Go open Wireshark and run `dig google.com @8.8.8.8 +nocookie` versus `dig google.com. @8.8.8.8 +nocookie`. Observe that the queries are identical other than the "Transaction ID" (and perhaps some IP or UDP-level randomness).
Application-level software can get it wrong, but it is in fact the same hostname at a level that pretty much everyone uses.
Application-level software getting it wrong does not invalidate that fact.
You can not adopt an identifier from some other protocol, and then use it with a different meaning, without a bug.
(Tangentially, this is why naming shouldn't be handled at the application layer, since it's already handled at lower levels. It's quite sad that no one wants to start moving HTTP towards SRV records.)
> I was referring to search domains as the exception
Yes, I assumed so, but as I pointed out, this would lead to the common one (news.ycombinator.com) being broken while the other (news.ycombinator.com.) would work (or else be broken by an application-layer bug, i.e. processing of the Host header causing it to break)!
> ai and ai. might ... have one redirect to the other, might serve different content
Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
(And, as above, to do so would actually lead to the site being inaccessible for some people with search domains, since `ai` might actually be used as a subdomain, and `ai.` would still work for them but for a faulty application-layer configuration)
They are different hostnames. One is fully-qualified, the other is not. That the relative one is almost certain to resolve to the same as the fully-qualified is irrelevant. The fully-qualified one has an extra label. This makes it different. If you model hostnames in your type system, it would obviously be wrong for example and example. to compare as equal.
> Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
You’re arguing against facts that I have already clearly demonstrated. It’s messy that the FQDN and relative forms are exposed in this way, and it would be nice if that had never happened, but they are exposed, and claiming that they’re not just because you’ve decided to consider it a bug is nonsense.
Look, I’m just going to leave one more link here and disengage: https://url.spec.whatwg.org/#concept-domain (but also see the definition of “origin” in that document, which clearly refutes your claim of sameness):
> The example.com and example.com. domains are not equivalent and typically treated as distinct.
> Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
You’re arguing against facts that I have already clearly demonstrated. It’s messy that the FQDN and relative forms are exposed in this way, and it would be nice if that had never happened, but they are exposed, and claiming that they’re not just because you’ve decided to consider it a bug is nonsense.
Look, I’m just going to leave one more link here and disengage: https://url.spec.whatwg.org/#concept-domain (but also see the definition of “origin” in that document, which clearly refutes your claim of sameness):
> The example.com and example.com. domains are not equivalent and typically treated as distinct.
You are arguing against facts that I have already clearly demonstrated. Get out Wireshark and test.
Once again, mistakes made by an application-layer program (or spec!) do not invalidate the facts of underlying layers.
The hostname will always resolve to the same IP. A search domain doesn't change that, it changes what hostname is resolved.
(BTW: hostnames have existed since long before whatwg or even the web. I'm not sure why you would think whatwg have the authoritative definition of hostname.)
Also, since you like specs, here you go: "every domain name ends with the null label of the root", implying that the domain `foo` is, in fact, canonically, the domain `foo.` - RFC1035, November 1987. (The RFCs contemplate search domains as well, and mention that the final dot might be used as a cue to the application/library whether or not to apply the search domains, but that's entirely an application/library decision and changes the effective hostname/FQDN.)
In short: I never said that browsers and servers don't in fact treat them differently, I said that's a bug. You can't say "well they do it that way and the spec they wrote says it" as reasoning for it.
Once again, mistakes made by an application-layer program (or spec!) do not invalidate the facts of underlying layers.
The hostname will always resolve to the same IP. A search domain doesn't change that, it changes what hostname is resolved.
(BTW: hostnames have existed since long before whatwg or even the web. I'm not sure why you would think whatwg have the authoritative definition of hostname.)
Also, since you like specs, here you go: "every domain name ends with the null label of the root", implying that the domain `foo` is, in fact, canonically, the domain `foo.` - RFC1035, November 1987. (The RFCs contemplate search domains as well, and mention that the final dot might be used as a cue to the application/library whether or not to apply the search domains, but that's entirely an application/library decision and changes the effective hostname/FQDN.)
In short: I never said that browsers and servers don't in fact treat them differently, I said that's a bug. You can't say "well they do it that way and the spec they wrote says it" as reasoning for it.
yeah I'd listen to the IETF here vs the WHATWG. lol what a silly argument to get into.
Very good power
The page also got some really good art
For a second, I thought I am high.
this is the most "OG" domain name I've ever seen
After getting one of these short domains/urls and it not working on my browser, I'll be a late adopter. I think I spent like $30/yr on whatever I bought too.