Home Page
Linux Basics Debian Linux Installation Using Debian Packages Linux Modem Setup Setting Up A Network Setting Up DNS Servers Linux Internet Servers Linux LAN Servers Linux Database Server Linux Syslog Server Linux Fax Server Linux Web Cam Servers Linux Proxy/NAT Servers Linux Firewall Servers Linux Security Compiling Linux Programs Home Automation What Now?


How To Set Up Linux DNS Services


The material on this page was prepared using a PC running Jessie 8.5
that was set up using our Installation and Packages pages.
If you are using a different version of Debian or you did not use
our pages to set up your system, you may encounter different prompts
and/or see different command responses rather than what is given here.


As mentioned on the Networking page, 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 identifer 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. And on small LANs where there are only a few machines you could just use a HOSTS file on each system instead of setting up a server running NIS or WINS. 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.

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 specify a URL with host and domain name in the browser's address bar. 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" type of 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 host and/or domain name to an IP address. (It is possible to enter a URL with a valid domain name but an invalid host name.) 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 visit Web sites, the DNS server your workstation queries for name resolution is typically run by your ISP. When you have your own Web site the DNS servers which respond to your visitors queries are typically run by your Web hosting provider. You could set up your own DNS server that would respond to both "internal" (from workstations on your LAN) and "external" (from your Web site's visitors) queries.

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 servers 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. Here you can typically get by with only one DNS server. It receives queries from LAN workstations wishing to access other LAN resources such as file servers, internal (intranet) Web servers, etc. 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 which 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 domain name resolution queries for external (Internet) servers to a DNS server. The DNS server most often used for this is your ISP's DNS servers. These are often the DNS servers you specify in your TCP/IP configuration on your PC. You can have your own DNS server respond to these Internet name 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 on 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. A LAN DNS server can simultaneously provide the functionality of a simple DNS server. And if you were to set up a couple authoritative DNS servers they could also provide the functionality of LAN and simple DNS servers. 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 Top of page

Finding a single server out of all of the servers on the Internet is like looking for a single file on hard-drive with tens of thousands of files on it. In both cases it helps to have some hierarchy built into the directory structure to logically group things. The DNS "namespace" is hierarchical in the same type of upside-down tree structure seen with file system folders. Just as you have the root of a hard-drive (C:\), the DNS namespace has a root which is signified by a period.

DNS namespace hierarchy

When specifying the absolute path to a file in a file system you start at the root and go to the file:

C:\windows\system32\drivers\etc\hosts
on a Windows file system or
/etc/bind/named.conf

on a Linux or UNIX system.

It's the reverse when specifying the absolute path to a server in the DNS namespace because you start at the server and go to the root like so:

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 a FQDN (Fully Qualified Domain Name). The use of FQDNs are 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 host name). DNS is basically just a database with records for these hostnames. However, 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 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 a DNS database map a host/domain name to an IP address. Here is a simplistic 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 the Web site at www.their-domain.com your PC sends a name resolution query to the DNS server that you specify in the TCP/IP configuration on your desktop computer). However, the DNS server you use 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? That's up to you.

When you register a domain name with someone like Network Solutions, one of the things they ask you to specify 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). The DNS servers you specify in your domain name registration application, are the authoritative DNS servers for your domain. You have to enter multiple DNS servers in your domain record for redundancy (fail-over) purposes.

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 host names of servers in the parent domain.

Once you've got your Web site up and running on your Web hosting provider's Web servers and someone surf's to your site, the DNS server they specified in their PC's TCP/IP configuration will query your Web hosting provider's DNS servers to get the IP address for your Web site. In other words 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 PC it is a "non-authoritaive" 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 command prompt on a Windows system, type in:

nslookup www.mit.edu

First you'll see the name and IP address of the DNS server you specified in your PC's TCP/IP configuration. Then you'll see the non-authoritative response your DNS server sent back containing the name and IP address of the MIT Web server. You'll also see that www.mit.edu is an alias for a server in an entirely different domain.

If you're on a Linux system type in the following at a shell prompt. Note that you only type in the domain without a hostname.

whois mit.edu

Near the bottom of the command output you'll see the authoritative Name Servers listed for the domain. The 'whois' command simply returns the contents of a site's domain registration record.

