G Suite DNSSEC signed MX records

G Suite (formally known as Google Apps) is a collection of Google services including Gmail with custom domains, all available through a single user account. G Suite’s default MX records (aspmx.l.google.com, and alt<1-4>.aspmx.l.google.com) are not DNSSEC signed. For users wanting DNSSEC signed G Suite MX records, Google has made such available.

DNSSEC is a security extension to the DNS protocol making it possible to sign DNS data with a digital signature using the public key cryptography approach. DNSSEC makes it possible to 1) Verify that DNS data actually is received from the expected origin zone. 2) Know that no modification of DNS data occurred during transit. More detailed information about DNSSEC is available at the Wikipedia page.

You can use a tool such as Verisign’s DNSSEC Analyzer to check the DNSSEC settings of a given hostname.

G Suite DNSSEC signed MX records:


The DNSSEC signed MX records answers to both IPv4 and IPv6 requests.

As a side note, despite that these MX records are made available by Google, they are not officially supported or documented. They could change, go offline, or somehow get unreliable at some point. I doubt this will happen anytime soon. In the past, Google has kept crucial legacy hostnames online, and some major web services are using these MX records.

BuyShared has switched to MailChannels for outgoing mails

E-Mail box

Recently my web hosting provider BuyShared (also known as BuyVM and Frantech) started using the SMTP provider MailChannels for outgoing e-mails. This is a neat feature that increases mail deliverability. Before switching to MailChannels, BuyShared routed outgoing mail through a local SMTP server. Due to more advanced and strict spam filters and policies by most major e-mail providers, including the world’s largest provides Gmail, Outlook, and Yahoo! Mail, sending e-mail directly from a shared web hosting account is not recommended. The chances of genuine mail ending up falsely marked as spam is at a level making this approach unreliable.

BuyShared added MailChannels “silently” meaning that no announcement was made, and the fact that they now use MailChannels is not even included on their website as of this writing. As a result, I, and probably many other BuyShared customers were (and still are) unaware about this change. The good news is that no reconfiguration of mail software is needed. Users should continue sending mail through BuyShared as usual since BuyShared takes care of routing outgoing mail through MailChannels.

Changing SMTP provider means that the Sender Policy Framework (SPF) should be changed for all domains sending mail through BuyShared. An SPF policy is added as a DNS (TXT) record and provides information about what IP addresses are allowed to delivery e-mails for a given domain. Having a correct SPF policy in place for a domain is essential for mail deliverability. While mail is not automatically rejected from domains without an SPF record, it is a crucial factor. More detailed information about SPF is available at the Wikipedia page.

MailChannels suggests using the following SPF TXT DNS record:

example.com TXT v=spf1 a mx include:relay.mailchannels.net ?all

This policy allows mail from the IP hosting the domain, the IP of the MX record of the domain, and MailChannels IP addresses. The “?all” means that mail sent from other IP’s should be marked as neutral.

I use a more strict SPF record:

example.org TXT v=spf1 include:relay.mailchannels.net -all

This policy only allows mail from MailChannels’ IP addresses and states that mail coming from any other IP should be considered non-genuine and fail.

If you want to add the MailChannels IP space to your existing SPF record you simply need to add include:relay.mailchannels.net to your existing policy.

After adding/editing your SPF record you can verify the changes using a tool such as MXToolBox SPF Records. Notice that changes to DNS records can vary from just a few minutes to several hours before they are propagated to the rest of the Internet.

How to add an SPF record depends on the DNS server used by your domain. If you are using the default BuyShared DNS servers (ns1-4.private-nameserver.net), you can add an SPF record through the “Zone Editor” in Cpanel.

BunnyCDN review

BunnyCDN (affiliate link) is a low-cost unmanaged content delivery network (CDN) service. Setting up the service and implementing the CDN into your website is an easy procedure, especially if you already understand the basics of a CDN.  BunnyCDN is one of the cheapest available CDN providers charging $0.01/GB for US and European traffic, and $0.03/GB for Asian and Oceanian traffic. In comparison a similar package from KeyCDN is priced at $0.04/GB and MaxCDN charge about $0.08/GB (and minimum $9/month.)

I recently signed up for a 14 days free trial period to evaluate BunnyCDN and this review reflect my first impression after using their CDN for a couple of weeks.

What is a CDN and why use one?

In essence, a CDN is about efficiently distributing content. A CDN is consisting of servers globally distributed at essential locations such as major internet traffic points and cities. Each server in the CDN will contain a cache of certain files and will serve the content to the visitors through the fastest possible route. A CDN is mainly used to host static content such as images, CSS and JS files, videos for download and streaming, and other files for download. Three majors points of using a CDN is to increase download speed for the visitors, have redundancy in case a server is down or overloaded, and to lower the load on the server hosting your website. A relative simple CDN such as BunnyCDN does not host dynamic content such as databases and server-side scripts. More advanced (and considerably more expensive) CDN providers can also host dynamic content, but this will increase complexity of the setup considerable, and will be an overkill for most websites. It is also important to note that a CDN is not an alternative backup solution. Generally, content is shared with a CDN through either a pull or a push zone. A pull zone connects to your server and download the static content to the CDN when the content is requested. This is the easiest option to setup and maintain. In a push zone setup, you upload the files directly to the CDN and do not need a local copy. This option requires more time to setup and maintain in comparison to a pull zone and also more expensive since you have to pay a storage fee for having the CDN hosting your files.

