Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 25. Using different DNS servers for different domains

By default, Red Hat Enterprise Linux (RHEL) sends all DNS requests to the first DNS server specified in the /etc/resolv.conf file. If this server does not reply, RHEL tries the next server in this file until it finds a working one. In environments where one DNS server cannot resolve all domains, administrators can configure RHEL to send DNS requests for a specific domain to a selected DNS server.

For example, you connect a server to a Virtual Private Network (VPN), and hosts in the VPN use the example.com domain. In this case, you can configure RHEL to process DNS queries in the following way:

  • Send only DNS requests for example.com to the DNS server in the VPN network.
  • Send all other requests to the DNS server that is configured in the connection profile with the default gateway.

You can configure NetworkManager to start an instance of dnsmasq. This DNS caching server then listens on port 53 on the loopback device. Consequently, this service is only reachable from the local system and not from the network.

With this configuration, NetworkManager adds the nameserver 127.0.0.1 entry to the /etc/resolv.conf file, and dnsmasq dynamically routes DNS requests to the corresponding DNS servers specified in the NetworkManager connection profiles.

Prerequisites

  • The system has multiple NetworkManager connections configured.

  • A DNS server and search domain are configured for the connection that is responsible for resolving a specific domain.

    For example, to ensure that the DNS server specified in a VPN connection resolves queries for the example.com domain, the following settings must be available:

    • A DNS server that can resolve example.com. A DHCP server can provide this information dynamically or you set the ipv4.dns and ipv6.dns parameters in the VPN connection profile.
    • A search domain set to example.com. A DHCP server can provide this information dynamically or you set the ipv4.dns-search and ipv6.dns-search parameters in the VPN connection profile.
  • The dnsmasq service is not running or configured to listen on a different interface than localhost.

Procedure

  1. Install the dnsmasq package: 

    # dnf install dnsmasq
    Copy to Clipboard Toggle word wrap

  2. Edit the /etc/NetworkManager/NetworkManager.conf file, and set the following entry in the [main] section: 

    dns=dnsmasq
    Copy to Clipboard Toggle word wrap

  3. Reload the NetworkManager service: 

    # systemctl reload NetworkManager
    Copy to Clipboard Toggle word wrap

Verification

  1. Search in the systemd journal of the NetworkManager unit for which domains the service uses a different DNS server: 

    # journalctl -xeu NetworkManager
...
Jun 02 13:30:17 <client_hostname>_ dnsmasq[5298]: using nameserver 198.51.100.7#53 for domain example.com
...
    Copy to Clipboard Toggle word wrap

  2. Use the tcpdump packet sniffer to verify the correct route of DNS requests:

    1. Install the tcpdump package: 

      # dnf install tcpdump
      Copy to Clipboard Toggle word wrap

    2. On one terminal, start tcpdump to capture DNS traffic on all interfaces: 

      # tcpdump -i any port 53
      Copy to Clipboard Toggle word wrap

    3. On a different terminal, resolve host names for a domain for which an exception exists and another domain, for example: 

      # host -t A www.example.com
# host -t A www.redhat.com
      Copy to Clipboard Toggle word wrap

    4. Verify in the tcpdump output that Red Hat Enterprise Linux sends only DNS queries for the example.com domain to the designated DNS server and through the corresponding interface: 

      ...
13:52:42.234533 tun0   Out IP server.43534 > 198.51.100.7.domain: 50121+ A? www.example.com. (33)
...
13:52:57.753235 enp1s0 Out IP server.40864 > 192.0.2.1.domain: 6906+ A? www.redhat.com. (33)
...
      Copy to Clipboard Toggle word wrap

      Red Hat Enterprise Linux sends the DNS query for www.example.com to the DNS server on 198.51.100.7 and the query for www.redhat.com to 192.0.2.1.

Troubleshooting

  1. Verify that the nameserver entry in the /etc/resolv.conf file refers to 127.0.0.1: 

    # cat /etc/resolv.conf
