4 ms·
The submission link is unnecessarily long, http://ai http://ai ought to work
by Retr0id 4y ago
The submission link is unnecessarily long, http://ai http://ai ought to work
- geowwy 4y agohttp://ai/ http://ai/ doesn't work for me, but http://ai./ http://ai./ does
- tgsovlerkhgsel 4y agoI 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.
- Bjartr 4y agoNeither works for me in Chrome on Android
- pxeboot 4y agoThey both work for me. I am using custom nameservers though.
- deleted 4y ago[deleted]
- Gigachad 4y agoThis is probably the most edge case url there is.
- CobrastanJorji 4y agohttp://ai./ http://ai./ works for me in Chrome with whatever my ISP default is.
- bornfreddy 4y agoBoth work for me in Firefox on MurenaOS (LineageOS based).
- bufferoverflow 4y agoBoth work in Chrome on Android. Strange we have opposite experiences. I guess it depends on ISP's DNS.
- deleted 4y ago[deleted]
- mindcrime 4y agoInteresting. 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"?
- anderskaseorg 4y agoOpenWrt 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 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-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ https://www.iab.org/documents/correspondence-reports-documen...
- mindcrime 4y agoThanks 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: https://wiki.archlinux.org/title/systemd-resolved#systemd-resolved_does_not_resolve_hostnames_without_suffix https://wiki.archlinux.org/title/systemd-resolved#systemd-re...
- SamBam 4y agohttp://ai http://ai works fine for me. I'm using Comcast's DNS with no special settings.
- deleted 4y ago[deleted]
- psnehanshu 4y agoA dot is required at the end. http://ai http://ai.
- psnehanshu 4y agoTurns out HN doesn't consider the final dot to be a part of the URL.
- Helmut10001 4y agoDoesn'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/ http://www.ai/ works.