Is a CDN a must for all websites? absolutely not. This blog uses a CDN to serve most static content, but it does not really require a CDN. The amount of visitors could easily be handled by the shared server hosting the blog. The speed would be a bit slower without the use of a CDN, but this will hardly be noticeable for the majority of the visitors. The content of the specific website and the amount of daily visitors are two crucial factors when deciding to offload traffic to a CDN or not. Sites without many images, downloadable files e.g. PDF, PPT, DOC, video etc. will not benefit much from a CDN, but frequently updated blogs with a steady amount of visitors, ecommerce sites, and archives of PDF files are good examples of sites that will benefit.


BunnyCDN provides many features, so I will just point out a few essential ones:

  • Multiple pull and push (currently in beta) zones.
  • Custom CNAME hostnames (setting up a custom CNAME hostname is recommended because 1) you have more control, for example, you can assign your own SSL to the hostname, 2) in case you decide to shift to a different CDN provider the transition will be easier, and 3) it looks more professional, and trustworthy.)
  • SSL support (you can use your own or get a free one from BunnyCDN.)
  • Blocking of countries, individual IP’s, and entire IP ranges (blocking happens at DNS level.)
  • Redirection of visitors from specific countries and regions (to save bandwidth costs it’s possible to redirect visitors to the closest cheapest possible datacenter. For example, you can redirect all traffic from Asia to US or EU servers to use cheaper bandwidth.)
  • All locations support both IPv4 and IPv6.
  • Option to purge the entire cache at once or just individual files.
  • No restrictions on file extension and size.
  • Hotlinking protection and URL authentication.
  • API access.
  • Basic statistics including real-time log monitoring.
  • Monthly traffic limit (avoid unexpected bills.)

The full list of feature can be found here: https://bunnycdn.com/features/


As of this writing, BunnyCDN has 13 points of presence (PoP) aka. they have edge servers caching content in 13 different datacenters around the globe including data centers in Europe, The United States, and Asia & Oceania. A South American presence is planned, but not in operation yet, and it has still not been disclosed where the South American PoP will be located. Below is a list of current locations:

United States:

  • New York City, NY
  • Los Angeles, CA
  • Kansas City, MO
  • Dallas, TX
  • Atlanta, GA
  • Seattle, WA


  • Paris, France
  • London, United Kingdom
  • Falkenstein, Germany
  • Bucharest, Romania

Asia & Oceania

  • Tokyo, Japan
  • Singapore
  • Sydney, Australia

User interface

The BunnyCDN user interface is very simple and fast to learn. It took me a couple of minutes to setup a new pull zone and under an hour to be more or less “fluent” in the entire interface and the functionalities provided. I believe beginners with basic knowledge about website development will be able to setup a pull or push zone and understand the basics within an hour or two. Some or the more advanced options such as SSL and advanced security settings will take a bit longer. The dashboard loads fast and smooth (since BunnyCDN is a CDN provider anything else would be strange). Everything is kept in a simple yet stylish manner and follows the standards of typical dashboard design.

Basic statistics about bandwidth usage, file requests, and cache hit rate is provided along real-time log monitoring. I am missing statistics about individual files, especially something like a top 25 list of most downloaded and most bandwidth consuming files. It would be very helpful to get an idea of what takes up bandwidth if you are just curious or want to optimize files. To get a more detailed understanding of the traffic, you will need to measure through other means.

Main page of the dashboard showing an overview of the account.

For each pull zone it’s possible to edit different parameters such as cache, security, and traffic settings.

Overview and settings of a push zone.


BunnyCDN charge on a monthly basis for actual traffic used (per-byte billing accuracy) with no monthly minimum. While there are no monthly minimum payments, there is a yearly minimum of 5$. BunnyCDN accepts major credit cards and BitCoin, but unfortunately not PayPal. The pricing structure is simple and transparent as they provide one plan. Due to differences in bandwidth prices around the world, they charge according to the following scheme:

  • US and Europe: $0.010/GB
  •  Asia & Oceania: $0.030/GB
  • South America: unknown at the moment.

For storage used by push zones, they charge $0.02/GB per month (Currently, it seems that they do not charge for storage as this feature is in beta.)

Pricewise BunnyCDN is at the absolute bottom when comparing with similar CDN providers, as mentioned, a similar package from KeyCDN is priced at $0.04/GB, and MaxCDN charges about $0.8/GB.

It is possible to save bandwidth costs by redirect visitors to the closest cheapest possible data center. For example, you can choose only to serve traffic from US and European locations no matter where the visitor is located. This redirection sort of conflicts with the philosophy of using a CDN, but can help cut costs if needed and will in many cases still result in increased speed in comparison to not using a CDN at all.

According to a small nonsystematic evaluation, the statistics about bandwidth usage looks like to be pretty precise and matches well when comparing with my own calculations of expected bandwidth usage.


