Posts

How to delegate a subdomain to another NameServer?

DNS, or the Domain Name System, is the backbone of the internet, responsible for converting human-friendly domain names into IP addresses that computers can understand. One of the key features of DNS is the ability to delegate a subdomain to another NameServer. This allows organizations to have more control over their DNS infrastructure and ensure that their DNS system is running smoothly and efficiently.

In this article, we will guide you through the process of delegating a subdomain to another NameServer (NS), including the technical details of creating a new zone file, adding NS records, and updating the parent zone file and other NameServer’s configuration. Whether you’re a system administrator, network engineer, or developer, this guide will help you understand the process of delegating a subdomain and why it is important.

Delegating a subdomain to another NameServer: A step-by-step guide

Step 1: Identify the sub-domain you want to delegate

The first step in delegating a sub-domain is to identify which sub-domain you want to delegate. This could be something like “subdomain.example.com,” where “subdomain” is the sub-domain you want to delegate and “example.com” is your main domain.

Step 2: Create a new zone file for the sub-domain

Once you have identified the sub-domain you want to delegate, you will need to create a new zone file for it. This zone file will contain the DNS records for the sub-domain and will be used by the other NameServer to resolve queries for it.

Step 3: Add NS records to the zone file

In the zone file, you will need to add NS records (NameSever records) for the sub-domain. These records will specify the other NameServer that will be responsible for resolving queries for the sub-domain.

If you want to look up NS records for your domain, use our free NS record lookup tool. 

Step 4: Update the parent zone file

Next, you will need to update the parent zone file, which is the zone file for the main domain. In the parent zone file, you will need to add a delegation for the sub-domain by adding an NS record that points to the other NameServer.

Step 5: Update the other NameServer’s configuration

Finally, you will need to update the other NameServer’s configuration to include the sub-domain. This could involve adding a new zone file or updating an existing one.

What is the need for delegating a subdomain to another NameServer?

Delegating a sub-domain to another NameServer is often necessary for a number of reasons. 

  • One of the most common reasons is to separate the management of different parts of a domain. For example, a large organization may have multiple teams or departments that are responsible for different sub-domains of the organization’s main domain. By delegating these sub-domains to different NameServers, each team or department can manage the DNS records for their specific sub-domain independently, without interfering with the rest of the organization’s DNS infrastructure.
  • Another reason to delegate a sub-domain to another NameServer is for security reasons. By delegating a sub-domain to a separate NameServer, it is possible to apply different security measures to that sub-domain, such as adding an additional layer of authentication or encryption. This can help to protect sensitive information and ensure that only authorized parties can access it.
  • Additionally, delegating a sub-domain to another NameServer can also be useful for performance reasons. By delegating a sub-domain to a NameServer that is geographically closer to the majority of users accessing that sub-domain, it is possible to reduce latency and improve the overall performance of the DNS system.

In summary, delegating a sub-domain to another NameServer is a useful way to separate the management of different parts of a domain, improve security, and enhance performance. It is a powerful tool that enables organizations to have more control over their DNS infrastructure and can help to ensure that their DNS system is running smoothly and efficiently.

In Conclusion

Delegating a sub-domain to another NameServer is a simple process that involves creating a new zone file for the sub-domain, adding NS records to it, updating the parent zone file, and updating the other NameServer’s configuration. With a little bit of technical knowledge, you can easily delegate a sub-domain and ensure that your DNS queries are resolved correctly.

/by

DMARC Subdomain Delegation

DMARC subdomain delegation can help domain owners delegate subdomains or a top-level domain to a third party in a way that is DMARC compliant. This can help the owner’s domain name reflect in the sender’s Mail From: address. 

When you delegate subdomains to a third-party DNS provider, the delegated organization becomes responsible for all DNS requests related to those subdomains. The delegated organization also has access to the subdomain’s MX records and TXT records, although they may not see these settings unless they are specifically configured to do so.

What is DNS zone delegation?

DNS delegation is the process by which a DNS server authorizes another DNS server to perform authoritative actions on behalf of that server. This allows for more efficient use of resources, especially when it comes to large-scale deployments.

For example, if your company has hundreds of servers across many different sites, you may want to delegate authority over those servers so that only one server is responsible for all records in a zone. This means that if one site goes down, other sites will still be able to resolve their name servers and access their data without issue.

Why is Zone delegation important or beneficial?

