Can a domain be taken by someone else if custom nameservers are misconfigured?

Question

Example: I own the domain example.com.

Instead of using the nameservers set up by default by the registrar, I set up my own nameservers on my own machines with bind9. Let's say that at the beginning, before becoming more experienced with bind9, a few things are misconfigured for a few months. For example allow-transfer settings are not properly configured. (By the way, is it related to DomainStatus: clientTransferProhibited visible in WHOIS or not?)

In this context, can a malicious user gain permanent ownership on the domain?

Or is the ownership of a domain done at a totally different 'layer', and no misconfiguration of a nameserver can be used to take ownership on a domain?

Answer 1

Domain names are registered to your user account on the registrar website. So the only way to get permanent access to a given registered domain is to either:

• take ownership of the user account (stealing credentials)
• transferring the domain to another account

Now that second part is usually locked when you create your domain, and you need to take active steps from your registrar account to allow such transfer to happen. allow-transfert is an option to enable DNS server to work with a primary/secondaries setup, not to transfer ownership.

In the end, should the nameserver be compromise, you always can revert the configuration on the registrar to use their own DNS or a new one you've just configured. Of course, if someone has access to your own NS, they can do malicious things with your domain name, such as redirecting users to their own websites.

Answer 2

For example allow-transfer settings are not properly configured. (By the way, is it related to DomainStatus: clientTransferProhibited visible in WHOIS or not?)

Absolutely not. You are confusing two points that are separate, yet linked.

On one side you have domain names registration operations. They go through your registrar which connects to the registry. This allows to create, renew, update, delete, transfer domain names.

Once existing at the registry and having nameservers and not be put on hold, the registry will publish your domain name authoritative nameservers through NS records.

How are your nameservers configured to reply to queries on your domain names is opaque. It can be in many ways. One way (quite old but still existing) is to have one of the nameserver be the "primary", where the zonefile is and where you can do changes, and the other ones are "secondary" in the sense that they will fetch the whole zonefile from the "primary", from time to time (or when instructed so directly by the primary).

The bind directive allow-transfer will control, on the primary, which nameservers can get the whole zonefile. Typically, but not necessarily only, that directive will contain the list of secondary nameservers IP addresses. And/Or a TSIG key.

On the other hand the EPP clientTransferProhibited status code you can see on whois output (or RDAP), means the domain name can NOT be transfered among registrars. This is a status controlled by the registrar (as all of them starting with client) used to make transfers more difficult to combat false transfers. It should be possible by the registrant of the domain name to control it, through registrar panel or API. See https://www.icann.org/epp#clientTransferProhibited for further explanation on this status code or any other you can see in whois/RDAP.

Note that none of these statuses have an impact on the way the DNS makes resolution except one (two in fact): clientHold (and respectively serverHold controlled by the registry then). If this status exists, it makes the registry NOT publish the name, and hence its resolution will fail. The domain is still registered (and that can be seen in whois/RDAP) but does not resolve.

Answer 3

Doing a separate answer to go on your specific point:

In this context, can a malicious user gain permanent ownership on the domain?

Or is the ownership of a domain done at a totally different 'layer', and no misconfiguration of a nameserver can be used to take ownership on a domain?

Nothing in the DNS resolution/configuration should impact who is the "owner" of the domain name. Who is the owner is the entity you put as registrant contact when you created or transferred the domain name, through your registrar. This entity will be displayed on whois/RDAP queries.

No matter what nameservers are set for your domain, and even if they are none, who is the owner is still this entity.

Now, there are cases where "proof" of ownership of the domain will be assessed through some mechanisms using the DNS. For example if you want to have a CA issue a DV-type X.509 certificate (often mislabeled as "SSL certificate"), the CA will request you prove the "ownership" of the domain name for which you want a certificate and for this will ask you, for example, to publish a specific TXT records at the label _acme-challenge in your zone. There is a leap of faith here going from "I am able to change the content of the zone" (which is what the CA requests you to do) to "I am the owner of the domain name", because as said above the owner is the entity (individual or organization) listed as registrant contact. It is expected though that this entity either manages the domain name nameservers itself, or delegated that to a provider it trusts.

Other TXT records are asked to be added at the apex of the domain to prove ownership of the website typically.

In the same way, if the entity shown as registrant uses for itself an email address being ON the domain (like [email protected] if it is the registrant of the domain name example.com) then one can assess, with the same leap of faith, that anyone able to read those emails control the domains. Some processes, including certificates issuance by CAs but others case too, will send an email to this address, with like typically a short lived random link and expect someone to click on it to prove being able to read those emails. Some process also customary contact postmaster@, webmaster@, admin@ or hostmaster@ on the domain name, so again anyone controlling the MX and A records in the nameservers (that will control where those emails will land) may in fact control the domain name.

Going back to:

a few things are misconfigured for a few months. For example allow-transfer settings are not properly configured.

First, let me say that we all started in the DNS world one day, but if you have like critical or production level domain name for which you need to guarantee DNS resolution you might want to start by delegating it to a trusted provider (there are plenty to choose from) to let it handle DNS and make sure it works, before doing it yourself. You can of course (and should) experiment on the side, with less important domain names, to see all kind of problems and solutions you may have.

In particular, if you misconfigure allow-transfer it can have only 2 consequences, because it can be either too restrictive or too lax:

• if you are in a primary/secondary setup and the primary is not configured correctly with allow-transfer to let secondary nameservers pick up the zone, it means basically at some point that only the primary nameserver will be able to reply correctly for any DNS query related to your domain, and the secondary nameservers won't have the data to be able to reply; since failover is built in at various DNS levels, the consequence of this will be that your domain name will still resolve (because at least the primary nameserver is working), but there will be delays (because anyone asking secondary nameservers will get first an error and then retry on primary; note that primary/secondary is mostly opaque outside of the organization handling the nameservers, so a client has no way on a cold boot to know which nameservers to use first, but will learn from replies and then tend to favor the nameservers that do reply properly); it makes also the whole setup brittle because you can believe to have 5 nameservers for your domain (1 primary + 4 secondaries) and hence be shielded from up to 4 servers malfunctioning, except that in reality, if only one (the primary) ceases to work, the other 4 are worthless (because without data) and your whole domain ceases to be resolved

• on the contrary, if allow-transfer is too wide, permitting "anyone" to contact your primary and fetch your zone, then the worse happening is that "someone" is able to retrieve all records in your domain name. Just with this it can't do much, BUT for someone wanting to "attack" you in a specialized way, getting that data allows sometimes to learn about various stuff, like topology of your internal networks, or software used and things like that, so it can be used as a part of a more generic attack. Note however that someone would have to specifically hit your primary and know that it will get this data, it is not broadcasted so noone will know your primary is "wide" open. DNS data is often considered akin to private data which is why zone transfers are normally either completely blocked when not needed or just allowed towards the nameservers really needing them (the secondaries), so having a wide allow-transfer may be seen during an audit or by some troubleshooting tools as a vulnerability, but as explains above just with that it does not create an attack path alone.