While I have not conducted a systematic evaluation of the download speed from BunnyCDN, I have tested the speed by downloading large files from different locations in the US and Europe and tested over several days. Overall the speed has been very satisfying. I have typical been able to download at 30MB/sec equivalent to about 240 Mbit/sec and have reached 90 MB/sec equivalent to about 720 Mbit/sec.

If you want to make your own simple speed test of BunnyCDN, you can download the official 100MB test file: http://test.b-cdn.net/100mb.bin

Uploading files to a push zone is also lightning fast. I was able to upload with 6MB/sec equivalent to about 48 Mbit/sec which is pretty good for the internet connection I was using.

As mentioned BunnyCDN offers a 14 days free trial period, so you will be able to do a more comprehensive evaluation to see if BunnyCDN meets your expectations and works for your specific needs.


An essential aspect of a CDN is that your content is cached at the different locations, so files actually are served through the CDN. The cache hit rate (aka. the amount of file requests served through the CDN) is currently about 60% which is on the lower site. Since I only recently started using BunnyCDN I suspect that the low hit rate simply means that the caching process is still in progress. I expect this to increase to about 80-90% during the coming days. Content is only cached at a given location if someone actually request content from that location.


BunnyCDN only provides support through e-mail. I have not needed support so far, but according to other customers, support requests are handled within a day. The number of tutorials and documentation provided by BunnyCDN is relatively limited at this point. Therefore users of BunnyCDN should be able and willing to do must stuff on their own, but through learning by doing most users should be able to get things to work.


In conclusion, I find BunnyCDN to be an interesting low-cost CDN option for private users and small businesses with basic feature requirements and limited budgets. Of positive aspects, I would point out the simplicity of the interface and API, the speed and network, and the low cost and the transparency of the pricing structure. It’s easy to get both a pull and push zone up and running, and the caching of files seems to be done quite quickly as within a few minutes. Of disadvantages I find the statistics to be limited, and I would like statistics about individual files. They only provide e-mail support and no uptime guarantee, there is no DDOS protection in place, and the documentation is limited at this point. The service is still under development so expect minor “blips” such as links not working, sections partially under development, and missing and outdated information around the website.

Ready to try out BunnyCDN? then click here (affiliate link) and get your 14 days free trail (no payment information required.)

Fighting spam with fake MX records

No junk mailSpam is a well known problem to all users of the Internet, especially technical administrators of Internet services. I own several domain names for different purposes. Some are used for websites, some are used for e-mail, some are used for both, some are used for infrastructure (e.g. mapping easy to remember hostnames to IP addresses), and some are just sitting for future use. Most of my domains are not used for receiving e-mail. However, spammers don’t care and will still send spam mails to these domains. Even without Mail eXchange (MX) records a domain is still not safe as many e-mail servers will instead tryout the A record of the domain. With several domains not used for e-mail, this can at times be annoying to manage and causes extra server load.

To minimize the problem, using fake MX records, known as ‘nolisting‘ has been proposed as a trick to reduce spam.

I’m currently using a free service offered by Junk Email Filter Inc. They are running Project Tar (formerly known as Project Tarbaby), essentially a cluster of fake MX servers. The project has two goals: 1) to help reduce incoming spam, and 2) to support the ongoing work of maintaining the Junk Email Filter blacklist of known spam sources.

The service is very simple to setup and use. Simply add the following hostname as the only MX record of the given domain:


You can set any value as the priority, for example, 10.

Every time a mail is received the system will respond with the code 550, which means that the message was not deliverable. Genuine senders will receive a reply with an error message and know that a given address is not available, and spam bots will move on and get registered in the blacklist.

Another free service is Fake MX. Add the following hostname as the MX record of the given domain:


Set any value as the priority, for example, 10. If you use more than one MX record, set the Fake MX record with a higher priority than the primary MX record. Also remember to read their terms of use before adding their mail server.

Using fake MX records is no ultimate solution to avoid all spam from getting in touch with your severs, but anecdotical experiences reported from different forums indicate that fake MX records significantly reduces spam.

More information about using fake MX records can be found at “Nolisting: Poor Man’s Greylisting” and “Other Trick For Blocking Spam.

As it is the case with most tricks also the nolisting strategy has some drawbacks. Especially if using a fake MX setup on a domain intended for receiving e-mail. Some of the drawbacks can be found at the Wikipedia page ‘Nolisting‘.

10 best free DNS providers

Domain name system (DNS) (also sometimes referred to as domain name service or domain name servers) is an essential part of not only what makes the World Wide Web work, but most parts of the Internet. In essence, DNS is used to translate hostnames into actual IP addresses, routing mail to the right servers, etc. As fast and reliable DNS is quite essential I have here compiled a list of 10 free DNS providers that have proved to offer stable, fast and interesting DNS free of charge. Most the following providers will be able to compete with DNS provided by hosting providers and paid services. Actually, some of the providers listed below are among the most popular DNS providers also offering a limited free plan of their paid plans. You can get more information about the performance of most major DNS providers at DNSPerf.

