Posts Tagged 'DNS'

March 12, 2014

Name Servers: Don't Get Lost in (Domain) Translation

The Domain Name System (DNS) is vital to keeping the Internet in order and easily accessible. Every byte on the World Wide Web lives in (at least) one specific place on the planet, and it's mapped to that location with an IP address like 66.228.118.53 (IPv4) or 2607:f0d0:4545:3:200:f8ff:fe21:67cf (IPv6). DNS translates the domain names you know and love to the correct IP addresses, so without DNS, you would have to memorize a 32-bit or 128-bit IP address for your favorite websites. Remember the last time your cell phone died? How many phone numbers did you have memorized?

There are plenty of resources available online to explain How DNS Works, so in this post, we'll focus on the basics of how we use DNS. Here's the scenario: We want to register a domain — softlayer.com — and make it available to the masses.

1. Reserve and Register a Domain Name
The first thing we need to do is purchase and register our domain name. To do this, we need to choose a domain registrar and verify that our domain is available. Every domain registrar effectively provides the same service: It will reserve an available domain on your behalf, and it will let you dictate where that domain will live. There's not a lot of differentiation or value-add in that service, so many registrars offer cheap or free domains as loss-leaders for higher margin hosting or Web services. Be sure to check the fine print to make sure you're not committing to a year of hosting to get a $0.99 domain name. Some registrars make the process of updating and configuring where a domain resolves more difficult than others, but for the sake of this example we'll assume that your registrar allows the same easy accessibility SoftLayer provides our customers in the customer portal.

The domain name we want is softlayer.com, and in this example, that domain name is available for us to reserve. Once we go through the ordering process, we'll need to associate the domain with a set of authoritative name servers. Authoritative name servers are effectively the go-to address book for a specified domain. By default, your domain registrar will provide name servers for your domain, but they can be changed easily to meet your needs. You have four typical options when it comes to choosing your domain's name servers:

  • Use the domain registrar's default name servers.
  • Use you hosting provider’s name servers.
  • Use a third party DNS service to manage your domain names.
  • Run your own name servers on your server to manage your domain names.

Each of these options has its own pros and cons, but because we're just interested in getting our domain online, we'll use SoftLayer's DNS control panel to manage our new domain name.

2. Create DNS Records
When we access our hosting provider's DNS control panel, we see this:

DNS Management

This is an extremely high level view of DNS, so we’re just going to focus on what we must have in order to make softlayer.com reachable via browser. The first thing we'll do is add a DNS zone. This is usually our domain, but in some situations, it can be a bit different. In this example, we'll create a “softlayer.com” zone to be responsible for the whole softlayer.com domain:

DNS Management

With that zone created, we now need to add new "Address Records" (A Records) within that zone:

DNS Management
DNS Management

The terminology used in different DNS control panels may vary, so let’s breakdown what the four sections in those screenshots mean:

  • Resource Type: This is our DNS record type. In our example, we have A records which link a hostname to our IP address. There are a number of DNS record types, each serving a different purpose.
  • Host: This is the host node or owner name — the name of the node that this record applies to. Using the @ symbol in the A record allows visitors to reach our website without the leading www. If we wanted blog.softlayer.com to live at a different IP address, we'd make that happen here.
  • Points To: This is the IP address of the host node. You might see this section referred to elsewhere as content, data or value. The standard term is RDATA — resource record data. This is specific to each data type.
  • TTL (Time-to-Live): TTL dictates how long your name server should keep a particular record before refreshing for possible updates. Generally speaking, longer TTLs work well if you’re just adding new entries and or don’t anticipate frequent record changes.

Once we save these changes in our DNS control panel, we play the waiting game. Because these DNS changes have to propagate across our DNS servers to be accessible to the Internet as a whole, the process typically takes 24-48 hours, if not sooner. SoftLayer’s customer portal has DNS check built-in as one a few different network tools. If you aren't a current customer, you can use What's my DNS? This is what the SoftLayer tool looks like:

DNS Management

3. Create rDNS Records
The last step we want to take in setting up our domain is to create Reverse DNS (rDNS) records. These records do the same thing as DNS records, but (as the name suggests) they function in the opposite direction. With rDNS, we can assign an IP address to a domain name. This step isn't required, but I recommend it to help ensure better performance of online activities like email and website visitor tracking.

