Last year I gave a talk at Ignite Boulder titled: “DNS in 5 Minutes”. I’ve been remiss in not sharing this, so here you go.

Click here to view the embedded video.

Remember, DNS can be fun too.

Thanks to the hard work of Florin T. Patrascu, DNSimple now has a brand new version for its iPhone app, and it’s awesome. With version 2.0 you can now register and transfer domains right in the app. It also possible to manage all of your various record types now as well and has a bunch of performance enhancements too.

Florin has worked really hard on this version of the iPhone app, and I think his hard work shows. Apply services, templates, change name servers, turn on and off whois privacy, manage contacts; there’s just so much to love about it.

One caveat: remove the old version of the app before installing 2.0.

If you have any questions please feel free to send us an email: support@dnsimple.com

Following up on the ALIAS record, I’m pleased to announce the general availability of a new virtual record type: the POOL record. The POOL record type lets you create multiple CNAME records on the same subdomain. On each request our authoritative name server will serve up one of the CNAME records randomly. Using our API you may add POOL records when they become available or remove them when the node they represent is not available.

The POOL record type was built to provide a simple mechanism for referencing nodes via CNAME records so service providers can control what hosts are available to respond to requests even though you might not control the A records for those nodes. For example, if you had one node on Amazon EC2 and another node on Rackspace’s Cloud then you could create two POOL records with the same name, one aliased to the EC2 node name and one aliased to the Rackspace node name. If either one of those nodes becomes unavailable you can remove its POOL record until it becomes available again.

At the moment we do not perform any monitoring of nodes: it is up to you to determine what constitutes a failed node if you want to remove its POOL record. Consider the current implementation a functional beta. Let us know if it is useful to you and how we might improve it. Your feedback is always appreciated.

Speaking of the ALIAS record…

We’re continuing to improve the reliability of the ALIAS record and reduce the lookup required when serving up an uncached ALIAS response. As of today we now have improved internal caching so if an upstream resolver fails to respond we can still provide a reasonable response to you. This should reduce the chance of the name server timing out and downstream resolvers caching negative results. We will continue to look for ways to enhance the performance of the ALIAS record, and as always if you have any issues with it please do let us know.

On April 10th we will be retiring the old IP address for ns4.dnsimple.com. We’ve already moved over all DNSimple customers who use ns4.dnsimple.com directly, as well as customers who use a vanity name server where the domain is registered through us. The only remaining name servers to be updated are vanity name servers that are managed by another registrar. If you manage a vanity name server and the domain is hosted at another registrar then you will receive an email today explaining the required change. Just in case you do not receive the email, here is the information you need:

• The new IPv4 address for ns4 is: 50.112.128.56
• The IPv6 address for ns4 is: 2001:470:1f0f:9e8::1:1

We want to make this transition as smooth as possible, so if you have any questions please feel free to contact us at support@dnsimple.com.

Late last year we introduced the ALIAS virtual record type at DNSimple. Since then we’ve had numerous people ask us how we implemented the functionality. While we are always making incremental changes, here is an overview of how it works:

When one of our authoritative name servers receives a request for an A record, CNAME record or the ANY type and there is a corresponding name with an ALIAS record, our name server will attempt to resolve the name found in the content part of the ALIAS record. For example, if the ALIAS points to proxy.herokuapp.com, then our authoritative server will resolve the name proxy.herokuapp.com and return its associated A records. If the name is a CNAME argon-stack-1879049447.us-east-1.elb.amazonaws.com record then our authoritative name servers will resolve the CNAME down to its A records. Ultimately we will always return A records in place of an A record, or a negative response if we cannot resolve the name.

Our authoritative name servers query local resolvers and will respect the TTL of the resulting records that it found. Thus if our authoritative name server resolves an ALIAS to an A record with a TTL of 60 seconds, we can cache the result for up to 60 seconds, reducing the response times for returning a successful result.  We also return the currently cached TTL from the resolver, which will always be less-than or equal to the TTL specified on the original A record.

Challenges

One of the biggest challenges is that resolvers may set their internal timeouts quite low, expecting a very fast response from authoritative name servers. Normally this is not a problem since the overhead of resolving the ALIAS name to its A records is usually fairly low. This is not *always* the case though, which is why we’ve spent time tweaking our own internal timeouts to improve the likelihood that we can return a result in a reasonable amount of time. It’s not perfect but we’ve got some more ideas on how to improve this even more.

Another challenge is that ALIAS records are currently not portable. There’s not much we can do about that at the moment, but in the future we plan on working with the DNS community to prepare an RFC that defines how the ALIAS record should behave. We believe that virtual records are an important part of DNS and thus an official RFC would be a useful addition to the existing DNS RFCs.

