A Pointer (PTR) record resolves an IP address to a fully-qualified domain name (FQDN) as an opposite to what A record does. PTR records are also called Reverse DNS records. PTR records are mainly used to check if the server name is actually associated with the IP address from where the connection was initiated. IP addresses of all Intermedia mail servers already have PTR records created. -------------------------------------------------------------- What is PTR Record? PTR records are used for the Reverse DNS (Domain Name System) lookup. Using the IP address you can get the associated domain/hostname. An A record should exist for every PTR record. The usage of a reverse DNS setup for a mail server is a good solution. While in the domain DNS zone the hostname is pointed to an IP address, using the reverse zone allows pointing an IP address to a hostname. In the Reverse DNS zone, you need to use a PTR Record. The PTR Record resolves the IP address to a domain/hostname. --------------------------------------------------------------

managed-keys-zone ./IN: loading from master file managed-keys.bind For solving it: nano /etc/bind/named.conf add include "/etc/bind/bind.keys"; And also create an empty file: touch /etc/bind/managed-keys.bind ********************************************************** When working with the Reverse DNS (rev.10.168.192.in-addre.arpa), and the zone file (mohsenhassani.ir.db) you can use the tool: named-checkzone mohsenhassani.ir rev.10.168.192.in-addr.arpa named-checkzone mohsenhassani.ir mohsenhassani.ir.db to check the validity of the files.

This file contains a summary of my own experiences: 1-There are some default zones in "/etc/bind/named.conf.external-zones"; no need to change them, neither to exclude it from the file "/etc/bind/named.conf" --------------------------------------------------------------------------------------------- 2-Add a line at the bottom of the file "/etc/bind/named.conf": "include "/etc/bind/named.conf.external-zones"; -------------------------------------------------------------------------------------------- 3-Create a file named "/etc/bind/named.conf.external-zones" and fill it up with: // -------------- Begin mohsenhassani.ir -------------- zone "mohsenhassani.ir" { type master; file "/etc/bind/zones/mohsenhassani.ir.db"; }; zone "1.10.168.192.in-addr.arpa" { type master; file "/etc/bind/zones/1.10.168.192.in-addr.arpa"; }; // -------------- End mohsenhassani.ir -------------- // -------------- Begin shahbal.ir -------------- zone "shahbal.ir" { type master; file "/etc/bind/zones/shahbal.ir.db"; }; zone "2.10.168.192.in-addr.arpa" { type master; file "/etc/bind/zones/2.10.168.192.in-addr.arpa"; }; // -------------- End shahbal.ir -------------- -------------------------------------------------------------------------------------------- 4-There is an empty directory in "/etc/bind/zones/". This the place for holding the data for above paths. So create a file named "mohsenhassani.ir.db" and fill it up with: $TTL 3h @ IN SOA ns.mohsenhassani.ir. a.b.com. ( 2013020828 20m 15m 1w 1h ) IN NS ns.mohsenhassani.ir. ns IN A 199.26.84.20 @ IN A 199.26.84.20 --------------------------------------------------------------------------------- 5-Repeat the earlier step with different file name and data. I mean create a file named "1.10.168.192.in-addr.arpa" in "/zones/" and fill it up with: $TTL 3h @ IN SOA mohsenhassani.ir. mail.mohsenhassani.ir. ( 3 15m 15m 1w 1h ) ; main domain name servers IN NS mohsenhassani.ir. IN NS www.mohsenhassani.ir. IN NS sites.mohsenhassani.ir. ; main domain mail servers IN MX 10 mail.mohsenhassani.ir. ; A records for name servers above IN A 192.69.200.153 www IN A 192.69.200.153 pania IN A 192.69.200.153 ; A record for mail server above mail IN A 192.69.200.153 --------------------------------------------------------------------------------------------- 6- OK, Done! When I was done doing this configurations, I was testing my work with "dig mohsenhassani.ir" but I got error like: root@mohsenhassani:/home/mohsen# dig mohsenhassani.ir ; <<>> DiG 9.7.3 <<>> mohsenhassani.ir ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mohsenhassani.ir. IN A ;; Query time: 383 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Mar 16 17:00:19 2013 ;; MSG SIZE rcvd: 34 In the line which is like ";; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8929" The word "SERVFAIL" shows that I have errors; There are many many many reasons which might cuase this error, and you may solve the error with its id. Anyway for this error I had to do this: sudo nano /etc/resolv.conf And add: 127.0.0.1 to first line. It had already 8.8.8.8 and 4.4.4.4 Then doing "dig mohsenhassani.ir" there was no more errors: root@mohsenhassani:/home/mohsen# dig mohsenhassani.ir ; <<>> DiG 9.7.3 <<>> mohsenhassani.ir ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39792 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;mohsenhassani.ir. IN A ;; ANSWER SECTION: mohsenhassani.ir. 10800 IN A 192.69.200.153 ;; AUTHORITY SECTION: mohsenhassani.ir. 10800 IN NS ns.mohsenhassani.ir. ;; ADDITIONAL SECTION: ns.mohsenhassani.ir. 10800 IN A 192.69.200.153 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Mar 16 17:02:26 2013 ;; MSG SIZE rcvd: 83 ----------------------------------------------------------------------------- Oh! And you have to create two sub-domains named "ns1.mohsenhassani.COM" and "ns2.mohsenhassani.COM" so that you can forward the ".ir" domains to these sub-domains.

http://jack-brennan.com/caching-dns-with-bind9-on-debian/ --------------------------------------------------------------------------------------------- apt-get install bind9 bind9utils --------------------------------------------------------------------------------------------- Configuration: When installing and configuring or restarting bind, in case of encountering errors, check the log files. The log files are not stored separately. BIND stores the logs in the syslog: nano /var/log/syslog *************************************************** 1-nano /etc/bind/named.conf.options We need to modify the forwarder. This is the DNS server to which your own DNS will forward the requests he cannot process. forwarders { # Replace the address below with the address of your provider's DNS server 88.135.34.227; }; ******************************************* 2-Add this line to the file: /etc/bind/named.conf include "/etc/bind/named.conf.external-zones"; ****************************************************** 3-nano /etc/bind/named.conf.external-zones This is where we will insert our zones. By the way, a zone is a domain name that is referenced in the DNS server. // -------------- Begin mohsenhassani.ir -------------- zone "mohsenhassani.ir" { type master; file "/etc/bind/zones/mohsenhassani.ir.db"; }; zone "1.10.168.192.in-addr.arpa" { type master; file "/etc/bind/zones/1.10.168.192.in-addr.arpa"; }; // -------------- End mohsenhassani.ir -------------- ********************************************** 4-nano /etc/bind/zones/1.10.168.192.in-addr.arpa $TTL 3h @ IN SOA mohsenhassani.ir. mail.mohsenhassani.ir. ( 3 15m 15m 1w 1h ) @ IN NS mohsenhassani.ir. @ IN A 192.69.204.35 ********************************************************** 5-Restart BIND: sudo /etc/init.d/bind9 restart in case of failing, check the errors: nano /var/log/syslog We can now test the new DNS server... ******************************************************* Modify the file resolv.conf with the following settings: sudo nano /etc/resolv.conf enter the following: search example.com nameserver 4.4.4.4 nameserver 8.8.8.8 *********************************************************** Now, test your DNS: dig example.com In case of errors, refer to errors in BIND category

