Malformed label: -- when parsing resolv.conf

[Jake-Shadle]

Describe the bug
My local /etc/resolv.conf triggers this error, due to the presence of the line search -- lan.

To Reproduce
Attemp to parse this file:

nameserver 127.0.0.53
options edns0 trust-ad
search -- lan

Expected behavior
I would expect this file to be parsed, if it is actually valid, which I'm assuming it is since my system works, but I honestly have no clue if trust-dns or systemd is in the wrong here since my efforts to figure out what the valid form(s) of the search entry in the resolv.conf is/are was met with defeat.

After playing around with my /etc/systemd/resolved.conf I'm becoming more convinced that this is a systemd bug, as doing any changes to the Domains= field (which controls the search field in resolv.conf) will always result in -- being appended or prepended to whatever entries I make.

System:

• OS: linux
• Architecture: x86_64
• Version: 6.3.8-200.fc38.x86_64
• rustc version: 1.70.0

Version:
Crate: proto
Version: 0.22.0

Additional context
I didn't configure this myself and since I've never had this issue in the past, I'm assuming a recent system update added/changed the search -- lan entry in the resolv.conf, so I'm assuming other people will start hitting this issue if this is a general update to Fedora 38/systemd-resolv, but that's just a guess.

That being said, I'm not certain this is a bug in trust-dns, but more likely systemd, but figured I would open this issue just in case that is not the case, or at least have a record of this issue if others hit it, as I was unable to find much info elsewhere about this.

[Jake-Shadle]

Oh and as a workaround, one can just edit /etc/resolv.conf to remove the -- from the search field, just be aware that those changes will be overwritten if you re/start the systemd-resolved service or reboot.

[Jake-Shadle]

Took a look at my laptop running PopOS instead of Fedora, but still using systemd, and sure enough the resolv.conf just has search lan with no --.

[CodeDead]

Still, the double dashes are valid config options for /etc/resolv.conf . This bug also impacts the MongoDB Rust driver on Linux.

[Jake-Shadle]

Do you have a reference for it in a spec? I tried and failed to find what - - even means.

[CodeDead]

https://man.archlinux.org/man/resolv.conf.5#search

…

On Sun, 23 Jul 2023, 12:07 Jake Shadle, ***@***.***> wrote: Do you have a reference for it in a spec? I tried and failed to find what - - even means. — Reply to this email directly, view it on GitHub <#1985 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4J3UW6YBUNPJBSP2JRUBDXRTZWLANCNFSM6AAAAAA2AEI7DQ> . You are receiving this because you commented.Message ID: ***@***.***>

[bluejekyll]

I have no idea what — would mean in this context?

I think one option would be for us to change the resolve.conf parsing to be lossy and ignore illegal input? My guess is this is some awkward default based on other configurations in the system, like no hostname?

[CodeDead]

I have no idea what — would mean in this context?

I think one option would be for us to change the resolve.conf parsing to be lossy and ignore illegal input? My guess is this is some awkward default based on other configurations in the system, like no hostname?

It would mean nothing. This is because of faulty hostnames for example or faulty network managers adding things that make no sense. If only double dashes are present, double dashes in the search can be ignored.

[djc]

@CodeDead how do you conclude that from those docs? I didn't see anything relevant in that man page?

Maybe we should look at the code (presumably in libc implementations) that parses resolv.conf?

[CodeDead]

@CodeDead how do you conclude that from those docs? I didn't see anything relevant in that man page?

Maybe we should look at the code (presumably in libc implementations) that parses resolv.conf?

Because -- is not a valid search domain and meaningless. Most likely added due to a network manager since most distro's use a network manager to manage /etc/resolv.conf (in my case the latest version of systemd-resolved)

If I, for example do a dig +search google the dig command will fail too with the error message:

dig: '--' is not a legal IDNA2008 name (string start/ends with forbidden hyphen), use +noidnin

You could either panic and fail, which is now the case for both dig and trust-dns repo or ignore the search domain because it is invalid. Whether this is a systemd bug is hard to tell, because it might be intended behavior to ignore double dashes when using systemd because systems with systemd running still work when search is set to the double dashes. It is still valid to place double dashes in the search field because there are no standards or restrictions listed in the manual that prevent you from doing that but it will not form a valid domain according to the domain standards. The question is how to handle that; to fail or to ignore the dashes.

Journaling systemd-resolved (with google dns) and no domain name set in the system will give me something like this:

journalctl -u systemd-resolved -f

Jul 24 18:44:38 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set DNS server list to: 8.8.8.8, 8.8.4.4
Jul 24 18:44:39 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set DNS server list to: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844
Jul 24 18:46:46 deadlinepc systemd-resolved[1120]: enp6s0: Bus client reset search domain list.
Jul 24 18:46:46 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set default route setting: no
Jul 24 18:46:46 deadlinepc systemd-resolved[1120]: enp6s0: Bus client reset DNS server list.
Jul 24 18:46:47 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set search domain list to: --
Jul 24 18:46:47 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set default route setting: yes
Jul 24 18:46:47 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set DNS server list to: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844
Jul 24 18:46:47 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set DNS server list to: 8.8.8.8, 8.8.4.4
Jul 24 18:46:48 deadlinepc systemd-resolved[1120]: enp6s0: Bus client set DNS server list to: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844

Which stems from a 'faulty' connection profile. The best (read: fastest) way to solve this problem for systemd, is to re-create the connection profile (delete the connection profile and create a new one) in systemd devices if the double dashes are present (probably stemming from faulty router / DHCP setup) in the hopes that the search field will then be retrieved and set correctly.

Whether or not to fail for invalid domains is another matter (because most of systemd will absolutely work and just ignore the problem) whereas some tools (like dig) will panic.

Ignoring the double dashes might be the way to go for systemd because it is not a valid domain and perhaps trust-dns should ignore invalid search domains too, but that is a decision to make and take for the maintainers. Either way, search -- is an invalid search domain but still, nothing prevents you from adding invalid search domains in resolv.conf or the actual router.