Ошибка dns linux

DNS resolution is an important service, without it functioning properly domain names will not be correctly resolved to IP addresses preventing other network services from working correctly. Therefore it is equally important to know how to troubleshoot DNS issues on a Linux client and fix any problems to reduce disruption.

There are multiple potential points of failure during the DNS lookup process such as at the system performing the lookup, at the DNS cache, or on an external DNS server. Here we will cover how to check these and perform various tests to identify where exactly the problem lies.


Red Hat Certified Engineer RHCE Video Course
Studying for your RHCE certification? Checkout our RHCE video course over at Udemy which is 20% off when you use the code ROOTUSER.


Local Server Configuration

First off it’s important to understand the ‘hosts’ section of the /etc/nsswitch.conf file, the default configuration for hosts is shown below.

hosts:      files dns myhostname

Essentially this means that host name resolution will be performed in the order specified, left to right. First files will be checked, followed by DNS.

As files are first these will be checked first, this references the local /etc/hosts file which contains static host name to IP address mappings. This file takes priority over any DNS resolution, any changes to the file will be placed straight into the DNS cache of that local server. Below is an example line of configuration from /etc/hosts

1.1.1.1     google.com

As this entry is in our host file locally, if we try to reach google.com our local machine will think that 1.1.1.1 is the correct IP address of google.com and will not perform a DNS lookup. This is demonstrated below by trying to ping google.com, DNS is not consulted as there is a hosts file entry which takes priority.

[root@centos ~]# ping google.com
PING google.com (1.1.1.1) 56(84) bytes of data.

If there is no entry in the hosts file DNS will be used next as per /etc/nsswitch.conf. The servers used for DNS resolution will be specified in the /etc/resolv.conf file, below is an example configuration of this file.

nameserver 192.168.0.1

In this case all DNS queries of our system will go to the DNS server at 192.168.0.1. Other secondary and tertiary DNS servers can also be specified here as backups.

Testing DNS

For DNS resolution to succeed to 192.168.0.1, the DNS server at 192.168.0.1 will need to accept TCP and UDP traffic over port 53 from our server. A port scanner such as the nmap tool can be used to confirm if the DNS server is available on port 53 as shown below.

Note: To install nmap run ‘yum install nmap -y’.