Every system on the Internet must have a unique IP address. (This does not include systems that are behind a NAT firewall because they are not directly on the Internet.) DNS acts as a directory service for all of these systems, allowing you to specify each one by its hostname. A telephone book allows you to look up an individual person by name and get their telephone number, their unique identifier on the telephone system's network. DNS allows you to look up individual server by name and get its IP address, its unique identifier on the Internet. There are other hostname-to-IP directory services in use, mainly for LANs. Windows LANs can use WINS. UNIX LANs can use NIS. But because DNS is the directory service for the Internet (and can also be used for LANs) it is the most widely used. UNIX LANs could always use DNS instead of NIS, and starting with Windows 2000 Server, Windows LANs could use DNS instead of, or in addition to, WINS. And on small LANs where there are only a few machines you could just use HOSTS files on each system instead of setting up a server running DNS, NIS, or WINS. As a service, DNS is critical to the operation of the Internet. When you enter www.some-domain.com in a Web browser, it's DNS that takes the www host name and translates it to an IP address. Without DNS, you could be connected to the Internet just fine, but you ain't goin' no where. Not unless you keep a record of the IP addresses of all of the resources you access on the Internet and use those instead of host/domain names. So when you visit a Web site, you are actually doing so using the site's IP address even though you specified a host and domain name in the URL. In the background your computer quickly queried a DNS server to get the IP address that corresponds to the Web site's server and domain names. Now you know why you have to specify one or two DNS server IP addresses in the TCP/IP configuration on your desktop PC (in the resolv.conf file on a Linux system and the TCP/IP properties in the Network Control Panel on Windows systems). A "cannot connect" error doesn't necessarily indicate there isn't a connection to the destination server. There may very well be. The error may indicate a failure in "resolving" the domain name to an IP address. I use the open-source Firefox Web browser on Windows systems because the status bar gives more informational messages like "Resolving host", "Connecting to", and "Transferring data" rather than just the generic "Opening page" with IE. (It also seems to render pages faster than IE.) In short, always check for correct DNS operation when troubleshooting a problem involving the inability to access an Internet resource. The ability to resolve names is critical, and later in this page, we'll show you some tools you can use to investigate and verify this ability. When you are surfing the Web viewing Web pages or sending an e-mail your workstation is sending queries to a DNS server to resolve server/domain names. (Back on the Modems page we showed you how to set up your resolv.conf file to do this.) When you have your own Web site that other people visit you need a DNS server to respond to the queries from their workstations. When you visit Web sites, the DNS server your workstation queries for name resolution is typically run by your ISP, but you could have one of your own. When you have your own Web site the DNS servers which respond to visitors' queries are typically run by your Web hosting provider, but you could likewise have your own one of these too. Actually, if you set up your own DNS server it could be used to respond to both "internal" (from your workstation) and "external" (from your Web site's visitors) queries. Even if you don't have your own domain name or even your own LAN, you can still benefit from using a DNS server to allow others to access your Debian system. If you have a single system connected to the Internet via a cable or DSL connection, you can have it act as a Web/e-mail/FTP server using a neat service called "dynamic DNS" which we'll cover later. Dynamic DNS will even work with a modem if you want to play around with it. DNS Server Functions: You can set up a DNS server for several different reasons: Internet Domain Support: If you have a domain name and you're operating Web, e-mail, FTP, or other Internet servers, you'll use a DNS server to respond to resolution queries so others can find and access your server(s). This is a serious undertaking and you'd have to set up a minimum of two of them. On this page, we'll refer to these types of DNS servers as authoritative DNS servers for reasons you'll see later. However, there are alternatives to having your own authoritative DNS server if you have (or want to have) your own domain name. You can have someone else host your DNS records for you. Even if someone else is taking care of your domain's DNS records you could still set up one of the following types of DNS servers. Local Name Resolution: Similar to the above scenario, this type of DNS server would resolve the hostnames of systems on your LAN. Typically in this scenario, there is one DNS server and it does both jobs. The first being that it receives queries from workstations and the second being that it serves as the authoritative source for the responses (this will be more clear as we progress). Having this type of DNS server would eliminate the need to have (and manually update) a HOSTS file on each system on your LAN. On this page, we'll refer to these as LAN DNS servers. During the Debian installation, you are asked to supply a domain name. This is an internal (private) domain name that is not visible to the outside world so like the private IP address ranges you use on a LAN, it doesn't have to be registered with anyone. A LAN DNS server would be authoritative for this internal, private domain. For security reasons, the name for this internal domain should not be the same as any public domain name you have registered. Private domain names are not restricted to using one of the established public TLD (Top Level Domain) names such as .com or .net. You could use .corp or .inc or anything else for your TLD. Since a single DNS server can be authoritative for multiple domains, you could use the same DNS server for both your public and private domains. However, the server would need to be accessible from both the Internet and the LAN so you'd need to locate it in a DMZ. Though you want to use different public and private domain names, you can use the same name for the second-level domain. For example, my-domain.com for the public name and my-domain.inc for the private name. Internet Name Resolution: LAN workstations and other desktop PCs need to send Internet domain name resolution queries to a DNS server. The DNS server most often used for this is the ISP's DNS servers. These are often the DNS servers you specify in your TCP/IP configuration. You can have your own DNS server respond to these resolution queries instead of using your ISP's DNS servers. My ISP recently had a problem where they would intermittently lose connectivity to the network segment that their DNS servers were connected to so they couldn't be contacted. It took me about 30 seconds to turn one of my Debian systems into this type of DNS server and I was surfing with no problems. On this page, we'll refer to these as simple DNS servers. If a simple DNS server fails, you could just switch back to using your ISP's DNS servers. As a matter of fact, given that you typically specify two DNS servers in the TCP/IP configuration of most desktop PCs, you could have one of your ISP's DNS servers listed as the second (fallback) entry and you'd never miss a beat if your simple DNS server did go down. Turning your Debian system into a simple DNS server is simply a matter of entering a single command. Don't take from this that you need three different types of DNS servers. If you were to set up a couple of authoritative DNS servers they could also provide the functionality of LAN and simple DNS servers. And a LAN DNS server can simultaneously provide the functionality of a simple DNS server. It's a progressive type of thing. If you were going to set up authoritative DNS servers or a simple DNS server you'd have to have a 24/7 broadband connection to the Internet. Naturally, a LAN DNS server that didn't resolve Internet host/domain names wouldn't need this. A DNS server is just a Debian system running a DNS application. The most widely used DNS application is BIND (Berkeley Internet Name Domain) and it runs a daemon called named that, among other things, responds to resolution queries. We'll see how to install it after we cover some basics. DNS Basics: Finding a single server out of all of the servers on the Internet is like trying to find a single file on the drive with thousands of files. In both cases, it helps to have some hierarchy built into the directory to logically group things. The DNS "namespace" is hierarchical in the same type of upside-down tree structure seen with file systems. Just as you have the root of a partition or drive, the DNS namespace has a root which is signified by a period. Namespace Root --> Top Level Domains --> Second Level Domains Namesapce Root: . Top Level Domains: com, net, org Second Level Domains: com --> aboutdebian, cnn, net --> sbc, org --> samba, debian When specifying the absolute path to a file in a file system you start at the root and go to the file: /etc/bind/named.conf When specifying the absolute path to a server in the DNS namespace you start at the server and go to the root: www.aboutdebian.com. Note that period after the 'com' as it's important. It's how you specify the root of the namespace. An absolute path in the DNS namespace is called an FQDN (Fully Qualified Domain Name). The use of FQDNs is prevalent in DNS configuration files and it's important that you always use that trailing period. Internet resources are usually specified by a domain name and a server hostname. The www part of a URL is often the hostname of the Web server (or it could be an alias to a server with a different hostname). DNS is basically just a database with records for these hostnames. The directory for the entire telephone system is not stored in one huge phone book. Rather, it is broken up into many pieces with each city having and maintaining, its piece of the entire directory in its phone book. By the same token, pieces of the DNS directory database (the "zones") are stored, and maintained, on many different DNS servers located around the Internet. If you want to find the telephone number for a person in Poughkeepsie, you'd have to look in the Poughkeepsie telephone book. If you want to find the IP address of the www server in the some-domain.com domain, you'd have to query the DNS server that stores the DNS records for that domain. The entries in the database map a host/domain name to an IP address. Here is a simple logical view of the type of information that is stored (we'll get to the A, CNAME, and MX designations in a bit). A www.their-domain.com 172.29.183.103 MX mail.their-domain.com 172.29.183.217 A debian.your-domain.com 10.177.8.3 CNAME www.your-domain.com 10.177.8.3 MX debian.your-domain.com 10.177.8.3 This is why a real Internet server needs a static (unchanging) IP address. The IP address of the server's NIC connected to the Internet has to match whatever address is in the DNS database. Dynamic DNS does provide a way around this for home servers however, which we'll see later. When you want to browse to www.their-domain.com your DNS server (the one you specify in the TCP/IP configuration on your desktop computer) most likely won't have a DNS record for the their-domain.com domain so it has to contact the DNS server that does. When your DNS server contacts the DNS server that has the DNS records (referred to as "resource records" or "zone records") for their-domain.com your DNS server gets the IP address of the www server and relays that address back to your desktop computer. So which DNS server has the DNS records for a particular domain? When you register a domain name with someone like Network Solutions, one of the things they ask you for are the server names and addresses of two or three "name servers" (DNS servers). These are the servers where the DNS records for your domain will be stored (and queried by the DNS servers of those browsing to your site). So where do you get the "name servers" information for your domain? Typically, when you host your Web site using a Web hosting service they not only provide a Web server for your domain's Web site files but they will also provide a DNS server to store your domain's DNS records. In other words, you'll want to know who your Web hosting provider is going to be before you register a domain name (so you can enter the provider's DNS server information in the name servers section of the domain name registration application). You'll see the term "zone" used in DNS references. Most of the time a zone just equates to a domain. The only times this wouldn't be true is if you set up subdomains and set up separate DNS servers to handle just those subdomains. For example, a company would set up the subdomains us.their-domain.com and europe.their-domain.com and would "delegate" a separate DNS server to each one of them. In the case of these two DNS servers, their zone would be just the subdomains. The zone of the DNS server for the parent their-domain.com (which would contain the servers www.their-domain.com and mail.their-domain.com) would only contain records for those few machines in the parent domain. Note that in the above example "us" and "Europe" are subdomains while "www" and "mail" are hostnames of servers in the parent domain. Once you've got your Web site up and running on your Web hosting provider's servers and someone surf's to your site, the DNS server they specified in their local TCP/IP configuration will query your hosting provider's DNS servers to get the IP address for your Web site. The DNS servers that host the DNS records for your domain, i.e. the DNS servers you specify in your domain name registration application, are the authoritative DNS servers for your domain. The surfer's DNS server queries one of your site's authoritative DNS servers to get an address and gets an authoritative response. When the surfer's DNS server relays the address information back to the surfer's local PC it is a "non authoritative" response because the surfer's DNS server is not an authoritative DNS server for your domain. Example: If you surf to MIT's Web site the DNS server you have specified in your TCP/IP configuration queries one of MIT's authoritative DNS servers and gets an authoritative response with the IP address for the 'www' server. Your DNS server then sends a non-authoritative response back to your PC. You can easily see this for yourself. At a shell prompt, or a DOS window on a newer Windows system, type in: nslookup www.mit.edu First, you'll see the name and IP address of your locally-specified DNS server. Then you'll see the non-authoritative response your DNS server sent back containing the name and IP address of the MIT Web server. If you're on a Linux system you can also see which name server(s) your DNS server contacted to get the IP address. At a shell prompt type in: whois mit.edu and you'll see three authoritative name servers listed with the hostnames STRAWB, W20NS, and BITSY. The 'whois' command simply returns the contents of a site's domain record. DNS Records and Domain Records Don't confuse DNS zone records with domain records. Your domain record is created when you fill out a domain name registration application and is maintained by the domain registration service (like Network Solutions) you used to register the domain name. A domain only has one domain record and it contains administrative and technical contact information as well as entries for the authoritative DNS servers (aka "name servers") that are hosting the DNS records for the domain. You have to enter the hostnames and addresses for multiple DNS servers in your domain record for redundancy (fail-over) purposes. DNS records (aka zone records) for a domain are stored in the domain's zone file on the authoritative DNS servers. Typically, it is stored on the DNS servers of whatever Web hosting service is hosting your domain's Web site. However, if you have your own Web server (rather than using a Web hosting service) the DNS records could be hosted by you using your own authoritative DNS servers (as in MIT's case), or by a third party like EasyDNS. In short, the name servers you specified in your domain record host the domain's zone file containing the zone records. The name servers, whether they be your Web hosting provider's, those of a third party like EasyDNS, or your own, which host the domain's zone file are authoritative DNS servers for the domain. Because DNS is so important to the operation of the Internet, when you register a domain name you must specify a minimum of two name servers. If you set up your own authoritative DNS servers for your domain you must set up a minimum of two of them (for redundancy) and these would be the servers you specify in your domain record. While the multiple servers you specify in your domain record are authoritative for your domain, only one DNS server can be the primary DNS server for a domain. Any others are "secondary" servers. The zone file on the primary DNS server is "replicated" (transferred) to all secondary servers. As a result, any changes made to DNS records must be made on the primary DNS server. The zone files on secondary servers are read-only. If you made changes to the records in a zone file on a secondary DNS server they would simply be overwritten at the next replication. As you will see below, the primary server for a domain and the replication frequency are specified in a special type of zone record. Early on in this page, we said that the DNS zone records are stored in a DNS database which we now know is called a zone file. The term "database" is used quite loosely. The zone file is actually just a text file that you can edit with any text editor. A zone file is domain-specific. That is, each domain has its own zone file. Actually, there are two zone files for each domain but we're only concerned with one right now. The DNS servers for a Web hosting provider will have many zone files, two for each domain it's hosting zone records for. A zone "record" is, in most cases, nothing more than a single line in the text zone file. There are different types of DNS zone records. These numerous record types give you flexibility in setting up the servers in your domain. The most common types of zone records are: An A (Address) record is a "host record" and it is the most common type. It is simply a static mapping of a hostname to an IP address. A common hostname for a Web server is 'www' so the A record for this server gives the IP address for this server in the domain. An MX (Mail eXchanger) record is specifically for mail servers. It's a special type of service-specifier record. It identifies a mail server for the domain. That's why you don't have to enter a hostname like 'www' in an e-mail address. If you're running Sendmail (mail server) and Apache (Web server) on the same system (i.e. the same system is acting as both your Web server and e-mail server), both the A record for the system and the MX record would refer to the same server. To offer some fail-over protection for e-mail, MX records also have a Priority field (numeric). You can enter two or three MX records each pointing to a different mail server, but the server specified in the record with the highest priority (lowest number) will be chosen first. A mail server with a priority of 10 in the MX record will receive an e-mail before a server with a priority of 20 in its MX record. Note that we are only talking about receiving mail from other Internet mail servers here. When a mail server is sending mail, it acts as a desktop PC when it comes to DNS. The mail server looks at the domain name in the recipient's e-mail address and the mail server then contacts its local DNS server (specified in the resolv.conf file) to get the IP address for the mail server in the recipient's domain. When an authoritative DNS server for the recipient's domain receives the query from the sender's DNS server it sends back the IP addresses from the MX records it has in that domain's zone file. A CNAME (Canonical Name) record is an alias record. It's a way to have the same physical server to respond to two different hostnames. Let's say you're not only running Sendmail and Apache on your server, but you're also running WU-FTPD so it also acts as an FTP server. You could create a CNAME record with the alias name 'FTP' so people would use ftp.your-domain.com and www.your-domain.com to access different services on the same server. Another use for a CNAME record was illustrated in the example near the top of the page. Suppose you name your Web server 'Debian' instead of 'www'. You could simply create a CNAME record with the alias name 'www' but with the hostname 'Debian' and Debian's IP address. NS (Name Server) records specify the authoritative DNS servers for a domain. There can multiples of all of the above record types. There is one special record type of which there is only one record in the zone file. That's the SOA (Start Of Authority) record and it's the first record in the zone file. An SOA record is only present in a zone file located on authoritative DNS servers (non-authoritative DNS servers can cache zone records). It specifies such things as: The primary authoritative DNS server for the zone (domain). The e-mail address of the zone's (domain's) administrator. In zone files, the '@' has a specific meaning (see below) so the e-mail address is written as me.my-domain.com. Timing information as to when secondary DNS servers should refresh or expire a zone file and a serial number to indicate the version of the zone file for the sake of comparison. The SOA record is the one that takes up several lines. Several important points to note about the records in a zone file: Records can specify servers in other domains. This is most commonly used with MX and NS records when backup servers are located in a different domain but receive mail or resolve queries for your domain. There must be an A record for systems specified in all MX, NS, and CNAME records. A and CNAME records can specify workstations as well as servers (which you'll see when we set up a LAN DNS server). Now let's look at a typical zone file. When a Debian system is set up as a DNS server the zone files are stored in the /etc/bind directory. In a zone file, the two parentheses around the timer values act as line-continuation characters as does the '\' character at the end of the second line. The ';' is the comment character. The 'IN' indicates an INternet-class record. $TTL 86400 my-name.com. IN SOA debns1.my-name.com. \ joe.my-name.com. { 2004011522 ; Serial no., based on date 21600 ; Refresh after 6 hours 3600 ; Retry after 1 hour 604800 ; Expire after 7 days 3600 ; Minimum TTL of 1 hour ) ;Name servers debns1 IN A 192.168.1.41 debns2.joescuz.com. IN A 192.168.1.42 @ IN NS debns1 my-name.com. IN NS debns2.my-name.com. ;Mail servers debmail1 IN A 192.168.1.51 debmail2.my-name.com. IN A 192.168.1.52 @ IN MX 10 debmail1 my-name.com. IN MX 20 debmail2.my-name.com. ;Aliased servers debhp IN A 192.168.1.61 debdell.my-name.com. IN A 192.168.1.62 www IN CNAME debhp ftp.my-name.com. IN CNAME debdell.my-name.com. Source: http://www.aboutdebian.com/dns.htm