starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #1985] `Malformed label: --` when parsing resolv.conf #839

New issue

Closed

opened 2026-03-16 00:30:44 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 00:30:44 +03:00

Owner

Originally created by @Jake-Shadle on GitHub (Jul 6, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1985

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.

Originally created by @Jake-Shadle on GitHub (Jul 6, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1985 **Describe the bug** My local `/etc/resolv.conf` triggers [this error](https://github.com/bluejekyll/trust-dns/blob/c4e92cf837b2cd5bd5c3567bc405d01cf6eb1f03/crates/proto/src/rr/domain/label.rs#L96), due to the presence of the line `search -- lan`. **To Reproduce** Attemp to parse this file: ```txt 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.

kerem closed this issue

2026-03-16 00:30:49 +03:00

kerem commented

2026-03-16 00:30:55 +03:00

Author

Owner

@Jake-Shadle commented on GitHub (Jul 6, 2023):

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 commented on GitHub (Jul 6, 2023): 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.

kerem commented

2026-03-16 00:31:00 +03:00

Author

Owner

@Jake-Shadle commented on GitHub (Jul 6, 2023):

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

@Jake-Shadle commented on GitHub (Jul 6, 2023): 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 `--`.

kerem commented

2026-03-16 00:31:05 +03:00

Author

Owner

@CodeDead commented on GitHub (Jul 23, 2023):

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

@CodeDead commented on GitHub (Jul 23, 2023): Still, the double dashes are valid config options for /etc/resolv.conf . This bug also impacts the MongoDB Rust driver on Linux.

kerem commented

2026-03-16 00:31:10 +03:00

Author

Owner

@Jake-Shadle commented on GitHub (Jul 23, 2023):

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

@Jake-Shadle commented on GitHub (Jul 23, 2023): Do you have a reference for it in a spec? I tried and failed to find what - - even means.

kerem commented

2026-03-16 00:31:15 +03:00

Author

Owner

@CodeDead commented on GitHub (Jul 23, 2023):

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
https://github.com/bluejekyll/trust-dns/issues/1985#issuecomment-1646799864,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4J3UW6YBUNPJBSP2JRUBDXRTZWLANCNFSM6AAAAAA2AEI7DQ
.
You are receiving this because you commented.Message ID:
@.***>

@CodeDead commented on GitHub (Jul 23, 2023): 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 > <https://github.com/bluejekyll/trust-dns/issues/1985#issuecomment-1646799864>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD4J3UW6YBUNPJBSP2JRUBDXRTZWLANCNFSM6AAAAAA2AEI7DQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-03-16 00:31:20 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 24, 2023):

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?

@bluejekyll commented on GitHub (Jul 24, 2023): 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?

kerem commented

2026-03-16 00:31:25 +03:00

Author

Owner

@CodeDead commented on GitHub (Jul 24, 2023):

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.

@CodeDead commented on GitHub (Jul 24, 2023): > 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.

kerem commented

2026-03-16 00:31:30 +03:00

Author

Owner

@djc commented on GitHub (Jul 24, 2023):

@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?

@djc commented on GitHub (Jul 24, 2023): @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`?

kerem commented

2026-03-16 00:31:35 +03:00

Author

Owner

@CodeDead commented on GitHub (Jul 24, 2023):

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

@CodeDead commented on GitHub (Jul 24, 2023): > @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.

kerem referenced this issue

2026-03-16 02:22:13 +03:00

[PR #839] [CLOSED] Bump serde from 1.0.97 to 1.0.98 #1728