Friday, May 20, 2011

Intro to DNS

The Domain Name System (DNS) is a hierarchical naming system used to organize and identify domains, similar to a phone book. Essentially, DNS translates meaningful domains names to IP addresses for the purpose of locating and addressing networking devices worldwide. For instance, the domain name might translate to This makes it much easier to remember URLs and email addresses.

A Records

A records (also known as host records) link a domain, or subdomain, to an IP address.

A records do not necessarily match IP addresses on a one-to-one basis. Many A records correspond to a single IP address where one machine serves many web sites. Alternatively, a single A record may correspond to many IP addresses to facilitate fault tolerance and load distribution.

An A record includes the following fields:
  • Host Name:

    The domain name.

  • IP Address:

    The IP address of the web server hosting the domain.

  • TTL:

    "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of 3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing the MX records will take longer.

CNAME Records

Canonical name (CNAME) records specify that a domain name is an alias of another domain name.

This helps when running multiple services from a single IP address. For example, an FTP and a web server may be located at a single IP address but running on different ports. Each service would then have its own entry in DNS, such as and

A CNAME record includes the following fields:
  • Host Name or Alias:

    The domain name that is being setup to point to another location.

  • URL or Alias For:

    The domain name to which the alias points.

  • TTL:

    "Time to Live." How long it will take to update the record.

When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. The canonical name that a CNAME record points to can be anywhere in the DNS, whether local or on a remote server in a different DNS zone.

For example, if your blog was available at, you could setup a CNAME to point your domain to the Blogger URL. Your readers would then visit to view your blog.   CNAME
This example record may be read as is an alias for the canonical name (CNAME)

MX Records

Mail Exchange (MX) records direct email a domain's mail flow.

Most domains have multiple MX records arranged in order of priority. When someone sends an email message to the domain, the first available server in the priority list handles the message.

An MX record includes the following fields:

  • Name:

    The name of your domain.

  • Class:

    This is always set to IN, which stands for Internet.

  • Type:

    For MX records, this is always set to MX.

  • TTL:

    "Time to Live." How long it will take to update the record.

  • Preference or Priority:

    The order of preference for mail delivery. Sending servers should try the lowest preference number first, then the next lowest, and so on.
    Data: The host name of the mail server that handles mail for that domain.

For instance, if your domain is, your MX records might look like this: IN MX 86400 1 IN MX 86400 2 IN MX 86400 3 IN MX 86400 4

TXT Records

A TXT-record provides the ability to associate some arbitrary and unformatted text with a host or other name. They are often used to establish SPF records, which are explained in-depth in another blog post [link].

NS Records

Name server records determine which servers will communicate DNS information for a domain. Two NS records must be defined for each domain. Generally, you will have a primary and a secondary name server record. NS records are updated with your domain registrar and will take 24-72 hours to take effect.

Wednesday, May 18, 2011

SPF Records Explained

Email spoofing, forging an e-mail header to make it appear as if it came from somewhere or someone other than the actual source, has become a world-wide problem. Though it can be legitimate, it is usually fraudulent and often used in spam and phishing emails to hide the origin of the message. We've all received scams via email that appear to be from our bank or from some other well-known sender but obviously aren't. Because core SMTP doesn't provide any authentication, it is easy to impersonate and forge emails.

Sender Policy Framework (SPF) is used as one of the standard methods for fighting spam by helping email systems verify the identity of a message sender. This protocol works by defining TXT records in a domain's DNS zone which can be used to validate legitimate email sources from a domain. The string placed within the TXT record specifies a list of authorized host names and IP addresses that mail can originate from for a given domain name.

More and more email systems are adopting SPF and we've repeatedly seen an increase in email deliverability among our customers who have implemented SPF. If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server.

How SPF Works

SPF records are added the same way as a regular A, MX, or CNAME record. The domain administrator publishes a DNS TXT record with a specific syntax that lists all SMTP servers that are valid to send email messages for your domain name. Then, when an email system that has implemented SPF receives a message, it checks the FROM line of the email message. It queries public DNS to find the appropriate TXT record and parses the appropriate SPF information.

If the message was sent from an authorized SMTP server, the message is stamped with an SPF x-header that indicates the message "passed" the SPF check and the message is delivered. If the message was sent from an SMTP server that is NOT authorized, the message is typically rejected. If the domain owner has not specified an SPF record, the message will be stamped with an SPF x-header that indicates it is “unknown" whether or not the message should be trusted.

Publishing Your Own SPF Record

First and foremost, you have to determine all the servers that send mail for your domain name. This is the most time consuming part of creating an SPF record. The more precise your list of sending servers, the more authoritative your SPF record will be.

Once this entry is placed within the DNS zone, no further configuration is necessary to take advantage of servers that incorporate SPF checking into their anti-spam systems.

Here's a sample SPF Record and explanation of each mechanism used:

This declares that this entry is an SPF version 1 record.

This declares that any servers that have valid mx records associated with your are valid sending servers.

This declares mail can originate from this IP address or network range. You may specify a network range by appending slash notation subnet.

This mechanism typically goes at the end of the SPF record and designates the IP addresses you list are the only acceptable sending IP addresses and that all others are prohibited.

Other Resources

To learn more about using SPF records for more advanced configurations, visit the SPF Project's page on SPF Record Syntax.

If you're looking for shortcuts, there are many online tools help you create an SPF record quickly and easily, such as the Microsoft SPF Record Wizard.

Monday, May 16, 2011

Our Industry Watchdog

Every industry needs a watchdog, someone who keeps a close eye on things. The hosting industry is fortunate to have Data Center Knowledge doing just that. The articles are well written and straight forward.

