Use DNSSEC to boost your security.

As you know, the Domain Name System (DNS) infrastructure is the soul of pretty much everything on the Internet. There’s no web hosting, e-mail or messaging services, etc., that can exist online without the DNS.

And being that important, yes, the DNS has its Achilles heel: security. Its focus is not there, and that makes it vulnerable. But don’t worry, DNSSEC already exists! A reliable choice to boost security!

What is DNSSEC?

DNSSEC or Domain Name System Security Extensions is a suite of extension specifications for encrypting DNS records sets and proving the original authoritative nameserver. It’s not about cryptographically signing DNS requests and answers but directly signing DNS data by their owner.

Then, if a criminal (man-in-the-middle) manages to snatch these DNS records, they will be unreadable due to the encryption.

DNSSEC serves for authentication, too, through digital signatures that use public-private key cryptography combinations. Each DNS zone owns its key pair (public/private).

A big DNSSEC advantage is it covers every domain’s level. From the very top, the root, all the way down to the hostname. It builds sort of a chain of trust all across the DNS tree. Every level up verifies the one below through the combined use of the public and private keys. If there’s a failure on one of the levels, the chain gets broken. Therefore data is considered unreliable.

Let’s try an example of the hierarchical digital authentication DNSSEC practices. Think about an lookup. .Net nameserver authenticates the zone below, which is

DNSSEC DNS record types.

DNSSEC adds the following DNS records in order to enable signature validation. 

DNSKEY. This record holds the public key that can verify RRSIG.

DS. It’s a delegation signer, and it contains the DNSKEY record’s hash and is put in the parent zone to verify the one under. 

RRSIG. It holds the signature for the recordset.

NSEC, NSEC3. Used for denial-of-existence of a DNS record, and to link to the next secure record.

How does DNSSEC boost security?

DNSSEC boosts your security, providing you with the tools (suite) to ensure that DNS records are not altered. This strengthens your protection and decreases the chances for criminal attempts like DNS cache poisoning. When a criminal manages to alter DNS records on the fly, the client receives them and gets dragged to a different server controlled by the criminal. 

Besides, DNSSEC allows you to authenticate the source of DNS data. By now, you should know about the frequency and different techniques criminals use to attack the DNS. This authentication feature is really significant. To have the certainty that data really belongs to the source they claim to be, meaning to the right authoritative name server, is gold. This reduces the chances of fake servers operating successfully.

If you activate DNSSEC, DNS recursive servers can authenticate data they work with really come from a legit source, so it’s reliable. Fake data will be discarded. And if by any chance the recursive can’t authenticate data, they won’t use them to keep the security. They will retry the authentication process to avoid the use of unreliable or forged data.


The use of DNSSEC to keep the DNS security is a good decision. Online risks and direct attacks to the DNS are not uncommon nowadays. Of course, DNSSEC costs, but you know that prevention always will be cheaper than the cost of fixing the unfortunate consequences of a criminal attack.

A breakdown of rDNS.

Are you experiencing problems with your e-mails? Perhaps they are going to the spam folder or missing. If this is your case, it’s possible that the origin of the problem is that you haven’t configured reverse DNS (rDNS).

What is reverse DNS (rDNS)?

The rDNS or reverse DNS is the DNS lookup of an IP address, with the goal to find the domain name behind it. Yes, it’s exactly the opposite of the regular DNS lookup, in which a domain name points to the IP address where it’s hosted.

The rDNS service usually is supplied by managed DNS providers. Basically, when you get it, you have the chance to create a reverse Master zone. By adding PTR records to this zone, you can verify the correct match between IP addresses and their domain name. PTR records become the evidence you need to prove the IP address really corresponds to the domain name and, therefore, avoid frauds.

The rDNS functions with IPv4 (A) and IPv6 (AAAA). 

What is a reverse Master zone?

A reverse Master zone is a Primary DNS zone on an authoritative DNS server you need for resolving IP addresses to domains. Its creation is a must because it’s the environment PTR records require for functioning correctly.

When a rDNS lookup is triggered, it will travel through the DNS hierarchy like a regular DNS lookup. The difference is rDNS lookups require a specific root domain: Within this domain, subdomains are produced with the numbers of an IP address in reverse. There’s a reason for this: the IP address information is more specific from the left to the right direction.

What is a PTR record?

The PTR or pointer record contains an IP address linked to the domain name. It’s the antithesis of an A record. This last supplies the corresponding IP address of a domain name. And actually, being opposites, they are teammates. You need an A or AAAA record for each PTR you add.

Let’s explain it through an example. When an e-mail is sent, the recipient’s mail server will verify the PTR record to confirm that the IP address corresponds to the domain it says to come from. This is an rDNS lookup. To ensure this match and avoid risks, there will be a second check, but the attention will go to the A or AAAA record.

PTR records are helpful for servers to confirm senders’ identity, for the recipients to trust that the sender’s IP address is not a forged one.

Suppose you wonder what happens when an e-mail server doesn’t have rDNS enabled. Well, they still try to protect security in a basic way. They discard the message or mark it as dangerous. The choice depends on their configuration.

Why do we need rDNS?

To prevent spam. Unwanted messages can be simply rubbish or dangerous threats. They can be looking for advertising or spreading malware, phishing, etc. rDNS can really reduce spam by verifying the IP addresses. If they are legit, rDNS will find it out!

To get easily readable logs. Logging systems register just IP addresses, those long sequences of numbers you perfectly know. Well, with rDNS those numbers can become domain names easier to be read on the logs.

To fix e-mail delivery problems. If your e-mails are going to the spam folder or missing, you can stop these problems by enabling rDNS. 


The rDNS is an efficient solution you should add to enhance your security. So check your configuration and set it up today!

