{"id":306,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:25:59","modified_gmt":"2020-08-22T20:25:59","slug":"this-is-the-page-title-toplevel-141","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=306","title":{"rendered":"Configuring the Domain Name System DNS"},"content":{"rendered":"\nConfiguring the Domain Name System DNS<\/title>\n<p>\nIn the first part of this section, I discussed <glossary>DNS<\/glossary>\nas being a means of centrally administering\nthe file necessary for node name to IP-address translation. Although the relationship of the files\nis pretty straight-forward, they are rather intimidating to the uninitiated. (Myself\nincluded)\n<\/p>\n<question id=\"302\" text=\"What is the 'start-up' configuration file for the DNS server?\" \/>\n<p>\nSo, what do the <glossary>DNS<\/glossary>\nconfiguration files look like? Well, since the first file\nthat named looks at is \/etc\/named.conf, that seems like a good place to start. Let’s\nassume we wanted to set up a primary <glossary>name server<\/glossary>.\n We might have a file that looks like this:<\/p>\n<filecontents type=\"\">\n; Boot file for Primary Master Name Server\n;\n;\n; type domain source file or host\n;\ndirectory \/etc\/named.d\nprimary siemau.com siemau.forward\nprimary 147.142.199.in-addr.arpa siemau.rev\nprimary 0.0.127.in-addr.arpa named.local\ncache . root.cache\n<\/filecontents>\n<p>\nLines beginning with a\nsemi-colon are considered comments and blank lines are ignored. The first line with configuration\ninformation is:\n<\/p>\n<p>\n<filecontents type=\"\">directory \/etc\/named.d <\/filecontents>\n<\/p>\n<question id=\"310\" text=\"What does the 'directory' directive define in the \/etc\/named.conf file?\" \/>\n<question id=\"318\" text=\"To make management easier, DNS configuration can be split across multiple files.\" \/>\n<p>\nThis tells <em>named<\/em> that if no path is\nspecified, it should look for the other configuration files in the specified directory. In this\ncase, \/etc\/named.d. Since the named.boot file is read when named starts up, you could change it to\nanything you want.\n<\/p>\n<question id=\"311\" text=\"What DNS record indicates the domain for which the server is responsible?\" \/>\n<p>\nThe first primary line says that we are the primary <glossary>name server<\/glossary>\nfor the\ndomain siemau.com This says that the information to resolve forward requests are found in the file\nsiemau.forward. Okay, so what are forward requests. Well, “forward requests” is my term. I use it\nfor two reasons. First, the file containing the information, often ends with .forward. Second, I\nthink the primary function of a <glossary>name server<\/glossary>\nis to translate names to <glossary>IP<\/glossary>\naddresses. Therefore, this\nis going forward. Translating <glossary>IP<\/glossary>\naddresses to names is going in reverse.\n<\/p>\n<p>\nNote that you will\noften see that the forward mapping file is referred to as named.hosts or domain_name.host and the\nreverse mapping as named.rev or domain_name.rev. I like to call one .forward and one .rev so I know\nby looking at them what their function is. It doesn’t matter what you call them as long as there are\npointed to in named.boot.\n<\/p>\n<question id=\"305\" text=\"What is the term used for the server that has the 'final say' about DNS entries?\" \/>\n<p>\nIn order to be the primary server we must say that we are the primary. This is\naccomplished through the Start of Authority (SOA) record, which says we are the start of authority\nfor the given <glossary>domain<\/glossary>.\n That is, when trying to find the answer to a query, the buck stops here. We\nhave all the right answers when it comes to this <glossary>domain<\/glossary>.\n The <glossary>SOA<\/glossary>\nrecord is required and might look like this:<\/p>\n<p>\n<filecontents>\nsiemau.com. IN SOA siemau.siemau.com. jimmo.siemau.com. (\n 8675309 ; Serial\n 10800 ; Refresh\n 800 ; Retry\n 3600000 ; Expire\n 259200 ) ; Minimum\n<\/filecontents>\n<p>\nThe fields in the first line are: <glossary>domain<\/glossary>,\n data <glossary>class<\/glossary>,\n type of record, primary name\nserver, responsible individual. The data <glossary>class<\/glossary>\nwill always be IN for Internet. Often you will see\nroot or postmaster as the person responsible for this <glossary>domain<\/glossary>.\n Here, I picked myself. Note that the\nformat is jimmo.siemau.com and not jimmo@siemau.com as one might expect.\n<\/p>\n<p>\nThe Serial number is\na way for secondary servers to keep track of the validity of their information. If the secondary has\na serial number that is lower than the serial number on the primary, it knows that the information\nis outdated. It will then pull over an updated copy.\n<\/p>\n<question id=\"312\" text=\"Which DNS entry tells a secondary server how often it should check for updated data?\" \/>\n<p>\nThe Refresh is how often (in seconds) the secondary\nservers should check the primary for updated information. In every implementation I have ever seen,\nthis value is set to 10800 seconds, or three hours. You can change it if your site requires it.\n<\/p>\n<p>\nThe Retry is how often (in seconds) the secondary server should retry to contact the primary.\nThis value of 3600 seconds (one hour) is also something I have seen in almost every case. Again,\nchange it as you need it.\n<\/p>\n<p>\nThe Expire time is how long the secondary will try before it gives\nup and declares the data it has as invalid. This is based on the attitude that no data is better\nthan old data. Here we have 1000 hours or almost 42 days.\n<\/p>\n<p>\nThe Minimum is the value that other\nresource records should use as their time-to-live, if no other value is defined for them. The\ntime-to-live is how long a given piece of information is considered valid.\n<\/p>\n<p>\nAt the end of each\nof these records you see a semi-colon. This is used in <glossary>DNS<\/glossary>\ndatabase files as the start of a comment.\nAny text\nfrom the semi-colon to the end of the line is considered part of the comment. You will also\nsee that many lines have semi-colons as their first character. In these cases, the whole line is a\ncomment.\n<\/p>\n<p>\nNote also there is a dot after each .com entry. This indicates the end of the name.\nRemember I mentioned that the trailing dot indicates the root domain? In these cases here, this dot\nis required. If you leave it off, the system will assume that it should tack on the <glossary>domain<\/glossary>\nname onto\nthe end. Therefore, you might end up with the <glossary>domain<\/glossary>\nname twice. This behavior can actually come in\nhandy and we’ll get to it shortly.\n<\/p>\n<p>\nThe <glossary>SOA<\/glossary> record is just one resource record that you find\nin <glossary>DNS<\/glossary>\ndatabase files. There are several others that we will get through during the course of this\ndiscussion. Resource records have general format:\n<\/p>\n<p>\n<screenoutput>name {ttl} data-class record-type record-specific-data <\/screenoutput>\n<\/p>\n<p>\nThe name is simply something we are looking for. For example, we might\nhave a machine name and we are looking for the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>.\n We have the machine name, this is our\nvalue. On the far right is the record-specific-data or the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>.\n The TTL value is the\ntime-to-live. This is an optional value since we already defined a minimum in the <glossary>SOA<\/glossary>\nrecord. We\ncould have also defined a ttl value for this <glossary>SOA<\/glossary>\nrecord, if we had wanted. The data-class can be one\nof several values. However, only the IN for Internet <glossary>class<\/glossary>\nis commonly used, therefore that is the\nonly one we’ll use here. The record-type tells us what kind of resource record we have. For example,\nSOA is one record type.\n<\/p>\n<question id=\"313\" text=\"What DNS record type defines the name server for a specific domain?\" \/>\n<p>\nAfter the <glossary>SOA<\/glossary> record there is usually an entry saying which machines\nare name servers, such as:\n<\/p>\n<p>\n<screenoutput>siemau.com. IN NS siemau.siemau.com.<\/screenoutput>\n<\/p>\n<p>\nThe value we\nhave is siemau.com. For this record type, this value is the <glossary>domain<\/glossary>\nname. The domain is the same\nfor the <glossary>SOA<\/glossary>\nrecord, as we are defining this machine to be the <glossary>name server<\/glossary>\nas well. The data-class,\nagain, is IN for Internet. Since we are defining which machine is the <glossary>name server<\/glossary>, the record type\nis NS, for <glossary>name server<\/glossary>.\n Lastly, we get the <glossary>FQDN<\/glossary>\nof the machine (<em>siemau.siemau.com.<\/em>).<em>\n<\/em>Note that in both cases we had the dot at the end of each name.\n<\/p>\n<p>\nOne thing that I should point out here is that a good choice for which machine is the <glossary>name server<\/glossary> is one that is on multiple\nnetworks, that is one that serves as <glossary>gateway<\/glossary>.\n This is a good choice since it already has to know\nabout multiple networks to be the <glossary>gateway<\/glossary>.\n It is said to be <em>well connected<\/em>. This saves\nmanaging one machine as the <glossary>gateway<\/glossary>\nand the other as the <glossary>name server<\/glossary>.\n<\/p>\n<p>\nNext, we have the name to <glossary>address<\/glossary>\nmappings. Let’s assume for simplicity’s sake that I only have two other machines in my\nnetwork. The entries for all my machines might look like this:\n<\/p>\n<p>\n<filecontents>\nsiemau.linux-tutorial.info. IN A 192.168.42.1\nvesta.linux-tutorial.info. IN A 192.168.42.2\njmohr.linux-tutorial.info. IN A 192.168.42.3\n<\/filecontents>\n<p>\nThe general format is:\n<\/p>\n<p>\nmachine-name data-type record-type IP-address\n<\/p>\n<question id=\"314\" text=\"What DNS record type defines the IP address for a specific machine?\" \/>\n<p>\nNote that despite the fact that siemau is our <glossary>name server<\/glossary>,\n we still need to include it here. Otherwise there would be no way to\ntranslate it’s name to an <glossary>address<\/glossary>.\n The new piece of information here is the A record-type. This\nsimply says that this specific record is making the translation from machine name to IP-address.\nEach entry is referred to as an <glossary>address<\/glossary>\nrecord, or address resource record. Note again the trailing\ndot (.).\n<\/p>\n<p>\nWe also need a mapping for the node “localhost”. This is a special name for the\nlocal machine and is accessed using a special driver called the “loopback driver”. Rather than\naccessing the card, the loopback driver knows that this is the local machine and does not need to go\nout to the <glossary>network<\/glossary>\ncard. Certain function on the system take advantage of the capabilities of this\ndriver.\n<\/p>\n<p>\n<screenoutput>localhost IN A 127.0.0.1<\/screenoutput>\n<\/p>\n<p>\nOne thing I need to point out is the\ndot (.) at the end of each <glossary>FQDN<\/glossary>.\n This says that the name stops here. Remember that the dot is use to\nindicate the root <glossary>domain<\/glossary>.\n By putting the dot here, this says that we have reached the root domain, so\nwe won’t go any further.\n<\/p>\n<p>\nLeaving the dot off can be a mistake or intention. In these examples\nit would be a mistake. In fact, in the time I was doing tech support, leaving off the dot was\n(perhaps) the most common mistake made when configuring the <glossary>name server<\/glossary>.\n However, we can leave it\noff intentionally in certain circumstance and have it be correct. We can use abbreviations (shorten\nforms) to indicate the machine name. For example, we could have written the first entry like this:\n<\/p>\n<p>\n<screenoutput>siemau IN A 192.168.42.1 <\/screenoutput>\n<\/p>\n<p>\nBecause we already defined what the <glossary>domain<\/glossary>\nname\nis in the named.boot file, the system knows what to append. Therefore, we can try to contact either\nsiemau or siemau.linux-tutorial.info and the <glossary>name server<\/glossary>\nwill translate that correctly to 192.168.42.1.\n<\/p>\n<p>\nWe now need to make the translations from <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nto name. As I mentioned before, there\nare “reverse” translations. The data for these translations is in the file siemau.rev as indicated\nby the line from named.boot:\n<\/p>\n<p>\n<screenoutput>primary 42.168.192.in-addr.arpa siemau.rev <\/screenoutput>\n<\/p>\n<p>\nIn\ngeneral, the format of the entry is similar to that of the forward entries. For our three examples\nthey would look like this:\n<\/p>\n<p>\n<filecontents>\n1.42.168.192.in-addr.arpa. IN PTR siemau.linux-tutorial.info.\n2.42.168.192.in-addr.arpa. IN PTR vesta.linux-tutorial.info.\n3.42.168.192.in-addr.arpa. IN PTR jmohr.linux-tutorial.info.\n<\/filecontents>\n<\/p>\n<question id=\"315\" text=\"What DNS record type defines the name of the machine for a specific IP address?\" \/>\n<p>\nThere are a couple of\nnew things here. First, is the record type. Here we have PTR for pointer records. These point to the\nmachine name. The next is the “in-addr.arpa” after the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>. To understand we need to take a step back.\n<\/p>\n<question id=\"320\" text=\"Using the first octet of the IP address, DNS determines to top-level domain a host belongs (e.g. .com, .edu)\" \/>\n<p>\nAssume we wanted to make the translation from machine name to <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nand we\nhad no idea where that machine was. As I mentioned there are name servers for all of the top-level\ndomains that are aware of the name servers for all of the domains under it. For the .com <glossary>domain<\/glossary>,\n one\nsuch machine is kava.nisc.sri.com. So, if we had wanted to find the machine vesta.linux-tutorial.info, we\ncould ask the <glossary>name server<\/glossary>\nthat was responsible for the .com <glossary>domain<\/glossary>\n(<i>kava.nisc.sri.com<\/i>). Since\nkava knows about the siemau <glossary>domain<\/glossary>,\n and knows that siemau.linux-tutorial.info is the <glossary>name server<\/glossary>\nfor that\ndomain it tells you to go ask siemau yourself.\n<\/p>\n<p>\nNow, let’s go the other way. Question: is the domain with the first octet of the <glossary>IP<\/glossary>\n<glossary>address<\/glossary> 199 a .com, .edu or .gov domain? How can you tell? The\nanswer is that there is no way to tell. <glossary>IP<\/glossary>\naddresses are not arrange by the type of organization. We\ncan guess that the <glossary>network<\/glossary>\n199 is probably a <glossary>class<\/glossary>\nC network (since it is over 192), but it can just\nas easily be .com a .edu or anything else. So rather than trying to find the <glossary>name server<\/glossary>\nfor every\nsingle <glossary>domain<\/glossary>\nand asking “Are you the right one?”, a quicker way had to be developed.\n<\/p>\n<p>\nThe\nsolution was to create a portion of the Internet name space that used the addresses as a name. This\nportion is considered a separate <glossary>domain<\/glossary>\nand is referred to as the in-addr.arpa domain. The names of\nboth machines and sub-domains within the in-addr.arpa <glossary>domain<\/glossary>\nare simply the <glossary>IP<\/glossary>\naddresses. There are\n256 sub-domains of the in-addr.arpa <glossary>domain<\/glossary>,\n 256 sub-domains of each of those domains and so on.\n<\/p>\n<p>\nIf you look, the “names” listed in the in-addr.arpa <glossary>domain<\/glossary>\nhave the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nreversed from\nthe way we are accustomed to seeing it. This is keeping with the idea that in the names, the more\nspecific names are on the left and get more general as you move to the right. It also makes things\neasier to managed since we can say that the 42.168.192.in-addr.arpa <glossary>domain<\/glossary>\nis administered by one\norganization. (This is because 192.168.42 is a separate Class C network).\n<\/p>\n <question id=\"319\" text=\"What could be wrong with this reverse DNS entry?<br \/>1.42.168.192.in-addr.arpa IN PTR siemau.linux-tutorial.info” \/>\n<p>\nNote also that\nthere is a dot at the end of the reverse <glossary>address<\/glossary>.\n Here, too, this tells the <glossary>name server<\/glossary>\nwhere the\nend is. Since we already said what the in-addr.arpa <glossary>domain<\/glossary>\nwas in the named.boot file. We can make\na short cut by listing only the <glossary>host<\/glossary>\nportion, just like we did with the <glossary>FQDN<\/glossary>.\n The entry for siemau\nwould then look like this:\n<\/p>\n<p>\n<filecontents type=\"\">1 IN PTR siemau.linux-tutorial.info.<\/filecontents>\n<\/p>\n<p>\nNote that here we\nhave the dot a the end of the <glossary>FQDN<\/glossary>,\n but it wasn’t at the end of the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nin the address (A)\nrecord. This is because the dot comes at the end of a <glossary>domain<\/glossary>\nname. In in-addr.arpa notation, the IP\naddress is part of a name, it just happens to look like an <glossary>IP<\/glossary>\n<glossary>address<\/glossary>,\n albeit a reversed one. Think\nof it this way, a period comes at the end of a sentence, which is a bunch of words. If you have a\nset of numbers, there is no period.\n<\/p>\n<p>\nIf we had a <glossary>class<\/glossary>\nB <glossary>network<\/glossary>,\n we could also make use of\nthese abbreviations. For example, if siemau had an <glossary>address<\/glossary>\nof 159.144.147.1, it’s pointer (PTR) record could have been written like this:\n<\/p>\n<question id=\"316\" text=\"Pointer (PTR) DNS records must always contain the complete IP address.\" \/>\n<p>\n<filecontents>1.147 IN PTR siemau.linux-tutorial.info.<\/filecontents>\n<\/p>\n<p>\nThis reminds me of the second most common error I say in support and that is using the\nabbreviations for the reverse <glossary>address<\/glossary>,\n but not reversing them! That is, in this example above, writing it as:\n<\/p>\n<question id=\"321\" text=\"What could be wrong with this reverse DNS entry?<br \/>1.147 IN PTR siemau.linux-tutorial.info.” \/>\n<p>\n<filecontents type=\"\">147.1 IN PTR siemau.linux-tutorial.info.<\/filecontents>\n<\/p>\n<p>\nDon’t do that! A reverse domain has the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nportion of the name reversed as well. No matter what part you include.\n<\/p>\n<question id=\"317\" text=\"What is the top-level of the reverse domain?\" \/>\n<p>\nBy writing the IP-Address reversed like this, we are essentially creating a new <glossary>domain<\/glossary>. The\nroot <glossary>domain<\/glossary>,\n is still dot (.). However, this time there is just the single top-level domain\nin-addr.arpa. This notation is often referred to as the <em>reverse domain<\/em>. Because we are\ndefining a new <glossary>domain<\/glossary>\nin the siemau.rev file, we need a new Start of Authority record. We could copy\nthe <glossary>SOA<\/glossary>\nrecord from the siemau.forward file, however the <glossary>domain<\/glossary>\nis wrong. The domain is now\n147.144.199.in-addr.arpa. So, all we need to do is replace the old <glossary>domain<\/glossary>\nname with the new one and\nthe entry would be identical. The first line would then look like this:\n<\/p>\n<p>\n<filecontents>147.144.199.in-addr.arpa. IN SOA siemau.linux-tutorial.info jimmo.linux-tutorial.info <\/filecontents>\n<\/p>\n<p>\nWe can now\nduplicate the remainder of the <glossary>SOA<\/glossary>\nrecord from the siemau.rev file. One thing I do to help keep\nthings straight is to think of the NS record as part of the <glossary>SOA<\/glossary>\nrecord. In “reality”, they separate\nrecords. However, if you think of them together, you won’t forget and leave off the NS record. Since\nwe are defining a new <glossary>domain<\/glossary>,\n we also need the NS record for this new domain. It’s NS record would\nlook like this:\n<\/p>\n<p>\n<filecontents>147.144.199.in-addr.arpa. IN NS siemau.linux-tutorial.info. <\/filecontents>\n<\/p>\n<p>\nHowever, I\ndon’t like the idea of two <glossary>SOA<\/glossary>\nrecords. There is the chance that I update the database files, but\nforget to update one of the <glossary>SOA<\/glossary>\nrecord with the new serial number. To eliminate that problem, there\nis a directive that you can give the <glossary>name server<\/glossary>\nto include another file while it’s reading the\ninformation. This is the $INCLUDE directive. To include a single <glossary>SOA<\/glossary>\nrecord, we create a file,\nperhaps siemau.soa and use the $INCLUDE directive in both the siemau.forward and siemau.rev files.\nThe line would look like this:\n<\/p>\n<p>\n<filecontents>$INCLUDE siemau.soa <\/filecontents>\n<\/p>\n<p>\nSince we already defined the\ndirectory in the named.boot file, there is no need for a path here. However, we have a problem. The\nSOA record in siemau.forward is for a different <glossary>domain<\/glossary>\n(siemau.dom) than in siemau.rev\n147.144.199.in-addr.arpa). We can take advantage of a magic character: @. This will be read as the\ndomain name, provided the <glossary>domain<\/glossary>\nname is same as the origin (The origin is the machine that this\ndata is on).\n<\/p>\n<p>\nLet’s create a single <glossary>SOA<\/glossary>\nfile (i.e. siemau.soa) and make it identical to other\nothers with the exception of the <glossary>domain<\/glossary>\nname. Instead we replace it with the “@.” Next we remove the\nSOA records from the siemau.forward and siemau.rev file and replace it with the $INCLUDE directive\nabove. When the <glossary>name server<\/glossary>\nreads the siemau.forward file, it gets to the $INCLUDE directive sees\nthat it needs to include the siemau.soa file. When it gets to the “@”, the system translates it as\nlinux-tutorial.info. Next, when the system reads the siemau.rev file, it sees the same directive, includes the\nsame file, however, this time the “@” is interpreted as “147.144.199.in-addr.arpa.\n<\/p>\n<p>\nThere are\nstill two lines in the named.boot file that we haven’t covered. The first sets up this servers as\nprimary for the “local” <glossary>domain<\/glossary>.\n This is a special domain that refers to this <glossary>host<\/glossary>\nonly. Remember\nfrom our discussion of <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nthat the <glossary>IP address<\/glossary>\nfor the local <glossary>host<\/glossary>\nis 127.0.0.1. The “network”\nthat this <glossary>host<\/glossary>\nis on is 127.0.0. We always need to be the primary <glossary>name server<\/glossary>\nfor this <glossary>domain<\/glossary>,\n there\nwe have the line in our named.boot:\n<\/p>\n<p>\n<filecontents>primary 0.0.127.in-addr.arpa named.local<\/filecontents>\n<\/p>\n<p>\nThe named.local file could contain just two lines:\n<\/p>\n<p>\n<filecontents>$INCLUDE named.soa 1 IN PTR localhost<\/filecontents>\n<\/p>\n <p>\nNote that here, too, we are including the named.soa file. When the system\nreads named.local, it includes named.soa and the “@” is translated to 0.0.127.in-addr.arpa as it\nshould.\n<\/p>\n<p>\nThe last line tells us to read the <glossary>cache<\/glossary> file:\n<\/p>\n<p>\n<filecontents>cache . root.cache <\/filecontents>\n<\/p>\n<p>\nThe root.cache file is the list of the root <glossary>domain<\/glossary>\nname serves. You can obtained\nthe most current list root name servers using anonymous <glossary>ftp<\/glossary>\nfrom the <i>machine\nftp.rs.internic.net<\/i>. The file is domain\/named.root.\n<\/p>\n<p>\nLet’s assume we want vesta to be the\nsecondary <glossary>name server<\/glossary>\nfor this <glossary>domain<\/glossary>.\n We would then create a named.boot file on vesta, that might\nlook like this:\n<\/p>\n<p>\n<filecontents>\ndirectory \/etc\/named.d\nsecondary linux-tutorial.info 192.168.42.1 siemau.forward\nsecondary 42.168.192.in-addr.arpa 192.168.42.1 siemau.rev\nprimary 0.0.127.in-addr.arpa named.local\ncache . root.cache\n<\/filecontents>\n<p>\nIf we look carefully, we see that the only difference is the that for the forward and reverse\nfiles, we change “primary” to secondary. Note that that vesta is still the primary for the domain\n0.0.127.in-addr.arpa (the local domain). The contents of the files are theoretically the same. This\nis where the concept of the serial number comes in. When the secondary loads it’s file it compares\nthe serial number to what it reads from the primary. Note also that the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>,\n 192.168.42.1,\nthe <glossary>address<\/glossary>\nof the <em>primary<\/em> server. In our case this is the machine siemau.\n<\/p>\n<p>\nIf we want a caching only server, the named.boot file is a little simpler:\n<\/p>\n<p>\n<filecontents>\ndirectory \/etc\/named.d\nprimary 0.0.127.in-addr.arpa named.local\ncache . root.cache\n<\/filecontents>\n<p>\nWe still specify the directory and the\nroot.cache file. However, we are now the primary for just a single machine, ourselves.\n<\/p>\n<p>\nIn\nany of the example named.boot files we could have include a line that simply said:\n<\/p>\n<p>\n<filecontents>slave<\/filecontents>\n<\/p>\n<p>\nThat would be a <glossary>name server<\/glossary>, regardless of what of type, that forwards\nall requests that it cannot satisfy to a list of predetermined forwarders. If this sever does not\nhave the answer, it will not interact with any other server, except for those listed as forwarders.\nTherefore, any time you have a slave server, you must also have a list of forwarders. The entry for\nthe forwarders might look like this:\n<\/p>\n<p>\n<filecontents>forwarders 199.145.146.1 199.145.148.1 <\/filecontents>\n<\/p>\n<p>\nThe last kind of server I called a <glossary>client<\/glossary>.\n It’s configuration is the simplest. You need to create a file called\n\/etc\/resolv.conf and include a line defining the <glossary>domain<\/glossary>\nand then a list of the name servers or\n<em>resolvers<\/em> as they resolve your queries. If we had siemau as the primary for this <glossary>domain<\/glossary>\nand vest the secondary, our file might look like this:\n<\/p>\n<p>\n<filecontents>\ndomain linux-tutorial.info\nnameserver 192.168.42.1\nnameserver 192.168.42.2\n<\/filecontents>\n<p>\nNote that if this file doesn’t exits, your\nsystem will expect to get it’s information from the \/etc\/hosts file. Therefore, you can say that on\nthe <glossary>client<\/glossary>\nside that if \/etc\/resolv.conf doesn’t exist, you are not using <glossary>DNS<\/glossary>.\n<\/p>\n <p>\nIf you have a\nlarger <glossary>network<\/glossary>\nwith many different departments, you might have already decided to have multiple name\nservers. As I mentioned, it is a good idea to have your name servers also be the <glossary>gateway<\/glossary>\nas they are\n“well connected.” This also applies to the <glossary>gateway<\/glossary>\nyou have to the Internet. To make life simpler\nfor both you trying to reach the outside world and the people trying to get in, it is a good idea\nto have the Internet <glossary>gateway<\/glossary>\nalso the primary <glossary>name server<\/glossary>\nfor your entire <glossary>domain<\/glossary>.\n<\/p>\n<p>\nIf your\norganization is large, then having the Internet <glossary>gateway<\/glossary>\na <glossary>name server<\/glossary>\nfor your entire organization\nwould be difficult to manage. Since you already decided to break your <glossary>network<\/glossary>\ndown by department,\nthen each department should have its own <glossary>name server<\/glossary>.\n One thing you could do is set up the domain\nname server as a secondary for the sub-domains. This is easy to set up (as we described above) and\nsaves you from having to maintain a list of every machine within your organization.\n<\/p>\n <question id=\"327\" text=\"What DNS record is used to define an 'alias' for a particular computer?\" >\n<p>\nThere are\nstill several record types that I haven’t mentioned. One of them is machine aliasing. For example,\nyou might have a machine that acts as your <glossary>ftp<\/glossary>\nserver, your mail server and your World Wide Web\nserver. Rather that requiring everyone accessing this machine to know that vesta.linux-tutorial.info is the\nserver for all three of these functions, you can create an <glossary>alias<\/glossary>\nto make things easier. This is done\nby the CNAME (canonical name) record. Example entries would look like this:\n<\/p>\n<p>\n<filecontents>\nftp IN CNAME vesta\nmailserv IN CNAME vesta\nwww IN CNAME vesta\n<\/filecontents>\n<p>\nAny reference to these three machines is translated\nto mean the machine vesta. Keep in mind that if you use such an <glossary>alias<\/glossary>,\n this should be the only\nreference in you <glossary>name server<\/glossary>\ndatabase. You should not have PTR record that point from an <glossary>IP<\/glossary>\naddress\nto one of these aliases, instead use it’s canonical (real) name, vesta.\n<\/p>\n<p>\nWe can also use the\nname server database to store information about the machine itself. This is done through the HINFO\n(host information) resource record. We could have the entry for our machine, siemau, that looks like\nthis:\n<\/p>\n<p>\n<filecontents>\nsiemau IN A 192.168.42.1\n IN HINFO Pentium Linux\n<\/filecontents>\n<\/p>\n<p>\nThe\nrecord specific data on the right is composed of two strings. The first is the Hardware and the\nsecond is the Operating System. The strings may contain spaces or tabs, but you need to include them\nwithin quotes or the system will seem them as separate strings. “Technically” these two strings\nshould be “machine name” and “system name” and match one of the strings in <glossary>RFC<\/glossary>\n1340, but this\nrequirement is not enforced. There is also the problem that man newer machines won’t be on the list.\n<\/p>\n<p>\nOne thing that seems to be missing is the machine name from the HINFO record. Well, this is\nanother short cut. By leaving the name field out of any record, it defaults to the same value as the\nprevious entry. Here, the previous entry is the A record for siemau. Therefore, the name field of\nthe HINFO record is also siemau.\n<\/p>\n<p>\nWe can also use the <glossary>name server<\/glossary>\nto manage certain aspects of\nour users. For example, you can have mail systems (such as MMDF) read the <glossary>name server<\/glossary>\ninformation to\ndetermine what machine a particular user gets his or her mail on. This is done with the MB (mailbox)\nresource record. An example, might look like this:\n<\/p>\n<p>\n<filecontents>jimmo IN MB siemau.linux-tutorial.info. <\/filecontents>\n<\/p>\n<question id=\"325\" text=\"What DNS records tell which server to send email to for a particular user?\" \/>\n<p>\nIn this <glossary>domain<\/glossary>,\n mail for the user\njimmo should be sent to the machine siemau.linux-tutorial.info. Note that this only works if you have unique\nusers within the <glossary>domain<\/glossary>.\n In addition, there must only be one MB record for each user.\n<\/p>\n <question id=\"324\" text=\"What DNS records tell which server to send email to for a particular domain?\" \/>\n<p>\nYou can\nmake things easier by specifying a single machine as the mail server. This is done with a MX (mail\nexchanger) resource record. The MX record can also be expanded to include sub-domains. For example,\nthe <glossary>name server<\/glossary>\nfor the linux-tutorial.info <glossary>domain<\/glossary>\nhas MX records for all the sub-domains under it. The\nresource specific information contains the presence, which is a numerical value used to determined\nthe order in which mail is sent to different machines. The preference should be 0 unless you have\nmultiple mail servers within the <glossary>domain<\/glossary>.\n<\/p>\n<p>\nLets assume that this is a large company and we have\ngiven each department its own <glossary>domain<\/glossary>\n(regardless if they have different <glossary>IP<\/glossary>\nsub-nets). We then decide\nthat mail sent to any one in a <glossary>subdomain<\/glossary>\ngoes to the mail-server for that sub-domain, but any mail\nto the parent <glossary>domain<\/glossary>,\ngoes to a different server. Some entries might look like this:\n<\/p>\n<p>\n<filecontents>\nlinux-tutorial.info. IN MX 0 siemau.linux-tutorial.info.\nfinance.linux-tutorial.info. IN MX 0 cash.finance.linux-tutorial.info.\nsales.linux-tutorial.info. IN MX 0 buyer.sales.linux-tutorial.info.\n IN MX 1 cash.finance.linux-tutorial.info.\nmarket.linux-tutorial.info. IN MX 0 editdmon.market.linux-tutorial.info.\nimages.market.linux-tutorial.info. IN MX 0 images.market.linux-tutorial.info.\n<\/filecontents>\n<p>\nIn this example, mail sent just to\na user in the <glossary>domain<\/glossary>\nlinux-tutorial.info will go to siemau.linux-tutorial.info. Mail sent to either of the other three\ndomains(<i>finance, sales, <\/i>and <i>market<\/i>) will be send to a machine in that respective\ndomain. Note that there are two MX records listed for the <i>sales.linux-tutorial.info<\/i> <glossary>domain<\/glossary>.\n One has a\npreference of 0 and the other a preference of 1. Since the preference for\n<i>buyer.sales.linux-tutorial.info<\/i> (0) is lower than for <i>cash.finance.linux-tutorial.info<\/i> (1), the mail\nprogram will first try buyer. If buyer can’t be reached it will try cash. Keep in mind that the\nnumbers have only mean what order to check. We could have given one a preference of 45 and the other\na preference of 66 and they would still have been checked in the same order.\n<\/p>\n<p>\nLet’s assume\nthat we feel mail to the sales department is so important that we want it to try still another\nmachine before it gives up. We could have a third MX record for sales.linux-tutorial.info that looks like\nthis:\n<\/p>\n<p>\n<filecontents> IN MX 2 siemau.linux-tutorial.info. <\/filecontents>\n<\/p>\n<p>\nIn this case, buyer will be\nchecked and if the mail message cannot be delivered, cash is checked. If cash cannot be reached,\n<i>siemau<\/i> is checked. If we changed the preference of siemau to 1, like the preference for\n<i>cash<\/i>, one of them will be chosen at random. This can be used if you want to spread the load\nacross multiple machines.\n<\/p>\n<p>\nThere are a few other resource records types that we haven’t\ndiscussed. There are not a commonly used as the others, so we will have to forgo talking about them.\nIf you would like to learn more, check the book <i>DNS and BIND<\/i> by Paul Albitz and\nCricket Liu from O’Reilly and Associates.\n<\/p>\n<p>\nAs I mentioned earlier, you can use the $INCLUDE\ndirective to include a file containing the <glossary>SOA<\/glossary>\nrecord. However, you can use the $INCLUDE directive\nto include any file. This is very useful if you files have grown to unmanageable sizes and you need\nto break them apart. Assume your <glossary>network<\/glossary>\ncontains 200 machines. There are A, PTR and possibly MX\nrecords for each machine. You could created three separate files for each of these. ( Normally, A\nand PTR are in separate files already.) You could then use the $INCLUDE directive to include the MX\nrecords in one of the other files.\n<\/p> The Name Server <\/p>\n<p>\nSorry, you’re going to\nhave to do it. Unless you are a flawless typist and have every step written down exactly, one day\nyou are going to forget something. As a result, the <glossary>name server<\/glossary>\nwon’t function the way you expect.\nHopefully, it’s something simple (like forgetting a dot) and you can quickly make the change.\n<\/p>\n<p>\nThe problem is what to do after you’ve made the change. Remember, named reads the\nconfiguration information when it starts. To get named to re-read the configuration file, you could\nstop and restart <glossary>TCP<\/glossary>.\n However, this would not be taken too kindly by the users who have their\nconnection suddenly drop. The solution is to poke named in the ribs and tell it go re-read the\nfiles. This is done by sending the named process a hang-up <glossary>signal<\/glossary>\nwith “kill -1 <pid>”, where\n<pid> is the <glossary>PID<\/glossary>\nof named. To find the PID, either grep through ps -e or look in\n\/etc\/named.pid. This also has the side effect of having secondary name servers check the serial\nnumbers, which can be used to force updates.\n<\/p>\n<p>\nIf you want to have named dump its current\ndatabase and <glossary>cache<\/glossary>\nyou can send named a <glossary>interrupt<\/glossary>\n<glossary>signal<\/glossary>\n(SIGINT, kill -2). This dumps the database\ninto <file type=\"\">\/usr\/tmp\/named_dump.db<\/file>. Sending named SIGUSR1 (kill -16) you can turn on debugging, the output\nwhich is sent to \/usr\/tmp\/named.run. Subsequent SIGUSR1 signals sent to named will increase the\ndebugging a level. Sending it SIGUSR2 (kill -17) turns off debugging completely.\n<\/p>\n<p>\nYou can\nalso get named to trace all incoming queries, which is sent to \/usr\/adm\/syslog. This is done by\nsending SIGWINCH (kill -20). Be careful with this, however. Even on smaller networks, the amount of\ninformation logged in syslog can be fairly substantial. If you forget to turn it of, you can fill up\nyour root file system. To turn of tracing, send SIGWINCH again. Note that all of theses options can\nbe enabled from the start-up script in <directory>\/etc\/rc2.d<\/directory>.\n<\/p>\n<question id=\"323\" text=\"What tool would you use to get information from a DNS server?\" \/>\n<question id=\"\" type=\"tf text=\"In the nslookup output, a line of asterisks indicats a problem with the name server or host resolution.\">\n<p>\nPerhaps the most useful debugging tools is\nnslookup (name server lookup). The nslookup command can be used either interactively or\nnon-interactively, to obtain information from different servers. Depending on how it’s set, you can\ninput an <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nand get a name back or input the name and get the <glossary>IP address<\/glossary>\nback. If you are\nusing the <glossary>name server<\/glossary>,\n either as a server or a <glossary>client<\/glossary>,\n nslookup can be used to gather information.\n<\/p>\n<p>\nTo start it interactively, simply type nslookup at the <glossary>command line<\/glossary>.\n You are then brought\ninto the nslookup “shell,” where you can issue commands and set the options needed to get the\ninformation you need. By using ‘set all’ you can view the current options. By default, nslookup\nwill return the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nof the input machine name (A forward query). For example, if we ran nslookup\non vesta, nslookup would respond with something like this:\n<\/p>\n<p>\n<screenoutput>\nDefault Server: siemau.linux-tutorial.info\nAddress: 192.168.42.1\n>\n<\/screenoutput>\n<p>\nThis tells us what the default server is and shows that it is ready for the first command by\ndisplaying the > prompt.\n<\/p>\n<p>\nLet’s say we wanted to see what information the <glossary>name server<\/glossary>\nwhen we run nslookup on siemau.\nWe type in jmohr and press return. This gives us:\n<\/p>\n<p>\n<screenoutput>\n> siemau\nServer: localhost\nAddress: 127.0.0.1\nName: siemau.linux-tutorial.info\nAddress:\n192.168.42.1\n<\/screenoutput>\nAs we can see this is what we expect. Note that in the first case, the default\nserver was siemau. However, when we run it on the <glossary>name server<\/glossary>\nitself, the server is\n“localhost.”<\/p>\n<p>\nOne question that comes to my mind is does it translate the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nback to\nthe <glossary>host<\/glossary>\nname correctly? Let’s see. When we type in the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>,\n we get:\n<\/p>\n<screenoutput>\n> 192.168.42.3\nServer: localhost\nAddress: 127.0.0.1\nName: vesta.linux-tutorial.info\nAddress: 192.168.42.3\n<\/screenoutput>\n<p>\nWe can list all the available information for a <glossary>domain<\/glossary>\nwith the ‘ls’ command. The general syntax is:<\/p>\n<p>\n<commandexample>ls [ option ] domain<\/commandexample>\n<\/p>\n<p>\nWhere <glossary>domain<\/glossary>\nis the name of the domain we would like the information about. If we want we can\nredirect the output to a file, we can use either type of output <glossary>redirection<\/glossary>\n(> or >>). If\nwe want to see it on the screen, we get:<\/p>\n<p>\n<screenoutput>\n> set all\nDefault Server: localhost\nAddress: 127.0.0.1\nSet options:\n nodebug defname search recurse\n nod2 novc noignoretc port=53\n querytype=A class=IN timeout=5 retry=2\n root=f.root-servers.net.\n domain=linux-tutorial.info\n srchlist=linux-tutorial.info\n<\/screenoutput>\n<p>\nIf I want to see everything there is about a\ndomain. I use the ls command. Keep in mind that by itself, the system will think it is a machine\nname and try to resolve it. However, followed by the <glossary>domain<\/glossary>\nname we get:<\/p>\n<p>\n<screenoutput>\n> ls\nlinux-tutorial.info\n[localhost]\n linux-tutorial.info. server = siemau.linux-tutorial.info\n siemau 192.168.42.1\n jmohr 192.168.42.2\n localhost 127.0.0.1\n vesta 192.168.42.3\n<\/screenoutput>\n<p>\nHowever, this does not tells us anything about the mail exchanger or canonical names that we may\nhave defined. To get everything, we us the -d option like this:<\/p>\n<p>\n<screenoutput>\n> ls -d linux-tutorial.info\n[localhost]\nlinux-tutorial.info. <glossary>SOA<\/glossary> siemau.linux-tutorial.info jimmo.linux-tutorial.info. (60001 1080 0 1800 3600000 86400)\n linux-tutorial.info. NS siemau.linux-tutorial.info\n linux-tutorial.info. MX 0 vesta.linux-tutorial.info\n jimmo MB siemau.linux-tutorial.info\n siemau A 192.168.42.1\n jmohr A 192.168.42.2\n siemau HINFO Pentium Linux\n localhost A 127.0.0.1\n www CNAME vesta.linux-tutorial.info\n mailserv CNAME vesta.linux-tutorial.info\n ftp CNAME vesta.linux-tutorial.info\n vesta A 192.168.42.3\n<\/screenoutput>\n<question id=\"326\" text=\"What DNS records tell information about that specific server?\" \/>\n<p>\nAs we can see, this gives us\neverything we can thing about including mail boxes, HINFO lines, canonical names, the <glossary>SOA<\/glossary>\nrecords\nand all of the <glossary>address<\/glossary>\nrecords. Note that there is only one MB record here. In reality, I probably\nwould have had MB records for all the users on this system. If this <glossary>network<\/glossary>\nhad been even a little\nlarger, then this output would probably be too much to view. Therefore you can use other options to\nlimit what you see. For example, the -t option is used to specify a type of query. If we wanted to\nlook for all the mail exchangers, we could use the command “ls -t MX linux-tutorial.info,” which\ngives us:<\/p>\n<p>\n<filecontents>linux-tutorial.info. 0 vesta.linux-tutorial.info<\/filecontents>\n<\/p>\n<p>\nWhich give us the <glossary>domain<\/glossary>,\nthe preference of the mail-exchanger and the name of the mail exchanger. Which is all the\ninformation in the MX record.\n<\/p>\n<p>\nWe can also tell nslookup that we want to look for particular\nkind of records. Say I want to look for the MX record for a particular machine. I could set the\nquery type to MX and look for that machine, like this:<\/p>\n<p>\n<screenoutput>\n> set type=MX\n> siemau.linux-tutorial.info\nServer: localhost\nAddress: 127.0.0.1\nsiemau.linux-tutorial.info preference = 0, mail exchanger = vesta.linux-tutorial.info\nsiemau.linux-tutorial.info internet address = 192.168.42.3\n<\/screenoutput>\n<p>\nOkay. This says that the mail exchanger for siemau is vesta. Are you sure? What\nnslookup is actually telling us is that <i>vesta.linux-tutorial.info<\/i> is the mail-exchanger for\n<i>siemau.linux-tutorial.info<\/i>. Why? Because we didn’t put the dot at the end of the <glossary>domain<\/glossary>\nname. Like\nother aspects of the <glossary>name server<\/glossary>,\n nslookup tacked the <glossary>domain<\/glossary>\nname onto the end of\n<i>siemau.linux-tutorial.info <\/i>to give us <i>siemau.linux-tutorial.info<\/i>. If I just use a machine name, the domain\nname is tacked on as well, but it comes out differently:<\/p>\n<p>\n<screenoutput>\n> siemau\nServer:\nlocalhost\nAddress: 127.0.0.1\nsiemau.linux-tutorial.info preference = 0, mail exchanger = siemau.linux-tutorial.info\nsiemau.linux-tutorial.info internet address = 192.168.42.1\n<\/screenoutput>\n<p>\nThe nslookup program\nalso has a configuration file that can come in handy. This is the .nslookuprc file in your home\ndirectory. Like the .exrc file for vi, the .nslookuprc is read every time you start nslookup. The\nformat is also like .exrc, with one entry per line. Assuming I wanted to set the query time to PTR\nrecords and set the time out to 5 seconds, I could have these two lines in my .nslookuprc file, like\nthis:<\/p>\n<p>\n<commandexample command=\"nslookup\">set querytype=ptr<\/commandexample>\n<\/p>\n<p>\n<commandexample command=\"nslookup\">set timeout=5<\/commandexample>\n<\/p>\n<p>\nThis would be the same as starting nslookup\nfrom the <glossary>command line<\/glossary>\nlike this:<\/p>\n<p>\n<commandexample command=\"nslookup\">nslookup -query=ptr -timeout=5<\/commandexample>\n<\/p>\n<p>\nSetting parameters is\nnot the only thing that you can do from the <glossary>command line<\/glossary>.\n In fact, most anything you can do from\ninside of nslookup, you can do from the command. I could expand the above command to give\nme:<\/p>\n<screenoutput>nslookup -query=ptr -timeout=5 192.168.42.3\nServer: localhost\nAddress:\n127.0.0.1\nName: vesta.linux-tutorial.info\nAddress: 192.168.42.3\n<\/screenoutput>\n<p>\nSo what is this all good\nfor? The most important thing is tracking down problems you might be experiencing. For example, if a\nparticular machine cannot reached, nslookup might show you that there is no A record for that\nmachine. Perhaps mail to a particular machine never ends up where it should. Checking the MX record\nfor that machine indicates it ends up going to a completely different machine than you though.\n<\/p>\n<p>\nUnfortunately, I cannot list every problem that could arise and what nslookup would show.\nHowever, with the understanding of how <glossary>DNS<\/glossary>\nand nslookup work that you’ve gained in the last couple\nof sections, the best way to proceed is to look at what nslookup is telling you. Based on the way\nyou think <glossary>DNS<\/glossary>\nis configured, is what nslookup records correct? This may sound like an over\nsimplification. However, isn’t that what problem solving really is? Knowing what should happen and\nwhat would cause it to happen differently?\n<\/p>\n<p class=\"subtitle\">Your Own <glossary>IP<\/glossary> Address<\/p>\n<p>\nIf you have a\nnetwork that is completely disconnected from the rest of the world, then there is no need for you to\nadhere to any of these conventions. You might be a commercial organization, but still want to use\nthe EDU <glossary>domain<\/glossary>.\n Nothing prevents you. There is also nothing preventing you from using <glossary>IP<\/glossary>\naddresses\nthat are used by some other organization. However, once you decide to connect to another\norganization or the Internet at large, you need to ensure that both your names and <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nare unique.\n<\/p>\n<p>\nIf you would like to have one machine that\nconnects to the internet, but have other machines that cannot. One solution is to use one of the IP\naddress defined in <glossary>RFC<\/glossary>\n1918. This RFC describes the need for “private” <glossary>address<\/glossary>\nand lists a range of\nclass A, B and C addresses that can be used internally within a company.\n<\/p>\n<p>\nSome routers will\nfilter out this addresses automatically, other require that they be so configured. This allows you\nto not only limit access to and from the internet, but also limits the need for unique addresses. If\nyou only have a handful of machines that need Internet access, some internet providers will sub-net\na Class C <glossary>address<\/glossary>\nand assign you a small block of addresses. See the <glossary>RFC<\/glossary>\nfor more details.\n<\/p>\n<p>\nIn\nmany cases, you Internet Service Provider (ISP) can apply for an <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nfor you. Also, the ISP\ncould provide you with a single <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nthat is actually part of their <glossary>network<\/glossary>.\n Internally, you\nthen use a private <glossary>network<\/glossary>\nas defined in <glossary>RFC<\/glossary>\n1918. In other cases, when you have a dial-up\nconnection to your <glossary>ISP<\/glossary>\nyou may have a dynamically assigned <glossary>address<\/glossary>,\n so it isn’t always the same.\n<\/p>\n<p>\n<center><table BORDER cellspacing=1 CELLPADDING=7 WIDTH=415>\n<tr>\n<td><b>File<\/b> <td><b>Function<\/b>\n<tr> <td>\/bin\/netstat <td>Show network status.\n<tr> <td>\/bin\/hostname <td>Delivers name of current host.\n<tr> <td>\/bin\/ping <td>Sends <glossary>ICMP<\/glossary> ECHO_REQUEST packets to <glossary>network<\/glossary> hosts.\n<tr> <td>\/etc\/dig <td>Send <glossary>domain<\/glossary> name query packets to name servers.\n<tr> <td>\/etc\/ftpaccess <td>FTP access configuration file\n<tr> <td>\/etc\/ftphosts <td>FTP individual <glossary>host<\/glossary> access file\n<tr> <td>\/etc\/ftpusers <td>List of users automatically denied FTP access\n<tr> <td>\/etc\/gated <td>gateway routing <glossary>daemon<\/glossary>.\n<tr> <td>\/etc\/hosts <td>list of hosts on <glossary>network<\/glossary>.\n<tr> <td>\/etc\/hosts.equiv <td>list of trusted hosts.\n<tr> <td>\/etc\/http\/conf\/* <td>HTTP configuration files\n<tr> <td>\/etc\/inetd.conf <td>Inetd configuration file.\n<tr> <td>\/etc\/named.boot <td>Name server configuration file\n<tr> <td>\/etc\/netconfig <td>Configure networking products.\n<tr> <td>\/etc\/networks <td>List of known networks.\n<tr> <td>\/etc\/protocols <td>List of Internet protocols.\n<tr> <td>\/etc\/services <td>List of network services provided.\n<tr> <td>\/etc\/tcpd <td>Access control <glossary>daemon<\/glossary> for Internet services.\n<tr> <td>\/sbin\/bin\/arp <td>Delivers <glossary>ARP<\/glossary> information.\n<tr> <td>\/sbin\/ifconfig <td>configure <glossary>network<\/glossary> interface parameters.\n<tr> <td>\/usr\/bin\/finger <td>Find information about users.\n<tr> <td>\/usr\/bin\/ftp <td>Network file transfer program.\n<tr> <td>\/usr\/bin\/logger <td>Make entries in the system log.\n<tr> <td>\/usr\/bin\/nslookup <td>Query name servers interactively.\n<tr> <td>\/usr\/bin\/rdate <td>Notify time server that date has changed.\n<tr> <td>\/usr\/bin\/rdist <td>Remote file distribution program.\n<tr> <td>\/usr\/bin\/rlogin <td>Remote login program.\n<tr> <td>\/usr\/bin\/route <td>Manually manipulate routing tables.\n<tr> <td>\/usr\/bin\/rwho <td>Who is logged in on local <glossary>network<\/glossary>.\n<tr> <td>\/usr\/bin\/talk <td>Talk to another user.\n<tr> <td>\/usr\/bin\/telnet <td>Telnet remote <glossary>login<\/glossary> program\n<tr> <td>\/usr\/sbin\/ftpshut <td>Shutdown <glossary>ftp<\/glossary> services\n<tr> <td>\/usr\/sbin\/httpd <td>HTTP Daemon\n<tr> <td>\/usr\/sbin\/inetd <td>Internet ‘super-server’\n<tr> <td>\/usr\/sbin\/routed <td>Network routing <glossary>daemon<\/glossary>.\n<tr> <td>\/usr\/sbin\/in.ftpd <td>FTP daemon\n<tr> <td>\/usr\/sbin\/in.rlogind <td>Remote <glossary>login<\/glossary> (rlogin) daemon\n<tr> <td>\/usr\/sbin\/in.rshd <td>Remote <glossary>shell<\/glossary> (rsh) daemon\n<tr> <td>\/usr\/sbin\/in.telnetq <td>Telnet Daemon\n<tr> <td>\/usr\/sbin\/in.tftpd <td>Trivial FTP (TFTP) Daemon\n<tr> <td>\/usr\/sbin\/in.fingerd <td>finger daemon\n<tr> <td>\/usr\/sbin\/traceroute <td>Trace <glossary>packet<\/glossary> routeis to remote machines.\n<\/table><\/center>\n<\/p>Table – Network commands<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Configuring the Domain Name System DNS In the first part of this section, I discussed DNS as being a means of centrally administering the file necessary for node name to IP-address translation. Although the relationship of the files is pretty … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=306\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-306","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/306","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=306"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/306\/revisions"}],"predecessor-version":[{"id":526,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/306\/revisions\/526"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}