If you've ever wanted to know what really happened to cause the Amazon Cloud to dry up or how a car crash was able to take down Rackspace or why the Planet (now Softlayer) caught fire then you'll want to put Data Center Knowledge on your must read list of Web sites.

Wednesday, May 11, 2011

Connect to SQL Server 2008 Remotely

There may be times when being able to connect to SQL Server using Studio Manager remotely rather logging in with Remote Desktop is preferred. Here's how to configure SQL Server 2008 to allow remote connections.

Please note that you should check with your hosting provider to determine the best TCP Port to use for your specific security configuration.

First, configure SQL Server 2008 to allow remote connections.

  1. Click Start, point to All Programs, point to Microsoft SQL Server 2008 R2, point to Configuration Tools, and then click SQL Server Configuration Manager.
  2. Click SQL Server Services, make confirm SQL Server (SQLEXPRESS) and SQL Server Browser running. 
  3. If SQL Server Browser is stopped, then select its properties and point to Service tab, change the Start Mode Disabled to Automatic, click the apply button, then click start option using right mouse click over SQL Server Browser.
  4. Click SQL Server Network Configuration, point to Protocols for SQLEXPRESS, point to TCP/IP, make sure TCP/IP status is Enabled.
  5. Open TCP/IP Properties form using right mouse click over TCP/IP, point to IP Address tab, point to TCP Port in Last section, change TCP Port to 1433, and click Apply button.
  6. Restart the SQL Server(SQLEXPRESS) using right mouse click over SQL Server(SQLEXPRESS).

Next, create an exception in Windows Firewall.

  1. Click Start, point to Control Panel, point to Windows Firewall Settings
  2. Click Change settings link, point to Exceptions tab
  3. Click Add port... button, do the following:
  4.  Collapse
  5. Name: 1433
  6. Port number: 1433
  7. Protocol: TCP
  8. Click OK, and click apply.

Lastly, here's an alternative process to create exceptions in Windows Firewall.

  1. Click Start, point to Administrative Tools, open Windows Firewall with Advanced Security.
  2. Click Inbound Rules, Click New Rule link at the top of right section.
  3. Select Port radio button, click next.
  4. Select TCP radio button, Enter port number in Specific local ports section such as:
  5.  Collapse
  6. Specific local ports: 1433
  7. Click next
  8. Select Allow the connection, click next button, again click next button
  9. Enter Name Ex. 1433
  10. Click Finish button

Tuesday, May 10, 2011

SQL Server IP Address and Port

You will need the IP Address and Port that SQL Server has been configured to use before you can access your databases remotely.

This can be done through the SQL Server Configuration Manager. See 'SQL Server Network Configuration' in the left pane, and then select 'Protocols for '. Double-click the 'TCP/IP' protocol name in the right pane, and this will open a 'TCP/IP Properties' dialog. Select the 'IP Addresses' tab, and you will see the TCP Port. See here:

Also, a very quick method to confirm the TCP Port that SQL Server is listening on:

EXEC xp_regread
@rootkey = 'HKEY_LOCAL_MACHINE',
@value_name = 'TcpPort',
@value = @tcp_port OUTPUT

SELECT @tcp_port [Port]

You can also use xp_cmdshell to return the IP Address of the SQL Server you are connected to, like this:

EXEC master.dbo.xp_cmdshell 'ipconfig'

That will return all of the other media and state details specfic to the network, such as DNS, Subnet Mask, Default Gateway, etc. Try this if you ONLY want to return the SQL Server IP Address:

CREATE TABLE #ipconfig(
captured_line VARCHAR(255)
INSERT #ipconfig
EXECUTE xp_cmdshell 'ipconfig /all';

LTRIM(RTRIM(CAST(PARSENAME(SUBSTRING(captured_line,40,15),4) AS VARCHAR(4))))+'.'+
LTRIM(RTRIM(CAST(PARSENAME(SUBSTRING(captured_line,40,15),3) AS VARCHAR(3))))+'.'+
LTRIM(RTRIM(CAST(PARSENAME(SUBSTRING(captured_line,40,15),2) AS VARCHAR(3))))+'.'+
LTRIM(RTRIM(CAST(PARSENAME(SUBSTRING(captured_line,40,15),1) AS VARCHAR(3)))) [IP Address]
captured_line like '%IPv4 Address%';

DROP TABLE #ipconfig

Thursday, May 5, 2011

Client Printing with Terminal Services

Starting with Windows 2008, you no longer have to install printer drivers on the server and that's because Microsoft added the Terminal Services Easy Print printer driver to Windows 2008 to make client printing, well easy. Still, you may find you are having a problem with client printers showing up on the server. If so, here's a checklist you can follow to ensure client printing is properly configured.

1. Check the Spooler Service is set to automatic start and is running.

  1. Go to Start -> Administrative Tools -> Services ->  Print Spooler

2. Check that Windows Printer mapping is allowed on the server.

  1. Go to Start -> Administrative Tools -> Terminal Services -> Terminal Services Configuration Right click RDP-Tcp and click properties
  2. Right click RDP-Tcp and click properties
  3. Click on Client Settings and make sure Windows Printer is NOT checked

3. Check that the Group Policy is not preventing client printer redirection.

  1. Go to Start -> Run -> Type in gpedit.msc
  2. Go to Administrative Templates -> Windows Components -> Terminal Services -> Terminal Server -> Printer Redirection
  3. Each setting should be set to 'Not configured'

4. Check the Terminal Services UserMode Port Redirector service is started.

  1. Go to Start -> Administrative Tools -> Services ->  Remote Desktop Services UserMode Port Redirector