[root@centos ~]# nmap -sU -p 53 192.168.0.1
Starting Nmap 6.40 ( http://nmap.org ) at 2015-08-26 15:22 AEST
Nmap scan report for 192.168.0.1
Host is up (0.00091s latency).
PORT   STATE         SERVICE
53/udp open|filtered domain
MAC Address: 02:00:79:55:00:0D (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

[root@centos ~]# nmap -sT -p 53 192.168.0.1
Starting Nmap 6.40 ( http://nmap.org ) at 2015-08-26 15:22 AEST
Nmap scan report for 192.168.0.1
Host is up (0.00099s latency).
PORT   STATE SERVICE
53/tcp open  domain
MAC Address: 02:00:79:55:00:0D (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

It’s worth noting that scanning UDP with nmap is not reliable due to the nature of UDP, this is why the state is listed as open or filtered. We can clearly see that TCP 53 is definitely open and responding which is a good sign, if the state was reported as filtered the next thing to investigate would be the connectivity to the DNS server, in particular any firewall running on the DNS server would need to be configured to allow TCP and UDP port 53 traffic in.

By running a packet capture we can view any DNS queries over the network, in this example we are running tcpdump to our local DNS server at 192.168.0.1 and we can see our request from 192.168.0.100 requesting the A record of google.com as well as the response of 216.58.220.142 which is returned from our local DNS server.

[root@testing ~]# tcpdump -n host 192.168.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:29:52.439222 IP 192.168.0.100.32811 > 192.168.0.1.domain: 8134+ A? google.com. (28)
15:29:52.440153 IP 192.168.0.1.domain > 192.168.0.100.32811: 8134 1/0/0 A 216.58.220.142 (44)

The Domain Information Groper (dig) tool can be used to perform DNS queries as demonstrated below. We are again querying for google.com and we are again returned the A record IP address of 216.58.220.142.

Note: Dig is provided by the bind-utils package which can be installed with ‘yum install bind-utils’.

[root@testing ~]# dig google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.3 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32536
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             65      IN      A       216.58.220.142

The status of the dig query correctly returned the IP address from our local DNS server at 192.168.0.1 and the status was NOERROR, which is returned when the query has been successfully resolved. Response codes can help you in the troubleshooting process, for a full list of them refer to RFC 5395.

Test Authoritive DNS Server

With dig we can also directly query the authoritative name servers for a domain, these are the DNS servers that hold the authoritative records for the domains DNS zone – the source of truth. If a correct response is received from the authoritative DNS server but not when querying against your own DNS server then you should investigate why your local DNS server is not able to resolve the record.

To get the name servers of a domain we can use the ‘whois’ command as shown below. This is part of the whois package and can be installed with ‘yum install whois -y’ if not already present.

[root@testing ~]# whois google.com | grep -i "name server"
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM

As shown google.com currently has 4 authoritative name servers, if we run a dig directly against any of these we should receive an authoritative response, that is an up to date and non cached response straight from the source rather than from our local DNS server. In the below example we have run our query against @ns1.google.com

[root@testing ~]# dig @NS1.GOOGLE.COM google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.3 <<>> @NS1.GOOGLE.COM google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3477
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       216.58.220.142

While the A record returned is the same in this instance, note that in this dig response we now have the “aa” flag in the header which represents that this is an authoritative answer and is not a cached response. If we run this same dig command again, the 300 second TTL that was returned in the answer section will continually state that the TTL is 300 seconds as the response is authoritative.

However if we were to run this dig without specifying @ns1.google.com we would be querying our 192.168.0.1 DNS server which is not authoritative for the google.com domain, after the first result the record will be cached locally. This can be confirmed by running the dig command again, as the TTL value will drop down until it reaches 0 and is removed from the cache completely.

By querying the authoritative name server directly we ensure that we are getting the most up to date response rather than a potential old cached response from our own local DNS server or local DNS cache.

Summary

As DNS is an important service being able to troubleshoot it is a useful skill. By default Linux will first check it’s local host file /etc/hosts before querying DNS servers defined in /etc/resolv.conf. It is important to confirm that the correct DNS servers have been specified within this file and that you can connect to them on TCP/UDP port 53. DNS queries can be checked with the dig command, either against the local DNS server or against the authoritative name server for the domain which will provide an up to date non cached result.


This post is part of our Red Hat Certified Engineer (RHCE) exam study guide series. For more RHCE related posts and information check out our full RHCE study guide.

In this troubleshooting post, we will exaplin:

  • Usage of dig command to troubleshoot common DNS problems.
  • Identify symptoms and causes associated with common DNS issues.

Troubleshooting DNS

Due to the client-server architecture of DNS, properly working DNS name resolution on a system is almost always dependent on not only the proper configuration and operation of DNS on that system but also on that of its resolving nameserver and the many authoritative nameservers used to resolve its DNS requests. Since DNS is a distributed directory, recursive name resolution often involves numerous behind-the-scenes interactions with many different authoritative nameservers. These numerous interactions create many possible points for failure.

The use of caching nameservers significantly reduces DNS workloads and improves DNS performance. However, the caching function adds another point of failure by creating scenarios where it is possible for DNS responses received by clients to be inaccurate due to the data no longer being current.

Due to the critical role that DNS plays in the functioning of network services, it is important that Linux administrators be able to quickly resolve DNS issues when they occur, in order to minimize service interruptions. The key to accurate and efficient DNS troubleshooting is being able to pinpoint which of the multiple points in the myriad of behind-the-scenes client-server interactions is responsible for the unexpected behavior observed. This requires the use of proper tools and a clear understanding of the diagnostic data they provide. Domain Internet Groper (dig) is a good tool for investigating DNS issues due to its verbose diagnostic output.

Name resolution methods

Because DNS service is often the most widely used method of name resolution, it often bears the blame whenever unexpected name resolution results occur. Remember that aside from DNS, in a heterogeneous environment, name resolution on networked hosts can occur via other methods, such as local hosts files, Windows Internet Name Service (WINS), etc.

On Linux systems, name resolution is attempted first with the hosts file /etc/hosts by default, per order specified in /etc/nsswitch.conf. Therefore, when beginning name resolution troubleshooting, do not leap to the assumption that the issue resides with DNS. Begin first by identifying the name resolution mechanism which is in play, rather than simply starting with DNS. The getent command from the glibc-common package, as well as the gethostip command from the syslinux package, can both be used to perform name resolution, mirroring the process used by most applications in following the order of host name resolution as dictated by /etc/nsswitch.conf.

$ getent hosts example.com
172.25.254.254  example.com
$ gethostip example.com
example.com 172.25.254.254 AC19FEFE

If the result of getent or gethostip differs from that produced by dig, then it’s a clear indication that something besides DNS is responsible for the unexpected name resolution result. Consult /etc/nsswitch.conf to determine what other name resolution mechanisms are employed before DNS.

Client-server network connectivity

For DNS name resolution to work properly, a system must first be able to conduct client-server interactions with its resolving nameserver or other authoritative nameservers. Some common DNS issues that have their origin at this layer are the result of the resolver and firewall misconfigurations.

When using dig to troubleshoot a DNS issue, if a response is not received from a DNS server, it is a clear indication that the cause lies with the client-server network connectivity to the DNS server.

$ dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> A example.com
;; global options: +cmd
;; connection timed out; no servers could be reached

A possible cause is the inability to reach the DNS server due to incorrect DNS server IP address(es) in a system’s DNS configuration. This could be in /etc/resolv.conf in the case of a system acting as a DNS client or in the forward-zone clause of /etc/unbound/unbound.conf in the case of a system configured as an unbound caching nameserver

Another possible cause is firewall rules, on either the client or server system, blocking DNS traffic on port 53. While DNS mostly uses the UDP protocol, it is important to note that when response data sizes exceed 512 bytes or 4096 bytes in the case of DNS servers that support Extension Mechanism for DNS (EDNS), resolvers will fall back to using TCP to retry the query. Therefore, proper DNS configuration should allow for DNS traffic on port 53 for both UDP and TCP. Allowing port 53 traffic for UDP only will result in a truncation error when the resolver encounters a response that is larger than what it can handle over UDP.

$ dig @serverX.example.com A labhost1.example.com
;; Truncated, retrying in TCP mode.
;; Connection to 172.25.1.11#53(172.25.1.11) for labhost1.example.com failed:
host unreachable

dig’s tcp or vc options are helpful for troubleshooting whether DNS queries can succeed with TCP. These options force dig to use TCP, rather than the default behavior of using UDP first and falling back to TCP only when response size necessitates it.

$ dig +tcp A example.com

When dealing with DNS issues at the network layer, dig provides a very sparse output and it is therefore often useful to also use a network packet analyzer, such as tcpdump, to determine what is transpiring behind the scenes at the network layer. Using tcpdump, the administrator can determine the information that cannot be ascertained with dig alone, such as the destination IP address of the DNS request, if request packets leave the client if request packets reach the server, if response packets leave the server if response packets reach the client, etc

DNS Response Codes

If DNS client-server communication is successful, dig will generate much more verbose output detailing the nature of the response received from the DNS server. The status field in the HEADER section of dig’s output reports the response code generated by the DNS server in response to the client’s query.

$ dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30523
...

A status of NOERROR indicates the query was resolved successfully. If the server encounters problems fulfilling the client’s query, one of the following common error statuses will be displayed.

DNS Return Codes

CODE MEANING
SERVFAIL The nameserver encountered a problem while processing the query.
NXDOMAIN The queried name does not exist in the zone.
REFUSED The nameserver refused the client’s DNS request due to policy restrictions.

SERVFAIL

A common cause of SERVFAIL status is the failure of the DNS server to communicate with the nameservers authoritative for the name being queried. This may be due to the authoritative nameservers being unavailable. It could also be a problem at the network layer interfering with the client-server communication between the DNS server and the authoritative nameservers, such as network routing issues or firewall rules at any hop in the network path.

To determine why a nameserver is generating a SERVFAIL status while performing recursion on behalf of a client’s query, the administrator of the nameserver will need to determine which nameserver communication is causing the failure. dig’s + trace option is helpful in this scenario to see the results of nameserver’s iterative queries starting with the root nameservers

NXDOMAIN

An NXDOMAIN status indicates that no records were found associated with the name queried. If this is not the expected result and the query is directed at a server that is not authoritative for the name, then the server’s cache may contain a negative cache for the name. The user can either wait for the server to expire the negative cache of that name, or submit a request to the server administrator to flush the name from the server’s cache. Once the name is removed from the cache, the server will query the authoritative nameserver to receive current resource records for the name.

The other scenario where an NXDOMAIN status may be unexpectedly encountered is when querying a CNAME record containing an orphaned CNAME. In a CNAME record, the name on the right side of the record, the canonical name, should point to a name that contains either A or AAAA records. If these associated A or AAAA records are nonexistent or are later removed, then the canonical name in the CNAME record is orphaned. When this occurs, queries for the owner name in the CNAME record will no longer be resolvable and will result in an NXDOMAIN return code.

REFUSED

A REFUSED status indicates that the DNS server has a policy restriction that keeps it from fulfilling the client’s query. Policy restrictions are often implemented on DNS servers to restrict which clients can make recursive queries and zone transfer requests. Some common causes of an unexpected REFUSED return code are clients configured to query the wrong DNS servers or DNS server misconfiguration causing valid client requests to be refused.

OTHER COMMON DNS ISSUES

Outdated cached data

A DNS return code of NOERROR signifies that no errors were encountered in resolving a query. However, it does not guarantee that there are no DNS issues present. There are situations where the DNS records in the DNS response may not match the expected result. The most common cause for an incorrect answer is that the answer originated from cached data, which is no longer current.

In these situations, first confirm that the response is indeed nonauthoritative cached data. This can be easily determined by looking at the flags section of dig’s output. DNS responses, which are authoritative answers, will be indicated by the presence of the aa flag.

$ dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22257
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

DNS responses that originate from cached data are not authoritative and therefore will not have the aa flag set. The other telltale sign that an answer is coming from cache is the counting down of the resource record’s TTL value in the responses of each subsequent query. TTLs of cached data will continuously count down to expiration while TTLs of authoritative data will always remain static.

Responses for nonexistent records

If a record has been removed from a zone and a response is still received when querying for the record, first confirm that the queries are not being answered from cached data. If the answer is authoritative as confirmed by the presence of the aa flag in dig’s output, then a possible cause is the presence of a wildcard (*) record in the zone.

*.example.com. IN A 172.25.254.254

A wildcard record serves as a catchall for all queries of a given type for a nonexistent name. With the previous wildcard record in place, if an A record previously existed for serverX.example.com and it is removed, queries for the name will still succeed and the IP address in the wildcard A record will be provided in its place.

Non-FQDN name errors

In a zone file, hostnames that are not expressed as Fully Qualified Domain Names (FQDNs) are automatically expanded to FQDNs by appending the name of the zone. To indicate that a name is an FQDN in a zone file, it must be ended with a “.”, i.e., “www.example.com.”. Failure to do so can lead to different issues depending on the type of record that the mistake is made in. For example, such a mistake made in the type-specific data portion of NS records has the potential of incapacitating an entire zone, while a mistake made in MX records could cause a complete halt of email delivery for a domain.

Looping CNAME records

While technically feasible, CNAME records that point to CNAME records should be avoided to reduce DNS lookup inefficiency. Another reason this is undesirable is the possibility of creating unresolvable **CNAME **loops, such as:

test.example.com. IN CNAME lab.example.com.
lab.example.com.  IN CNAME test.example.com.

While a CNAME record with an orphaned CNAME will result in an NXDOMAIN status, looping CNAME records will return as NOERROR.

Missing PTR records

Many network services use DNS to perform reverse lookups of incoming connections from clients. The absence of PTR records in DNS may result in issues, the nature of which varies depending on the service. SSHD, by default, will perform reverse lookups of connecting client IPs. Absence of PTR records will lead to delays in the establishment of these connections.

Many MTAs incorporate reverse DNS lookups of connecting client IPs as a defense against malicious email clients. In fact, many MTAs are configured to reject client connections for IPs, which cannot be resolved with a PTR query in DNS. As such, administrators supporting network services need to ensure that they understand the requirements these services have for not just forward, but also reverse DNS lookups.

Round-robin DNS

A name can have multiple A or AAAA records in DNS. This is known as round-robin DNS, and is often used as a simple, low-cost, load-balancing mechanism to distribute network resource loads across multiple hosts. When a DNS client queries for a name that contains multiple A or AAAA records, all records are returned as a set. However, the order that the records are returned in the set permutates for each query. Since clients normally make use of the first address in the set, the variation in the order of the records in each response effectively results in a distribution of network service requests across the multiple IP addresses in these round-robin DNS records.

While round-robin DNS is a valid technical configuration, there are times when this configuration is inadvertently created. When a request to change the IP address of an A record is mistakenly implemented as a resource record addition rather than a resource record modification, then round-robin DNS is created. If the network resources on the old IP address is retired, the load distribution effect of the round-robin DNS will result in service failures for approximately half of the clients

DNS (Domain Name System) is the phonebook of the internet. A Domain name is a unique alphanumeric address that users type in the URL bar in the browser in order to access a website.

Domain names enable users to access a website instead of using an IP address that maps onto every domain name. Sometimes, you may encounter DNS issues such as a misconfigured DNS server which might lead to downtime.

In this guide, we look at 6 tools you can leverage to troubleshoot DNS Name resolution problems in Linux.

Table of Contents

1. Nslookup Command

The good old nslookup command has been around for a while. It’s a command-line tool that queries and provides detailed information about the internet domain name servers.

You would typically use the nslookup tool to obtain DNS records of a domain name such as the mapping between a domain name and its associated IP address. The information obtained from querying a DNS record is valuable in troubleshooting DNS-related issues.

To retrieve information about a DNS record, use the following syntax:

$ nslookup domain_name

For example, to check the DNS record of a domain called linuxtechwhiz.info, run the command:

$ nslookup linuxtechwhiz.info

If everything is okay, you should get output that resembles what we have here.

Check Domain DNS in Linux

Check Domain DNS in Linux

The first section displays information about the server used to obtain the DNS records. In this case, it is the local DNS server on my local network. Sometimes, this might be your router or an internal corporate server.

The second section displays the Fully Qualified Domain name and its corresponding IP address (Both IPv4 and IPv6). In some cases, like ours, IPv4 is the only active protocol.

For some domain names, both protocols are enabled. For example, if you query google.com, you find that the domain name maps to multiple IP addresses, both IPv4 and IPv6.

$ nslookup google.com

Query Domain DNS in Linux

Query Domain DNS in Linux

2. dig Command

Short for Domain Information Groper, dig is yet another command-line tool for querying Domain Name System (DNS) name servers. It’s a better DNS query tool and replaced the nslookup command.

The dig command allows you to perform DNS lookups and provide intricate details about various DNS records including A, MX, and SOA records.

The most straightforward way of probing a DNS record is by typing the dig command followed by the domain name and pressing ENTER.

$ dig linuxtechwhiz.info

Query Domain DNS Info in Linux

Query Domain DNS Info in Linux

The output of the dig command is quite verbose. To display the IP address mapping include the +short suffix as shown.

$ dig linuxtechwhiz.info +short

74.207.227.36

3. host Command

The host command is another handy tool you can use to handle manual DNS resolution. For example, you can perform a DNS forward lookup as shown.

$ host linuxtechwhiz.info

Check DNS Forward Lookup

Check DNS Forward Lookup

You can also perform a reverse lookup as follows.

$ host 173.82.232.55

Check DNS Reverse Lookup

Check DNS Reverse Lookup

The -C option lets you query for the SOA records.

$ host -C linuxtechwhiz.info

Check DNS SOA Records

Check DNS SOA Records

In addition, you can query for the MX records using the -t mx flags as shown.

$ host -t mx google.com

Check DNS MX Records

Check DNS MX Records

To display all the information about a domain, pass the -a flag as shown.

$ host -a google.com

Check Domain DNS Info

Check Domain DNS Info

4. ping Command

The ping command is mostly used to check the availability or reachability of a system or node.

You can test the connectivity of a domain name by pinging the domain as shown.

$ ping linuxtechwhiz.info -c 4

A positive response implies that the name resolution is working as expected. An error points to a DNS resolution issue.

Moreover, you can ping the remote IP associated with the domain name to check if the system hosting your name is up and reachable.

$ ping 173.82.232.55 -c 4

Ping Remote Linux Host

Ping Remote Linux Host

The command-line tools that we have just looked at only provide limited information about your DNS records and cannot adequately be used to troubleshoot complex DNS issues.

5. MXToolBox

MXToolBox is a free online tool (paid for extra features) that provides fast and accurate network diagnostic and DNS lookup tools.

It provides you with a comprehensive outlook of your domain health, which includes monitoring your domain, displaying information about any DNS or IP blacklists, probing the email server for any issues, checking the web server, and running over 15 tests on your DNS server.

It’s a highly recommended tool if your sole purpose is to get to the bottom of any DNS-related issue.

MxToolbox - MX Lookup Tool

MxToolbox – MX Lookup Tool

6. IntoDNS

IntoDNS is another valuable tool that you can use to check and troubleshoot any DNS-related issues. In just a few seconds, it generates a detailed report about NS records, nameservers, SOA and MX records, TTL, refresh interval, and much more.

In addition, it provides information about mail servers’ IP address and their validity and any possible problem with your domain name.

IntoDNS - Checks DNS Servers

IntoDNS – Checks DNS Servers
Closing Thoughts

These are just a few tools that provide insights into your DNS records which come in handy in troubleshooting any faults or errors associated with your domain. We hope you found this guide insightful. Feel free to reach out with any comments or feedback.

A temporary failure in name resolution is a common issue that Linux users may encounter when their system cannot resolve a hostname to an IP address. This problem can occur due to various reasons, such as network connectivity issues, DNS configuration problems, or issues with the local hosts file. In this article, we will discuss several steps you can take to troubleshoot and resolve this issue on your Linux system.

1. Check your internet connection

Before diving into the technical aspects of resolving the issue, it is crucial to ensure that your system is connected to the internet and that the network is functioning properly. Verify your system’s network connection by attempting to access a website or using the ping command to check the connectivity to a known IP address or domain.

Try to ping an IP address eg: 8.8.8.8 and see the results:

ping 8.8.8.8 -c 4 

If the ping is successful, that means internet is working properly on your system.

2. Verify DNS settings

The first step in troubleshooting temporary failure in name resolution is to verify your system’s DNS settings. The /etc/resolv.conf file contains the DNS server IP addresses, which are usually provided by your Internet Service Provider (ISP) or network administrator. This is the most common error we encouding for this error.

To view the contents of the /etc/resolv.conf file, run the following command:

cat /etc/resolv.conf 

If the file is empty or does not contain valid DNS server IP addresses, you can add them manually. To edit the file, run:

sudo nano /etc/resolv.conf 

Add the following lines with the appropriate DNS server IP addresses, such as Google’s public DNS servers:

nameserver 8.8.8.8

nameserver 8.8.4.4

Save and exit the file using Ctrl+X, then Y, and finally Enter.

3. Check the local hosts file

The /etc/hosts file contains hostname and IP address mappings for your local system. Ensure that this file has the correct entries for your system’s hostname and IP address. You can view the file using:

cat /etc/hosts 

If the file is incorrect or missing entries, edit it using:

sudo nano /etc/hosts 

Add or correct entries as needed, following this format:

127.0.0.1   localhost

192.168.1.100 local.example.com

<yoursystemip>        <yourhostname>

Save and exit the file.

4. Restart the network service

After making changes to the DNS or hosts files, you need to restart the networking service to apply the changes. Run one of the following commands, depending on your Linux distribution:

sudo systemctl restart networking 

or

sudo /etc/init.d/networking restart 

5. Clear the DNS cache

If your system uses a DNS caching service like nscd or dnsmasq, you should clear the cache to ensure that the latest DNS information is used. Run the appropriate command to restart the service:

sudo systemctl restart nscd 

For dnsmasq:

sudo systemctl restart dnsmasq 

6. Test the name resolution

After completing the above steps, test the name resolution using the ping, host, or nslookup commands:

ping example.com 
host example.com 
nslookup example.com 

If the issue persists after following these steps, you may need to consult your network administrator or ISP for further assistance.

Conclusion

Resolving a temporary failure in name resolution on Linux systems involves checking network connectivity, verifying DNS settings, inspecting the local hosts file, restarting network services, and clearing the DNS cache. By following the steps outlined in this article, you should be able to troubleshoot and resolve most cases of temporary failure in name resolution. However, if the issue persists, it is essential to seek help from your network administrator or ISP, as there may be underlying problems with the network infrastructure or configuration that need to be addressed.

In some cases, the issue may also be related to firewall settings or security software on your system that is blocking DNS requests. Make sure to check your firewall rules and security software settings to ensure that they are not interfering with your system’s ability to resolve hostnames.

Furthermore, it is important to keep your system updated and ensure that all packages, including DNS-related tools and services, are up to date. Regularly updating your system can help prevent issues related to outdated or incompatible software components.

By following these steps and maintaining a healthy system, you can minimize the occurrence of temporary failures in name resolution and ensure smooth operation of your Linux system on the network.

Модератор: Bizdelnick

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Решено: Не работает DNS — не преобразуются адреса в ip.

Linux DeLi. Ядро Linux 2.4.33. Когда ввожу ping www.mail.ru, по пишет «Unknown host www.mail.ru». Кроме того не настроить динамический ip-адрес, dhclient’а нет, поэтому ввожу «ifconfig eth0 192.168.0.2». Доступны ip адреса, находящиеся в локальной сети.
даже не знаю что и делать… Да и должно ли быть так?

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

ubuntuAndrew »

Караул! Когда устанавливал dhcp (скачал исходники с isc.org), то часто выводил «Цель all не требует выполнения команд», но там были all-mn all-еще что-то, потом оказалось, что у меня не прописан PATH каталог /usr/local/sbin. Ввел export PATH=»все-все-все что было+:/usr/local/sbin», запустил как всегда dhclient eth0, но вместо привычных сообщений о dhcp-запросах он помолчал и ушел.

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

ubuntuAndrew »

ifconfig -a:
eth0 Link encap:Ethernet HWaddr 00:50:04:54:96:6C
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:10 Base address:0x6800

lo Link encap:Local Loopback
LOOPBACK MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Папки /etc/networks нет вообще, вот /etc/networks:

# networks This file describes a number of netname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
#

loopback 127.0.0.0

# End of networks.

route:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0

tracert: Команда не найдена.

Заодно, содержимое каталога /etc:
adjtime bitlbee/ conf.d/ cron.d/ cron.daily/ cron.hourly/ cron.monthly/
cron.weekly/ cups/ ddclient/ devfsd.conf dhcpc/ fdprm fonts/
fstab group gtk-2.0/ hostname hosts hosts.allow.new hosts.deny.new
hotplug/ hotplug.d/ inetd.conf inittab inputrc issue ld.so.cache
lilo.conf lilo.conf.bak login.defs logrotate.d/ lynx.cfg lynx.lss
makepkg.conf man.conf mime.types modules.conf modules.devfs motd mtab
nanorc networks pacman.conf pango/ passwd pcmcia/ ppp/ profile profile.old
protocols rc* rc.conf rc.conf~ rc.conf~~ rc.conf.old rc.conf.old~ rc.d/
rc.local* rc.modules* rc.multi* rc.multi~* rc.multi.abackup* rc.service*
rc.shutdown* rc.single* resolv.conf resolve.conf securetty services shadow
shadow- shells skel/ slsh.rc ssh/ ssl/ sysctl.conf syslog.conf txt TZ wgetrc
X11/ xml/ zhcon.conf

C’est tout. Voici tout les plumes de ma tante…

Да, еще подробности моей сети. Интернет->модем ADSL со встроенным роутером -> роутер -> компьютер. На роутере настроен Static DHCP для моего компа — 192.168.0.2, ip роутера — 192.168.0.1, маска подсети — 255.255.255.0.

Аватара пользователя

Red User

Сообщения: 229
ОС: Debian

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

Red User »

ubuntuAndrew писал(а): ↑

11.05.2010 19:38

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0

Тебе надо добавить маршрут для адресов не из сети 192.168.0.0. После этого по крайней мере должны пинговаться гугловские dns:

Но вообще по-правильному это где-то должно настраиваться в дистрибутиво-специфичном месте, чтобы не вводить каждый раз команду.

А ведь когда-то не боялись мы программы любой,
И с одним лишь debug’ом выходили на бой,
И искусно написанный вирус встречали как брата

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

ubuntuAndrew »

Теперь роутер миновал, пинг взял все тестовые ip, которые я дал. Привел /etc/resolv.conf к следующему виду:
dyndns 216.146.35.35
dyndns2 216.146.36.36

Это dns сервера, необходимые для нормальной работы службы ddns (dyndns.com), но до сих пор dns адреса не резольвируются. Сейчас попробую выйти в Интернет через какой-нибудь публичный proxy-сервер.

Indarien

Сообщения: 436
ОС: Debian, Fedora, Ubuntu

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

Indarien »

ubuntuAndrew писал(а): ↑

11.05.2010 19:38

Папки /etc/networks нет вообще, вот /etc/networks:

Indarien писал(а): ↑

11.05.2010 12:51

и файл /etc/network/interfaces

Читайте внимательнее. Никаких нетворкс и йестердейзс.
/etc/network/interfaces
В ресолв.конф впишите ДНСки как сказали.
tracert — согласен нет, пардон, это из венды, traceroute нужен.
Шлюз по умолчанию. Вы сидите через модем, он у вас как, роутером стоит? Так поднимите на нем DHCP и пусть он вам сам раздает и ДНСки и шлюзы. Зачем терзать клиента?
покажите nslookup еще

А DHCP поднят, так настройте его просто. У меня у самого так было, когда-то чеез адсл, сча просто чеерз роутер, но не принципиально, все раздвалось с коробочки, просто подрубаешь тачку\ноут и все, ХП, 7ка, Убунта, Деб все ходило без бубна.

-=Правильно заданный вопрос содержит 50% ответа=-

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

ubuntuAndrew »

Так… если файл /etc/networks — yesterday, то пора подумывать о смене Линукса… Ладно помучаюсь еще…
Надо вписывать вручную ip адреса всех сайтов, которые мне могут пригодится?
Что касается dhcp: модем дает ip адрес роутеру (192.168.1.2), а роутер уже дает ip адреса всей сети, в. ч. и моему компьютеру.

Вообще-то мне этот компьютер нужен только как LAMP сервер с Drupal и DynDNS клиентом. А ему нужны именно его dns сервера, используемые для подключений. Да и где у Linux настроить выход именно на определенные dns-сервера?

Аватара пользователя

Red User

Сообщения: 229
ОС: Debian

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

Red User »

(ubuntuAndrew) писал(а):Надо вписывать вручную ip адреса всех сайтов, которые мне могут пригодится?

Думаю, не стоит.

(ubuntuAndrew) писал(а):Да и где у Linux настроить выход именно на определенные dns-сервера?

В /etc/resolv.conf

(ubuntuAndrew) писал(а):Сейчас попробую установить libc-2.11.

Зачем?

А ведь когда-то не боялись мы программы любой,
И с одним лишь debug’ом выходили на бой,
И искусно написанный вирус встречали как брата

ubuntuAndrew

Сообщения: 205
ОС: Linux Ubuntu 12.04
Контактная информация:

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

ubuntuAndrew »

Так… Судя по словам Мани, resolv.conf содержит ассоциации между доменными именами узлов и их ip адресами. То есть что бы получить доступ к сайту site.examle с ip 192.168.192.168, надо вбить в resolv.conf:

Код: Выделить всё

site.examle   192.168.192.168
another.site2.example   192.168.192.169

И только после этого можно будет получить доступ только к этим двум сайтам.
Но по словам Red User:

Да и где у Linux настроить выход именно на определенные dns-сервера?

В /etc/resolv.conf

То есть получается, туда можно вписать какой-нибудь dns-сервер (именно один dns сервер) и все будет работать. Тогда в каком же виде представлять nameserver?

А libc я решил переустановить, поскольку даже после того, как я вбил в /etc/resolv.conf след. строку:

, пинг unixforum не брал. Так как ping обращается для резольвирования к системной функции из libc, а она resolv.conf не читает, следовательно libc кривая.

watashiwa_daredeska

Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

watashiwa_daredeska »

ubuntuAndrew писал(а): ↑

12.05.2010 23:53

Так… Судя по словам Мани, resolv.conf содержит ассоциации между доменными именами узлов и их ip адресами.

Нет. Нет. Нет. Ещё раз, я не знаю, что Вы там читаете и как, но /etc/resolv.conf — НЕ /etc/hosts. В /etc/resolv.conf имеется ограниченное число директив: nameserver, search и др. Это директивы, а не «типографский» элемент оформления, который надо заменить на что-то ещё, вбивать надо буква в букву и никак иначе.

ubuntuAndrew писал(а): ↑

12.05.2010 23:53

А libc я решил переустановить, поскольку даже после того, как я вбил в /etc/resolv.conf след. строку:

, пинг unixforum не брал.

Это строка для… ну, почти для /etc/hosts, а не для /etc/resolv.conf. Чтобы unixforum.org ресолвился в адрес 89.104.102.12, можно прописать в /etc/hosts строку:

. Ещё раз: в /etc/hosts, а не в /etc/resolv.conf, примечание: именно эту строку, в /etc/hosts. В /etc/resolv.conf прописывается другое и по другому.

В /etc/hosts прописывается соответсвие имя->IP вместо DNS, а в /etc/resolv.conf прописываются адреса DNS.

Indarien

Сообщения: 436
ОС: Debian, Fedora, Ubuntu

Re: Решено: Не работает DNS — не преобразуются адреса в ip.

Сообщение

Indarien »

2 ubuntuAndrew
resolv.conf
Это НЕ файл где описываются хосты, там указываются ДНС сервера и только.
Вид должен быть таким
nameserver 8.8.8.8
nameserver IP адрес ДНС сервера

nameserver Это НЕ имя хоста, это синтаксис файла и писать надо именно nameserver пробел IP и никак иначе.

networks
У вас это файл?

-=Правильно заданный вопрос содержит 50% ответа=-

Понравилась статья? Поделить с друзьями:
  • Ошибка dns host not found ростелеком телевидение
  • Ошибка dns 80710104
  • Ошибка dns 5504
  • Ошибка dme бмв е39
  • Ошибка dme 2e97