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:
$ ping ai.
ping: ai.: Temporary failure in name resolution
But if I edit /etc/resolv.conf and change the nameserver to 8.8.8.8 like this:
# nameserver 127.0.0.53
nameserver 8.8.8.8
it works fine.
$ 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
Hmm... I wonder if that's a systemd-resolved issue, or an OpenWRT issue, or "other"?
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.
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:
#nameserver 127.0.0.53
nameserver 192.168.1.1
It works, so the OpenWRT box seems to be doing the Right Thing now. I guess systemd-resolved is likewise doing something weird with these one-component names. Huh.
EDIT:
Found the corresponding systemd-resolved issue. See here:
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.
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 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.
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
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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”.
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.
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.
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?
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
>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.
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.
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.)
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.
> 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)
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.
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.
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.
