Bug: Search paths get appended to every resolution, causing failed DNS lookups #37

New issue

Open

opened 2026-07-28 13:12:10 +00:00 by s1lv3r · 2 comments

s1lv3r commented

2026-07-28 13:12:10 +00:00

Member

Quote from @odd:oddware.net in dev room (second link):

Sorry if this is a known issue and I've just missed it, but I noticed yesterday that if /etc/resolv.conf contains a domain x.y.z entry, then c10y (26.6.2) will append that domain to dns requests, which ofc will fail. I tried removing the domain line, and it went back to normal after that. No more queries for <matrix-domain>.my.internal.domain.
Is this known?

See-Also:

First report in support room: https://matrix.to/#/!c10y-QdW7SIuT1NJWy3knfQT-tgAEMsUwZfthmFicQE/%24Liv6cH8V_bvSVt79KHKNa7qfQypIG4DRVgfAatKyNJo?via=wolfgirl.pet&via=gingershaped.computer&via=matrix.org
Second report in dev room: https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%244fO1MJmi0IVVCE05kNYfNk_szL1PaE7o7E2ZPPu2cTk?via=wolfgirl.pet&via=explodie.org&via=matrix.org

Quote from `@odd:oddware.net` in dev room (second link): > Sorry if this is a known issue and I've just missed it, but I noticed yesterday that if /etc/resolv.conf contains a `domain x.y.z` entry, then c10y (26.6.2) will append that domain to dns requests, which ofc will fail. I tried removing the domain line, and it went back to normal after that. No more queries for `<matrix-domain>.my.internal.domain.` > Is this known? See-Also: - First report in support room: https://matrix.to/#/!c10y-QdW7SIuT1NJWy3knfQT-tgAEMsUwZfthmFicQE/%24Liv6cH8V_bvSVt79KHKNa7qfQypIG4DRVgfAatKyNJo?via=wolfgirl.pet&via=gingershaped.computer&via=matrix.org - Second report in dev room: https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%244fO1MJmi0IVVCE05kNYfNk_szL1PaE7o7E2ZPPu2cTk?via=wolfgirl.pet&via=explodie.org&via=matrix.org

s1lv3r added the

Kind/Bug

Priority

Medium

labels

2026-07-28 13:12:49 +00:00

s1lv3r commented

2026-08-01 13:22:45 +00:00

Author

Member

I believe this happens due to these lines in c10y:

	if let Some(domain) = sys_conf.domain() {
		conf.set_domain(domain.clone());
	}

	for sys_conf in sys_conf.search() {
		conf.add_search(sys_conf.clone());
	}

However, it was my understanding that domain and search only got applied to non-qualified domains (domains without periods). Somewhere in that code that fails, and I am unsure of why.

Resolvematrix' default resolver gets created like this, without explicitly setting any options:

        let resolver = self.dns_resolver.unwrap_or(Arc::new(
            hickory_resolver::Resolver::builder_tokio()?.build()?,
        ));

I would assume the default options also use search and domain, but I may be mistaken in that assumption.

I believe this happens due to these lines in c10y: ```rs if let Some(domain) = sys_conf.domain() { conf.set_domain(domain.clone()); } for sys_conf in sys_conf.search() { conf.add_search(sys_conf.clone()); } ``` However, it was my understanding that `domain` and `search` only got applied to non-qualified domains (domains without periods). Somewhere in that code that fails, and I am unsure of why. Resolvematrix' default resolver gets created like this, without explicitly setting any options: ```rs let resolver = self.dns_resolver.unwrap_or(Arc::new( hickory_resolver::Resolver::builder_tokio()?.build()?, )); ``` I would assume the default options also use `search` and `domain`, but I may be mistaken in that assumption.

s1lv3r commented

2026-08-01 13:31:14 +00:00

Author

Member

Usually, the ndots option is what would say if the search domain should be used:

    /// Sets the number of dots that must appear (unless it's a final dot representing the root)
    ///  before a query is assumed to include the TLD. The default is one, which means that `www`
    ///  would never be assumed to be a TLD, and would always be appended to either the search
    #[cfg_attr(feature = "serde", serde(default = "default_ndots"))]
    pub ndots: usize,

The default for hickory-resolver is 1, i.e. 1 dot must be included before it is assumed to include the TLD, and the search domain gets ignored. According to the resolv.conf(5) man page, the default here is also 1.

I suspect the original reporters might have changed the ndots options on their systems, because there was no change to how the DNS resolver is built before and after the rewrite. Will ask reporters directly.

Usually, the `ndots` option is what would say if the search domain should be used: ```rs /// Sets the number of dots that must appear (unless it's a final dot representing the root) /// before a query is assumed to include the TLD. The default is one, which means that `www` /// would never be assumed to be a TLD, and would always be appended to either the search #[cfg_attr(feature = "serde", serde(default = "default_ndots"))] pub ndots: usize, ``` The default for hickory-resolver is 1, i.e. 1 dot must be included before it is assumed to include the TLD, and the search domain gets ignored. According to the [`resolv.conf(5)`](https://man7.org/linux/man-pages/man5/resolv.conf.5.html) man page, the default here is also 1. I suspect the original reporters might have changed the ndots options on their systems, because there was no change to how the DNS resolver is built before and after the rewrite. Will ask reporters directly.