Records and 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 or EasyDNS) 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.

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 your ISP, by you using your own authoritative DNS servers, or by a third party like EasyDNS (we show you how to do that below).

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, your ISP's, those of a third party like EasyDNS, or your own, are the auhoritative 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 redundency) and these would be the servers you specify in your domain record. (You could set up one of your DNS servers yourself and then have a third-party provider Like EasyDNS host your redundent server which would also give you geographic diversity.)

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 cycle. 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 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 which 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 files for each domain it's hosting a Web site 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 numeric Priority field. You can enter two or three MX records each pointing to different mail servers, 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 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 like 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 authoriative 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 respond to two different hostnames. Let's say you're not only running Sendmail and Apache on your server, but you're also running VSFTPD 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 will often cache A and CNAME zone records of frequently-accessed Web sites). An SOA record 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:

Now lets 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 parantheses around the timer values act as line-continuation characters as does the '\' character at the end of 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.my-name.com.   IN     A       172.16.52.132

@                     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.



Several things to take note of when evaluating this example zone file:

  • Records are grouped in fours and then subgrouped in twos. The lines are spaced apart only to aid in the readability of this example. You don't want any blank lines in a zone file.

  • The first two records in the group of four use A records to specify the servers, and then the second two records are types which specify what those servers are used for. Optionally, you could list all A records together, all NS records together, all CNAME records together, etc.

  • The first record in the subgroup of two is a shorthand way of entering the information (without the FQDN). The second record is the longhand way. The '@' is a shorthand way of specifying "this zone" (this domain).

  • Whenever you specify a domain in a zone file it must have a trailing period to make it a FQDN.

  • The $TTL 86400 line at the very top of the file specifies the Time To Live value for the record (used by secondary DNS servers).

  • Notice that this zone file specifies the required two DNS servers (with the primary specified in the SOA record) and two mail servers (also for redundancy).

  • Also notice the priority numbers before the hostnames in the MX records.

If you had a simpler setup with only one server with the hostname 'debian' that operated as a Web, e-mail, and FTP server and you had your DNS records hosted by someone like EasyDNS, your zone file would look a lot simpler:

$TTL 86400
my-name.com.          IN     SOA    ns1.easydns.com. \
                                    me.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
                      )
debian                IN     A       192.168.1.51
ns1.easydns.com.      IN     A       216.220.40.243
ns2.easydns.com.      IN     A       205.210.42.20
@                     IN     NS      ns1.easydns.com.
@                     IN     NS      ns2.easydns.com.
@                     IN     MX      10 debian
www                   IN     CNAME   debian
ftp                   IN     CNAME   debian
debian                IN     CNAME   @



Naturally, the 192.168.1.51 private address in this example would have to be an ISP-assigned public address for an Internet-accessible server. We just used a private address as an example.

Notice that the last CNAME record is a little different from the others. It specifies which server should handle requests when no hostname is specified, i.e. requests going to simply my-name.com in a URL, etc. Notice also that you can specify other domains in your zone file which is where the long-hand way of specifying a FQDN is useful.


Dynamic DNS Top of page

If you set up a Debian system to act as a home Web server you, and others if you wish, can access the Web pages on it from anywhere by entering the system's IP address in the URL. The IP address would be whatever is assigned to you by your ISP. The problem is that, unless you pay extra to have a static IP address, the IP address assigned by your ISP will change from time to time and trying keeping up with these changes can be a pain. You can get around this by using a host and domain name to access your system instead of an IP address. Being able to access your system using a consistent name in the URL even though the IP address changes is what dynamic DNS is all about.

Dynamic DNS (DDNS) is the ability for a host (your Debian server) to update its own DNS A record. A host's IP address (or what appears to be its IP address) can change when you use a home broadband service such as cable or DSL. If you have a broadband connection, DDNS allows you to have a full-time Internet server even though you don't have a static IP address.

Here's how it works. You run a small DDNS client on your server that periodically sends your current ISP-assigned IP address to the DDNS server to update your server's A record. If you have your own domain name, the DDNS server is the one that's listed as the primary name server in your domain record. Most DNS servers do not support dynamic updates by default. They have to be configured to listen for dynamic updates.

When your Debian server is booted up (or when the client software runs periodically) the DDNS client software sends a request to the DDNS server to check/update the IP address in the A record for your server with what the DDNS client is reporting as the current address. If you've pulled a different IP address from your ISP since the last time a request was sent, the A record is updated with this new IP address.

