Archive for July, 2007

X web hosting - The default line discipline chosen by slattach is

Friday, July 27th, 2007

The default line discipline chosen by slattach is CSLIP. You may choose any other discipline using the -p switch. To use normal SLIP (no compression), you use: # slattach -p slip /dev/ttyS3 & The disciplines available are listed in Table 7.1. A special pseudo-discipline is available called adaptive, which causes the kernel to automatically detect which type of SLIP encapsulation is being used by the remote end. Table 7.1: Linux Slip-Line Disciplines Disclipline Description slip Traditional SLIP encapsulation. cslip SLIP encapsulation with Van Jacobsen header compression. slip6 SLIP encapsulation with six-bit encoding. The encoding method is similar to that used by the uuencode command, and causes the SLIP datagram to be converted into printable ASCII characters. This conversion is useful when you do not have a serial link that is eight bit clean. cslip6 SLIP encapsulation with Van Jacobsen header compression and six-bit encoding. adaptive This is not a real line discipline; instead, it causes the kernel to attempt to identify the line discipline being used by the remote machine and to match it. Note that you must use the same encapsulation as your peer. For example, if cowslip uses CSLIP, you also have to do so. If your SLIP connection doesn’t work, the first thing you should do is ensure that both ends of the link agree on whether to use header compression or not. If you are unsure what the remote end is using, try configuring your host for adaptive slip. The kernel might figure out the right type for you. slattach lets you enable not only SLIP, but other protocols that use the serial line, like PPP or KISS (another protocol used by ham radio people). Doing this is not common, though, and there are better tools available to support these protocols. For details, please refer to the slattach(8) manual page. After turning over the line to the SLIP driver, you must configure the network interface. Again, you do this using the standard ifconfig and route commands. Assume that we have dialed up a server named cowslip from vlager. On vlager you would execute: # ifconfig sl0 vlager-slip pointopoint cowslip # route add cowslip # route add default gw cowslip The first command configures the interface as a point-to-point link to cowslip, while the second and third add the route to cowslip and the default route, using cowslip as a gateway. Two things are worth noting about the ifconfig invocation: The pointopoint option that specifies the address of the remote end of a point-to-point link and our use of vlager-slip as the address of the local SLIP interface. We have mentioned that you can use the same address you assigned to vlager’s Ethernet interface for your SLIP link, as well. In this case, vlager-slip might just be another alias for address 172.16.1.1. However, it is also possible that you have to use an entirely different address for your SLIP link. One such case is when your network uses an unregistered IP network address, as the Brewery does. We will return to this scenario in greater detail in the next section.

Chapter 7 - Serial Line IP Packet protocols (Web server application)

Thursday, July 26th, 2007

Chapter 7 - Serial Line IP Packet protocols like IP or IPX rely upon the receiver host knowing where the start and end of each packet are in the data stream. The mechanism used to mark and detect the start and end of packets is called delimitation. The Ethernet protocol manages this mechanism in a LAN environment, and the SLIP and PPP protocols manage it for serial communications lines. The comparatively low cost of low-speed dialup modems and telephone circuits has made the serial line IP protocols immensely popular, especially for providing connectivity to end users of the Internet. The hardware required to run SLIP or PPP is simple and readily available. All that is required is a modem and a serial port equipped with a FIFO buffer. The SLIP protocol is very simple to implement and at one time was the more common of the two. Today almost everyone uses the PPP protocol instead. The PPP protocol adds a host of sophisticated features that contribute to its popularity today, and we’ll look at the most important of these later. Linux supports kernel-based drivers for both SLIP and PPP. The drivers have both been around for some time and are stable and reliable. In this chapter and the next, we’ll discuss both protocols and how to configure them. General Requirements To use SLIP or PPP, you have to configure some basic networking features as described in the previous chapters. You must set up the loopback interface and configure the name resolver. When connecting to the Internet, you will want to use DNS. Your options here are the same as for PPP: you can perform your DNS queries across your serial link by configuring your Internet Service Provider’s IP address into your /etc/resolv.conf file, or configure a caching-only name server as described under “Caching-only named Configuration” in Chapter 6, “Name Service and Resolver Configuration.” SLIP Operation Dialup IP servers frequently offer SLIP service through special user accounts. After logging in to such an account, you are not dropped into the common shell; instead, a program or shell script is executed that enables the server’s SLIP driver for the serial line and configures the appropriate network interface. Then you have to do the same at your end of the link. On some operating systems, the SLIP driver is a user-space program; under Linux, it is part of the kernel, which makes it a lot faster. This speed requires, however, that the serial line be converted to the SLIP mode explicitly. This conversion is done by means of a special tty line discipline, SLIPDISC. While the tty is in normal line discipline (DISC0), it exchanges data only with user processes, using the normal read(2) and write(2) calls, and the SLIP driver is unable to write to or read from the tty. In SLIPDISC, the roles are reversed: now any user-space processes are blocked from writing to or reading from the tty, while all data coming in on the serial port is passed directly to the SLIP driver. The SLIP driver itself understands a number of variations on the SLIP protocol. Apart from ordinary SLIP, it also understands CSLIP, which performs the so-called Van Jacobson header compression (described in RFC1144) on outgoing IP packets. This compression improves throughput for interactive sessions noticeably. There are also six-bit versions for each of these protocols. A simple way to convert a serial line to SLIP mode is by using the slattach tool. Assume you have your modem on /dev/ttyS3 and have logged in to the SLIP server successfully. You will then execute: # slattach /dev/ttyS3 & This tool switches the line discipline of ttyS3 to SLIPDISC and attaches it to one of the SLIP network interfaces. If this is your first active SLIP link, the line will be attached to sl0; the second will be attached to sl1, and so on. The current kernels support a default maximum of 256 simultaneous SLIP links.

