With a lot of managed DNS providers, Oracle Dyn included, it is possible to use white-label or vanity nameservers. Doing so, however, comes with a few nuances that are not well known in the market.
Let’s take a look at what vanity nameservers are and discuss whether or not you should use them.
What is nameserver vanity?
In order for DNS queries to be responded to, you will have to define nameservers at your registrar. These are usually presented as ns1.dnsprovider.net or something similar depending on your DNS provider. If anyone does a whois on your domain, or performs a DNS lookup for a host within your zone, these nameservers will be returned as the authority for the zone.
Here is an example of a whois output for dyn.com with Oracle Dyn nameserver hostnames:
And here is a dig lookup for dyn.com with the nameservers and their associated A records (IP addresses):
With nameserver vanity, you would instead use nameservers that show your own organisation as the NS records (ns1.mydomain.com), while using your DNS provider to fulfil those DNS functions.
How are vanity nameservers achieved?
The core objective is to create your own nameserver hostnames (e.g. ns1.mydomain.com) and point them to the IP addresses of your DNS provider’s nameservers. This is accomplished in a few steps:
- Choose your desired nameserver hostnames.
- Your DNS provider will provide the IP address of the nameservers you will use in your new service. These could be shared nameserver IPs or ones specifically for yourself only.
- You will create the relevant A records using the IPs provided on the nameserver hostnames you have decided. For example, on the ns1 label of your zone mydomain.com.
- Once those records are created and published live, you will then have to create something called glue records using the IPs for the nameservers directly to your domain registration. This resolves the paradox of using a hostname within your zone as the nameserver for your zone, known as being “in bailiwick.”
- You can then delegate your new nameserver hostnames at your registrar.
This takes a bit of work, but once you are done, you have nameservers that reflect your organisation. While there are some benefits to vanity nameservers, there are also some significant risks.
Pros and cons of vanity nameservers
One reason organisations may wish to have vanity nameservers is just that: vanity. Having your brand domain in delegation keeps uniformity. There is a misguided belief that this obscures the providers in delegation, but a simple whois of the IPs will show that they remain registered to the DNS provider.
The only real technical benefit of vanity nameservers is in cases where an organisation has many thousands of zones that are delegated to existing operating nameservers and is looking to outsource them. We see this most often in the hosting community, where it is not practical to have hundreds or thousands of customers independently re-delegate. It is far more efficient to have the new nameserver IPs take over the existing nameserver names, automatically converting customers to the new platform all at once.
A major downside of vanity nameservers is that they can make organisations more appealing DDoS attack victims. DNS-based DDoS attacks have been on the rise year after year, and if would-be attackers see a company running its own DNS, which vanity implies, it is possible they are more likely to launch an attack. Of course, if you are using a managed DNS provider such as Oracle Dyn, you are well protected, but why take the risk? If you have a large and well-known managed DNS provider in delegation, it may act as a deterrent to potential bad actors.
Another large downside is that by using the IPs of the managed provider, it introduces increased management and complexity. If the DNS provider decides for whatever reason to change its nameserver IPs, you may be left with vanity nameservers pointing to deprecated IPs. Of course ,you would expect the DNS provider to alert you to this, but it is another unnecessary risk to take.
Lastly comes the issue of forward and reverse DNS matching. With IP addresses, you can perform reverse DNS lookups to see the official hostname for the IP. This is declared with a PTR record in a reverse DNS zone. Your custom nameserver hostnames may be pointing to the IPs of your DNS provider, but their IPs are pointing to their own nameservers. This is sometimes known as “incomplete vanity.”
Here is an example of a forward DNS lookup for the nameserver ns1.examplezone.net showing the Dyn nameserver IP address:
Here is an example of a reverse DNS lookup for the Dyn ns1 IP address, showing the reverse PTR record for the Dyn nameserver:
Complete vs. incomplete vanity
Incomplete vanity is not zero risk. If a governing body decides to object to this setup in the future, there could be issues. There is also nameserver irregularity, and if there was some future exploitation of the forward/reverse match resolution, that could have an impact as well.
While imperfect, incomplete vanity is achievable on most DNS providers. Some providers that are less conscious to the risks involved even recommend it. At Oracle Dyn, it is indeed possible at no increased cost, but we do not recommend it. Instead, we recommend either using the default NS set or going the full mile to complete vanity setup.
If you do want vanity nameservers, the best practice would be complete or truevanity. Oracle Dyn would provide your own set of dedicated IP addresses for your nameservers, known as a private pool. These would be announced from all locations like any other nameserver for Oracle Dyn. Oracle Dyn can then ensure the PTR records for the reverse match the hostnames containing the A records. Oracle Dyn is registered and operates for the IPs, and everything else is matched exactly as it should be.
Which way to go?
As with pretty much everything in DNS, it depends on your use case. The vast majority of cases will simply not technically benefit from having vanity nameservers, whether they are complete or incomplete. If this is internally preferable, so be it. If large number of domains are delegated to existing nameservers, vanity nameservers should be explored.
Regardless of the naming convention used, having complete vanity with a private pool from Oracle Dyn can have real benefits in terms of mitigating DDoS attacks. Private pools offer isolation for the domains from the other customers on the Dyn network. If one of the couple hundred customers on one of our public nameserver pools is attacked, all customers delegated to those nameservers will experience some of the mitigation techniques, such as scrubbing or moving traffic around the network. This will not reduce availability, but it could have a slight effect on performance. Enterprise customers on a private pool will not be affected unless they are attacked directly. Additionally, because the nameserver is dedicated, an attack on it will immediately indicate it is a directed attack on the enterprise’s brand. This provides valuable time for a response from both Dyn and the enterprise’s own networking group.
If you are a current customer and unsure on which path to go down, or someone looking to move DNS provider, feel free to drop us a line and we can provide some advice on your setup.