Score:0

Ubuntu 20.04 upgrades - DNS name resolution fails on internal network

kr flag

My company distributes software to clients on Ubuntu VMs. Recently we've been updating all client VMs from Ubuntu 16/18 to Ubuntu 20.04.

We've been having an issue where DNS name resolution isn't working on the internal network. It's working outside of the network (we're able to ping external websites), but we're not able to connect to machines on the internal network by DNS name - only by IP address. In many cases we were able to resolve internal DNS names on the old VMs (Ubuntu 16/18), but it's not working when we install the new VM using the same network settings.

We usually set the VM up with a static IP. The client's IT gives us their network info and internal dns server(s), and we set up our 00-installer-config.yaml file accordingly

/etc/netplan/00-installer-config.yaml example setup:

network:
  ethernets:
    enp0s10f0:
      addresses: [192.168.10.200/24]
      gateway4: 192.168.10.1
      nameservers:
        addresses: [192.168.10.1, xxx.xxx.xxx.xxx, etc.]
  version: 2

On the old VMs, often we couldn't ping internal machines by DNS name until we added the local domain name. Eg. ping fs01 wouldn't work but ping fs01.clientdomain.local would work. However, on the Ubuntu VMs this doesn't seem to be helping at all. We always have to revert to the IP address of a file server rather than using the domain name. In most cases this is fine since the IP is static and not subject to change, but this isn't always the case and we'd prefer to be able to connect via DNS name.

Networking and domains really aren't my strong suit. If anyone could make suggestions of things to try or areas to research that would be much appreciated!

UPDATE

I tried the suggestion of adding the internal nameserver IP address to the nslookup command and took some screenshots. It does look like the VM is able to find the host with nslookup, but only when I include the nameserver IP explicitly.

192.168.1.4 is the nameserver and also the host that we're trying to connect to.

Note: This was working on the old Ubuntu 18.04 VM, using the same internal nameserver and the FQDN hostname.

Regular Ping

user@ubuntu:~$ ping <hostname.domain.local>
    ping: <hostname.domain.local>: Temporary failure in name resolution

Simple nslookup

user@ubuntu:~$ nslookup <hostname.domain.local>
    Server:     127.0.0.53
    Address:    127.0.0.53#53

    ** server can't find <hostname.domain.local>: SERVFAIL

nslookup with nameserver IP

user@ubuntu:~$ nslookup <hostname.domain.local> 192.168.1.4 
    Server:     192.168.1.4## Heading ##
    Address:    192.168.1.4#53

    Name:       <hostname.domain.local>
    Address:    192.168.1.85
    Name:       <hostname.domain.local>
    Address:    192.168.1.4

In this case, the 192.168.1.4 nameserver was the only nameserver entry in our yaml file. So I don't see how this could be some sort of issue with the order of nameservers in the file:

network:
  ethernets:
    enp0s10f0:
      addresses: [192.168.1.21/24]
      gateway4: <gateway>
      nameservers:
        search: [<domain.local>]
        addresses: [192.168.1.4]
  version: 2
jtessier72 avatar
cn flag
Is your gateway also your DNS server like in the example? Also, what is the output of 'nslookup <hostname>' and 'nslookup <hostname.yourdomain.com>'. Seems like you can't reach the DNS server.
kr flag
Sometimes IT gives us the gateway as one of their DNS servers. Usually they're different though. We tried doing nslookup on the hostname one time and weren't able to find it. But we were able to connect to the DNS server which was very strange. We recently did an update where we were able to connect by hostname for the first time, but their domain was ".ca" as opposed to ".local" (ie. `hostname.domain.ca`). I'm not sure why that would make a difference
jtessier72 avatar
cn flag
On old VMs, adding the search suffix clientdomain.local would help - as if you type ping fs01 it would append the search suffixes in order when trying to resolve the name. You might compare the IP addresses of the nameservers. When you say you can connect to the dns server - is that by ping or some other means?
kr flag
Yes it was just a simple ping to the DNS server that we tried. I think IT may have done an nslookup directly to the DNS server in one case but I can't recall exactly. Someone suggested to me to do an `nslookup <host FQDN> <nameserver IP address>` rather than only specifying the host, so I'll be sure to try that next time
ru flag
FYI you forgot to configure your search domains. If `hostname` is supposed to be `hostname.foo.bar` when you're using the FQDN your search domains need to be set up for `foo.bar` in the config. Add a `search: [clientdomain.local]` to your 'nameservers' section.
kr flag
Sorry I forgot to include that, I copied over the file contents manually. I've updated the config output above to be more accurate. We did try adding the search domain this time and I ran through the `ping/nslookup` commands again but it didn't have an effect on our internal name resolution issue
ru flag
@user2437443 I assume you ran `netplan apply` after the change or rebooting after that, because otherwise it wouldn't work. It also won't work unless 192.168.1.4 (DNS server) is aware the DNS search domain is present. And make sure you aren't including the `<` or `>` because that isn't part of the domain. Also, SERVFAIL means that when the system tried to query 192.168.1.4 an error happened so the DNS server failed to reply with a response that is valid. That suggests the DNS server you're using is broken or misconfigured, and not a client-side problem.
jtessier72 avatar
cn flag
You can see what the real active DNS server is: systemd-resolve --status | grep 'DNS Servers' -A2
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.