1. Forum
  2. Usenet
  3. LINUX.GENTOO.USER

  • Re: [gentoo-user] systemd DNS does not resolve 'local' addresses

    From Rich Freeman@21:1/5 to [email protected] on Sat Apr 2 23:50:01 2022
    On Sat, Apr 2, 2022 at 5:22 PM Alexander Puchmayr <[email protected]> wrote:

    ## portage.local maps to 192.168.1.6
    ## DNS-Server provided via DHCP is 192.168.1.1 (openwrt-router)

    buildhost-desktop ~ # ping portage.local
    ping: portage.local: Temporary failure in name resolution

    Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

    So, I haven't really used resolved much, but I see you have mDNS
    enabled. Does the portage.local host broadcast itself using mDNS? If
    it is running Gentoo then the answer is no unless you have it running
    avahi, which is usually not installed by default. Many
    desktop-oriented linux distros provide avahi by default.

    A resolver that supports mDNS will not use DNS to resolve the .local
    TLD, in accordance with RFC 6762.

    If you intend to use .local for DNS and not mDNS then you probably do
    not want mDNS enabled. You can either disable it for resolved
    globally by setting MulticastDNS=no in the [Resolve] section of /etc/systemd/resolved.conf, or by disabling it for a specific network
    in your network manager (the setting has the same name for
    systemd-networkd).

    This is one of those reasons why it is best to not use the .local TLD
    for DNS on your home network. You can disable it on systemd-resolved,
    but some IoT device in your home might have it permanently enabled.
    It allows a form of name resolution to work without any DNS server as
    devices discover and broadcast on their own.

    --
    Rich

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexander Puchmayr@21:1/5 to All on Sat Apr 2 23:30:01 2022
    Hi,

    After upgrading systemd from 249.9 to 249.11, some of my host names defined in my router's host file do no longer resolve, but nslookup can still resolve
    them properly. With 249.9 everything works fine, and all other machines which did not yet get the update work fine.

    Any ideas?

    Thanks,
    Alex

    ## portage.local maps to 192.168.1.6
    ## DNS-Server provided via DHCP is 192.168.1.1 (openwrt-router)

    buildhost-desktop ~ # ping portage
    ping: portage: Name or service not known

    buildhost-desktop ~ # ping portage.local
    ping: portage.local: Temporary failure in name resolution

    buildhost-desktop ~ # host portage
    portage has address 192.168.1.6

    buildhost-desktop ~ # nslookup portage
    Server: 192.168.1.1
    Address: 192.168.1.1#53

    Name: portage
    Address: 192.168.1.6

    buildhost-desktop ~ # dig portage
    ; <<>> DiG 9.16.27 <<>> portage
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40446
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;portage. IN A

    ;; ANSWER SECTION:
    portage. 0 IN A 192.168.1.6

    ;; Query time: 3 msec
    ;; SERVER: 192.168.1.1#53(192.168.1.1)
    ;; WHEN: Sat Apr 02 22:49:50 CEST 2022
    ;; MSG SIZE rcvd: 52

    buildhost-desktop ~ # resolvectl
    Global
    Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: uplink
    Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
    1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google
    2606:4700:4700::1111#cloudflare-dns.com
    2001:4860:4860::8888#dns.google
    2606:4700:4700::1001#cloudflare-dns.com
    2001:4860:4860::8844#dns.google

    Link 2 (enp3s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
    Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/ unsupported
    Current DNS Server: 192.168.1.1
    DNS Servers: 192.168.1.1
    buildhost-desktop ~ #

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexander Puchmayr@21:1/5 to All on Sun Apr 3 10:30:01 2022
    Thanks for the hint with mDNS, I wasn't aware of that. I'm using the '.local' domain for all my machines for more than 15 years now, longer than mDNS
    exists, but finally, after some research I found the problem, and actually it wasn't systemd per se, it was an update of /etc/nsswitch.conf. The old version had

    Hosts: mymachines files myhostname dns

    while the new version contains

    Hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

    The extra "resolve [!UNAVAIL=return]" makes the difference. It loads the glibc's plugin nss-resolve [1], which then calls systemd-resolved [2], which interprets '.local' as mDNS address. The mDNS is not activated on purpose, it seems to be some default setting of the router which does not appear in the configuration pages (or I didn't find it).

    Anyway, there are some ways to solve this:
    1) create an entry in /etc/hosts on every machine. Contradicts the idea of
    DNS, but works
    2) keep the old setting in nsswich.conf (without "resolve ...")
    3) change my "own" TLD from .local to something else, like .home, as suggested in [3]

    I think as long term strategy option 3 would be the best.

    Regards
    Alex

    [1] https://www.freedesktop.org/software/systemd/man/nss-resolve.html
    [2] https://www.freedesktop.org/software/systemd/man/systemd-resolved.html#
    [3] https://www.rfc-editor.org/rfc/rfc6762#appendix-G



    Am Samstag, 2. April 2022, 23:48:06 CEST schrieb Rich Freeman:
    On Sat, Apr 2, 2022 at 5:22 PM Alexander Puchmayr

    <[email protected]> wrote:
    ## portage.local maps to 192.168.1.6
    ## DNS-Server provided via DHCP is 192.168.1.1 (openwrt-router)

    buildhost-desktop ~ # ping portage.local
    ping: portage.local: Temporary failure in name resolution

    Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

    So, I haven't really used resolved much, but I see you have mDNS
    enabled. Does the portage.local host broadcast itself using mDNS? If
    it is running Gentoo then the answer is no unless you have it running
    avahi, which is usually not installed by default. Many
    desktop-oriented linux distros provide avahi by default.

    A resolver that supports mDNS will not use DNS to resolve the .local
    TLD, in accordance with RFC 6762.

    If you intend to use .local for DNS and not mDNS then you probably do
    not want mDNS enabled. You can either disable it for resolved
    globally by setting MulticastDNS=no in the [Resolve] section of /etc/systemd/resolved.conf, or by disabling it for a specific network
    in your network manager (the setting has the same name for
    systemd-networkd).

    This is one of those reasons why it is best to not use the .local TLD
    for DNS on your home network. You can disable it on systemd-resolved,
    but some IoT device in your home might have it permanently enabled.
    It allows a form of name resolution to work without any DNS server as
    devices discover and broadcast on their own.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich Freeman@21:1/5 to [email protected] on Sun Apr 3 17:20:01 2022
    On Sun, Apr 3, 2022 at 4:25 AM Alexander Puchmayr <[email protected]> wrote:

    wasn't systemd per se, it was an update of /etc/nsswitch.conf. The old version
    had

    Hosts: mymachines files myhostname dns

    while the new version contains

    Hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

    The extra "resolve [!UNAVAIL=return]" makes the difference. It loads the glibc's plugin nss-resolve [1], which then calls systemd-resolved [2], which interprets '.local' as mDNS address. The mDNS is not activated on purpose, it seems to be some default setting of the router which does not appear in the configuration pages (or I didn't find it).

    So, the nsswitch file does direct glibc to use the systemd resolve
    library, but it is resolved that is using mDNS. Did you check your resolved.conf? Does it have MulticastDNS=no set? If it isn't
    explicitly set you'd probably need to check the build-time options for
    what the defaults are these days.

    I don't see how your router would impact this. You don't even need
    DHCP/DNS at all to use mDNS, as long as the hosts implement mDNS and
    link-local autoconfig. (Those are addresses in the range
    169.254.0.0/16 and fe80::/10. Many OSes support this at this point by default.)

    In any case, disabling resolved would certainly solve the issue, but
    if you want to still use it you can fine-tune the mDNS settings on it.

    --
    Rich

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)