Ultimately our goal is to continue advancing the state of art for DNS and domains. We have more coming down the pipe and as always welcome ideas and feedback from you to help improve DNSimple and DNS in general.

Hey everyone Robert here. It’s been a while since we did a blog post and it isn’t because we’ve been lazy.

Anthony and Darrin have been doing an awesome job continuing to make DNSimple a solid and robust product as well as providing top notch support. Another huge thanks to everyone that chose to vote with their wallet on SOPA and become a DNSimple customer. We’re very happy to have you.

So speaking of not being lazy I’ve got a big update for you. Exciting times!

Announcing the DNSimple Community

Today we’re happy to announce the launch of the DNSimple Community site. We’ve set up this site to provide our next level of support and provide a place for all of us to discuss everything DNSimple.

On the site you can:

1. Connect with your fellow DNSimple users
2. Get all of your support questions answered in our support group
3. Browse the main how-to articles in the knowledge base (used by many of you all)
4. Discuss features
5. Discuss, trade notes on and ask questions about the API
6. And just talk about DNS in general

More groups are on the way and if you don’t see one that fits what you need definitely let us know.

Join The DNSimple Community Today

It takes just a minute to join so head on over to the community site and create a free account.

I’ll see you there.

Today all of our name servers experienced performance degradation that in turn caused customer sites to fail to resolve. This was especially evident to customers who are using our ALIAS record type.

The source of the issue was a malformed TXT record that ended up getting published out to the name servers. This malformed record in turn caused our DNS backends to churn as they would fail and restart. The reason that customers using ALIAS records were especially susceptible to this issue is because a.) they depend on the backends to resolve the ALIAS record in a timely fashion and b.) they tend to have low time-to-live values and therefore are cached for shorter times.

After fixing the malformed record and putting a fix in place so that the issue would not occur again we saw the performance return to normal. With the issue resolved we are now working on improving our notifications so that we become aware of performance degradations sooner to minimize the impact to our customers.

Please accept my apologies if you were affected by this issue. We will continue to work hard to minimize the likelihood of these types of issues in the future.

Transferring a domain from one registrar (like GoDaddy) to another (like DNSimple) can be a scary thing. You have domain names that you want to make sure stay operational during the transfer and you want to know that your domain will be safe. I’ve put together this blog post to help clarify how the transfer process works.

Here are a couple of things that you should know about before transferring a domain:

• When you transfer a domain the name servers for the domain will not be changed. This is a good thing if your domain is already hosted by a DNS provider that you use and trust. On the other hand, if you are using your registrar’s name servers (for example, if you use GoDaddy’s DNS) then you should switch to DNSimple’s name servers before you start your transfer because they will likely turn off your DNS records either during the transfer process or shortly after the transfer completes.
• Your domain must be more than 60 days old and cannot have been transferred within the last 60 days.
• Your domain must be unlocked before you start your domain transfer.
• Certain registrars such as GoDaddy require that you remove whois privacy protection before attempting to transfer a domain.
• For many domains you’ll need an authorization code from your current registrar and you have to submit with your domain.

When you start a domain transfer the first thing we do is look in the current Whois for the administrative contact email address associated with your domain. We also look for the registrant email address. If these two email addresses are different then each will receive an authorization email. This authorization email will come from info@transfer-approval.com and will include text explaining that a transfer has been requested. It will include a link that you must click on to continue the transfer process.

Once you’ve authorized the transfer request we will submit your transfer request to the registry for your domain. At this point the current registrar has 5 days to respond to the transfer request. During those 5 days they may approve the transfer, decline the transfer or do nothing. At the end of the 5 days if they’ve done nothing then the transfer will automatically complete.

Your current registrar may reject the transfer due to the following reasons:

• Evidence of fraud
• UDRP action
• Court order by a court of competent jurisdiction
• Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact
• No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into “Registrar Hold” status by the Registrar of Record prior to the denial of transfer.
• Express written objection to the transfer from the Transfer Contact. (e.g. – email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means)
• A domain name was already in “lock status” provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status.
• A domain name is in the first 60 days of an initial registration period.
• A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs).

When your transfer completes successfully the domain will automatically be extended the minimum allowed registration period, which is 1 year for most domains. Since the domain is extended you won’t lose time still left on your domain registration. The extension is included in the transfer fee for the domain. The domain will show up in your account as registered once we receive notification that the transfer is complete and we will bill your credit card for the amount of the transfer. You’ll also receive an email indicating that the transfer has completed. There may be a small period of time between when your transfer completes successfully and when it appears in your DNSimple account as registered where the domain may no longer appear in the losing registrar’s domain list. This is one reason why it’s a good idea to set up your DNS before you transfer if you plan on switching to DNSimple’s name servers.

