Not Respecting DHCP-Supplied Domain

[bj-github]

I have an assortment of Raspberry Pis (RPis) and a couple of ODroids (C2, C4) on a network managed by an OpenWRT-based gateway running DNSMasq to provide DHCP/DNS services. In each case, I edit /etc/hostname with the desired <hostname> after flashing an image to the boot medium.

The RPis run a mix of images from RaspberryPi.com/software and raspi.debian.net/tested-images/. The DHCP-supplied Domain is picked up by these images, and hostname -f returns <hostname>.<domain>.

I'm trying out the ODroid C4 image from here. It seems to ignore the DHCP-supplied Domain: hostname -f on this device simply returns <hostname>.

Any pointers, please, on how to have the ODroid pick up the DHCP-supplied Domain in similar fashion to the other images?

[johang]

Maybe use the systemd.network option UseDomains=.

[bj-github]

Thank you for the pointer. I created /etc/systemd/network/99UseDHCPDomain.network, placed this in it:

[DHCPv4]
UseDomains=true

[DHCPv6]
UseDomains=true

and rebooted. Alas, hostname -f still returns <hostname> alone, not <hostname>.<domain>.

Which still doesn't get to the reason why the Debian-provided RPi images pick up the DHCP-supplied Domain "out of the box", but these SBC images based on the same Debian packages do not?

[johang]

That's not how systemd .network files work. Add it to the existing files.

[bj-github]

Oh. I was using what I found in the man systemd.network documentation, especially Example 3 toward the end which showed creating such a file with the [DHCPv6] heading. Failing that, could you point me to where I put the UseDomains=true instead, please?

I've also noticed that the Debian RPi image finishes up with an /etc/resolv.conf of

domain <domain>
search <domain>
nameserver 192.168.<#>.1

while on the SBC image it contains:

nameserver 127.0.0.53
options edns0 trust-ad
search .

along with a comment noting that I'm looking at a redirect to /run/systemd/resolve/stub-resolv.conf.

I also discovered resolvectl does not exist on the Debian RPi image while on the SBC image it returns:

Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (end0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.<#>.1
       DNS Servers: 192.168.<#>.1 fd00:ab:cd::1

reinforcing that the network setup on the SBC images is very different than on the Debian RPi images. So no point in me spending time comparing the network setup of the two ...

[bj-github]

For what it is worth, my current "workaround" for this is to put <hostname>.<domain> in the device's /etc/hostname. With that in place, auto-apt-proxy is able to get the service entry from OpenWRT's dnsmasq to locate the apt-cacher-ng service running elsewhere in the network. hostname -f is returning <hostname>.<domain>, hostname -s returns <hostname>, and hostname -d returns <domain>.

But I'd still prefer to have the DHCP-supplied <domain> respected like it is with the Debian RPi images (not to mention the images supplied by the RPi folk).

[johang]

root@debian:~# cat /etc/systemd/network/en.network 
[Match]
Name=en*

[Network]
DHCP=true

[DHCPv4]
UseDomains=true

[DHCPv6]
UseDomains=true
root@debian:~# resolvectl 
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enxb827ebdf929b)
    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
        DNS Domain: net.johang.se
root@debian:~# cat /etc/resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search net.johang.se

[bj-github]

Ahh, excellent, thank you for that. Removed the <domain> from /etc/hostname and added your lines, and indeed the resolvectl output and ../resolve.conf now have <domain> appearing as in yours.

Very much appreciated - B.

[johang]

OK, so does it work for you now?

[bj-github]

Yes.

I guess my question is whether the addition of those settings should be part of a default set-up, on the assumption it'd be the expected behaviour when DHCP is used?