Please post comments with your experiences with free DNS providers, corrections, and questions.

The following list is in no particular order as it ‘s hard to rank the free DNS providers from best to worst because they provide different types of DNS service. For example, Hurricane Electric (HE.net) provides a stable, fast, and no limits service, but have a simple interface with limited features making it bothersome if you manage several domains and need to make frequent updates. Other free DNS providers offer more features but have different types of limitations, so the best provider depends on your specific needs.

Hurricane Electric (HE.net)

Hurricane Electric is a top class free DNS provider that both can be used for hobby and production domains. They are limited to 50 domains. They provide both primary and secondary DNS. They have a globally distributed network providing fast response time in most parts of the world. The interface is very simplistic and requires a bit of learning.

DNSPref Hurricane Electric (HE.net) performance chart


The well-known proxy and CDN provider CloudFlare is also offering free DNS on a solid anycast network. On special feature is CloudFlares IPv6 Gateway included in the free plan. In case your server only can be accessed through IPv6 CloudFlare provides a gateway and makes your server accessible through IPv4 as well. This does have some limitations in relation to actually having a dedicated static IPv4, but for serving web pages, etc. this will fit common needs. Besides regular DNS service, it’s also possible to add a line of additional services such as proxy, caching of some static files, DNSSEC, and SSL. They offer service for unlimited domains.

DNSPref CloudFlare performance chart


NS1 is one of the major DNS players and is used by some of the largest Internet companies. They are limited to a single domain. Notice that the free plan is called “free trial”, but seems to be an unlimited trial as long as the number of records and query limitation are not passed.

DNSPref NS1 performance chart


A professional DNS provider offering a free limited plan of the paid plans. They are limited to three domains.

DNSPref ClouDNS performance chart


1984 Hosting Company provides free primary and secondary DNS. Besides normal DNS records they also support web redirects. As indicated by the name they focus on protection of freedom and civil rights.

FreeDNS (Afraid.org)

Well established and known for providing a high-quality DNS product. They offer unlimited domains. A nice feature is that if you use FreeDNS for primary DNS, they allow users to add additional external secondary name severs. Part of the idea behind FreeDNS is to allow people with no domain to create a free subdomain of domains using primary DNS from FreeDNS (it is possible to pay a fee to avoid this). While the idea of sharing is a good and useful it will also be a major concern for many domain owners as they partly lose control of how their domain is used and exposed. This is the main reason why I not personally use FreeDNS for primary DNS for any of my domains.

DNSPref FreeDNS (Afraid) performance chart


GeoScaling is a relatively new DNS provider. What makes them interesting is that they are offering what they call smart subdomains. Whenever a user is requesting a smart subdomain, it’s possible to get a different kind of information, for example, the country of the user so the request can be redirected to the nearest server of the country. They offer up to 1 million DNS requests per month.


Namecheap is best known as a popular domain registrar. What is less known is that they also offer free DNS for domains registered at any registrar and not just at Namecheap. They offer unlimited domains.

DNSPref Namecheap performance chart


DNS4.pro is offering an easy to setup and use DNS solution on an anycast network with nodes in North America, Europe, and Asia. They are limited to five domains.


Zonomi provides free DNS hosting for a single domain. They allow up to 10 records, and 1 million queries per month. This is quite limited, but will work for users will limited requirements such as a personal domain etc. Their DNS servers are distributed in the US and Europe, but they do not provide anycast. On the positive side, they also offer secondary DNS if you need additional name servers for your domain.

Free secondary (slave) DNS

Need free secondary (slave) domain name servers (DNS)? Luckily there are several stable providers offering this. The following list contains only providers that have proven stability and commitment. The list is based on my own experiences and by going through reviews of the services. Information about the performance of most of the listed providers can be found at DNSPerf, a service monitoring most major DNS providers’ response time and uptime.

Please post your experiences, corrections, and suggestions for free DNS providers currently not included on the list.

Hurricane Electric

Hurricane Electric (HE.net) provides both primary and secondary DNS. DNS is served on a stable and fast anycast network served through their global infrastructure.

Some pros are:

  • Stable and fast anycast network.
  • Rated as one of the fastest DNS networks in the world.
  • A long term player.
  • Low track record of downtime.
  • Offers both primary and secondary DNS.
  • Unmetered DNS queries.
  • Responds to both IPv4 and IPv6 DNS requests.
  • Supports “notify”.
  • Supports “stealth master.”
  • Support included.

Some cons are:

  • Limit of 50 domains (zones), and 10.000 records per domain. For personal users and small businesses, this should be more than enough.
  • No DNSSEC support.
  • The interface is quite technical and not user-friendly.
  • Changing primary name server, switching a from secondary DNS to primary, or vice verse means that the domains need to be deleted and added again. With more than a few domains this is a hassle.

I have used HE.net DNS for secondary DNS during the last six months and have a good impression. I have not noticed any downtime, and the servers are providing fast DNS responses. I highly recommend HE.net DNS for both primary and secondary DNS. Their free product will even out beat several paid DNS products. The main disadvantages are the user interface and the missing DNSSEC support.

Website: https://dns.he.net