When you use a cable/DSL router such as those made by Linksys or DLink (not to be confused with the cable or DSL modem that your ISP gives you), what appears to be your server's IP address is actually the IP address on the "external" router interface. As mentioned on the Networking page, the router does NAT and this address translation can cause difficulties for dynamic DNS. ddclient is a DDNS client that works with routers doing NAT, is compatible with a number of DDNS services, and is available as a Debian package.

DNS Is Only Half The Battle

If you want to have your Debian server act as a publically-accessible Internet server such as a Web server you need to have DNS translate your domain name to the IP address your ISP assigned to the external interface of your cable/DSL router. However, that's not enough.

DNS gets the Internet traffic to your router's external interface but if you don't tell your router what to do with that traffic the router simply drop it. You need to set up port forwarding on your router. By default, Web servers listen for requests on port 80 so all Web browsers specify port 80 in their requests. You have to tell your router that when it receives traffic for port 80 it needs to forward that traffic to your Debian Web server system on your internal network.

We cover setting up port forwarding on a cable/DSL router to forward Web traffic to a server on your internal LAN on our Internet Servers page.


Dynamic DNS with Your Own Domain

You can use dynamic DNS if you already have, or want to have, your own registered domain name. You may want your own domain name for several reasons:

  • You want to set up production Internet servers for an organization or business with static IP addresses.
  • You want to use your own domain name with your home server(s).
  • You want to set up a "non-production" domain just for playing around with. A non-production domain would allow you to investigate how DNS works by playing around with the zone record values. Being that there's no production servers in the domain, there's no problem if you screw something up. (A non-production domain is a real domain with whatever name you choose but you just use it with test servers. Naturally, you can make it a production domain at any time just by setting up "real" servers.)

For this I use the DNS Hosting (with .COM registration) package from EasyDNS because it kills two birds with one stone (and because they have toll-free telephone tech support). EasyDNS will not only host your zone files on their DNS server but also register your domain name both for $35/year. That's a pretty good deal as well as being convenient. You don't have to go to one place to register/renew your domain name, and then go to another place to host your DNS records. When you register a domain name with EasyDNS they'll set up some preliminary zone records for you and you can go in and add/modify/delete records.

The best part is support for dynamic DNS is included in their DNS offerings so you can use them for home and test servers that don't have static IP addresses (and ddclient works with them too).

EasyDNS Domain Settings

Dynamic DNS is not enabled by default for your domain. When you click on the DYN link you'll see a messege that no dynamic records have been defined.

EasyDNS Domain Settings

To enable dynamic DNS for your domain:
  1. Click on the Edit button
  2. Enter an @ in the Host field
  3. Enter 300 in the TTL field
  4. Click on the Next button
  5. On the subsequent summary page click on the Confirm button

EasyDNS Domain Settings

It's important to note that when you enable dynamic DNS for your domain there will no longer be an A record listed for the domain. That's because an A record is a static (unchanging) record and the very nature of dynamic DNS is that IP addresses may change. You can however still create an alias "www" record by using the root domain in the Address field like so:

EasyDNS Domain Settings

If you already have a domain name and servers that have static IP addresses EasyDNS provides a Web interface for DNS management so you can play around with the settings, change server names, create A and MX records, etc.

EasyDNS Domain Settings

Most places that will host your DNS records (like your ISP or Web hosting provider) won't let you even see them much less work with them. Having EasyDNS host your DNS records will allow you to have some control in the management of your DNS. Their straight DNS records hosting service (without the domain registration/renewal piece) costs $20/year. Just be sure to update your domain record with the EasyDNS name servers information once you sign up for the service and get your DNS records set up. (You also have the option of transferring your domain to them, i.e. making them the domain name registrar, if you want to take advantage of the single-payment convenience thing.)

Having your own non-production domain will not only let you play around with zone records, but you can experiment with having your own authoritative DNS server. One of EasyDNS's servers would be the primary authoritative name server and you could set up your Debian server as a secondary. Then you'd just use the Web interface to enter your server's hostname and IP address as a secondary server entry. This way you could play with the "zone transfers" that take place between authoritative servers.

But the benefits of having your own non-production domain go beyond just DNS. It also comes in handy for testing Sendmail e-mail server and Apache Web server configurations, etc. For instance, you can see if your Debian system properly sends and receives e-mail for your non-production domain. Or you could install a test certificate (available for free from most certifying authorities like Thawte or Verisign) on your Debian system acting as a Web server so you can investigate SSL functionality. Just about any type of Internet server you want to play with will have more functionality when you can give it a registered domain name that has DNS resolution capabilities. And if you don't have any plans to eventually use it as a production domain, just let it expire after the first year is up and the knowledge gained will be well worth the 35 bucks.

