Posts Tagged ‘DNS’

Moving your email to Google Apps

Working in I.T. for many years the biggest energy among all users is email. From my desktop support background I can assure you that I have had my share of email problems and solutions. My favorite email solution has to be Google Apps. Google Apps is a step just above your normal Gmail email. Both are free, but Apps allows you to use a domain name that you own or gives you the option to purchase one during setup for $10 a year. Included with Google Apps is Gmail, Google Calendar, Google Docs, Google Sites, and much much more… I will go into more detail about the other services Google apps has to offer in later posts. Right now we’ll just be concerned with the initial setup of your domain and email.

You can sign up for Google Apps using the domain or website you already own, or purchase a new domain from one of Googles registration partners.

Lets get started?

  1. Go to Google Apps (for free) and click the big blue button to begin. If you are purchasing a domain you must first setup a Google Apps free account, even if you are trying to setup a Google Business Account. Google makes you get a free Apps account then you can upgrade to a free trial for Google Business. Google Business is also a great pay for service that allows you to use Outlook exchange services. $5 a year per user.
  2. Follow the instructions that appear to sign up your domain and create your Google Apps account, it is very self explanatory. The instructions are easy to follow, but there are a few things:
    • If you are setting up your own domain, you have to prove to Google that you own the domain or website. This requires that you have access to any one of the following: the domain’s or website’s DNS records (managed by your domain host or registrar), the server that hosts your domain’s web site (via FTP or SSH), or a Google Analytics account for your domain. For more details Verifying your Domain.
    • Next you need to create an email address at your domain where you’ll send and receive mail (webmaster@your_domain.com). You are going to use this email and password to log in to your Google Apps account and manage the domain to add users, as well as access your own Google Apps services.
    • You have to provide an alternate email address that’s not in your Google Apps domain. I used a gmail address that you can easily setup fro free. This is incase you forget you password  and Google needs to send you new login credentials. This should continue to be a valid address.

After you sign up, we’ll take you to your Google Apps administrator control panel. Now you can log in to your new account, verify domain ownership (if you signed up an existing domain), and continue setting up services for your users. click on the Setup link in the navigation bar and you can use the setup wizard to add users and services.

If you’d like to see more details after that, please leave a comment, and I will consider updating this post with more detailed steps.

 

What is DNS?

What is DNS?
DNS stands for Domain Name System. You see, humans understand words and numbers, however, computers understand one’s and zero’s. The next quote is a technical explanation,  “DNS is the mechanism that translates Internet domain names, such as example.com, into IP addresses, such as 192.168.0.2.” In other words, DNS is the white pages of the internet, it translates our human words into 1′s and 0′s the computers language.

When you type the website address of example.com into the browser window, the computer knows that you want to go to the IP address of 192.168.0.2, because of DNS. You then expect to see a website in your browser window. This website is downloaded from a server. How does your computer and the internet know that it should download that particular website from that particular server? The answer is two fold; first, there is a a network layer of the Internet that uses one or more IP addresses to identify each server; the second, is DNS allows websites to be mapped to those IP addresses, so that when a particular website is requested, the right IP address is recovered, and the right server is asked for the correct website files.

DNS is maintained by special servers called nameservers, Servers of Authority, or SOA for short. Nameservers contain a zone file for each website or domain. The zone file lists the IP addresses that each website or domain uses for web requests, sub-domains, email, etc. Yes, I’m sorry that some of that language got out of hand, but I’ll will go over it all soon enough. A nameserver is like our phone book for your website or domain, where the IP address is your phone number. The zone file is like the actual printed listing in the phone book. Today I’d like to dissect a DNS Zone File so as to provide a better understanding of DNS and how DNS works.

Zone files consist of comments, directives and resource records. Comments start with ‘;’ (semicolon) and are assumed to continue to the end of the line. Comments can occupy a whole line or part of a line. Directives start with ‘$’ and are standardized, like  $ORIGIN  and $TTL. There are a number of Resource Record (RR) types such as, A records, NS records, and SOA records. There are many more.
The window below is an example of a very generic DNS zone file.

(Sorry about the formatting)

$TTL 86400 ; 24 hours could have been written as 24h or 1d
$ORIGIN example.com.
@ 1D IN SOA ns1.example.com. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
@ IN NS ns1.example.com. ; in the domain
@ IN NS ns2.example.com. ;
@ IN MX 10 mail.example.com. ; internal mail provider
ns1 IN A 192.168.0.1 ;name server definition
www IN A 192.168.0.2 ;web server definition
mail IN A 192.168.0.2 ; internal mail address

We are just going to go down the line.

TTL or Time To Live, in the DNS context defines the duration in seconds that the resource record may be cached. The units used are seconds. A common TTL value for DNS is 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that if a DNS record was changed, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Origin is a directive, this is the domain for which the zone file “originates” from. The origin is replaced by the “@” symbol in  a resource record or can also be left blank.

Now we come to our first resource record, the SOA or Server of Authority. This record must always come first and is the most important. The SOA specifies authoritative information, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone. In our example, the @ replaces the domain named by the origin directive, our TTL is 1 day, and the resource class is the internet (IN). Our type is SOA and ns1.example.com is our primary name server. The email address of the person responsible for this zone and to which email may be sent to report errors or problems, hostmaster@example.com. The serial number is defined to be a 10 digit field. This value MUST increment when any resource record in the zone file is updated. Slave DNS servers compare this number to a number they saved for the resource record and decides whether it updates the record or not. The convention is to use a date based serial number value to simplify the task of incrementing, the most popular convention being yyyymmddss where yyyy = year, mm = month and dd = day ss = a sequence number in case you update it more than once in the day. “refresh” indicates the time when the slave will try to refresh the zone from the master by reading the master DNS SOA resource record. “retry” defines the time between retries if the slave (secondary) fails to contact the master when refresh” (above) has expired. “expiry” indicates when the zone data is no longer authoritative. Used by slave or (secondary) servers only. “minimum” is the negative caching time – the time a NAME ERROR = NXDOMAIN result may be cached by any resolver. Now we’re on to the rest of the resource records.

Your first resource record after the SOA record should always be your NS record or nameserver. In my example here, our nameserver is the domain for the Zone File, that is not always the case. You will see later, a Zone File for a domain using a Master domain to control or handle DNS. The next record is the NS record for the secondary nameserver, it can be the same or an external nameserver. A few records below you can see there is a corresponding A record that associates the nameserver domain to an IP address. You can see the mistake I made here, by not including an A record for the secondary nameserver, ns2.example.com. Now lets read the records, the “@” we know stands for the origin, example.com in our example, the IN is the class which stands for internet protocol. There are other classes but they are antiquated, I don’t think anyone uses them, but I could be mistaken. NS is for nameserver, then we have the nameservers domain name, same for the secondary nameservers record. We’ll skip the MX record for now, but note the origin resolves to a sub-domain, mail.example.com, and that sub-domain has a corresponding A record. The first A record resolves the primary nameserver to the IP address of 192.168.0.1. Remember our “White Pages” analogy, the IP is the “computer” address for the domain or human readable address. You could also go as far to say that the IP address for the nameserver domain is the IP address of the physical server, as well. The next A record is that for our actual website, www.example.com. WWW here is a subdomain of example.com. You could also include an A record for just example.com without the WWW. When you type www.example.com in your browser this DNS record tells you the IP address of the web server, 192.168.0.2.  Then last, but not least our mail records A record that resolves the mail servers IP address to 192.168.0.2.

That was a lot to digest. I think my next post will be about setting up Google Apps to work with your website.

Return top