Ubuntu's New DNS: Unknown Host

If you're the type of person who installs Ubuntu's server edition, you're also likely the sort of person who knows how to configure network settings. For most distributions, especially those based on Debian, the process is a bit strange, but familiar.

To configure the various interfaces, you edit /etc/network/interfaces and add the appropriate IP information, along with the gateway address. That doesn't complete the process, however, because if you manually configure the network interfaces, you need to add the DNS servers manually to the /etc/resolv.conf file. That's the way it's always been, and I never put much thought into it—until Canonical changed the way the resolv.conf file works.

I'll admit, my initial reaction was one of frustration, but once I got over myself, I have to say it makes much more sense to add the DNS configuration right into the /etc/network/interfaces file as well. My only complaint is that there aren't comments in either the /etc/resolv.conf file or the /etc/network/interfaces file on actually how to do it! (Thankfully, there is a note in /etc/resolv.conf warning that any changes will be overwritten, but no hints on how to make changes properly.)

The process, as it turns out, is rather simple. In /etc/network/interfaces, simply add a couple lines to the end of the stanza for a particular interface—for example:

# The primary network interface
auto eth0  
iface eth0 inet static   
address 192.168.1.200   
netmask 255.255.255.0   
gateway 192.168.1.1   
dns-nameservers 192.168.1.1   
dns-domain example.com   
dns-search example.com

You'll notice the last three lines contain a few unfamiliar directives. They are fairly self-explanatory, but important to know. Once added to the /etc/network/interfaces file like above, the /etc/resolv.conf file is populated with the proper information when the network is activated. It's fairly simple, and it makes sense to have all the settings in one spot—but frustrating if you don't know about the changes!

______________________

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

New DNS

RonTrex's picture

For latest Ubuntu versions /etc/resolv.conf actually is symbolic link to /run/resolvconf/resolv.conf

Ron @ http://www.bluepelicanloans.com/

This is very frustrating

Alistair Pirie's picture

This is very frustrating indeed. Is Ubuntu slowly shooting itself in the foot?

A few small issues like this have cause me a huge pain in the backside!

Auto diagnostic technicians

autelcn.com's picture

Auto diagnostic technicians work as apprentices at repair facilities under the supervision of experienced craftsmen. On-the-job training lasts from two to five years and exposes auto diagnostic technicians to a variety of situations, says the Bureau of Labor Statistics. http://www.autelcn.com/

Ubuntu sucks on servers

Bachsau's picture

One more reason I'd never use ubuntu on servers.

Speaking of DNS configuration...

crh's picture

Has anybody else noticed that with the latest Ubuntu LTS version that using the OpenVPN client does not apply the new DNS address provided by the server? I've read a few things about it and one of them seemed to be along the lines of what Shawn posted here but that fix doesn't seem to resolve the issue. Also some posts say that the problem is really with the server configuration but those so called fixes break the VPN. I know the DNS address was set correctly when I was using OpenVPN client under 10.04LTS but not with 12.04LTS. Hum...

I want my coffee shop anonymity back. For the time being I'm RDPing via the VPN until I can get Ubuntu to accept/use my internal DNS IP address that was set up just for that purpose.

no worry be happy

Cellofan's picture

I use Debian since 2002 and I learned from school, you do not get anything if we begin to study the system.

This seems counter-intuitive

Anonymous's picture

How does this make more sense?
/etc/network/interfaces contains settings that are relevant to a particular interface.
DNS has absolutely nothing to do with configuring a network interface (think ISO OSI layers here).

If you want to configure your interfaces and DNS settings in one place you should be using some something like network-manager which by definition is designed to include DNS and interface configuration in one place.

To put it another way, using this approach could potentially use a different DNS server for each active interface. This would kinda make sense if you had a public interface and a VPN interface but how on earth do you let the OS/kernel know which DNS server to use?

You are spot on; this makes

fukawi2's picture

You are spot on; this makes very little sense. DNS is a system-wide setting, not per-interface.

Perfect example why I don't even consider Ubuntu, well, for anything, especially servers.