DNS is a central piece of the Internet as we know it, so by understanding how to use it, you'll have a much better understanding of how the Internet works. It seems challenging at first glance, but as you see from this simple walkthrough, when you break down and understand each step, you won't get overwhelmed. A wealth of DNS tools and tutorials are available for free online, and our DNS documentation might be a great resource to bookmark so you'll never get lost in domain translation.

- Landon

August 14, 2013

Setting Up Your New Server

As a technical support specialist at SoftLayer, I work with new customers regularly, and after fielding a lot of the same kinds of questions about setting up a new server, I thought I'd put together a quick guide that could be a resource for other new customers who are interested in implementing a few best practices when it comes to setting up and securing a new server. This documentation is based on my personal server setup experience and on the experience I've had helping customers with their new servers, so it shouldn't be considered an exhaustive, authoritative guide ... just a helpful and informative one.

Protect Your Data

First and foremost, configure backups for your server. The server is worthless without your data. Data is your business. An old adage says, "It's better to have and not need, than to need and not have." Imagine what would happen to your business if you lost just some of your data. There's no excuse for neglecting backup when configuring your new server. SoftLayer does not backup your server, but SoftLayer offers several options for data protection and backup to fit any of your needs.

Control panels like cPanel and Plesk include backup functionality and can be configured to automatically backup regularly an FTP/NAS account. Configure backups now, before doing anything else. Before migrating or copying your data to the server. This first (nearly empty) backup will be quick. Test the backup by restoring the data. If your server has RAID, it important to remember that RAID is not backup!

For more tips about setting up and checking your backups, check out Risk Management: The Importance of Redundant Backups

Use Strong Passwords

I've seen some very week and vulnerable password on customers' servers. SoftLayer sets a random, complex password on every new server that is provisioned. Don't change it to a weak password using names, birthdays and other trivia that can be found or guessed easily. Remember, a strong password doesn't have to be a complicated one: xkcd: Password Strength

Write down your passwords: "If I write them down and then protect the piece of paper — or whatever it is I wrote them down on — there is nothing wrong with that. That allows us to remember more passwords and better passwords." "We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet." Just don't use any of these passwords.
I've gone electronic and use 1Password and discovered just how many passwords I deal with. With such strong, random passwords, you don't have to change your password frequently, but if you have to, you don't have to worry about remembering the new one or updating all of your notes. If passwords are too much of a hassle ...

Or Don't Use Passwords

One of the wonderful things of SSH/SFTP on Linux/FreeBSD is that SSH-keys obviate the problem of passwords. Mac and Linux/FreeBSD have an SSH-client installed by default! There are a lot of great SSH clients available for every medium you'll use to access your server. For Windows, I recommend PuTTY, and for iOS, Panic Prompt.

Firewall

Firewalls block network connections. Configuring a firewall manually can get very complicated, especially when involving protocols like FTP which opens random ports on either the client or the server. A quick way to deal with this is to use the system-config-securitylevel-tui tool. Or better, use a firewall front end such as APF or CSF. These tools also simplify blocking or unblocking IPs.

Firewall Allow Block Unblock
APF apf -a <IP> apf -d <IP> apf -u <IP>
CSF* csf -a <IP> csf -d <IP> csf -dr <IP>

*CSF has a handy search command: csf -g <IP>.

SoftLayer customers should be sure to allow SoftLayer IP ranges through the firewall so we can better support you when you have questions or need help. Beyond blocking and allowing IP addresses, it's also important to lock down the ports on your server. The only open ports on your system should be the ones you want to use. Here's a quick list of some of the most common ports:

cPanel ports

  • 2078 - webDisk
  • 2083 - cPanel control panel
  • 2087 - WHM control panel
  • 2096 - webmail

Other

  • 22 - SSH (secure shell - Linux)
  • 53 - DNS name servers
  • 3389 - RDP (Remote Desktop Protocol - Windows)
  • 8443 - Plesk control panel

Mail Ports

  • 25 - SMTP
  • 110 - POP3
  • 143 - IMAP
  • 465 - SMTPS
  • 993 - IMAPS
  • 995 - POP3S

Web Server Ports

  • 80 - HTTP
  • 443 - HTTPS

DNS

DNS is a naming system for computers and services on the Internet. Domain names like "softlayer.com" and "manage.softlayer.com" are easier to remember than IP address like 66.228.118.53 or even 2607:f0d0:1000:11:1::4 in IPv6. DNS looks up a domain's A record (AAAA record for IPv6), to retrieve its IP address. The opposite of an A record is a PTR record: PTR records resolve an IP address to a domain name.