If your transfer fails to complete for any reason we will not charge your card and you will receive an email indicating that the transfer has failed along with an explanation of why the transfer failed. Once you receive that email you may make any changes necessary to ensure that the transfer completes successfully (such as unlocking the domain, disabling privacy protection, etc.) and retry the transfer.

If you ever have any concerns before, during or after the transfer of a domain, we’re always here to help. Send an email to support@dnsimple.com with the domain name you are transferring and we’ll help you out. If you’re looking for specific details about how to transfer out of GoDaddy take a look at our post on that topic: http://blog.dnsimple.com/preparing-domains-godaddy-for-transfer-out/.

P.S. If you’re interested in the finer details of domain transfers then take a look at ICANN’s transfer policies: http://www.icann.org/en/transfers/policy-12jul04.htm.

GoDaddy’s statement before congress regarding SOPA was published yesterday and suffice to say that the negative response has been overwhelming. That’s exactly how it should be too. We at DNSimple oppose SOPA and any attempt by the US government to try to rule the Internet. DNSimple vehemently opposes any attempts to censor the Internet or to provide the facilities to do so. Unfortunately if SOPA passes there will be little that can be done to stop site takedowns in the US and blocking of sites outside the US. Even as it stands now, sites can be taken down by going after them at the root name servers, as the US government has done previously.

Trying to regulate the Internet on a country-by-country level is an ineffective policy, plain and simple. Giving too much power to entities that have clearly demonstrated the will to abuse it should not be allowed. If you don’t believe me, then how about reading through the letter sent to congress by 83 well-known and respected engineers who have all contributed massively to the Internet in one way or another.

If you are a US citizen, then write or call your congressperson and tell them that they should vote against SOPA. Call or write your senator while you’re at it and let them know how you feel. If you are not a US citizen then make sure your government knows that you oppose censorship of the Internet and that they should not follow the lead of the US in this case. And above all, do not support companies that support SOPA.

Keep the Internet free.

Anthony Eden

DNSimple Founder

PS. If you’re ready to say Goodbye to GoDaddy, we’ll transfer the domain at cost.

Most of the times DNS does what you expect it to do with little or no fuss (well, ok, sometimes with a little more fuss) but we strive to make DNS as easy as possible at DNSimple. Today I’d like to introduce a new record type that we’ve added to make pointing to dynamic hosting services a little less painful. This record is called an ALIAS record.

Dave Winer wrote up a good explanation for the ALIAS record:

 CNAMEs are wonderful. It would be great if everything could be a CNAME. Obviously some names have to point to IP addresses, or nothing would resolve.

DNS has a limit. The top level of a domain must be an A record, it cannot be a CNAME. For example, scripting.com cannot be a CNAME, it must be an IP address, because that’s what the value of A records are. IP addresses.

However if I use dnsimple.com, I could make the value of scripting.com an ALIAS record whose value is s3.amazonaws.com. Then, when a request comes in to lookup scripting.com, it looks up s3.amazonaws.com, gets an IP address and returns that. The caller doesn’t know or care how they got the address.

Thanks, Dave, for the excellent explanation.

Let’s take a look at an example using a site deployed on Heroku. Up until recently, if you used the DNSimple one-click service for Heroku we’ve added 3 A records pointing to Heroku’s servers. This works, however it isn’t the best set up because if Heroku ever changes one of their IP addresses, or adds a new address, then your service will start failing sporadically. Additionally, if Heroku needs to make temporary changes then your app may start failing while those changes are in place.

With the new ALIAS record, you can point your domain to a single host name (such as the proxy.heroku.com CNAME record) and we will return the IP addresses associated with that host name as if they were your own. Whenever proxy.heroku.com changes the A records returned for your domain will change along with it, without any need for your intervention.

This would also work for an Amazon Elastic Load Balancer or S3 host name. If you point your domain to one of those hosts with an ALIAS record it will return the current A records for that host and will update when the host updates, using the time-to-live specified by the host.

One might compare this to a CNAME, however there is a significant difference: a CNAME record must be the only record for a particular name. This means that you cannot use a CNAME for your second-level domain as it must include NS records and an SOA record. You *can* use an ALIAS record though as that will effectively be converted to A records behind the scenes by our name servers.

Note that if you are pointing a subdomain to another subdomain in the same domain (i.e. foo.example.com -> bar.example.com) then you should use a CNAME record.

We’re still working out some of the details of ALIAS records, but we do feel that they are a very useful addition to the records supported by DNSimple. Please feel free to contact us at support@dnsimple.com if you have any questions or issues with the ALIAS records, or any other questions about or domain and DNS services.