BuddyNS is a secondary DNS provider only. They offer both paid and free plans. They allow an unlimited amount of domains, however, on the free plan all DNS requests for all domains must not exceed 300.000 queries per month.

Some pros are:

  • A long term player.
  • Fast synchronization (0-10 minutes).
  • Unlimited zones (aka. domains) and records.
  • Name servers located around the world (however, no anycast network).
  • Responds to both IPv4 and IPv6 DNS requests.
  • Supports “notify”.
  • Supports “stealth master.”
  • Support is provided (deferred 24 hours, but still offered).

Some cons are:

  • No anycast network.
  • Limit of 300.000 queries/month total traffic (per-account).
  • No DNSSEC support.
  • Only offering secondary DNS.

BuddyNS seems to provide a very stable and professional DNS solution. I have no personal experience, but they have received decent reviews. They will cover DNS needs for the average user and small businesses. One major disadvantage is the limit of 300.000 DNS queries per month. The amount of DNS queries made in relation to a given domain will depend very much on what the domain is used for. For example, a domain used for a personal or small business website and e-mail will be fine.

Website: https://buddyns.com


NS1 provides both primary and secondary DNS service. They are providing one of the world’s fastest and most stable DNS networks.

Some pros are:

  • Stable and fast anycast network.
  • Rated as one of the fastest DNS networks in the world.
  • A long term player.
  • Unlimited zones (aka. domains).
  • Responds to both IPv4 and IPv6 DNS requests.
  • Includes advanced routing features such as geographic routing.
  • Supports “notify”.
  • Supports “stealth master.”
  • Two monitoring jobs (can detect a down server and reroute traffic.)
  • One filter chain (used to set up an intelligent routing algorithm.)

Some cons are:

  • Limit of 500.000 queries/month total traffic (per-account).
  • Limited to 50 records.
  • No support.

NS1 is running a very solid DNS network and has received positive reviews. The limit of 50 records (e.g. A, MX records, etc.) means that the service only will be interesting for users with a few domains. Individuals and small businesses with limited DNS needs will be able to use a strong free DNS service outcompeting several paid DNS products, but the limits can easily be outgrown. Notice that the free plan is called “free trial”, but seems to be an unlimited trial as long as the number of records and query limitation are not passed.

Website: https://ns1.com/


ClouDNS offers primary or secondary DNS hosting. They offer both a paid and free plan. The free plan allows up to three domains.

Some pros are:

  • Unmetered DNS queries.
  • Unlimited records per domain (but only three DNS zones aka. domains)
  • Offers both primary and secondary DNS.
  • Four name servers located at different geographically locations (but no anycast network).
  • Offers dynamic DNS (DDNS or DynDNS).
  • DNSSEC support.
  • Provides basic statistics about number of DNS queries.
  • Three Mail forwards.
  • Web redirects.

Some cons are:

  • No anycast network.
  • Limit of 3 DNS zones (domains).

Website: https://cloudns.net


DNS4.pro offers primary or secondary DNS hosting. They offer both a paid and free plan. The free plan allows up to five domains.

Some pros are:

  • Stable and fast anycast network.
  • A long term player.
  • DNSSEC support.
  • Responds to both IPv4 and IPv6 DNS requests.
  • Supports “stealth master.”
  • Decent interface.

Some cons are:

  • Limit of 5 DNS zones (domains).
  • Limit of 500.000 queries/month total traffic (per-account).

DNS4.pro has been around for several years and received positive reviews. They are providing a strong free DNS product that will out beat DNS provided by most web hosting companies and several commercial DNS products. The major disadvantage is the limit of only five zones (domains) and to some extent the limit of 500.000 DNS queries per month. They will be a good option for small to medium websites.

Website: https://dns4.pro


FreeDNS (also known as freedns.afraid.org) has proven to be a stable and long-term DNS provider. They offer both primary and secondary DNS. If you don’t have your domain, you can choose up to five free subdomains from a rather comprehensive list of domains.

Some pros are:

  • Stable and fast network.
  • A long term player.
  • Low track record of downtime.
  • Offers both primary and secondary DNS.
  • Responds to both IPv4 and IPv6 DNS requests.
  • Unmetered DNS queries.
  • Unlimited zones (domains)
  • DNSSEC support.
  • Offers dynamic DNS (DDNS or DynDNS).
  • Option to add additional external secondary name servers.

Some cons are:

  • Only one name server when used for secondary DNS.
  • The interface is a bit “messy” and not user-friendly.

FreeDNS has been around for many years and manages a rock solid DNS network. A nice feature is that if you use FreeDNS for primary DNS, they allow users to add additional external secondary name servers. If you need a temporary subdomain for development or testing FreeDNS is a great option. They are also a good option for secondary DNS.

Website: https://freedns.afraid.org


1984 Hosting Company provides free basic free primary and secondary DNS.

Some pros are:

  • Stable and fast anycast network.
  • Unmetered DNS queries.
  • Unlimited zones (domains)
  • Offers both primary and secondary DNS.
  • Web redirects
  • DNSSEC support.

Some cons are:

  • No IPv6 DNS support.