Hostname
A hostname is the human-readable label you assign of your server to help you differentiate it from your other devices. A hostname should resolve to its server's main IP address, and the IP should resolve back to the hostname via a PTR record. This configuration is extremely important for email ... assuming you don't want all of your emails rejected as spam.

Avoid using "www" at the beginning of a hostname because it may conflict with a website on your server. The hostnames you choose don't have to be dry or boring. I've seen some pretty awesome hostname naming conventions over the years (Simpsons characters, Greek gods, superheros), so if you aren't going to go with a traditional naming convention, you can get creative and have some fun with it. A server's hostname can be changed in the customer portal and in the server's control panel. In cPanel, the hostname can be easily set in "Networking Setup". In Plesk, the hostname is set in "Server Preferences". Without a control panel, you can update the hostname from your operating system (ex. RedHat, Debian)

A Records
If you buy your domain name from SoftLayer, it is automatically added to our nameservers, but if your domain was registered externally, you'll need to go through a few additional steps to ensure your domain resolves correctly on our servers. To include your externally-registered domain on our DNS, you should first point it at our nameservers (ns1.softlayer.com, ns2.softlayer.com). Next, Add a DNS Zone, then add an A record corresponding to the hostname you chose earlier.

PTR Records
Many ISPs configure their servers that receive email to lookup the IP address of the domain in a sender's email address (a reverse DNS check) to see that the domain name matches the email server's host name. You can look up the PTR record for your IP address. In Terminal.app (Mac) or Command Prompt (Windows), type "nslookup" command followed by the IP. If the PTR doesn't match up, you can change the PTR easily.

NSLookup

SSL Certificates

Getting an SSL certificate for your site is optional, but it has many benefits. The certificates will assure your customers that they are looking at your site securely. SSL encrypts passwords and data sent over the network. Any website using SSL Certificates should be assigned its own IP address. For more information, we have a great KnowledgeLayer article about planning ahead for an SSL, and there's plenty of documentation on how to manage SSL certificates in cPanel and Plesk.

Move In!

Now that you've prepared your server and protected your data, you are ready to migrate your content to its new home. Be proactive about monitoring and managing your server once it's in production. These tips aren't meant to be a one-size-fits-all, "set it and forget it" solution; they're simply important aspects to consider when you get started with a new server. You probably noticed that I alluded to control panels quite a few times in this post, and that's for good reason: If you don't feel comfortable with all of the ins and outs of server administration, control panels are extremely valuable resources that do a lot of the heavy lifting for you.

If you have any questions about setting up your new server or you need any help with your SoftLayer account, remember that we're only a phone call away!

-Lyndell

November 2, 2012

The Trouble with Open DNS Resolvers

In the last couple of days, there's been a bit of buzz about "open DNS resolvers" and DNS amplification DDoS attacks, and SoftLayer's name has been brought up a few times. In a blog post on October 30, CloudFlare explained DNS Amplification DDoS attacks and reported the geographic and network sources of open DNS resolvers that were contributing to a 20Gbps attack on their network. SoftLayer's AS numbers (SOFTLAYER and the legacy THEPLANET-AS number) show up on the top ten "worst offenders" list, and Dan Goodin contacted us to get a comment for a follow-up piece on Ars Technica — Meet the network operators helping to fuel the spike in big DDoS attacks.