Web hosting compare - Authoritative answers can be found from: A.ROOT-SERVERS.NET internet

Thursday, July 26th, 2007

Authoritative answers can be found from: A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33 To see the complete set of available commands, use the help command in nslookup. Other Useful Tools There are a few tools that can help you with your tasks as a BIND administrator. We will briefly describe two of them here. Please refer to the documentation that comes with these tools for more information on how to use them. hostcvt helps you with your initial BIND configuration by converting your /etc/hosts file into master files for named. It generates both the forward (A) and reverse mapping (PTR) entries, and takes care of aliases. Of course, it won’t do the whole job for you, as you may still want to tune the timeout values in the SOA record, for example, or add MX records. Still, it may help you save a few aspirins. hostcvt is part of the BIND source, but can also be found as a standalone package on a few Linux FTP servers. After setting up your name server, you may want to test your configuration. Some good tools that make this job much simpler: the first is called dnswalk, which is a Perl-based package. The second is called nslint. They both walk your DNS database looking for common mistakes and verify that the information they find is consistent. Two other useful tools are host and dig, which are general purpose DNS database query tools. You can use these tools to manually inspect and diagnose DNS database entries. These tools are likely to be available in prepackaged form. dnswalk and nslint are available in source from http://www.visi.com/~barr/dnswalk/ and ftp://ftp.ee.lbl.gov/nslint.tar.Z. The host and dig source codes can be found at ftp://ftp.nikhef.nl/pub/network/ and ftp://ftp.is.co.za/networking/ip/dns/dig/.

*** No address (A) records available for unc.edu (Web site templates)

Wednesday, July 25th, 2007

*** No address (A) records available for unc.edu > set type=SOA > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu origin = ns.unc.edu mail addr = host-reg.ns.unc.edu serial = 1998111011 refresh = 14400 (4H) retry = 3600 (1H) expire = 1209600 (2W) minimum ttl = 86400 (1D) unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net unc.edu name server = ns.unc.edu ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 ns.unc.edu internet address = 152.2.21.1 In a similar fashion, you can query for MX records: > set type=MX > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu preference = 0, mail exchanger = conga.oit.unc.edu unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu unc.edu name server = ns.unc.edu unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net conga.oit.unc.edu internet address = 152.2.22.21 imsety.oit.unc.edu internet address = 152.2.21.99 ns.unc.edu internet address = 152.2.21.1 ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 Using a type of ANY returns all resource records associated with a given name. A practical application of nslookup, besides debugging, is to obtain the current list of root name servers. You can obtain this list by querying for all NS records associated with the root domain: > set type=NS > . Server: tao.linux.org.au Address: 203.41.101.121 Non-authoritative answer: (root) name server = A.ROOT-SERVERS.NET (root) name server = H.ROOT-SERVERS.NET (root) name server = B.ROOT-SERVERS.NET (root) name server = C.ROOT-SERVERS.NET (root) name server = D.ROOT-SERVERS.NET (root) name server = E.ROOT-SERVERS.NET (root) name server = I.ROOT-SERVERS.NET (root) name server = F.ROOT-SERVERS.NET (root) name server = G.ROOT-SERVERS.NET (root) name server = J.ROOT-SERVERS.NET (root) name server = K.ROOT-SERVERS.NET (root) name server = L.ROOT-SERVERS.NET (root) name server = M.ROOT-SERVERS.NET