Recall that the @ symbol means "this domain." When it's in the mail zone field as above it simply indicates that the MX record is for the "root" domain (such as my-last-name.net).

EasyDNS Domain Settings

Your Domain and Spam

One problem with having your own domain name is that spammers my use it as the supposed source of their garbage. In turn you may get contacted by people telling you not to send them any more spam or you may get bounce-back e-mails saying your e-mail couldn't be delivered to an address you never sent an e-mail to.

SPF (Sender Policy Framework) is a DNS-based mechanism for reducing spam. Typically your average domain only has one SMTP server (specified in the MX record) which sends out e-mails for the domain. You can create an SPF record in DNS to specify the IP address of this SMTP server. In other words, an SPF record gives the IP address of the server that is authorized to send e-mail for a given domain. E-mail servers that receive e-mail from the Internet can do an SPF lookup to see if the IP address of the server that sent the e-mail is the IP address of the server that's authorized to send the e-mail.

Whether you use static A records or dynamic DNS, SPF records are entered as TXT records and the records can look pretty cryptic simply because there are a lot of options that can be specified. However, if you have a domain name that will not be used for e-mail it's easy to create an SPF TXT record that tells SPF-checking e-mail servers not to accept any e-mail from your domain. You specify your domain name and the contents of the TXT record are:

v=spf1 -all

Luckily the EasyDNS service supports SPF TXT records and includes a tutorial on SPF and its different options here. Your entry will look like this:

EasyDNS Domain Settings

When you add a TXT record to your domain it has to be replicated but after a day or so you can check to make sure the SPF TXT record you entered is valid by using the SPF record checker at:

www.kitterman.com/spf/validate.html

SPF won't "turn off" spam over night. But as more and more administrators implement it in their DNS records and on their e-mail servers it can eventually reduce it significantly.


Your Own DNS Server ?

If you have your own domain name and you also want to try running your own DNS server, EasyDNS has a Enterprise DNS Service for $15/year which takes some of the risk out of running your own DNS. You would set their servers up to transfer zone information from your DNS server. You would then enter your DNS server address as the primary in your domain record, and the EasyDNS DNS server address as the secondary DNS server in your domain record. Then, should your DNS server ever fail, name resolution queries will go to the EasyDNS server.

Your Own Domain Without Your Own Servers

Would you like your own domain name and receive e-mail and Web traffic to your domain without all the work of setting up your own e-mail and Web servers? Piece of cake!

Just get the DNS Pro Service package from EasyDNS for $55/year. This service includes the domain name registration and you'll be able to:

  • have your domain name annually renewed automatically when you renew this service.

  • have e-mails sent to a you@yourdomain.com e-mail address automatically forwarded to whatever existing e-mail address you want (such as your Yahoo or Gmail e-mail address) without having to pay for additional e-mail services.

  • use their EasySMTP service to send e-mail messages using your you@yourdomain.com e-mail address.

  • have Web requests to http://www.yourdomain.com automatically forwarded to any URL you want (like your personal Web space you get from your ISP).

