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

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 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 ago
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-resolved_does_not_resolve_hostnames_without_suffix https://wiki.archlinux.org/title/systemd-resolved#systemd-re...
- schoen 4y ago
  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.
  - ngcc_hk 4y ago
    Is there any safe way to do that? Other than set the DNS to 8.8.8.8?
    - mindcrime 4y ago
      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.
      - hjV9H2bWu4ZhXPy 4y ago
        Does a lookup for "ai." work without it? That is (explicitly, even!) a FQDN...
        mindcrime 4y ago
        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?
hjV9H2bWu4ZhXPy 4y ago
> 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.
xelxebar 4y ago
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'

mindcrime 4y ago

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-resolved_does_not_resolve_hostnames_without_suffix https://wiki.archlinux.org/title/systemd-resolved#systemd-re...

schoen 4y ago
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.
- ngcc_hk 4y ago
  Is there any safe way to do that? Other than set the DNS to 8.8.8.8?
  - mindcrime 4y ago
    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.
    - hjV9H2bWu4ZhXPy 4y ago
      Does a lookup for "ai." work without it? That is (explicitly, even!) a FQDN...
      - mindcrime 4y ago
        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?

hjV9H2bWu4ZhXPy 4y ago

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

xelxebar 4y ago

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'