Score:0

The correct domain settings in /etc/resolv.conf?

cn flag

Currently I'm trying to configure settings of internal enterprise domain names for virtual SUSE hosts, which OS is SUSE Linux Enterprise Server 12 SP4.

There are two domain names that the SUSE hosts need to resolve: "infra.enterprise.com" and "test.infra.enterprise.com", and the domain name of these SUSE hosts' name has been set to "infra.enterprise.com" correctly.

The domains and records are all located on two MS AD/DNS servers(internally): 192.168.1.1 as primary and 192.168.1.2 as secondary.

However, I'm confused what parameters should I put in the /etc/resolv.conf file?

just nameserver 192.168.1.1 192.168.1.2 is fine and the SUSE hosts will automatically resolve the two domains?

Or I should add domain infra.enterprise.com?

and search infra.enterprise.com test.infra.enterprise.com?

is this gonna influence the SUSE hosts to resolve all the FQDN from the two domains?

Score:0
in flag

nameserver allows only one argument.

correct would be:

nameserver 192.168.1.1
nameserver 192.168.1.2

This would allow you to resolve full qualified domain names. But this alone does not allow you to resolve simple host names without FQDN.

For example, if you want to run ping infra and expect it to resolve infra.example.com you need to add this as a search domain.

search example.com

This would allow you to resolve infra as infra.example.com.

Score:0
in flag

Form manual:

   nameserver Name server IP address
          Internet address of a name server that the resolver should
          query, either an IPv4 address (in dot notation), or an
          IPv6 address in colon (and possibly dot) notation as per
          RFC 2373.  Up to MAXNS (currently 3, see <resolv.h>) name
          servers may be listed, one per keyword.  If there are
          multiple servers, the resolver library queries them in the
          order listed.  If no nameserver entries are present, the
          default is to use the name server on the local machine.
          (The algorithm used is to try a name server, and if the
          query times out, try the next, until out of name servers,
          then repeat trying all the name servers until a maximum
          number of retries are made.)

   search Search list for host-name lookup.
          By default, the search list contains one entry, the local
          domain name.  It is determined from the local hostname
          returned by gethostname(2); the local domain name is taken
          to be everything after the first '.'.  Finally, if the
          hostname does not contain a '.', the root domain is
          assumed as the local domain name.

          This may be changed by listing the desired domain search
          path following the search keyword with spaces or tabs
          separating the names.  Resolver queries having fewer than
          ndots dots (default is 1) in them will be attempted using
          each component of the search path in turn until a match is
          found.  For environments with multiple subdomains please
          read options ndots:n below to avoid man-in-the-middle
          attacks and unnecessary traffic for the root-dns-servers.
          Note that this process may be slow and will generate a lot
          of network traffic if the servers for the listed domains
          are not local, and that queries will time out if no server
          is available for one of the domains.

          If there are multiple search directives, only the search
          list from the last instance is used.

          In glibc 2.25 and earlier, the search list is limited to
          six domains with a total of 256 characters.  Since glibc
          2.26, the search list is unlimited.

          The domain directive is an obsolete name for the search
          directive that handles one search list entry only.

So nameserver are servers and used for query sequentially by resolver(if provided). Search option can be used for multiple subdomain with some limitation.

I sit in a Tesla and translated this thread with Ai:

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.