Your own domain name is nice to have for several reasons. You may want to use your last name for your domain name (if it's available). Some of the benefits of having your own domain name include:

  • You can set up lastname.com e-mail addresses for every member of your family (called "mailmaps") and simply forward their e-mail to their existing e-mail account even if everyone uses a different ISP or Web-mail service.

  • With your own domain name, your e-mail address and Web URL will always remain the same no matter how often you switch ISPs or Web-mail services.

And because so many Web sites use your e-mail address as a login ID it's a real pain to change your e-mail address. Not to mention notifying everyone that your e-mail address is different. With e-mail forwarding using your own domain name, if you switch ISPs you simply change the forwarding address. The ability to have a consistent e-mail address is valuable for students as their e-mail providers change while they go from high school to college to their first job (and having a lastname.com e-mail address looks good on a resume too). It allows you to have the same e-mail address if you're forced to change ISPs because you move to a different city. It also protects you from ISP mergers, failures, and name changes like the Time-Warner/Charter/Bright House/Spectrum mess. And having a consistent Web URL via Web forwarding means you won't lose all the search engine traffic to your Web pages if the URL to your personal Web space changes.


Installing ddclient

So you have your Debian server set up as a Web server that you want to make publically accessable and you've found a domain name that's available so all you need now is a dynamic DNS service and a dynamic DNS client. As we showed you earlier, you can register your domain and sign up for the dynamic DNS service at EasyDNS. With that done you can install ddclient, the dynamic DNS client. You'll need your EasyDNS account username and password when you install the package. Begin the package installation by typing in

apt-get install ddclient

at the shell prompt. You'll then be prompted for the following:
  1. Select the 'EasyDNS' entry as teh service you want to use.

  2. Enter the username you chose when you signed up with your service.

  3. Enter the password you chose when you signed up with your service.

  4. When it prompts you for a network interface just enter eth0

  5. The next screen may seem confusing if you selected 'EasyDNS' in Step 1 because it prompts you for "your DynDNS fully qualified domain names" and then gives examples for dyndns.org. What they mean by the "DynDNS" is "Dynamic DNS", not "DynDNS.org". The "fully qualified" is also a bit misleading. You don't need to enter a trailing period after the TLD (.com, .net, or .org Top Level Domain). All you need to do is enter your server's hostname followed by your, or dyndns.org's, domain name. Example:

    debian.gates.com

The client will now be installed and the appropriate configuration file will be created. However, if your home server is behind a cable/DSL router (such as a Linksys, DLink, or Netgear) or some other type of firewall or proxy server, you'll need to change the interface. Open the config file in a text editor with the command:

nano /etc/ddclient.conf

and replace the line:

use=if, if=eth0

with the line:

use=web, web=support.easydns.com/utils/get_ip.php

This uses a page on EasyDNS's Web site to display your 'outside' IP address. The ddclient software will read the IP address off the returned HTML code and send it to EasyDNS. It'll do this periodically which is necessary with the changing IP addresses you get with home cable and DSL services.

Your file should now look something like this.

# /etc/ddclient.conf

protocol=easydns
use=web, web=support.easydns.com/utils/get_ip.php
server=members.easydns.com
login=bgates
password=luvlinux
my-last-name.net

Exit the text editor saving the file (Ctrl-X,y,Enter). If you use Apache's virtual hosts feature to host multiple Web sites on your server and you have multiple domain names registered with EasyDNS you can update the dynamic DNS for all the domains simultaneously by separating each of the domains by a comma like so:

# /etc/ddclient.conf

protocol=easydns
use=web, web=support.easydns.com/utils/get_ip.php
server=api.cp.easydns.com/dyn/tomato.php
login=bgates
password=luvlinux
my-last-name.net,moe.com,larry.com,curly.com

There's a second ddclient configuration file that you may want to take a look at. Open it in a text editor with the command:

nano /etc/default/ddclient

The only value you may want to change here is last line, changing the daemon_interval from 300 (5 minutes) to 900 (15 minutes).
If you're testing out dynamic DNS on a system that has a modem rather than a broadband connection you'd only need to make three changes to the ddclient setup. When you are installing the program and it asks for an interface enter ppp0 (that's a zero, not the letter o). In the second configuration file we just looked at you'll want to change the run_ipup value from 'false' to 'true' and the run_daemon value from 'true' to 'false.'
Once you've got your configuration file set up and you've set your domain for dynamic DNS, you can test your ddclient configuration to make sure it's working with the command:

ddclient -daemon=0 -noquiet -debug -verbose -force

As mentioned earlier, it takes awhile for a DNS update to replicate and for down-stream, non-authoritative DNS servers to expire their caches. To see if it has taken affect yet, try pinging using your domain name and see if the returned IP address matches what was indicated in the message when you started ddclient.


Other DNS Server Files Top of page

Given that a DNS server can host the zone files for many different domains, each having two zone files, it needs a way to tell which zone files are for which domains. It does this in the named.conf file which, like the zone files themselves, is located in the /etc/bind directory (which you'll see when we install Bind shortly).

Of the two zone files for each domain the one we've been talking about all along has been for forward lookups (resolving names to IP addresses). This zone file is typically named db.my-last-name.net.

DNS also offers a "reverse lookup" function that allows you to translate IP addresses to host/domain names. The information that allows this to happen is stored in the second zone file. Here's a reverse-lookup zone file that corresponds to the simpler zone file we showed earlier:

$TTL 86400
1.168.192.in-addr.arpa. IN     SOA    ns1.easydns.com. \
                                      me.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
                      )
51                    IN     PTR     debian
@                     IN     NS      ns1.easydns.com.
@                     IN     NS      ns2.easydns.com.



Note that the NS records are the same but there's no A records. And since we only have one system handling all three Web, e-mail, and FTP server functions we only need one PTR record. A PTR (Pointer) record is the opposite of an A record. It has the host part of the IP address and gives the corresponding hostname. Typically you want a PTR record for every A record in the forward-lookup file provided the server is in the domain. We don't have PTR records for the name servers above because they're in a different domain (and thus in a different address space).

Why is only the host part of the IP address needed in this file? Because the network portion of the IP address is used when naming the reverse-lookup zone file, and it's reversed. Because 192.168.1.x is a Class C network, the first three octets make up the network portion of the IP address so it's used in the zone file name. Only the last octet specifies the individual host so it's used to specify the host in PTR records. With the above example IP address, the reverse-lookup zone file would be named:

db.1.168.192

The reverse-lookup zone file is also located in the /etc/bind directory. There's another place this naming convention is used. Take a look at the start of the SOA record. The domain is specified as

1.168.192.in-addr.arpa

in-addr.arpa is the default domain for all reverse lookups. As you'll see below, the shorthand method of specifying this with the '@' is normally used.


DNS Tools, Testing, and Troubleshooting Top of page

When you're testing changes to your DNS records things may not act the way you expect them to. What you need is some patience. Most DNS servers cache lookups. If you make a change to a zone record on EasyDNS or the IP address you pulled from your ISP changes and ddclient sends the update, it'll take the DNS servers at EasyDNS up to 15 minutes to update. Then the DNS server that your desktop system is using to resolve names may cache the old information for another 20 to 30 minutes.

If you're using a Windows system to test DNS changes don't forget that it also has a DNS cache. You can clear it manually in a command prompt with the command:

ipconfig /flushdns

As a result, if you make a change to your zone records give it at least 45 minutes before you try to see if the changes had the desired effect. Web browsers also cache name-to-address information. If you're using a Web browser to test your changes, you may want to go and delete all the files in the browser's cache directory as well.
The above makes playing around with dynamic DNS when using a modem kind of a pain. You have to keep the connection up for for at least 45 minutes because if you disconnect, you'll pull a different IP address when you reconnect and your DNS records will have invalid IP addresses. If your dial-up ISP is one that disconnects your call after x minutes of inactivity you'll need to run the ping command in the background to keep the dial-up connection alive.
A DNS problem will likely be in one of three places:


The most basic tool for testing DNS is the ping command. If you can ping a Web server using its IP address but not it's domain name, you have a DNS problem. If you can ping a server using its domain name you'll notice that the server's IP address is also displayed. Verifying that this is the correct IP address will verify that DNS is working properly. Another thing ping can tell you is if you're pinging an actual server or an alias. Using the MIT example again, you may type in

ping www.mit.edu

but the response may indicate not only a different hostname but a different domain as well. That's the reverse-lookup zone file in action.

Another common tool for testing DNS is nslookup (name server lookup) and it's available on Linux systems and Windows systems. As you saw earlier in this page this command will show you what name server your PC is using to resolve names, as well as return hostname and address information on the server that's specified as the target of the command. However, it also has an interactive mode that increase its usefulness. If you simply type in:

nslookup

and you'll get a > prompt. There are several statements that you can enter at his prompt. One helpful one is when you want your system to send queries to a different, other than the default, name server. At the prompt type in the 'server' command followed by the IP address of the DNS server to use (8.8.8.8 is one of Google's public DNS servers):

server 8.8.8.8

Then at the next > prompt you just type in the hostname.domain you want information on. You'll see in the response that the name server being queried has changed to the one you specified. Type 'exit' at the prompt when you're done. Another similar tool on Linux systems is the dig command. You can specify the alternate DNS server to use on the command line:

dig 8.8.8.8 mit.edu any

The any parameter tells it to return information on all record types. Check the man pages for dig and nslookup for more information.


Your Own DNS Server Top of page

Don't set up your Debian system as a DNS server if it doesn't have access to the Internet. It will try and use external DNS servers (called "root hints" which we explain later) to resolve names and they won't be accessible. This will cause problems trying to FTP or telnet to your Debian server even over a local LAN using only IP addresses.

DNS is simply another server application. You can use your Linux system as an authoritative, LAN, or simple DNS server. Simple DNS servers and LAN servers which also provide simple DNS services (resolving Internet host/domain names) need to be connected to the Internet but being behind a firewall should not present a problem as long as you have UDP port 53 is open on the firewall. If you're going to set up and test a secondary authoritative DNS server you'll also need to have TCP port 53 open on the firewall as well for zone transfers.

We'll show you how to set up simple and LAN DNS servers in this section. Setting up production ("real") authoritative DNS servers (remember that you need at least two) is beyond the scope of this page because you'll need to do quite a bit more reading to learn about zone transfers (insecure and secure) between primary and secondary servers and you'll need to know a lot more about the named.conf file. The issue of server security also becomes more important. However, seeing how to set up DNS server files for a LAN DNS server will be a good start.


Where to learn more - The best of our bookshelves:

DNS and BIND
More info...
    DNS and BIND is another case where an O'Reilly book is considered the bible in the industry. I doubt there's a DNS server admin out there that doesn't have a copy. The 4th Edition covers BIND 9 with its security enhancements. The first three chapters provide a detailed foundation in the basics of DNS operation from zone files to root name servers. From there it's all about server configuration. Setting up multiple servers, incremental zone transfers, and round-robin load distribution are just a few of the things covered. It also covers how to set up a server to respond to DDNS requests from clients and DHCP servers as well as how to control which systems have this ability through ACLs (Access Control Lists). How to use BIND's debugging levels and debugger output to solve problems is also covered.


A Simple DNS Server

As mentioned earlier, the most widely used DNS application is called BIND and installing it is simply a matter of entering the command:

apt-get install bind9

Congratulations! You now have a simple DNS server. Now just change the DNS server settings in the TCP/IP configuration files on the workstations on your LAN so that they start using this server as their preferred DNS server. You can use your ISP's DNS server(s) as alternate servers as this will provide some redundancy if your server ever goes down. You'll also want to modify the /etc/resolv.conf file on the DNS server itself so that it points to itself. Do that by opening the file in a text editor with the command:

nano /etc/resolv.conf

and making sure the first nameserver line is:

nameserver 127.0.0.1

Why is setting up a simple DNS server so easy? Because of things called "root hints". The root hints are a list of root-level DNS servers in the /etc/bind/db.root file. Your simple DNS server will query a root server to get the addresses of authoritative DNS servers for each given domain (so it can contact those authoritative DNS servers to get the IP addresses of the desired hosts).

Just remember that your simple DNS server needs a 24/7 connection to the Internet. Or it at least needs to be connected to the Internet any time any system on your LAN needs to access anything on the Internet.

A LAN DNS Server

We'll cover setting up a LAN DNS server for a small LAN where the workstation addresses are statically assigned. If you have a larger LAN that uses DHCP, you'll need to set up the server to respond to DDNS update requests because a system's A record will need to be updated when DHCP assigns the system a different address. (The /etc/bind/rndc.key file is used to ensure that dynamic DNS registrations are secure.)

In setting up a LAN DNS server we need to:

The zone files are just like the zone files we have above. You can even copy/paste the following zone files into a text editor and edit them accordingly if you want. If you're viewing this page on a Windows system, you can copy/paste them into Notepad and FTP them to your Debian system (remember to use ASCII mode when you FTP). Because the zone file names aren't Windows-friendly just save them in Notepad using names like forward.txt and reverse.txt. You can rename them when we copy them from your home directory to the /etc/bind directory. Remember that FTP won't work with the root account (it's a security thing) so use the user account you created when you installed Debian. When you FTP the files to your Debian system they'll go into this account's home directory. We'll copy them over to the right place in a bit.