nameserver 127.0.0.1
    Copy to Clipboard Toggle word wrap

    If the entry is missing, check the dns parameter in the /etc/NetworkManager/NetworkManager.conf file.

  2. Verify that the dnsmasq service listens on port 53 on the loopback device: 

    # ss -tulpn | grep "127.0.0.1:53"
udp  UNCONN 0  0    127.0.0.1:53   0.0.0.0:*    users:(("dnsmasq",pid=7340,fd=18))
tcp  LISTEN 0  32   127.0.0.1:53   0.0.0.0:*    users:(("dnsmasq",pid=7340,fd=19))
    Copy to Clipboard Toggle word wrap

    If the service does not listen on 127.0.0.1:53, check the journal entries of the NetworkManager unit: 

    # journalctl -u NetworkManager
    Copy to Clipboard Toggle word wrap

You can configure NetworkManager to start an instance of systemd-resolved. This DNS stub resolver then listens on port 53 on IP address 127.0.0.53. Consequently, this stub resolver is only reachable from the local system and not from the network.

With this configuration, NetworkManager adds the nameserver 127.0.0.53 entry to the /etc/resolv.conf file, and systemd-resolved dynamically routes DNS requests to the corresponding DNS servers specified in the NetworkManager connection profiles.

Important

The systemd-resolved service is provided as a Technology Preview only. Technology Preview features are not supported with Red Hat production Service Level Agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These previews provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features.

For a supported solution, see Using dnsmasq in NetworkManager to send DNS requests for a specific domain to a selected DNS server.

Prerequisites

  • The system has multiple NetworkManager connections configured.

  • A DNS server and search domain are configured for the connection that is responsible for resolving a specific domain.

    For example, to ensure that the DNS server specified in a VPN connection resolves queries for the example.com domain, the following settings must be available:

    • A DNS server that can resolve example.com. A DHCP server can provide this information dynamically or you set the ipv4.dns and ipv6.dns parameters in the VPN connection profile.
    • A search domain set to example.com. A DHCP server can provide this information dynamically or you set the ipv4.dns-search and ipv6.dns-search parameters in the VPN connection profile.

Procedure

  1. Install the systemd-resolved package: 

    # dnf install systemd-resolved
    Copy to Clipboard Toggle word wrap

  2. Enable and start the systemd-resolved service: 

    # systemctl --now enable systemd-resolved
    Copy to Clipboard Toggle word wrap

  3. Edit the /etc/NetworkManager/NetworkManager.conf file, and set the following entry in the [main] section: 

    dns=systemd-resolved
    Copy to Clipboard Toggle word wrap

  4. Reload the NetworkManager service: 

    # systemctl reload NetworkManager
    Copy to Clipboard Toggle word wrap

Verification

  1. Display the DNS servers systemd-resolved uses and for which domains the service uses a different DNS server: 

    # resolvectl
