Score:0

How to configure NetworkManager to not set default search domain in RHEL8 based distros?

pk flag

Assume having a host with single, IPv4 only connection, named ens192, which has statically configured network settings (IP, DNS, gateway), named vm1.example.invalid. NetworkManager will add the following string to /etc/resolv.conf:

search example.invalid

Sometimes you don't want that or want to replace search domain with some other domain. When you do

nmcli connection modify ens192 ipv4.dns-search foo.invalid

/etc/resolv.conf will contain

search foo.invalid example.invalid

The question is:

How can i unset default search example.invalid in generated /etc/resolv.conf, using NetworkManager only?

What i tried:

  1. Explicitly setting ipv4.dns-search, like in example above, setting ipv6.dns-search failed with this property is not allowed for 'method=ignore'. Default domain search still appended to new dns-search.
  2. Reconfiguring server using nm-tui
  3. Setting search domain to . which is not only useless due to p.1, but also ignored in source code
  4. removing offending domain from /etc/resolv.conf. After restarting NetworkManager - it regenerates back
  5. Tried messing with network-scripts - but unsuccessfully

Workaround:

In my case, due to existing *.example.invalid wildcard A DNS record, this default search domain setting messed with resolving of non-existing domains and with kubernetes nodes, which are using ndots 5 by default (relevant issue for openshift and an article), resulting in broken dns within cluster. I resorted to manual management of /etc/resolv.conf, which is covered by Redhat docs, and while it works - I'd like to manage networking from one obvious place (NetworkManager), and to understand, why exactly this default record is even added? I tried skimming through NM source code, but not being a C programmer - haven't found a part where this default domain is being set.

Score:1
ck flag

you can find code here, this behavior is expected

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/core/dns/nm-dns-manager.c

void
nm_dns_manager_set_hostname(NMDnsManager *self, const char *hostname, gboolean skip_update)
{
    NMDnsManagerPrivate *priv   = NM_DNS_MANAGER_GET_PRIVATE(self);
    const char          *domain = NULL;

    /* Certain hostnames we don't want to include in resolv.conf 'searches' */
    if (hostname && nm_utils_is_specific_hostname(hostname)
        && !NM_STR_HAS_SUFFIX(hostname, ".in-addr.arpa")
        && !nm_inet_is_valid(AF_UNSPEC, hostname)) {
        domain = strchr(hostname, '.');
        if (domain) {
            domain++;
            /* If the hostname is a FQDN ("dcbw.example.com"), then add
             * the domain part of it ("example.com") to the searches list,
             * to ensure that we can still resolve its non-FQ form
             * ("dcbw") too. (Also, if there are no other search domains
             * specified, this makes a good default.) However, if the
             * hostname is the top level of a domain (eg, "example.com"),
             * then use the hostname itself as the search (since the user
             * is unlikely to want "com" as a search domain).
             *
             * Because that logic only applies to public domains, the
             * "assume_any_tld_is_public" parameter is FALSE. For
             * example, it is likely that the user *does* want "local"
             * or "localdomain" as a search domain.
             */
            if (domain_is_valid(domain, TRUE, FALSE)) {
                /* pass */
            } else if (domain_is_valid(hostname, TRUE, FALSE)) {
                domain = hostname;
            }

            if (!nm_hostname_is_valid(domain, FALSE))
                domain = NULL;
        }
    }

    if (!nm_strdup_reset(&priv->hostdomain, domain))
        return;

    _LOGT("set host domain to %s%s%s", NM_PRINT_FMT_QUOTE_STRING(priv->hostdomain));

    if (skip_update)
        return;

    if (!priv->updates_queue) {
        gs_free_error GError *error = NULL;

        if (!update_dns(self, FALSE, FALSE, &error))
            _LOGW("could not commit DNS changes: %s", error->message);
    }
}

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.