Here's the forward-lookup zone file for a LAN with the domain name kplan.net. Note that the A records are grouped together, as are the other record types, and that there are no blank lines. However, when trying to get my DNS server to work I did see an error in the syslog file about the reverse-lookup zone file not ending in a "new line" so make sure there's a blank line at the bottom of the file.

$TTL 86400
kplan.net.            IN     SOA    debianserver.kplan.net. \
                                    keith.kplan.net. (
                   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
                      )
gwrouterpc            IN     A       192.168.10.1
windesktop            IN     A       192.168.10.10
winserver             IN     A       192.168.10.20
macdesktop            IN     A       192.168.10.30
linuxdesktop          IN     A       192.168.10.40
debianserver          IN     A       192.168.10.50
@                     IN     NS      debianserver
@                     IN     MX      10 debianserver
www                   IN     CNAME   debianserver
ftp                   IN     CNAME   debianserver
debianserver          IN     CNAME   @



And here's the reverse-lookup zone file for the same domain:

$TTL 86400
@                     IN     SOA    debianserver.kplan.net. \
                                    keith.kplan.net. (
                   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
                      )
1                     IN     PTR     gwrouterpc
10                    IN     PTR     windesktop
20                    IN     PTR     winserver
30                    IN     PTR     macdesktop
40                    IN     PTR     linuxdesktop
50                    IN     PTR     debianserver
@                     IN     NS      debianserver