Just sign up for an account to get access to the free DNS service.

Website: https://www.1984hosting.com/product/freedns/


XName offers both free primary and secondary DNS hosting. The free service is only intended for personal users and small businesses. They provide a decent and stable service, but DNS query response time is average, and the name servers are not geographically distributed.

Some pros are:

  • Unmetered DNS queries.
  • Unlimited zones (domains)
  • Offers both primary and secondary DNS.
  • Offers dynamic DNS (DDNS or DynDNS).
  • Multi-users groups (with read-only and/or read-write users) with action logs.

Some cons are:

  • No anycast network.
  • Not all name servers respond to both IPv4 and IPv6 DNS requests.
  • Average DNS response time.
  • All name servers are placed in the same geographical location (France)

Website: http://xname.org


Zonomi provides free DNS hosting for one domain. The free plan allows 1 million queries per month and only 10 records. This is quite limited, but will work for users will limited requirements such as a personal domain etc. Their DNS servers are geographically distributed, but they do not provide anycast.

Some pros are:

  • Geographically distributed name servers (nine name servers available.)
  • Offers both primary and secondary DNS.
  • Cheap to upgrade to a paid version with more features and less limits.

Some cons are:

  • Limit of a single zone (domain.)
  • Limit of 1 million queries per month (should be more than enough for most domains.)
  • Limit of only 10 records.
  • No anycast network.
  • Not all name servers respond to both IPv4 and IPv6 DNS requests (but most do.)
  • Average DNS response time.

Website: https://zonomi.com


PUCK only provides secondary DNS through a single name server.

Some pros are:

  • A long-term player.
  • Responds to both IPv4 and IPv6 DNS requests.
  • Unmetered DNS queries.
  • DNSSEC support.
  • Responds to both IPv4 and IPv6 DNS requests.

Some cons are:

  • Only one secondary name server (located in Chicago, IL, USA).
  • No anycast network.
  • High DNS response time.

I will not recommend PUCK for production domains as only one secondary name server with no anycast support is provided. Since PUCK have shown long-term commitment the PUCK name server can be used in a mix with other name servers, and is a good option for development and test purposes. According to several reports the name server can be quite unstable.

Website: https://puck.nether.net/dns/


Twisted4life provides free secondary DNS hosting of up to 10 domains. They offer both a free and paid plan.

Some pros are:

  • Provides basic statistics about the number of DNS queries.
  • Unmetered DNS queries.

Some cons are:

  • Only one secondary name server (located in Singapore).
  • No anycast network.
  • Only responds to IPv4 DNS requests.
  • High DNS response time.
  • Limited to 10 zones (domains)
  • Very simple interface missing features, for example, the option to change account e-mail address and password.

I will not recommend Twisted4life for production domains as only one secondary name server with no anycast support is provided on the free plan. Other free services are superior to Twisted4life. As it’s fast and simple to setup an account, adding domains, and configure your primary name server Twisted4life is great for development and testing. The secondary name server can also be used in a blend with secondary name servers from other providers.

Website: https://twisted4life.com


Zoneedit offers free DNS for two zones on two name servers in separate data centers.

Some pros are:

  • A long-term player.
  • Dynamic DNS.
  • Url Forwarding, cloaked and redirects.
  • Email Forwarding.

Some cons are:

  • Limited to 250,000 queries per month.
  • No anycast network.
  • No DNSSEC support.
  • No IPv6 DNS support.
  • No support, but access to a support community forums.

Website: https://www.zoneedit.com/free-dns/

Installing MaraDNS on CentOS