DNS zone delegation is an important part of your DNS infrastructure.

The DNS zone, or domain, is a collection of one or more DNS servers that are authoritative for a given domain. When you have a single DNS server, it’s called a primary DNS server. If you have multiple DNS servers, they’re all called secondary servers.

Zone delegation allows you to designate one or more name servers as secondary servers for the zone. The main goal of zone delegation as rightfully pointed out by Microsoft in their Zone delegation document, is to create redundancy in your DNS environment and allow you to add new name servers or change their configuration without disturbing the rest of your network.

What is Subdomain Delegation?

Subdomain delegation is a great way to delegate control of your domain to another person or entity. It’s also known as subdomain transfer, subdomain management, and subdomain proxy, and it can be used for many different purposes.

What does Subdomain Delegation mean for you?

When you delegate your domain, you’re essentially giving someone else permission to manage your domain on your behalf. This means that the person who receives your domain will be able to do whatever they want with it—whether that’s adding additional domains or changing DNS settings or even deleting the whole thing outright. It’s up to them!

How does Subdomain Delegation work?

Subdomains are just like regular domains: they have names and an IP address. The difference between a domain and a subdomain is that subdomains are under some other domain name (like “example.com”). To use them effectively, you need three things: a hostname that matches the original domain name, an IP address that matches what was assigned when the original domain was created (which may or may not be the same as the current one), and access rights given by whoever controls it. 

Does DMARC Subdomain Delegation make your life easier?

There are several reasons as to why you might want to delegate your subdomains to a third-party provider. Given below are a few of them: 

  • You want your domain’s identity and name to reflect on the emails your third parties send out through their nameservers
  • Your emails will be DMARC compliant as they will appear to be originating from your domain, and since you will be in full control of the subdomain you can make DNS changes at will
  • All emails originating from nameservers with your delegated subdomains will pass SPF authorization and therefore DMARC
  • This will ensure smooth and uninterrupted email delivery 

How to delegate a subdomain to a third-party provider?

Note: For subdomain delegation, you will need to have a subdomain registered with your current DNS provider and the nameserver information of the third party. 

  • Login to your DNS registrar’s control panel 
  • In your DNS zone file, create a new NS (nameserver) record 
  • Enter your subdomain name in the Name field, your nameserver information followed by a dot (.) in the Value field, and a TTL of 1800 or 3600 
  • Save changes to your record and wait for your DNS to update the changes

You can follow the same procedure to delegate the subdomain to all the nameservers of your third-party provider. 

Finally, to finish your subdomain delegation process you need to add your subdomain to the DNS zone file of your third-party provider, and you’re done! 

DMARC Compliance and Your Third Parties 

Making your third parties DMARC compliant is a good way to make sure you’re getting no false negatives. More often than not a legitimate email fails delivery on the receiver’s side and gets marked as spam due to misconfigured third-party source alignment for the DMARC protocol. 

We have covered an entire blog on how to make your third-party vendors DMARC compliant. 

For more information, contact us today and book a free consultation with a DMARC expert!

/by

DKIM Key Rotation Explained

DKIM key rotation is the process of updating your DKIM keys. You should rotate your keys periodically—the exact period isn’t important, but the process itself is. Why should you do it? Rotating keys refers to creating new keys and updating DNS records with those new keys. The purpose of rotating your DKIM keys is similar to why you might change your passwords periodically: it’s a security measure that helps prevent attackers from impersonating your domain and sending spam or phishing emails.

Let’s take a look at why you use DKIM keys in the first place.

Why do you use DKIM keys?

DKIM stands for DomainKeys Identified Mail. It’s a way to add an additional layer of security to your email server so that your emails don’t get flagged as spam and end up in spam folders. The best way to think about DKIM is as an encrypted identifier attached to your messages so that recipients can verify that the message was actually sent by you, the person it’s claiming to come from. This identifier, or key, is what allows them to verify that.

How does DKIM work?

DKIM works by adding this identifier to each email that’s being sent out. When someone receives one of these emails, they can check the header or footer of the message and find a string of numbers and letters, which is the encrypted identifier or DKIM key. Before an email is sent to its recipient, the sender’s email server signs every email with a digital signature, which is then validated by the receiving email server. This process proves that the email has not been tampered with or altered in any way. 

When you send your email, the signature is attached as a header at the end of the message. Recipient servers use public keys (provided by domain owners through DNS records) to decrypt and verify these signatures.