Notice that instead of using 10.168.192.in-addr.arpa at the start of the SOA record in the reverse lookup file I just used the shortcut. Now when I add a new system to my network I can just add entries to these two files rather than editing the HOSTS files on all of the servers and workstations.

If you created these files on a Windows system using Notepad and FTPed them to your Debian server, go into the directory you FTPed them into and move/rename them like so:

mv forward.txt /etc/bind/db.kplan.net
and
mv reverse.txt /etc/bind/db.10.168.192

After doing this (or creating your own zone files from scratch) you may want to restart server so the bind app intializes with the new files and configurations.

If you want to make sure that BIND isn't having a problem with your zone files, you can check the syslog after you boot the system (which is when BIND starts up and reads the zone files). At a shell prompt just type in:

nano /var/log/syslog

and look near the bottom of the file. You'll see messages when BIND was started. Check to see if any of them refer to any errors that were encountered. If it didn't have a problem with the zone file you'll see it referenced along with:

loaded serial 1

indicating that it has set the serial number (version) to 1.

While the zone file naming convention that BIND uses by default is db. followed by the domain name, and the reverse-lookup zone file is similar except that the domain name is replaced by the reversed network address, you can actually name them whatever you want. You tell the server what zone files to use in the named.conf file.

named.conf

In many installations the named.conf file is the main configuration file for a DNS server. In it you tell the server what, if any, forwarders to use, what domains it's authoritative for, and which zone files it should use for each domain. In more recent versions of Debian it's just a pointer to several smaller configuration files which contain the same information but you have to hunt for it.