16 ; (My web server) serial 86400 ; refresh: once per

Wednesday, July 25th, 2007

16 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; brewery 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; winery 1.2 IN PTR vlager-if2.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com. Verifying the Name Server Setup nslookup is a great tool for checking the operation of your name server setup. It can be used both interactively with prompts and as a single command with immediate output. In the latter case, you simply invoke it as: $ nslookup hostname nslookup queries the name server specified in resolv.conf for hostname. (If this file names more than one server, nslookup chooses one at random.) The interactive mode, however, is much more exciting. Besides looking up individual hosts, you may query for any type of DNS record and transfer the entire zone information for a domain. When invoked without an argument, nslookup displays the name server it uses and enters interactive mode. At the > prompt, you may type any domain name you want to query. By default, it asks for class A records, those containing the IP address relating to the domain name. You can look for record types by issuing: > set type=type in which type is one of the resource record names described earlier, or ANY. You might have the following nslookup session: $ nslookup Default Server: tao.linux.org.au Address: 203.41.101.121 > metalab.unc.edu Server: tao.linux.org.au Address: 203.41.101.121 Name: metalab.unc.edu Address: 152.2.254.81 The output first displays the DNS server being queried, and then the result of the query. If you try to query for a name that has no IP address associated with it, but other records were found in the DNS database, nslookup returns with an error message saying “No type A records found.” However, you can make it query for records other than type A by issuing the set type command. To get the SOA record of unc.edu, you would issue: > unc.edu Server: tao.linux.org.au Address: 203.41.101.121

Web design tools - Example 6.11: The named.hosts File ; ; /var/named/named.hosts

Tuesday, July 24th, 2007