Why is DKIM key rotation important for your domain’s security?

DKIM key rotation is when you start using a new private/public key pair to sign and authenticate your message—and then stop using the old private/public key pair.

Why is this important? Well, if somebody were able to get access to your private key, they could actually use it to send fraudulent emails that appear to be from you! To prevent this kind of malicious activity, it’s best practice to rotate your keys every few months.

To understand the importance of DKIM key rotation better, let’s take a look at this example: 

Let’s say you send out an email campaign for a holiday sale at your store. You use your DKIM keys to sign your emails, but if you send out enough emails using the same key pair over time, bad actors may eventually intercept and decode one of them, since each message uses the same cryptographic hash algorithm. Once they’ve got your public key, they can start signing their phishing emails with it without you even knowing! That’s why periodic DKIM key rotation is crucial to the security of your domain.

How can you rotate your DKIM keys?

1. Manual DKIM key rotation

You can manually rotate your DKIM keys from time to time by creating new keys for your domain. To do so follow these steps: 

  • Head over to our free DKIM record generator tool
  • Enter your domain’s information and enter the desired DKIM selector of your choice 
  • Hit the “Generate” button 
  • Copy your brand new pair of DKIM keys 
  • The public key is to be published on your DNS, replacing your previous record
  • The private key is to be either shared with your ESP (if you’re outsourcing your emails) or uploaded on your email server (if you handle email transfer on-premise) 

2. Subdomain DKIM key delegation

Domain owners can outsource DKIM key rotation by allowing a third party to handle it for them. This is when the owner of the domain delegates a dedicated subdomain to an email vendor and asks them to generate a DKIM key pair on their behalf. This allows owners to evade the hassle of DKIM key rotation by outsourcing the responsibility to a third party. 

This however can cause policy override problems with DMARC entries. It is recommended that rotated keys are monitored and reviewed by domain controllers to ensure smooth and error-free deployment. 

3. DKIM CNAME key delegation

CNAME stands for canonical name, and are DNS records that are used to point to data of an external domain. CNAME delegation allows domain owners to point to DKIM record information that is maintained by any external third party. This is similar to subdomain delegation since the domain owner is only required to publish a few CNAME records on their DNS, while the DKIM infrastructure and DKIM key rotation are then handled by the third party that the record points to. 

For example, 

“domain.com” is the domain from which originating emails are to be signed, and “third-party.com” is the vendor who will handle the signing process. 

s1._domainkey.domain.com CNAME s1.domain.com.third-party.com

The above-mentioned CNAME record needs to be published in the DNS of the domain owner. 

Now, s1.domain.com.third-party.com already has a DKIM record published on its DNS which can be: s1.domain.com.third-party.com TXT “v=DKIM1; p=MIG89hdg599….”

This information will be used to sign emails originating from domain.com. 

Note: You need to publish multiple DKIM records (recommended: at least 3 CNAME records) with different selectors on your DNS to enable DKIM key rotation. This will allow your vendor to switch between keys while signing and provide them with alternative options.

4. Automatic DKIM key rotation

Most email vendors and third-party email service providers enable automatic DKIM key rotation for customers. For example, if you are using Office 365 for routing your emails, you will be happy to know that Microsoft supports automatic DKIM key rotation for their Office 365 users. 

We have covered a full document on how to enable DKIM key rotation for your Office 365 emails on our knowledge base. 

Benefits of Automatically rotating your DKIM keys

  • You don’t have to do anything on your part if your vendor allows automated rotation of DKIM keys. Everything is managed by them. 
  • Manual configurations are prone to human errors.
  • Automatic key rotation is fast and effective, requiring no interference on your part. 
  • The DKIM management system is completely outsourced and handled by a third party.

Deploying a DKIM key rotation strategy

We call it the “3 Ds of DKIM key rotation”: 

  • Discuss 
  • Decide
  • Deploy 

This sums up an effective DKIM key rotation strategy for your domains. When you are availing of any third-party service for your emails and your vendor is handling rotation for you, make sure you have an open and transparent discussion as to when and how frequently you want to rotate your keys. You should have a say regarding timelines as well as the size you want to use for your selector key (whether you want to use 1024 bits or 2048 bits for more security). 

Once the discussion phase passes, you and your vendor must mutually decide on what your strategy is and finally proceed to deploy the same.

/by