Forwarders let you specify other DNS servers to use when your DNS server receives a query for a domain it isn't authoritative for. Your LAN DNS server will be authoritative for your LAN's domain name, but it may not know about other domains.

Do You Need Forwarders ?

If you've been paying attention you may be asking yourself why you would need to specify "forwarder" DNS servers if you have root hints. Good for you. Typically you don't need or want forwarders. It just adds another hop in Internet DNS queries.

The only time you'd need to enter forwarders is if you need to contact other non-Internet domains, such as a different domain that is internal to your company or the private domain of a partner company that you have connectivity to. In this case your forwarders would be the DNS servers tha are authoritative for whatever private domains you need to access systems on.


If you do need to use forwarders open the /etc/bind/named.conf.options file using the nano text editor. You'll see an indented block of text like this:

// forwarders {
// 	0.0.0.0;
// };


The '//' are comment characters in this file so you'll need to remove those also. You should end up with a block of text that looks like this:

forwarders {
192.168.243.9;
192.168.253.9;
};


We have to let the server knows it's authoritative for the kplan.net domain above. Open the /etc/bind/named.conf.default-zones file and at the bottom of the file enter the following for the forward and reverse zone files:

zone "kplan.net" {
    type master;
	file "/etc/bind/db.kplan.net";
};

zone "10.168.192.in-addr.arpa" {
    type master;
	file "/etc/bind/db.10.168.192";
};


Save the file and we're in business from a server perspective. The named daemon is running, we already have a root hints database, our zone files our set up, and our forwarders (if needed) are set up. Now just change the /etc/resolv.conf file on any Debian and UNIX systems so it looks like this:

search kplan.net
nameserver 192.168.10.50

On Windows systems you'd have to change the "Preferred DNS server" in the TCP/IP properties to the 192.168.10.50 address.

Now that you've got a feel for what DNS does for you, and possibly have your own domain name with name resolution capabilities, it's time to start setting up some servers.


SECURITY WARNING

Do NOT plan to use the system you will create using these guide pages as a "production" (real) server. It will NOT be secure!

There are many steps involved in creating a secure Internet or LAN server. While we do refer to some things you can do to make your system more secure, there are many other measures related to system security that also need to be taken into consideration and they are not covered on these pages.

These guide pages are meant as a learning tool only. The knowledge gained on these pages will help you understand the material covered in security-related publications when you are ready to consider setting up a production server.




Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.



Site, content, documents, original images   Copyright © 2003-2016   Keith Parkansky   All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.

This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.

LIABILITY

IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.