MaraDNS is a simple lightweight domain name service (DNS) including both an authority and a recursive DNS. In a few words DNS is used to translate domain names (for example, bornoe.org) into an IP address (for example, bound to a specific server on the Internet. An authority DNS contains information about specific domains and which IP addresses they should translate into. For example, the authority DNS of bornoe.org is elsa.ns.cloudflare.com. This server knows the IP address of the server hosting bornoe.org. A recursive DNS is used to request the IP of a domain name from an authority DNS or the hostname of an IP. You can read more about the differences between authority and recursive DNS at Wikipedia.

In this guide I will go through a basic installation of MaraDNS on CentOS (MaraDNS can also run on other Linux flavours such as Debian) and have MaraDNS act as a primary (master) DNS.

Note on IPv6 support: MaraDNS does support IPv6, but needs to be compiled in a IPv6 mode. How to do this is not included in this quick quide.


  • Easy to install and configure.
  • Secure.
  • Fast.
  • Low memory intensive.
  • Free and open source.


  • Does not support instant transfer of zone records to secondary (slave) DNS. As MaraDNS does not support “notify”, changes to DNS zone records (depending on specific setup) will take a while to transfer to secondary DNS. This will most likely be the case if you are using a slave DNS hosted by a third party.
  • No existing graphical user interface. All configuration and changes must be made through a terminal making changes to the zone files a bit complicated. Changes in the zone file are done manually using a specific MaraDNS syntax. This can easily result in mistakes leading to miss configuration.
  • Cannot explicit be used as a secondary (slave) DNS. Through some work arounds it is possible to setup MaraDNS as a secondary DNS, but the primary (master) DNS must also be running MaraDNS. Especially if the primary DNS is running another DNS program, it will require quite some customization to get instant transfer of zone records.
  • Requires restart after modifications to any settings. Every time changes are made to any settings including modifications to NS records MaraDNS needs to be restarted. Generally this will be less of a problem to most users.

In conclusion MaraDNS is a great lightweight and secure DNS option great for people wanting to learn and experiment with DNS, or for professionals only requiring simple standard DNS. For non technical users it is a hassle to update zone files, and terminal access to the server running MaraDNS is required. This can be problematic if several users need to modify zone files. Due to the requirement of manual configuration it can also be a hassle to maintain a large amount of domains, especially if modifications are made on a common basis. MaraDNS is a great choice for a low end server or VPS due to low hardware requirements.

Installing and configuring MaraDNS

It’s relative easy to install and configure MaraDNS. By installing MaraDNS you also install the recursive DNS Deadwood, but you can decide if you want to use it or not. Often it’s easier just to use a publicly available recursive DNS or one provided by your ISP.

Step 0: Preparation

Terminal access, root privileges, and static IPv4 address.

You will need terminal access to the server and root privileges. Your server must also be assigned a static IPv4 address. Optionally you can also assign an IPv6 address in addition to the IPv4 address, but this requires additional configuration not covered in this guide.

Text editor

During configuration you will need a text editor. Use your favorite text editor or install one. A very simple editor is nano, if not preinstalled it can be installed with the command yum install nano.


To compile the MaraDNS source code you will need the compiler GCC installed on your system. If you do not have GCC installed, it is very simple to install by using the following command:

# yum install gcc

Disable other DNS software

In case your server is already running a DNS program you will need to disable or uninstall it before you install MaraDNS.

Optionally find a secondary DNS service

This step is optionally, but it is always recommended to have one or more secondary (slave) DNS for your domain. Some domain registrars will even require a minimum of two name servers. You can either host your own secondary DNS, or use a third party. There are several good paid and free options. HE.net DNS and BuddyNS are two stable providers offering free secondary DNS.

Adding a glue record at your domain registrar

This is optionally, but highly recommended. Glue records are added at your domain registrar. See documentation from your registrar or contact support to get information about how to add a glue record.

Step 1: Download MaraDNS

First thing is to download MaraDNS from the official repository (you can check http://maradns.samiam.org/download.html to see if a new version has been released, this posted has been updated to include version 2.0.15 released February 5, 2018.)

# wget http://maradns.samiam.org/download/2.0/2.0.15/maradns-2.0.15.tar.bz2 

Step 2: Unpacking, compiling, and installing MaraDNS files.

Next step is to get MaraDNS installed on your system. This is a fast procedure that only takes a couple of minutes.

Step 2.1: Unpacking MaraDNS.

# tar -jxvf maradns-2.0.15.tar.bz2

Step 2.2: Go to the directory containing the MaraDNS files.

# cd maradns-2.0.15

Step 2.3: Compiling MaraDNS.

# make

Step 2.4: Installing MaraDNS.

# make install

If you want MaraDNS to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns on

That’s it! MaraDNS is now installed on your server.

Step 3: Configuring MaraDNS files.

Now that MaraDNS is installed on your system some simple configuration is needed.

Step 3.1: Configuring the “mararc” file.

Open the MaraDNS config file /etc/mararc The file is relative self explanatory. Here a snippet of the default /etc/mararc file:

# The address this DNS server runs on. If you want to bind
# to multiple addresses, separate them with a comma like this:
# ",,"
ipv4_bind_addresses = ""
# The directory with all of the zone files
chroot_dir = "/etc/maradns"
# The following line (commented out) tells MaraDNS to look at the
# file db.example.net to get the zone for example.net
csv2["example.net."] = "db.example.net"
# Naturally, we can have multiple zone files
#csv2["example.com."] = "db.example.com"

Locate this line: ipv4_bind_addresses = ""

Add the public IP (v4) of your sever to the IP list so the list will look like this: ipv4_bind_addresses = ", <public server IP (v4)>"

Next you will need to add a list of zone files containing information about the domains that should be served by MaraDNS. One line for each zone reference. For example:

csv2["example.net."] = "db.example.net"
csv2["example.com."] = "db.example.com"
csv2["bornoe.org."] = "db.bornoe.org"

Every time you add or remove a domain from MaraDNS you will need to update /etc/mararc.

Step 3.2: Configuring zone files.

Each domain served by MaraDNS will need a separate zone file that by default should be saved into the directory /etc/maradns/

The names of the files should match those used in the file /etc/mararc so in this example you would need to create three files named db.example.netdb.example.com, and db.bornoe.org.

Here a simple example of what the zone file db.example.net could look like:

/origin example.net. ~
# SOA and NS records of the domain. In this example ns.example.net is the primary DNS and ns2-5.he.net are slave DNS.
% +14400 soa ns.example.net. [email protected] 2015072422 3600 3600 604800 14400 ~
% +14400 ns ns.example.net. ~ #This is the hostname assigned to your IP
% +14400 ns ns2.he.net. ~
% +14400 ns ns3.he.net. ~
% +14400 ns ns4.he.net. ~
% +14400 ns ns5.he.net. ~

# A record pointing example.net to the IP
% +14400 a ~

# CNAME record pointing www.example.net to the IP of example.net
www.% +14400 cname % ~

# Another A record pointing ftp.example.net to the IP
ftp.% +14400 a ~

# MX records for mail received @example.net
% +14400 mx 1 aspmx.l.google.com. ~
% +14400 mx 5 alt1.aspmx.l.google.com. ~
% +14400 mx 5 alt2.aspmx.l.google.com. ~
% +14400 mx 10 alt3.aspmx.l.google.com. ~
% +14400 mx 10 alt4.aspmx.l.google.com. ~

To make the file as simple as possible I have in the first line, /origin example.net. ~ specified example.net as the domain in question. This way I only need to type % instead of example.net.

It’s important to remember that all hostnames must end with a . (period), and all lines must end with a ~ (tilde). For example if you want to add a MX record:

example.net. (or as in the example above simply use % instead of example.net.) +14400 mx 1 mail.my-mail-host.com. ~

Assign a hostname to the IP address of the server running MaraDNS. In the example above this would be the hostname ns.example.net. For example:

ns.% +14400 a <IP of your server> ~

You only need to add this record to the domain used for the NS hostname.

To add comments to your zone files simply begin the line with a # (hashtag).

This is just a simple example to get you started. You can get more details about all options here.

Step 4: Start, stop, and restart MaraDNS.

To start MaraDNS:

# /etc/init.d/maradns start

To stop MaraDNS:

# /etc/init.d/maradns stop

To restart MaraDNS:

# /etc/init.d/maradns restart

Setting up DNS zone transfers and DNS query over TCP

In case you are using a slave DNS that requires TCP and to allow DNS query over TCP you will need to configure MaraDNS to allow this. You will need to run the build in server zoneserver along with MaraDNS.

Step 1: configuring zoneserver.

Open the file /etc/mararc

Add the following lines:

zone_transfer_acl = "" 
#This allows all system to make requests to your DNS. Separate IP addresses with a comma if needed. 
#You can replace with a specific IP of the DNS slave that will make requests. Allowing all systems to connect is generally a bad idea.

tcp_convert_acl = ""

tcp_convert_server = "<IP (v4) address of your server. If you need to add more than one IP, simply separate with commas.>"
#For example, tcp_convert_server = "" long_packet_ipv4 = "<IP (v4) address of your server. If you need to add more than one IP, simply separate with commas.>"
#For example, long_packet_ipv4 = ""

Step 2: Start, stop, restart zoneserver.

To start zoneserver:

# /etc/init.d/maradns.zoneserver start

If you want zoneserver to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns.zoneserver on

The zoneserver is now configured and running.

To stop zoneserver:

# /etc/init.d/maradns.zoneserver stop

To restart zoneserver:

# /etc/init.d/maradns.zoneserver restart

Making changes to MaraDNS configuration and zone files.

You will need to restart MaraDNS and zoneserver every time you make changes to the MaraDNS configuration file mararc or add, modify, or remove a zone file.

As shown earlier this is easily done with the commands:

# /etc/init.d/maradns restart
# /etc/init.d/maradns.zoneserver restart

Every time you update a zone file you will need to update the SOA serial number as many slave DNS services only will download changes to the zone file when they notice a new SOA serial number. The example of a zone file above contains the line:

% +14400 soa ns.example.net. [email protected] 2015072422 3600 3600 604800 14400 ~

The first number, 2015072422, is the serial. Update this number by simply adding a new value, for example, + 1 to the current number or using todays date and hour.

Setting up Deadwood

Deadwood is the recursive DNS server of MaraDNS. As mentioned earlier you do not need to use Deadwood. You can also use a publicly available recursive DNS or one provided by your ISP. If you do not want to use Deadwood you can simply skip this section.

Step 1: configuring Deadwood.

Open the Deadwood config file /etc/dwood3rc

locate the line: bind_address=""

Add the public IP (v4) of your sever to the IP list so the list will look like this: bind_addresses = ", <public server IP (v4)>"

By default only localhost is allowed to connect to Deadwood. If you need other hosts to connect to Deadwood, you will need to locate the line: recursive_acl = "", and add the IP’s of the hosts allowed to use Deadwood. Notice that recursive name servers can be abused for DDoS attacks, so make sure only to allow trusted hosts to connect if any at all. If you do allow external access then make sure to check that your configuration is safe. For example, use openresolver.com to check if your recursive DNS is open for potential abuse.

Step 2: Start, stop, restart Deadwood.

To start Deadwood:

# /etc/init.d/maradns.deadwood start

If you want Deadwood to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns.deadwood on

Deadwood is now configured and running.

To stop Deadwood:

# /etc/init.d/maradns.deadwood stop

To restart Deadwood:

# /etc/init.d/maradns.deadwood restart

Remember to restart Deadwood if you make any changes to the config file /etc/dwood3rc