4 DDoS attacks in recent history

The DDoS attacks are devastating businesses all around the globe. They are coming each time more potent and last longer, without any sign of going away. Even the big companies are not safe from them. Cybercriminals have diverse tactics and use different protocol vulnerabilities, extensive networks of bots, and amplification methods. 

Having a large network of DNS servers and advanced DDoS protection was not enough in these 4 DDoS attacks in recent history. Here you can see how bad could it be to receive a DDoS attack. 

2.3 Tbps DDoS attack against Amazon in 2020

The large DDoS attack happened in February 2020, and Amazon’s AWS said it was the largest ever recorded DDoS attack in history with its 2.3 Tbps*. The attack used CLDAP reflection (a known UDP reflection vector) to amplify the attack. Apparently, the cybercriminals used the vulnerability well when you think about the power of their attack. It lasted for 3 days, which is not a lot, and Amazon’s claim that there was no downtime, but still, such an attack can bring down many servers. 

*At that time, the attack on Google from 2017 was not public yet.

2.54 Tbps DDoS against Google in 2017

Can you believe that in 2017, there was such a huge DDoS attack?! 2.54 Tbps is still the record of the strongest DDoS traffic ever recorded. Google came out about the attack long after it happened. Whole 3 years later! What we know about the attack is that most of the traffic originated in China. There were 167 million packets per second that were attacking 180000 targets. Immense numbers! Google says that it had no impact on its services, and there were no negative consequences.

6 Mrps against Google’s client in 2020

Google and people who are using their services don’t have it easy when it comes to DDoS attacks. A massive flood attack of 6 Mrps (millions of requests per second) and 690 Mpps (mega packets per second) happened last year. That was extremely unexpected to see such a massive IoT DDoS attack. What we can see of this case is that in the future, we can expect even stronger attacks with more requests per second and a bigger traffic size. 

Ransom DDoS attacks on the rise in 2021

Did you know about the Ransom DDoS attacks? Cybercriminals target a company’s servers and send massive traffic coming from multiple sources until the servers can’t respond anymore. Typical DDoS attack, but the twist here is that these attacks can last months, and the goal of the criminals is to get a ransom for stopping it. According to John Chambers from JC2 Ventures, there will be at least 65 000 ransom DDoS attacks in 2021. A popular hacking group that is often related to this type of attack is Fancy Lazarus. They ask for between 2 and 5 bitcoins as a payment. Other previous names they used were Fancy Bear, Lazarus, and Lazarus Group.


No matter the size or industry, we are all under constant DDoS threat. What can we do about it? Stop most of them. Having DDoS protection might not be a 100% guarantee for perfect defense, but it is still worth it. Imagine how many small, medium-sized, and even huge DDoS attacks can most of the DDoS protection stop. 99% uptime is a lot better than 90%! And, in case of a ransom attack, be prepared with a backup of your business. Better recover your computers than to pay and not to get a thing in return. 

Best Practices for Setting Your TTL.

Expiry dates, deadlines, waiting, appointments… sometimes can stress you. But time is a helpful tool for efficiently working, complying with processes, and reaching objectives. The TTL is a good example! Learn these best practices for setting your TTL and manage your domain better.

What is TTL?

Time-to-live is the time or the number of hops every data packet is set up for being alive. Either on a network or devices, like a recursive server’s cache memory.

When a data packet already complied with its configured number of hops or its time expires, routers will discard it. In the case of devices, it will be removed from their cache not to use it anymore.

There’s TTL also on the DNS records of your domain. Their TTL points to the time they will be alive and until when the information they hold will be valid.

Why do we need TTL?

We need TTL to control the amount of data packets that exist. For example, have you ever thought about how many data packets travel every minute across a network? Imagine a scenario without an expiry date. Even the first data packet ever sent could be around without purpose, just traveling non-stop.

Time-to-live helps optimize traffic of data packets, identifies if the data they hold are still valid, and allows to obtain information about them too. For example, you can know how long a data packet has been around, and you can track its route. This information is really valuable in a cyber world full of threats.

Best Practices for Setting Your TTL.

Time-to-live can slow down or speed up important processes of your domain. DNS propagation, for instance. Learn how to use time in your favor! Just follow the best practices for setting your TTLs.

  • To define a convenient TTL value, consider the kind of DNS record you will add or edit and how many changes it can need in time. 
  • If you want to speed your DNS resolution, set up higher TTL values on your DNS records for them to be longer saved on the cache of the DNS recursive servers.
  • If your domain demands constant modifications of the DNS records, a high time-to-live value on them can slow down your propagation process. Lowering TTL values to speed the propagation is the best practice for you.
  • TTL for DNS records that are barely changed should be higher.
  • Domains of mission-critical services like aircraft, railway, electric power grid operating, and control systems require frequent updates and DNS load balancing setups. The best time-to-live practice in these cases is definitely, to define low TTL values. 
  • When you set up the cache TTL for your domain, differentiate between dynamic and static resources. Your dynamic content, specifically what involves users’ interaction, is frequently modified by them. Think about your comments section as an example. When you do not control changes or additions of content, better don’t cache. It will be hard for you to calculate an adequate TTL that keeps that content cached and refreshed on your domain.

But if you control the content, for instance, prices on the products you sell. Since you know how frequently you change such prices (daily, weekly, monthly, etc.), you can perfectly cache and establish a convenient TTL, low or high. 

On the other hand, to cache static resources are really convenient, and the best practice is to set up high TTLs. Loading time will be faster. 


TTL can be your ally or your executor. Managing time could be a challenging game. TTLs are the chance for you to master how to move time in your favor! You can become the Chronos your domain needs for running smoothly!