0

Debian 12.4 with networking managed by systemd networking.service, dual stack IPv4 and IPv6.

I am aware of the many questions asking how to stop the system from updating resolv.conf, and this is not a duplicate.

TL;DR

At bootup, ifup appears to be overwriting resolv.conf (which I want) but doing it "incorrectly" (I think). The result is that resolv.conf ends up looking like this (prefix obfuscated):

nameserver 26xx:xxxx:xxxx:xxxx:201:2eff:fe70:3bfe

What is missing here is the nameserver entry for IPv4, and the search entry for my LAN domain.

Details

To troubleshoot, I did the following:

  • Deleted all current leases in /var/lib/dhcp
  • Started packet capture on the firewall for DHCP and DHCP6 ports
  • Rebooted the Debian system
  • Examined the resulting capture file with Wireshark

The findings are:

  • The IPv4 DHCP transaction requests, and the server returns, all the necessary information, including the hostname, domain name and DNS server IP.
  • The IPv6 DHCP transaction requests the same data, but the response includes only the DNS server address; hostname and domain name are not present in the DHCP6 response.

What I suspect is happening is that ifup is correctly setting up resolv.conf with the IPv4 data, then completely overwriting it with the IPv6 response instead of combining them.

THE QUESTION: What is supposed to happen with DHCP options and resolv.conf in a dual-stack system? Another way of asking that is "Who's at fault here, ifup or pfSense?"

Note

Packages network-manager and resolvconf are not installed, and systemd-networkd is disabled. The network is being managed by systemd's networking.service unit. I didn't intentionally set things up this way, it's what I got by default at installation.

Improve this question

1 Answer 1

Reset to default
2

What I suspect is happening is that ifup is correctly setting up resolv.conf with the IPv4 data, then completely overwriting it with the IPv6 response instead of combining them.

Your suspicion is probably exactly correct.

Plain ifup (without resolvconf or some other means of dealing with multiple sources of DNS settings) has no memory of previous DNS settings nor any way to combine settings from several sources; it's "the most recent source wins", plain and simple.

And on a dual-stack system, DHCPv4 and DHCPv6 are two separate sources of DNS information. Apparently your DHCPv6 server is not configured to assign hostnames nor provide domain name information.

"Who's at fault here, ifup or pfSense?"

Definitely ifup: it's inadequate for your setup in this regard unless augmented with resolvconf or systemd-resolved. Either of those would provide the capability to merge settings from two or more sources - and DHCPv4 and DHCPv6 on the same physical interface count as two separate sources.

Improve this answer
3
  • I tried systemd-resolved first, but the result was identical to my original problem (even after a reboot). Then I uninstalled systemd-resolved and installed resolvconf and that fixed the issue. Name resolution on Linux is clearly a case of "too many cooks..." :-) Thanks! Commented Feb 11, 2024 at 0:12
  • Are you aware that, when properly set up, systemd-resolved makes /etc/resolv.conf obsolete and causes just a backwards-compatibility setting nameserver 127.0.0.53 to appear in there? When using systemd-resolved, the actual nameserver settings can only be seen using resolvectl status. Commented Feb 11, 2024 at 7:14
  • Yes, I'm aware of that. In my particular instance, for reasons I don't fully understand, systemd-resolved was unable to handle the dual-stack DNS resolution. It still insisted on providing DNS only over IPv6. resolvconf worked seamlessly as soon as it was installed, and I don't really have the time to mess with this any more. I might revisit this in a few weeks when I have a bit more time. Thanks for pointing me in the right direction. Commented Feb 11, 2024 at 18:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.