What DNS services do you provide?

We currently offer primary DNS services for domains employing a redundant, distributed network of name servers located on 7 geographically distinct networks across North America and Europe.

What are DNS credits?

When you are entitled to one year DNS service for one domain with us, we give you a total of 366 credits, corresponding to one credit for each day of the year. Each DNS domain you host with us will consume one credit per day. Additionally, if you activate Web Forwarding for your domain, this feature will consume an additional credit per day.

By using a credit system, you have the flexibility to add/remove domains and features from our system, and only need to renew your subscription when your credits run low.

What is validation?

Validation is the act of verifying that data you have entered into the DNS system is legitimate. This lets you know if the changes you make are valid and will function on our DNS servers. If errors are detected, you have the opportunity to correct the errors before they impact your existing, functioning configuration.

WARNING: If you make changes to a functioning DNS configuration that results in a validation error, CORRECT THE CHANGES. While the default handling of our DNS system will provide limited protection to your old configuration, if we ever have to reload a server with a complete new configuration for any reason, any domains that are not validated will not be downloaded to the new configuration. Complete reloads are rare, but may happen as we upgrade software, bring new servers on-line, etc.

Validation reports an authoritative name server error?

The domain name system operates by having root servers know the location of the official, or authoritative name servers for each domain. Typically your registrar or ISP will set these up for you, and they will usually point to the registrar or ISP's name servers. When you decide to configure your domain on our name servers, you need to tell the root servers that the name servers responsible for handling DNS queries for your domain are the SecuritySpace name servers. When you do this, you should use a minimum of 3 name servers, and can use all 4 listed below.

• ns1.securityspace.net (Dallas, TX USA)
• ns2.securityspace.net (Washington DC, USA)
• ns3.securityspace.net (Miami, FL USA)
• ns4.securityspace.net (Vienna, Austria)

My registrar requires the IP addresses of your name servers.

Actually, they shouldn't - the information is at best useless, at worst dangerous. You should only have to supply the names of our servers as listed above (ns1-4.securityspace.net). In fact, given how the root servers operate, any IP address information for our name servers that you supply along with your domain to your registrar will remain unused by the root name servers.

There are some unique circumstances where something known as "Glue" records are required, and happens when the name servers for a domain are in the domain itself. Because of this situation, some registrars incorrectly require you to ALWAYS submit the IP address information along with the qualified name of the name server.

Why is it bad to supply the IP address? Because IP addresses may change over time. If we move one of our servers' IP address, and you are referencing the name, there is no impact to you. The DNS system will simply pick up the location of the new server. If, however, you use the IP address directly, you may suddenly find that the server in question is no longer handling queries for you.

What is DNS load balancing?

DNS load balancing is when you have, for example, multiple web servers serving the same content (for redundancy), and you want the load to be evenly distributed among these servers, and you do so by using DNS servers to serve out different IP addresses to different clients, thereby distributing the load across your different servers.

To accomplish this using DNS, one technique (and the only one we support) is to define multiple A (IP address) records using the same name (e.g. www.yourdomain.com), each with a different IP. Then, when queries are issued for your domain, the complete list of records is returned with the order changing each time. Most clients will always try the FIRST IP address returned, and will fail-over to others if the first is unavailable.

Do you support CNAME based load balancing?

No. CNAME based load balancing, where multiple records are defined using the same Name (alias) but different canonical names was supported in BIND 8, but is no longer supported in BIND 9. If you must use DNS based load balancing, you will need use the multiple A record technique for accomplishing this.

Do you support IPv6?

Yes. IPv6 support is available via AAAA records. These are added to our interface in the same fashion that A records are added.

Do you support PTR records?

Yes. We provide full support for both complete zone files, as well as what is known as Classless delegation. Classless delegation is one technique that can be used when your ISP allocates to you a subset of a /24 address range, but you still would like to control reverse DNS lookups.

When you participate in a Classless delegation, the ISP will provide you with the domain name to use. For example, if you wish to handle PTR records for the IP addresses 172.16.1.0 up to 172.16.1.7, the ISP might assign to you the domain name 0/28.1.16.172.in-addr.arpa (they might replace the '/' with a hypen, or use another arbitrary name altogether.) You would then add the above domain to our system, and then add PTR records for the octets 0,1,2...7, and assign the host name for each.

The full details on how Class delegation works works can be found in RFC 2317.

Do you support wildcard records?

Yes. You may specify one wildcard A record per domain, which will be the default resolution used if no other A records match the query for your domain. When you specify a wildcard record, the IP address associated with it is returned only if a DNS query is issued that doesn't match any other A records you already have defined for the domain.

Do you support SPF?

Yes. Sender Policy Framework, or SPF, is implemented via TXT records in a zone. We support creation and editting of TXT records. Simply specify your spf string within a TXT record as you normally would, and then validate & activate your changes.

Do you support CAA (Certificate Authority Authorization)?

Yes. For a brief description of how this works, we recommend starting with the Wikipedia page describing these records. The tags currently supported (and all that are available) are "issue", "issuewild", and "iodef".

Do you support Dynamic DNS?

Yes. We allow you to update your IP address as it may change from time to time using a simple one line URL request. Documentation for supported clients and the Dynamic DNS update protocol is available on-line.

Can I configure you to be a slave server?

Yes. We support both Master and Slave zones. When adding a domain into our system, you decide at the time you add it whether or not you want our name server network to act as Master or Slave for your domain.

When configuring a Master domain, all of our name servers will be acting as a Master server. When configured a Slave domain, all of our name servers will act as a slave server.

What is the difference between Master/Slave and Primary/Secondary?

Good question! Most people equate Master with Primary and Secondary with Slave. In reality, the two are not quite the same. Primary name servers are the default name server (the first server that will be queried) based on how you have configured your domain's NS records with your registrar. Secondary name servers are the backup if the primary name server fails.

Master and slaves refer to a management arrangement used within DNS servers to propagate information changes from one server to another. Masters are the holders of the authoritative information, who in turn arrange to pass this information off to slaves. Often a Master server is the Primary, and slave servers are the secondary, but this need not be the case!

When you configure a master zone with us, all of our name servers will operate as a master name server. If you configure a slave zone with us, all of our name servers will act as a slave to your specified master name server.

What is Web Forwarding?

Web forwarding allows you to forward, or "redirect", a web request to your domain to another URL of your choosing. This URL might be located on another ISP, free web space provider, or an IP address-port combination. When you setup web forwarding, all requests for a given host will be sent to the URL you specify. You may, if you choose, set up multiple hosts, each going to a different URL. For example,

   www.yourdomain.com     -> http://freespace.geocities.com/yourname/index.html
   yahoo.yourdomain.com   -> http://www.yahoo.com
   private.yourdomain.com -> http://192.168.1.1:8000/login.html

Each domain is limited to a maximum of 100 Web Forwarding records.