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: in-addr.arpa. 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!