Learning Action in publishing DNS part 10

Tham khảo tài liệu Learning Action in publishing DNS part_10, công nghệ thông tin, hệ điều hành phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Learning Action in publishing DNS part 10 Chapter 10It is improbable that the usual client would use a port other than port 53, since they would not beaware of the existence of ports 7053 and 8053.A DNS proxy is run on the firewall standard port 53 of the name server. The DNS proxy serveridentifies the source of queries. Based on their origins, the proxy either refuses them, or handsthem over to the name server on port 7053 or the name server on port 8053.If the queries come from: • An Internet client, then they are handed over to the Internet name server (port 7053 in the figure) • An intranet client, then there are two different cases. Firstly, any request for a translation from the company.com domain is handed over to the intranet name server (port 8053). Secondly, any request for a translation of a different Internet domain is left to the DNS proxy, which decides: If we want to translate the Internet on the intranet, then the request is o handed over to the Internet name server (port 7053). If we do not want to translate other Internet domains on the intranet, o then it gives a negative response. What is interesting about this is the fact that if we do not have other (for example, secondary) name servers, then we do not even need the intranet root name server. The negative response is issued directly by the DNS proxy. • An application running on the firewall (such as proxy), then if the request is for the company.com domain it is handed over to the intranet name server (port 8053) or if it concerns a different domain it is handed over to the Internet name server (port 5073).10.4 End RemarksIn this book, we learned about DNS principles, resolver configuration, and configuration ofvarious name servers. You must have realized that domain registration and delegation is altogetherquite easy. However, in spite of its comprehensibility, the DNS is often a source of problems toordinary computer users.The correct diagnosis of computer problems is similar to a correct medical diagnosis. In bothcases, it is important not only to reach the correct diagnosis, but also to do so in the minimumtime. We can suspect mistakes in a DNS configuration if a user complains either that his or hercomputer does not communicate at all or, more often, the communication seems to be slow fromtime to time even if the network infrastructure is fast.In such cases, if a user asks you for help, you should sit down in front of the users computer, run thecommand prompt (never mind if it is a UNIX or a Windows machine), and find out the following: 169DNS and Firewall 1. Find the IP addresses of an default gateway and a local DNS server (for example, the IP address of the DNS server of your Internet Service Provider). If the TCP/IP protocol stack is installed; the best method to do it is to type a ipconfig command (in Windows) or ifconfig (in UNIX). 2. By ping with IP address of default gateway command test connection to default gateway. If a default gateway is accessible, simply type the ping command along with the IP address of DNS server. If the default gateway or DNS server does not respond, we can see that it is not a DNS problem, but a problem of the network infrastructure. 3. If the DNS server is placed outside your local network, you should also verify the network connection quality with the help of the ping command, now with the parameter –t (in Windows only). Let the command work for a while, stop it, and look at its statistic. If more than 10% of packets are lost, then the problem is again in the network infrastructure. 4. Now you can focus on the DNS because the problem is probably there. Accomplishing this is very simple. Type the ping command, not with an IP address of the DNS server, but with its name. The response must be as fast as if you are using the IP address. If not, check the resolver configuration. 5. Now you can check if a DNS translation of the name of some remote server in Internet to its IP address is functional. Be aware of the fact that known Internet servers are usually configured not to respond to the ping command. You must use the tracert command (or traceroute in UNIX) instead.If you have passed all the previous steps successfully, verify if the response is faster when using theIP address compared to using a DNS name. If both responses are equally fast, then the problem isneither in the network infrastructure nor in DNS. The problem could not be on the client site, but onthe server (application) site (for example, the DNS configuration of the application server is wrong).You probably think that the previously described problems are too shallow for you, but you shouldrealize that the DNS problems can be found in different levels: • Ordinary users: Their computers either run or not, and they are usually ignorant about DNS. • Local administrators: They configure users computers and should understand the basic DNS principles. • Local name server administrators (local hostmasters): They must understand the DNS configuration and principles in detail. • ISP hostmasters: They must know about not only DNS configuration, but also communication with the Internet registries. • Internet Registry hos ...