Hacker News Reader

Comment by Retr0id | Hacker News Reader

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:

  $ 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.

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:

  #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-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.

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.

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 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.

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

They both work for me. I am using custom nameservers though.

This is probably the most edge case url there is.

http://ai./ works for me in Chrome with whatever my ISP default is.

Both work for me in Firefox on MurenaOS (LineageOS based).

Both work in Chrome on Android. Strange we have opposite experiences. I guess it depends on ISP's DNS.

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.

http://ai works fine for me. I'm using Comcast's DNS with no special settings.

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.

Reply on news.ycombinator.com