Loading
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
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Linux Backup and Recovery
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.
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- A Topic for Discussion - Open Source Feature-Richness?
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
- Developer Poll
- May 2013 Issue of Linux Journal: Raspberry Pi
- Reply to comment | Linux Journal
57 min 18 sec ago - Reply to comment | Linux Journal
3 hours 29 min ago - Reply to comment | Linux Journal
4 hours 47 min ago - great post
5 hours 22 min ago - Google Docs
5 hours 44 min ago - Reply to comment | Linux Journal
10 hours 32 min ago - Reply to comment | Linux Journal
11 hours 19 min ago - Web Hosting IQ
12 hours 53 min ago - Thanks for taking the time to
14 hours 30 min ago - Linux is good
16 hours 27 min ago
Poll
Comments
New DNS
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
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
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
One more reason I'd never use ubuntu on servers.
Speaking of DNS configuration...
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
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
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
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
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
dns-* entries in /e/n/i are for / used by resolvconf which exists since at least 2003 (in Debian).
This article would be
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
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
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
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
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
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
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.