While the content of that article is less sensationalized than the title, there are still a few gaps to fill about when it comes to how SoftLayer is actually involved in the big picture (*SPOILER ALERT* We aren't "helping to fuel the spike in big DDoS attacks"). The CloudFlare blog and the Ars Technica post presuppose that the presence of open recursive DNS resolvers is a sign of negligence on the part of the network provider at best and maliciousness at worst, and that's not the case.

The majority of SoftLayer's infrastructure is made up of self-managed dedicated and cloud servers. Customers who rent those servers on a monthly basis have unrestricted access to operate their servers in any way they'd like as long as that activity meets our acceptable use policy. Some of our largest customers are hosting resellers who provide that control to their customers who can then provide that control to their own customers. And if 23 million hostnames reside on the SoftLayer network, you can bet that we've got a lot of users hosting their DNS on SoftLayer infrastructure. Unfortunately, it's easier for those customers and customers-of-customers and customers-of-customers-of-customers to use "defaults" instead of looking for, learning and implementing "best practices."

It's all too common to find those DNS resolvers open and ultimately vulnerable to DNS amplification attacks, and whenever our team is alerted to that vulnerability on our network, we make our customers aware of it. In turn, they may pass the word down the customer-of-customer chain to get to the DNS owner. It's usually not a philosophical question about whether DNS resolvers should be open for the greater good of the Internet ... It's a question of whether the DNS owner has any idea that their "configuration" is vulnerable to be abused in this way.

SoftLayer's network operations, abuse and support teams have tools that flag irregular and potentially abusive traffic coming from any server on our network, and we take immediate action when we find a problem or are alerted to one by someone who sends details to abuse@softlayer.com. The challenge we run into is that flagging obvious abusive behavior from an active DNS server is a bit of a cat-and-mouse game ... Attackers cloak their activity in normal traffic. Instead of sending a huge amount of traffic from a single domain, they send a marginal amount of traffic from a large number of machines, and the "abusive" traffic is nearly impossible for even the DNS owner to differentiate from "regular" traffic.

CloudFlare effectively became a honeypot, and they caught a distributed DNS amplification DoS attack. The results they gathered are extremely valuable to teams like mine at SoftLayer, so if they go the next step to actively contact the abuse channel for each of the network providers in their list, I hope that each of the other providers will jump on that information as I know my team will.

If you have a DNS server on the SoftLayer network, and you're not sure whether it's configured to prevent it from being used for these types of attacks, our support team is happy to help you out. For those of you interested in doing a little DNS homework to learn more, Google's Developer Network has an awesome overview of DNS security threats and mitigations which gives an overview of potential attacks and preventative measures you can take. If you're just looking for an easy way to close an open recursor, scroll to the bottom of CloudFlare's post, and follow their quick guide.

If, on the other hand, you have your own DNS server and you don't want to worry about all of this configuration or administration, SoftLayer operates private DNS resolvers that are limited to our announced IP space. Feel free to use ours instead!

-Ryan

January 18, 2012

Keep Fighting: SOPA on the Ropes. PIPA Lurking.

The Internet is unnervingly quiet today. In response to the Stop Online Piracy Act (SOPA) in the House of Representatives and the Protect IP Act (PIPA) in the Senate, some of the most popular sites on the web have gone dark today – demonstrating the danger (and the potential unchecked power) of these two bills.

Late Friday afternoon, Judiciary Committee Chairman Lamar Smith announced that the DNS-blocking provisions would be removed from SOPA, and on Saturday, The White House responded to in opposition to the the bills as they stand today. Shortly thereafter, SOPA was "shelved."

The Internet was abuzz ... but the Champagne wasn't getting popped yet. After digging into the details, it was revealed that SOPA being "shelved" just meant that it is being temporarily put to sleep. Judiciary Committee Chairman Lamar Smith stood explained:

"To enact legislation that protects consumers, businesses and jobs from foreign thieves who steal America's intellectual property, we will continue to bring together industry representatives and Members to find ways to combat online piracy.

Due to the Republican and Democratic retreats taking place over the next two weeks, markup of the Stop Online Piracy Act is expected to resume in February."

I only mention this because it's important not to forget that SOPA isn't dead, and it's still very dangerous. If you visit sites like reddit, Wikipedia, Mozilla and Boing Boing today (January 18, 2012), you experience the potential impact of the legislation.

The Internet's outrage against SOPA has brought about real change in our nation's capital: The House is reconsidering the bill, and they'll hopefully dismiss it. With our collective momentum, we need to look at the PROTECT IP Act (PIPA, or Senate Bill 968) – a similar bill with similarly harmful implications that's been sneaking around in SOPA's shadow.

As it is defined today, PIPA has a stated goal of providing the US Government and copyright holders an additional arsenal of tools to aide in taking down 'rogue websites dedicated to infringing or counterfeit goods.' The Senate bill details that an "information location tool shall take technically feasible and reasonable measures, as expeditiously as possible, to remove or disable access to the Internet site associated with the domain name set forth in the order." In addition, it must delete all hyperlinks to the offending "Internet site."

Our opposition to PIPA is nearly identical to our opposition to SOPA. Both require a form of essentially breaking a core aspect of how the Internet functions – whether that breakage happens in DNS (as detailed in my last blog post) or in the required rearchitecture of the way any site that accepts user-generated content has to respond to PIPA-related complaints.

PIPA is scheduled for Senate vote on January 24, 2012. It is important that you voice your opinion with your government representatives and let them know about your opposition to both SOPA and PIPA. We want to help you get started down that path. Find your local representatives' contact information:

[SOPA Concerns]: Contact your congressperson in the U.S. House of Representatives
[PIPA Concerns]: Contact your Senator in the U.S. Senate

Keep spreading the word, and make sure your voice is heard.

-@toddmitchell

January 12, 2012

How the Internet Works (And How SOPA Would Break It)

Last week, I explained SoftLayer's stance against SOPA and mentioned that SOPA would essentially require service providers like SoftLayer to "break the Internet" in response to reports of "infringing sites." The technical readers in our audience probably acknowledged the point and moved on, but our non-technical readers (and some representatives in Congress) might have gotten a little confused by the references to DNS, domains and IP addresses.

Given how pervasive the Internet is in our daily lives, you shouldn't need to be "a techie" to understand the basics of what makes the Internet work ... And given the significance of the SOPA legislation, you should understand where the bill would "break" the process. Let's take a high level look at how the Internet works, and from there, we can contrast how it would work if SOPA were to pass.

The Internet: How Sites Are Delivered

  1. You access a device connected in some way to the Internet. This device can be a cell phone, a computer or even a refrigerator. You are connected to the Internet through an Internet Service Provider (ISP) which recognizes that you will be accessing various sites and services hosted remotely. Your ISP manages a network connected to the other networks around the globe ("inter" "network" ... "Internet").
  2. You enter a domain name or click a URL (for this example, we'll use http://www.softlayer.com since we're biased to that site).

Internet Basics

  1. Your ISP will see that you want to access "www.softlayer.com" and will immediately try to find someone/something that knows what "www.softlayer.com" means ... This search is known as an NS (name server) lookup. In this case, it will find that "www.softlayer.com" is associated with several name servers.

Internet Basics

  1. The first of these four name servers to respond with additional information about "softlayer.com" will be used. Domains are typically required to be associated with two or three name servers to ensure if one is unreachable, requests for that domain name can be processed by another.
  2. The name server has Domain Name System (DNS) information that maps "www.softlayer.com" to an Internet Protocol (IP) address. When a domain name is purchased and provisioned, the owner will associate that domain name with an authoritative DNS name server, and a DNS record will be created with that name server linking the domain to a specific IP address. Think of DNS as a phone book that translates a name into a phone number for you.

Internet Basics

  1. When the IP address you reach sees that you requested "www.softlayer.com," it will find the files/content associated with that request. Multiple domains can be hosted on the same IP address, just as multiple people can live at the same street address and answer the phone. Each IP address only exists in a single place at a given time. (There are some complex network tricks that can negate that statement, but in the interest of simplicity, we'll ignore them.)
  2. When the requested content is located (and generated by other servers if necessary), it is returned to your browser. Depending on what content you are accessing, the response from the server can be very simple or very complex. In some cases, the request will return a single HTML document. In other cases, the content you access may require additional information from other servers (database servers, storage servers, etc.) before the request can be completely fulfilled. In this case, we get HTML code in return.

Internet Basics

  1. Your browser takes that code and translates the formatting and content to be displayed on your screen. Often, formatting and styling of pages will be generated from a Cascading Style Sheet (CSS) referenced in the HTML code. The purpose of the style sheet is to streamline a given page's code and consolidate the formatting to be used and referenced by multiple pages of a given website.

Internet Basics

  1. The HTML code will reference sources for media that may be hosted on other servers, so the browser will perform the necessary additional requests to get all of the media the website is trying to show. In this case, the most noticeable image that will get pulled is the SoftLayer logo from this location: http://static2.softlayer.com/images/layout/logo.jpg

Internet Basics

  1. When the HTML is rendered and the media is loaded, your browser will probably note that it is "Done," and you will have successfully navigated to SoftLayer's homepage.

If SOPA were to pass, the process would look like this:

The Internet: Post-SOPA

  1. You access a device connected in some way to the Internet.
  2. You enter a domain name or click a URL (for this example, we'll use http://www.softlayer.com since we're biased to that site).

*The Change*

  1. Before your ISP runs an NS lookup, it would have to determine whether the site you're trying to access has been reported as an "infringing site." If http://www.softlayer.com was reported (either legitimately or illegitimately) as an infringing site, your ISP would not process your request, and you'd proceed to an error page. If your ISP can't find any reference to the domain an infringing site, it would start looking for the name server to deliver the IP address.
  2. SOPA would also enforce filtering from all authoritative DNS provider. If an ISP sends a request for an infringing site to the name server for that site, the provider of that name server would be forced to prevent the IP address from being returned.
  3. One additional method of screening domains would happen at the level of the operator of the domain's gTLD. gTLDs (generic top-level domains) are the ".____" at the end of the domain (.com, .net, .biz, etc.). Each gTLD is managed by a large registry organization, and a gTLD's operator would be required to prevent an infringing site's domain from functioning properly.
  4. If the gTLD registry operator, your ISP and the domain's authoritative name server provider agree that the site you're accessing has not been reported as an infringing site, the process would resume the pre-SOPA process.

*Back to the Pre-SOPA Process*

  1. The domain's name server responds.
  2. The domain's IP address is returned.
  3. The IP address is reached to get the content for http://www.softlayer.com.
  4. HTML is returned.
  5. Your browser translates the HTML into a visual format.
  6. External file references from the HTML are returned.
  7. The site is loaded.

The proponents of SOPA are basically saying, "It's difficult for us to keep up with and shut down all of the instances of counterfeiting and copyright infringement online, but it would be much easier to target the larger sites/providers 'enabling' users to access that (possible) infringement." Right now, the DMCA process requires a formal copyright complaint to be filed for every instance of infringement, and the providers who are hosting the content on their network are responsible for having that content removed. That's what our abuse team does full-time. It's a relatively complex process, but it's a process that guarantees us the ability to investigate claims for legitimacy and to hear from our customers (who hear from their customers) in response to the claims.

SOPA does not allow for due process to investigate concerns. If a site is reported to be an infringing site, service providers have to do everything in their power to prevent users from getting there.

-@toddmitchell

July 29, 2010

What Makes SoftLayer Different?

I often get asked “what makes SoftLayer different?” The problem with that simple question is – SoftLayer is so different from all the competition out there that it’s not a simple question to answer. I have my standard version that I run thru – but I’m not sure people really grasp how different SoftLayer really is. After talking to my wife, she recommended doing a Letterman style top 10 reason why SoftLayer is different. I figured I would give it a shot – so here it is..

  1. SoftLayer terminates 40Gbps to every single rack!! 20Gbps to the public internet and 20Gbps to the private network.
  2. SoftLayer offers three types of VPN services for out-of-band connectivity (SSL, PPTP, IPSEC)
  3. SoftLayer manages its own nationwide MPLS network with 10 PoPs and over 1000Gbps of transit and peer connectivity
  4. SoftLayer offers free enterprise grade DNS services through our DNS farms located in all 10 PoPs in North America
  5. SoftLayer has over 1600 APIs for custom integration, a full service control panel for ease of use and a private label option for resellers
  6. Every single server in every datacenter is a rackmount, hotswap, tool-less chassis offering enterprise grade hardware with ultra-fast modifications
  7. SoftLayer has downloadable iPhone, Android and Blackberry apps in addition to our mobile phone friendly .mobi site for complete control.
  8. Only hybrid solution available – dedicated, virtualized, and cloud instances operating in a single environment and control thru a single interface or API
  9. Private Network – connect any server to any other server in any datacenter with a click of a button
  10. Fastest service delivery
  • Over 1000 servers in stock
  • Dedicated servers – 4 hours or less
  • Servers with virtualization – 2 hours or less
  • Cloud instances & storage – 5 to 15 minutes
  • Firewalls, Load Balancers, SAN Storage – added real time w/ no downtime

-@lavosby

June 9, 2010

DNS from All Angles

Serving up content on the internet can be a tricky business. It isn’t just about running a web or app server(s) in an efficient and reliable manner. One of the other critical factors is DNS. You have to understand and optimize how the name the content is advertised under gets translated to the IP address of the content. I don’t want to turn this into a DNS primer, but the two ends of the line of communication are the authoritative DNS server controlled by the domain owner which stores the official translation of the name to the number and the resolving DNS server which acts as a cache and is where the end-user connects to directly. Both ends of the chain have their own idiosyncrasies which can affect how quickly and reliably your content gets delivered.

On the end-user side, I just read an article about how public DNS providers like OpenDNS and Google are breaking the internet. OK, maybe not breaking the internet, but the public DNS providers are confusing CDN location-based algorithms. The article is here: http://www.sajalkayan.com/in-a-cdnd-world-opendns-is-the-enemy.html and I recommend strongly that both content providers and content consumers read it.

The summary is that some CDN algorithms use the ip address (and location) of the DNS server making the request and if that DNS server is nowhere near the end-user on the internet, the end-user will get served content from farther away and will get that content slower than desired. The conclusion is that an end-user should always use a DNS server located as close as possible network-wise, usually that ends up being a DNS server of the network provider.

That is good advice for the end-user, but what about the content provider? If you flip this around and come at DNS from the content provider’s point of view who doesn’t use CDN, you want to make sure that when a DNS request is made, that your authoritative DNS server gets the ip address as fast and reliably as possible back to the end-user.

SoftLayer has built out authoritative DNS farms in all our Datacenters and Network POPs and anycasted the ip addresses for the name servers. What that means is that SoftLayer customers – who get to use our DNS for free – can have their authoritative domain services hosted at all 10 points in North America and through the routing optimization inherent in the internet, the name to number conversion for those domains will happen as close as possible to the end-user and the results will be delivered as quickly as possible.

One very important goal of every content provider is to get the end-user the best experience as possible. Understanding how the internet works from the end-user and well as the server-side is critical. It doesn’t matter how good your content or app is if the end-user has a poor experience.

-@nday91

August 26, 2009

Cool Tool: nslookup

If you've been around the Internet awhile you've probably heard of the Domain Name Service. DNS is what takes www.domain.com and turns it into the 1.2.3.4 IP address which your application actually uses to find the server hosting www.domain.com.

Fascinating, Michael, why do I care? Well if you ask that question you've never had DNS fail on you.

When name resolution goes on the blink one of the tools that support uses to see what is going is the command-line utility nslookup. In its most basic form nslookup is going to do an A record query for the string you supply as an argument and it'll send that query to your operating system's configured resolvers.


C:\>nslookup www.softlayer.com
Server: mydns.local
Address: 192.168.0.1

 


Non-authoritative answer:
Name: www.softlayer.com
Address: 66.228.118.51


What is the utility telling us? First off, it asked a resolver at 192.168.0.1 for the information. Non-authoritative answer means that the server which returned the answer (192.168.0.1) is not the nameserver which controls softlayer.com. It then gives the IP address or addresses which were found.



C:\>nslookup -q=mx softlayer.com ns1.softlayer.com
Server: ns1.softlayer.com
Address: 67.228.254.4


softlayer.com MX preference = 20, mail exchanger = mx02.softlayer.com
softlayer.com MX preference = 30, mail exchanger = mx03.softlayer.com
softlayer.com MX preference = 10, mail exchanger = mx01.softlayer.com
softlayer.com nameserver = ns2.softlayer.net
softlayer.com nameserver = ns1.softlayer.net

 


This is a slightly different query. Rather than asking my local resolver to do an A record query for www.softlayer.com I've sent an MX (mail exchanger) query for softlayer.com directly to the nameserver ns1.softlayer.com. Notice that the response does not have the non-authoritative tag. The server ns1.softlayer.com is one of the nameservers which is configured to respond with a definite answer to a question rather than just saying "well, this other guy said...".

One thing that both of these queries fail to do is show the TTL for the answer they give. Time to Live (TTL) is what generally controls how long a resolver will keep an answer in cache. While the TTL is valid the resolver will use that answer. Once the TTL expires, the resolver goes looking for a fresh answer. This is great for performance but it does have a dark side to it: because of TTL, changes to DNS records are not seen instantly by all clients. If ClientA hits your website often his resolver is going to have the query result cached (say www.domain.com -> 1.2.3.4). You change the record to www.domain.com -> 5.6.7.8 but ClientA's resolver is going to continue to respond with 1.2.3.4 until the TTL runs out. If ClientA controls their resolver they can flush its cache. Generally though it is controlled by their ISP and you just have to wait.

To see the TTL for an answer you can use the nslookup form below:



C:\>nslookup
Default Server: mydns.local
Address: 192.168.5.1

 


> set debug
> www.softlayer.com.
Server: mydns.local
Address: 192.168.5.1


------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 2, additional = 0


QUESTIONS:
www.softlayer.com, type = A, class = IN
ANSWERS:
-> www.softlayer.com
internet address = 66.228.118.51
ttl = 86400 (1 day)
AUTHORITY RECORDS:
-> softlayer.com
nameserver = ns1.softlayer.net
ttl = 86400 (1 day)
-> softlayer.com
nameserver = ns2.softlayer.net
ttl = 86400 (1 day)


------------
Non-authoritative answer:
Name: www.softlayer.com
Address: 66.228.118.51


The key to this spew is 'set debug' which causes nslookup to display additional information about the response, including the TTL value of the answer. You'll notice that the TTL in the ANSWERS section is 86400 seconds, which is the number of seconds in one day. This is a common TTL value. If I run the query again though, I have the following answers section:



ANSWERS:
-> www.softlayer.com
internet address = 66.228.118.51
ttl = 85802 (23 hours 50 mins 2

 


Notice how the TTL is counting down. The resolver is going to continue responding with the answer 66.228.118.51 until that TTL hits zero. At zero, the resolver will go looking for a new answer. What this means for you as a domain operator is that if you know you're going to be changing a record you should adjust down the TTL for that record a couple of days in advance. For example when some friends and I moved our colo server from one provider to another we dropped the TTLs for our DNS records down to 30 minutes two days prior to the move. Once the move was complete we were able to put them back to prior values.

 

If you spend any time at all messing with DNS you should play around with nslookup.

If you're on a Unix system take a look at the command 'dig' as well.

Happy resolving.

August 25, 2008

Do You Know Where Your Nameserver Is?

Today we are getting back to the basics. Really simple stuff like how content gets served up on the internet. I'm going to keep things at a fairly high level, so don't flame me if I oversimplify things. I was trying to explain this to my Mom recently (Hi Mom!) and that inspired me to write this blog.

The first thing that has to happen is for the viewer to make a request by typing in a site name or clicking on a link in a web browser. That request usually has a text-based name as part of the request (like "www.softlayer.com"). Each name has a domain ("softlayer.com") and each domain has an authoritative nameserver to translate the name into a numerical address. That numerical address is used by the internet infrastructure to make sure the request gets to the right place. Phone numbers work the same way, so just think of an IP address (and domain name) serving the same purpose as a traditional phone number which defines the location of the “owner” of the number (at least in the landline world) based on country, region, and city.

If the nameserver for a name is slow or down, then the request will be delayed, or even worse, fail because the nameserver was not available to translate the name into an address. And if the translation fails, the viewer will not get the content he or she requested.

So, if you are running a website, you want your nameservers to be highly available and service the request as quickly as possible. Here is where I get to brag about SoftLayer a little. We provide nameserver service to our customers. Our customers can use our web portal or a sophisticated programming interface (the SoftLayer API) to manage the numerical addresses for their names. We have located nameservers at several locations and we keep the data synchronized between the sites. Our nameservers themselves have the same addresses using a technology called anycast (http://en.wikipedia.org/wiki/Anycast).

What all this means is that our customers get to have their name to number translation hosted at multiple sites. This results in faster translation times and in the case of a disaster at one site, the other nameservers will still be working.

In other words, SoftLayer has very cool nameservers.

-@nday91

June 26, 2007

TTL and propagation

Every DNS record is equipped with a TTL. The TTL (Time To Live) is basically the expiration date on that record. Long story short, it's a countdown from when it was initially received until when it is marked as invalid and discarded for a replacement record. This is a very important piece of information that I've run into often as being either outright ignored or misunderstood.

Let's say you have a domain-something awesome like awesomedomain.wow--and awesomedomain.wow has a TTL of 24 hours. When I go to visit awesomedomain.wow as a new visitor (and you know I would, because it sounds awesome) I'm going to receive a record translating awesomedomain.wow to an IP address that will be valid for 24 hours. Any other time I visit that domain in the next 24 hours, I'm going to use that cached address because the record hasn't expired yet. In 24 hours regardless of if awesomedomain.wow has moved IPs, I'm going to trash that old DNS record I've cached locally and go look it up again. The new record will then be referred to by me for the next 24 hours, at which time I'll do it all over again.

But what happens when you have to change your IP, but you want your visitors to see the smallest amount of downtime possible? My first suggestion is to mirror your sites on both IPs, but that is a different discussion entirely. The second is to manipulate your TTL. First lower it to something smaller-from a day to an hour perhaps. Then give that new record with that new TTL at least 24 hours to propagate. Now you can be certain that at the 25th hour, all of your visitors now have a record that will expire in one hour. Next, change your IP for awesomedomain.wow, the record that your visitors have cached locally will expire in an hour, and then they will have your new record with your new IP. Feel free to bump your TTL back up to what it was originally in this step, since they have the new IP. Now your visitors have only had an old record for an hour rather than 24, and they probably missed that hour it was inaccessible while they were posing for a painting or having their top hats heightened. Because all of your visitors are terribly classy.

-Joshua

Subscribe to dns