Example 6.11: The named.hosts File ; ; /var/named/named.hosts Local hosts at the brewery ; Origin is vbrew.com ; @ IN SOA vlager.vbrew.com. janet.vbrew.com. ( 2000012601 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; ; local mail is distributed on vlager IN MX 10 vlager ; ; loopback address localhost. IN A 127.0.0.1 ; ; Virtual Brewery Ethernet vlager IN A 172.16.1.1 vlager-if1 IN CNAME vlager ; vlager is also news server news IN CNAME vlager vstout IN A 172.16.1.2 vale IN A 172.16.1.3 ; ; Virtual Winery Ethernet vlager-if2 IN A 172.16.2.1 vbardolino IN A 172.16.2.2 vchianti IN A 172.16.2.3 vbeaujolais IN A 172.16.2.4 ; ; Virtual Spirits (subsidiary) Ethernet vbourbon IN A 172.16.3.1 vbourbon-if1 IN CNAME vbourbon Example 6.12: The named.local File ; ; /var/named/named.local Reverse mapping of 127.0.0 ; Origin is 0.0.127.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 1 ; serial 360000 ; refresh: 100 hrs 3600 ; retry: one hour 3600000 ; expire: 42 days 360000 ; minimum: 100 hrs ) IN NS vlager.vbrew.com. 1 IN PTR localhost. Example 6.13: The named.rev File ; ; /var/named/named.rev Reverse mapping of our IP addresses ; Origin is 16.172.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. (

Adelphia web hosting - are dialing in to the Internet, as described

Tuesday, July 24th, 2007

are dialing in to the Internet, as described in Chapter 7, Serial Line IP and Chapter 8, The Point-to-Point Protocol. A named.boot file for a caching-only server looks like this: ; named.boot file for caching-only server directory /var/named primary 0.0.127.in-addr.arpa named.local ; localhost network cache . named.ca ; root servers In addition to this named.boot file, you must set up the named.ca file with a valid list of root name servers. You could copy and use Example 6.10 for this purpose. No other files are needed for a caching-only server configuration. Writing the Master Files Example 6.10, Example 6.11, Example 6.12, and Example 6.13 give sample files for a name server at the brewery, located on vlager. Due to the nature of the network discussed (a single LAN), the example is pretty straightforward. The named.ca cache file shown in Example 6.10 shows sample hint records for a root name server. A typical cache file usually describes about a dozen name servers. You can obtain the current list of name servers for the root domain using the nslookup tool described in the next section.43 Example 6.10: The named.ca File ; ; /var/named/named.ca Cache file for the brewery. ; We’re not on the Internet, so we don’t need ; any root servers. To activate these ; records, remove the semicolons. ; ;. 3600000 IN NS A.ROOT-SERVERS.NET. ;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ;. 3600000 NS B.ROOT-SERVERS.NET. ;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ;. 3600000 NS C.ROOT-SERVERS.NET. ;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ;. 3600000 NS D.ROOT-SERVERS.NET. ;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ;. 3600000 NS E.ROOT-SERVERS.NET. ;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ;. 3600000 NS F.ROOT-SERVERS.NET. ;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ;. 3600000 NS G.ROOT-SERVERS.NET. ;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ;. 3600000 NS H.ROOT-SERVERS.NET. ;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ;. 3600000 NS I.ROOT-SERVERS.NET. ;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ;. 3600000 NS J.ROOT-SERVERS.NET. ;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ;. 3600000 NS K.ROOT-SERVERS.NET. ;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ;. 3600000 NS L.ROOT-SERVERS.NET. ;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ;. 3600000 NS M.ROOT-SERVERS.NET. ;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; Note that you can’t query your name server for the root servers if you don’t have any root server hints installed. To escape this dilemma, you can either make nslookup use a different name server, or use the sample file in Example 6.10 as a starting point, and then obtain the full list of valid servers.

Web hosting account - NS NS records are used to specify a

Monday, July 23rd, 2007

NS NS records are used to specify a zone’s primary server and all its secondary servers. An NS record points to a master name server of the given zone, with the resource data field containing the hostname of the name server. You will meet NS records in two situations: The first situation is when you delegate authority to a subordinate zone; the second is within the master zone database of the subordinate zone itself. The sets of servers specified in both the parent and delegated zones should match. The NS record specifies the name of the primary and secondary name servers for a zone. These names must be resolved to an address so they can be used. Sometimes the servers belong to the domain they are serving, which causes a “chicken and egg” problem; we can’t resolve the address until the name server is reachable, but we can’t reach the name server until we resolve its address. To solve this dilemma, we can configure special A records directly into the name server of the parent zone. The A records allow the name servers of the parent domain to resolve the IP address of the delegated zone name servers. These records are commonly called glue records because they provide the “glue” that binds a delegated zone to its parent. CNAME This record associates an alias with a host’s canonical hostname. It provides an alternate name by which users can refer to the host whose canonical name is supplied as a parameter. The canonical hostname is the one the master file provides an A record for; aliases are simply linked to that name by a CNAME record, but don’t have any other records of their own. PTR This type of record is used to associate names in the in-addr.arpa domain with hostnames. It is used for reverse mapping of IP addresses to hostnames. The hostname given must be the canonical hostname. MX This RR announces a mail exchanger for a domain. Mail exchangers are discussed in “Mail Routing on the Internet”. The syntax of an MX record is: [domain][ttl][class]MX preference host host names the mail exchanger for domain. Every mail exchanger has an integer preference associated with it. A mail transport agent that wants to deliver mail to domain tries all hosts who have an MX record for this domain until it succeeds. The one with the lowest preference value is tried first, then the others, in order of increasing preference value. HINFO This record provides information on the system’s hardware and software. Its syntax is: [domain][ttl][class] HINFO hardware software The hardware field identifies the hardware used by this host. Special conventions are used to specify this. A list of valid “machine names” is given in the Assigned Numbers RFC (RFC-1700). If the field contains any blanks, it must be enclosed in double quotes. The software field names the operating system software used by the system. Again, a valid name from the Assigned Numbers RFC should be chosen. An HINFO record to describe an Intel-based Linux machine should look something like: tao 36500 IN HINFO IBM-PC LINUX2.2 and HINFO records for Linux running on Motorola 68000-based machines might look like: cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO AMIGA-3000 LINUX2.0 Caching-only named Configuration There is a special type of named configuration that we’ll talk about before we explain how to build a full name server configuration. It is called a caching-only configuration. It doesn’t really serve a domain, but acts as a relay for all DNS queries produced on your host. The advantage of this scheme is that it builds up a cache so only the first query for a particular host is actually sent to the name servers on the Internet. Any repeated request will be answered directly from the cache in your local name server. This may not seem useful yet, but it will when you

primary statement must contain an SOA record for (Web hosting unlimited bandwidth)

Monday, July 23rd, 2007

primary statement must contain an SOA record for this zone. The resource data contains the following fields: origin This field is the canonical hostname of the primary name server for this domain. It is usually given as an absolute name. contact This field is the email address of the person responsible for maintaining the domain, with the “@” sign replaced by a dot. For instance, if the responsible person at the Virtual Brewery were janet, this field would contain janet.vbrew.com. serial This field is the version number of the zone file, expressed as a single decimal number. Whenever data is changed in the zone file, this number should be incremented. A common convention is to use a number that reflects the date of the last update, with a version number appended to it to cover the case of multiple updates occurring on a single day, e.g., 2000012600 being update 00 that occurred on January 26, 2000. The serial number is used by secondary name servers to recognize zone information changes. To stay up to date, secondary servers request the primary server’s SOA record at certain intervals and compare the serial number to that of the cached SOA record. If the number has changed, the secondary servers transfer the whole zone database from the primary server. refresh This field specifies the interval in seconds that the secondary servers should wait between checking the SOA record of the primary server. Again, this is a decimal number with at most eight digits. Generally, the network topology doesn’t change too often, so this number should specify an interval of roughly a day for larger networks, and even more for smaller ones. retry This number determines the intervals at which a secondary server should retry contacting the primary server if a request or a zone refresh fails. It must not be too low, or a temporary failure of the server or a network problem could cause the secondary server to waste network resources. One hour, or perhaps one-half hour, might be a good choice. expire This field specifies the time in seconds after which a secondary server should finally discard all zone data if it hasn’t been able to contact the primary server. You should normally set this field to at least a week (604,800 seconds), but increasing it to a month or more is also reasonable. minimum This field is the default ttl value for resource records that do not explicitly contain one. The ttl value specifies the maximum amount of time other name servers may keep the RR in their cache. This time applies only to normal lookups, and has nothing to do with the time after which a secondary server should try to update the zone information. If the topology of your network does not change frequently, a week or even more is probably a good choice. If single RRs change more frequently, you could still assign them smaller ttls individually. If your network changes frequently, you may want to set minimum to one day (86,400 seconds). A This record associates an IP address with a hostname. The resource data field contains the address in dotted quad notation. For each hostname, there must be only one A record. The hostname used in this A record is considered the official or canonical hostname. All other hostnames are aliases and must be mapped onto the canonical hostname using a CNAME record. If the canonical name of our host were vlager, we’d have an A record that associated that hostname with its IP address. Since we may also want another name associated with that address, say news, we’d create a CNAME record that associates this alternate name with the canonical name. We’ll talk more about CNAME records shortly.

Web design software - The cache and primary statements have been converted

Monday, July 23rd, 2007

The cache and primary statements have been converted into zone paragraphs with type clauses of hint and master, respectively. The zone files do not need to be modified in any way; their syntax remains unchanged. The new configuration syntax allows for many new options that we haven’t covered here. If you’d like information on the new options, the best source of information is the documentation supplied with the BIND Version 8 source package. The DNS Database Files Master files included with named, like named.hosts, always have a domain associated with them, which is called the origin. This is the domain name specified with the cache and primary options. Within a master file, you are allowed to specify domain and host names relative to this domain. A name given in a configuration file is considered absolute if it ends in a single dot, otherwise it is considered relative to the origin. The origin by itself may be referred to using (@). The data contained in a master file is split up in resource records(RRs). RRs are the smallest units of information available through DNS. Each resource record has a type. A records, for instance, map a hostname to an IP address, and a CNAME record associates an alias for a host with its official hostname. To see an example, look at Example 6.11, which shows the named.hosts master file for the Virtual Brewery. Resource record representations in master files share a common format: [domain][ttl][class] type rdata Fields are separated by spaces or tabs. An entry may be continued across several lines if an opening brace occurs before the first newline and the last field is followed by a closing brace. Anything between a semicolon and a newline is ignored. A description of the format terms follows: domain This term is the domain name to which the entry applies. If no domain name is given, the RR is assumed to apply to the domain of the previous RR. ttl In order to force resolvers to discard information after a certain time, each RR is associated a time to live (ttl). The ttl field specifies the time in seconds that the information is valid after it has been retrieved from the server. It is a decimal number with at most eight digits. If no ttl value is given, the field value defaults to that of the minimum field of the preceding SOA record. class This is an address class, like IN for IP addresses or HS for objects in the Hesiod class. For TCP/IP networking, you have to specify IN. If no class field is given, the class of the preceding RR is assumed. type This describes the type of the RR. The most common types are A, SOA, PTR, and NS. The following sections describe the various types of RRs. rdata This holds the data associated with the RR. The format of this field depends on the type of RR. In the following discussion, it will be described for each RR separately. The following is partial list of RRs to be used in DNS master files. There are a couple more of them that we will not explain; they are experimental and of little use, generally. SOA This RR describes a zone of authority (SOA means “Start of Authority”). It signals that the records following the SOA RR contain authoritative information for the domain. Every master file included by a