Frequently Asked Questions
If you have NearlyFreeSpeech.NET DNS for your domain, your authoritative name servers are the "official" name servers for that domain.
However, in order for these name servers to be used, you must take the list of authoritative name servers and make them active by entering them at your domain registrar (even if your domain is registered through us).
If you go to the DNS information panel and see both "Authoritative Name Servers" and "Active Name Servers" then you have NearlyFreeSpeech.NET DNS, but your domain registration points elsewhere.
If that's the case, you have two options to correct the problem:
This scenario most commonly arises when you transfer an existing domain name from another registrar without updating the name servers first. In that case, you just need to change them in our system once the transfer completes.
For maximum reliability it is always best to make sure that the active and authoritative name servers match. There are isolated reports of weird things happening if they don't, and some ccTLD registries (notably .DE) actually verify that they match before allowing changes.
First, when configuring third-party DNS, make sure that you have configured the names that you will be using for your site as aliases on the Site Information page. Otherwise, when the request gets to our network, our servers will have no idea what site you want and will return an "Unknown Site" error message.
The preferred way to set up third-party DNS is to create a CNAME record. This allows you to take full advantage of our load balancing and fault tolerance features to get the best performance and reliability for your site. If your site was named example and you wanted to use the domain name www.example.com then you would configure a CNAME record from www.example.com to example.nfshost.com.
However, you cannot use a CNAME record with a bare domain name (such as example.com without www. in front). All domain names have special records, called SOA records, which must exist. But CNAMEs must not coexist with any other records. So, if you attempt to point example.com to example.nfshost.com via a CNAME record, you will violate the DNS specification because the mandatory SOA record won't be there. This will cause all kinds of unpredictable and hard-to-diagnose problems with your domain.
In such cases (or if you just hate CNAME records) you can also use A and AAAA records with the IP address(es) for your site to set up third party DNS. They're at the bottom of the Site Information panel in the "Web Site Addresses" box.
The caveat with using A/AAAA records with third-party DNS is that you are then responsible to keep them up to date if they change. Fortunately, that's exceedingly rare, and in most cases the old IP will continue to work for several months. As long as you make a practice of checking on it from time to time (set a reminder!), it will typically be fine.
The major exception to "typically" relates to DDOS attacks. If there is a DDOS attack on a specific IP address, we may have to disable that IP address without warning and move affected sites to another one. If you're using our DNS, that's no problem. If you're using third-party DNS with CNAMEs, that's no problem. But if you're using third-party DNS and you're using manually-configured A records and the IP address you're using gets attacked and we have to block that IP to mitigate the attack, then you may experience downtime until you manually update your third-party DNS. Such circumstances are rare, but they do happen.
If you have NearlyFreeSpeech.NET DNS service, you may obtain your name server information from the DNS information page for your domain in our user interface. Just go to the Domains panel and, for the domain in question, under the "DNS" column, click "Manage." The name servers for your domain are listed in the "Authoritative Name Servers" box.
If you are using third party DNS, you must get the name server information from your DNS provider.
If you do not have NearlyFreeSpeech.NET DNS and you do not have DNS from a third party, you do not have name servers and will usually not be able to use domain names with your website, except through "masking" or "forwarding" offered by some domain registrars.
If you're registering a new ccTLD domain name with a third-party registrar and you're planning to use NearlyFreeSpeech.NET DNS, and you run into a situation where the registrar needs you to have valid name servers before you register the domain, send us an Assistance Request and we'll add the domain and activate DNS for you.
In order to add NearlyFreeSpeech.NET DNS to an existing website, follow these steps:
That's all there is to it!
If you've already registered your domain with a third-party registrar when you set up NearlyFreeSpeech.NET DNS, don't forget to update your list of name servers at your domain registrar with the name server information we provide for your domain.
No. When you create NearlyFreeSpeech.NET DNS for a site named www.example.com, your NearlyFreeSpeech.NET DNS is actually being set up for your registered domain, example.com. You may add as many subdomain names as you want to an existing NearlyFreeSpeech.NET DNS domain at no additional cost.
Multiple names can each point to a different site, all point to the same site, or any combination you need.
This is generally very straightforward.
(In order for this to work, you must first have set up NearlyFreeSpeech.NET DNS for your domain name. If that is not already done, start with this FAQ entry and then return here.)
Since each registrar has a slightly different way of editing name servers, you would need to contact them for specific help with using their system.
Once these steps are complete, you may have to wait awhile for the change to take effect. Changes in most top-level domains take less than 24 hours, and the major ones (.com, .net, and .org) often take effect within a few minutes.
If your domain registrar provides DNS service, you can also use that, although it is not recommended. Please see this FAQ entry for more information.
All you have to do is create another site from our member interface.
You may also add additional subdomains to a site you already have, by following the instructions in this related FAQ entry.
We do not use or support the scheme of placing subdomains in subdirectories of your existing site that is employed by some mass-market hosting control panel options.
Follow these steps:
The IPv4 (and IPv6, if enabled) addresses listed at the bottom of the Site Information page, under "Web Site IP Addresses," are used by our web servers. They are not alternate addresses for our name servers. They are provided for reference only and almost never need to be used e.g. from DNS records.
For more information about how those IP addresses work with our service, see this entry.
If you are trying to obtain DNS name server information, please read this entry.
SPF is the Sender Policy Framework, a way to use DNS to tell the world about the servers that can legitimately send email for your domain. It is an anti-spam tool that makes it a little easier to identify spam, and a little harder for spammers to hide.
We've noticed that many of our members register more domains than they need for email purposes. For example, someone whose domain is example.com may also register example.net or other similar domain names to prevent competitors from creating similarly-named sites. But they only use their primary domain for email.
Our "SPF Email Protection" feature is an easy, automatic SPF record that will tell the world that your domain isn't used for email. That will help foil spammers who might otherwise forge email from that domain, as described in this FAQ entry. That means that spammers have one less place to hide, and also that you won't get their bounce messages.
Our standard offering is designed to be easy to use for this common case. If you need more specific settings for SPF, you can create your own custom TXT record for your domain containing any SPF code you want. The specific code you need depends on the server you use to send (not receive) email, which is usually your ISP's mail server.
To find out what SPF code you should use, or to learn more about SPF and how it can help you, check out the SPF home page.
SPF isn't suitable for all cases. For example, it doesn't work well if your domain sends email from a number of different or frequently changing places. But where it is suitable, it both helps you a little bit, and it's a way to be a "good netizen" to your Internet neighbors by making spamming just a little bit harder.
Anyone who wants to send mail from their domain from our servers and wants an SPF record for it should refer to this FAQ entry instead.
These instructions assume you have turned on our DNS and that your domain name registration has our name servers listed. To turn DNS on for a new domain, see this FAQ entry; to turn it on for a domain you've newly registered with or transferred to us (that wasn't already using our DNS), see this one.
To add new resource records:
To remove existing resource records:
NOTE: If you want to remove a record that is related to an alias for a site hosted here, you will not see a "Remove" button. This means the related alias must be removed from your site to remove the DNS record. See this related FAQ entry for more information.
See this FAQ entry.
No, we do not presently support wildcard DNS; adding support for wildcard aliases would slow down everybody, even people who weren't using them.
If you run into this, it is most likely a CNAME or A record that was automatically created by our system when you added a corresponding alias to one of your sites because you wanted our system to know that a certain hostname (such as www.example.com) should be used with that site.
If this is your situation, the record in question will appear in the "NearlyFreeSpeech.NET Resource Records " box on the DNS information panel for your domain and will typically look similar to:
www.example.com CNAME example.nfshost.com.
example.com A 10.11.12.13
If you want to remove a DNS record associated with a site alias, like a CNAME record pointing to an .nfshost.com name, visit the Sites panel and select the relevant site's short name. The Site Information panel will list the aliases and provide "Remove" buttons in the "Site Names & Aliases" box. Removing the alias will automatically delete any related records from your DNS.
Probably not. There is a chance that they will be the same, but they are chosen randomly from available name servers so that chance is very small.
Yes, manual setup of your DNS on a geographically and administratively independent secondary name server is available on a per-domain basis as an Assistance Request.
This service is set up manually on purpose. It would be relatively straightforward (if somewhat failure prone) to set it up automatically, but doing so would create a dependency relationship between the offsite name server and the primary one. That doesn't completely eliminate the reliability benefits of having a geographically diverse name server, but it does greatly diminish them, so we don't do it that way. Our goal is for our secondary DNS to be as close as we can make it to having secondary DNS from a completely separate provider.
There are a couple of ways to do this.
First, it can be done through our API, which does allow the dynamic modification of DNS records. This approach can be a bit convoluted, but many smart people have written and released scripts and libraries to help streamline the process. Searching the web for "NearlyFreeSpeech.NET dynamic dns" should produce a variety of options.
The second approach is to set up a name for your home machine with a dynamic DNS provider like No-IP.com (which offers a free service), or Dyn. In the case of No-IP.com, they will give you a name like your-name.noip.com and you can load a widget on your home computer or Internet router to keep the address up to date. Then, from our end, add a DNS record for the name you want that is a CNAME to the name they gave you; i.e. if you want www.example.com to point to your home machine, and they gave you example.no-ip.com, you would add a CNAME DNS record here in your example.com domain with a name of "www" and a data value of "example.no-ip.com." including the trailing dot.
We are strongly yes-www. (There used to be a site in favor of no-www, but it went away. I guess yes-www is winning.)
Using URLs with bare domains (like https://example.com/) creates a number of problems, and we strongly recommend that you avoid it for anything other than redirecting to the real web site (like www.example.com).
Some of the limitations are:
Despite the drawbacks, this is something that visitors to your site expect to work and we know that.
The best compromise is to redirect visitors from example.com to your www.example.com alias. To do that, add both www.example.com and example.com as aliases to your site and (unless you are using WordPress) enable the hard canonical type setting. If you are using WordPress, it will manage your host names automatically, and you should set the site's canonical type to off (the default).
There are, of course, exceptions; this is more of a guideline than an actual rule. It may make sense to forego the www for a business website if the web site is the business. Sites with very short names are also perpetually trendy, and knocking "www." off the front in service of shortness is definitely one way to chase that trend.
If you're sure you're an exception, apply these recommendations in reverse to direct visitors from www.example.com to example.com.