...
Link 2 (enp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute ...
Current DNS Server: 192.0.2.1
       DNS Servers: 192.0.2.1

Link 3 (tun0)
    Current Scopes: DNS
         Protocols: -DefaultRoute ...
Current DNS Server: 198.51.100.7
       DNS Servers: 198.51.100.7 203.0.113.19
        DNS Domain: example.com
    Copy to Clipboard Toggle word wrap

    The output confirms that systemd-resolved uses different DNS servers for the example.com domain.

  2. Use the tcpdump packet sniffer to verify the correct route of DNS requests:

    1. Install the tcpdump package: 

      # dnf install tcpdump
      Copy to Clipboard Toggle word wrap

    2. On one terminal, start tcpdump to capture DNS traffic on all interfaces: 

      # tcpdump -i any port 53
      Copy to Clipboard Toggle word wrap

    3. On a different terminal, resolve host names for a domain for which an exception exists and another domain, for example: 

      # host -t A www.example.com
# host -t A www.redhat.com
      Copy to Clipboard Toggle word wrap

    4. Verify in the tcpdump output that Red Hat Enterprise Linux sends only DNS queries for the example.com domain to the designated DNS server and through the corresponding interface: 

      ...
13:52:42.234533 tun0   Out IP server.43534 > 198.51.100.7.domain: 50121+ A? www.example.com. (33)
...
13:52:57.753235 enp1s0 Out IP server.40864 > 192.0.2.1.domain: 6906+ A? www.redhat.com. (33)
...
      Copy to Clipboard Toggle word wrap

      Red Hat Enterprise Linux sends the DNS query for www.example.com to the DNS server on 198.51.100.7 and the query for www.redhat.com to 192.0.2.1.

Troubleshooting

  1. Verify that the nameserver entry in the /etc/resolv.conf file refers to 127.0.0.53: 

    # cat /etc/resolv.conf
nameserver 127.0.0.53
    Copy to Clipboard Toggle word wrap

    If the entry is missing, check the dns parameter in the /etc/NetworkManager/NetworkManager.conf file.

  2. Verify that the systemd-resolved service listens on port 53 on the local IP address 127.0.0.53: 

    # ss -tulpn | grep "127.0.0.53"
udp  UNCONN 0  0      127.0.0.53%lo:53   0.0.0.0:*    users:(("systemd-resolve",pid=1050,fd=12))
tcp  LISTEN 0  4096   127.0.0.53%lo:53   0.0.0.0:*    users:(("systemd-resolve",pid=1050,fd=13))
    Copy to Clipboard Toggle word wrap

    If the service does not listen on 127.0.0.53:53, check if the systemd-resolved service is running.

25.3. Routing DNS traffic through a certain interface
Copia collegamento

NetworkManager supports different mechanisms to configure DNS servers in the system, which include adding configuration to the /etc/resolv.conf file and configuring DNS services, such as systemd-resolved, dnsmasq, and dnsconfd.

Each DNS server mentioned in a connection profile is associated with a specific network interface. The DNS backend services systemd-resolved and dnsmasq ensure that each DNS name server remains accessible only through the correct network interface. However, other backend services do not support this feature. In this regard, NetworkManager has a feature that automatically adds a dedicated route so that each name server is reached only through the correct interface. You can set up the ipv4.routed-dns and ipv6.routed-dns properties to use this feature.

Example scenario:

  • Connection profile 1 <example-connection-1> :

    • Default gateway: 192.0.2.254
    • DNS server: 10.0.0.1
    • Search domain: example-domain.com

  • Connection profile 2 <example-connection-2> :

    • Default gateway: 198.51.100.254 (this gateway has no access to the 10.0.0.0/24 network)
    • DNS server: 203.0.113.1

In this example, you have two connection profiles: <example-connection-1> and <example-connection-2> that are connected through enp1s0 and enp7s0 network interfaces. If the <example-connection-2> second profile was connected first, the default gateway 198.51.100.254 of this connection has a lower metric and takes precedence over the first profile. Consequently, RHEL uses the default gateway of the second connection while connecting to the DNS server 10.0.0.1 of the first profile. As a result, the DNS resolution fails. To solve this problem, enable the ipv4.routed-dns setting for both connection profiles so that NetworkManager creates a dedicated route for the 10.0.0.1 DNS server through the correct interface, in this case, enp1s0.

Prerequisites

  • The connection profiles already exist.

Procedure

  1. Modify the connection profile to enable the creation of routes to the name server:

    1. For connection profile 1, enter: 

      # nmcli connection modify <example-connection-1> ipv4.routed-dns yes
      Copy to Clipboard Toggle word wrap

    2. For connection profile 2, enter: 

      # nmcli connection modify <example-connection-2> ipv4.routed-dns yes
      Copy to Clipboard Toggle word wrap

  2. Re-activate the connections: 

    # nmcli connection up <example-connection-1>

# nmcli connection up <example-connection-2>
    Copy to Clipboard Toggle word wrap

Verification

  • Display the route to reach an IP address: 

    # ip route get 203.0.113.1
203.0.113.1  dev  enp1s0  table  20053  src  10.0.0.1  uid  0
    Copy to Clipboard Toggle word wrap

    This command verifies if the name server is reached through the correct interface and uses the policy routing method that places all the routes for DNS servers in the special routing table 20053.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat