.ai
ai
ai
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
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...
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...
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.
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.
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?
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.
--- /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'> 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.
Comment of note:
n@ai is also a valid email address. Owned by a guy named Ian.
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?
s/model/email validation code
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
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
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.
There are a lot of people in this world who can choose between exactly one ISP.
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?
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.
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.
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.)
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.
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”.
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.
goes to cloudflare. how did they register this?
1 is the network address. .0.0.1 is the host address. 1.256 would be 1.0.1.0, etc.
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.
>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.
HN gets confused and doesn't add the domain name after the link title though.
https://news.ycombinator.com./
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.)
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.
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)
> 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.
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.