This feature is important for desktops/laptops

Anonymous's picture

I agree that this makes little sense for (most) servers. However, it's quite important for many desktops/laptops because of VPNs. Many people these days are running one, or sometimes more!, VPNs to connect to private networks. Once that happens your statement that "DNS is a system-wide setting, not per-interface", is just not good enough. It should NOT be a system-wide setting, because the hostnames you can see through one interface are not visible through the other interface. When I want to look up private hostnames in one VPN I need to use that VPN's DNS servers; when I want to look up private hostnames in another I need to use its servers; when I want to look up hostnames on my private LAN I need to use my LAN's DNS servers, etc.

Although I wish Ubuntu (or Debian) had the ability to take on this problem at a more fundamental level, where it SHOULD be solved, at least they're making some effort to fix it which is appreciated.

Not to start a flame war or anything but just as a data point: Windows handles this VPN situation without issue (when it works). There's nothing magical about the UNIX method of /etc/resolv.conf--in fact, it's an inflexible and insufficient solution that has been obsolete for many years, but lives on because no one has the time/energy/whatever to fix it.

dns-* entries in /e/n/i are

gregoa's picture

dns-* entries in /e/n/i are for / used by resolvconf which exists since at least 2003 (in Debian).

This article would be

Anonymous's picture

This article would be considerably more informative if it included details about which version of Ubuntu initiated this change to the DNS configuration method. The wording of the title makes it seem like an issue new for 12.10, which it is not.

For latest Ubuntu versions

Anonymous's picture

For latest Ubuntu versions /etc/resolv.conf actually is symbolic link to /run/resolvconf/resolv.conf
and for workstation (for servers I use old ones — 8.04 and 10.04) it is updated by NetworkManager for which (some of) settings are in /etc/NetworkManager

This isn't a new thing. It's

Anonymous's picture

This isn't a new thing. It's been around for some time. I don't know if it was in older version of Ubuntu but I haven't configured my DNS settings in /etc/resolv.conf for some time on Debian-based systems.

not new, and still buggy

Roland's picture

I just installed Snowlinux, a Debian7 Wheezy derivative. The box could not ping or browse (via mini-httpd) itself,
by name or by IPaddress. And DNS was broken, despite setup via XFCE's gui. Fixed DNS by hand-creating /etc/resolv.conf.

Still couldn't ping/browse itself, but other boxes could.
Turns out lo was down because /etc/network/interfaces was empty except for 2 comments. This "new" stuff is clearly broken and shouldn't be foisted on the user community in its current state. Why fix that which isn't broken? What is the point of these changes?

Should've commented this better in /etc/resolv.conf

Sum Yung Gai's picture

I ran into this as well and, since there was no available direction (can't Google very well when you've got no DNS), I just temporarily stuck in a quick little script to make a new /etc/resolv.conf, with my DNS settings, at each boot time in /etc/rc.local. No, not the most elegant way by far, but I was in a time bind, and this quick hack got the job done at the moment.

Later on, when things 'round here settled down a bit, I did the proper Googling and found this info. It's not at all a bad way to do it; not trying to claim that it is somehow "bad". However, that info really should've been in the "new" /etc/resolv.conf as comments, in the first place. As the article points out, we've been doing /etc/resolv.conf for years--decades, even. Had that been in there, I'd have hacked /etc/network/interfaces right then and there and been on my way.

--SYG

Broken Resolv.conf

Lambchopper's picture

I came across this just this week. After having a mi-fi connection update my resolv.conf and then not setting it back when I was disconnected. I found that by manually renaming that file and creating a new one, I inadvertently broke it and Network Manager wasn't updating the file anymore.

I found the fix on-line and it was rather simple:
sudo apt-get reconfigure resolvconf

Then choose yes to the enable dynamic updates option. That will reset the default behavior this article references.

Been using resolvconf in

Seeker5528's picture

Been using resolvconf in Debian for years, couldn't use in Ubuntu for a while due to a combination of factors relating to transition to upstart and transition from '/var/run' to '/run'. It's good to see these things sorted out.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix