Posted in

DNS TTL Definition: Why DNS Changes Take Time to Propagate

DNS TTL determines how long a DNS record can be cached before a resolver should retrieve a fresh version.

TTL means Time to Live, and it is one of the main reasons a DNS change may not appear everywhere immediately.

How does DNS TTL work?

Suppose your website currently points to:

192.0.2.10

Your A record has a DNS TTL of 3600 seconds, or one hour.

A recursive resolver looks up the domain and caches the answer. Ten minutes later, you change the record to a different IP address.

That resolver may continue returning its cached answer until the record’s remaining TTL expires. Once it needs the record again, it can request the newer value.

Longer TTL values can improve caching efficiency, while shorter TTL values allow changes to become visible more quickly.

Is that DNS propagation?

What people call DNS propagation is often really a collection of caches around the internet expiring at different times.

There isn’t a giant DNS update being pushed simultaneously to every computer on Earth.

Different resolvers may have cached the old record at different times, so one person might see your new server while another temporarily sees the old one.

Should you always use a low DNS TTL?

Not necessarily.

Lower TTL values mean resolvers need to request fresh answers more frequently. Higher TTL values provide more caching but make planned changes slower to appear.

For an upcoming migration, administrators often reduce the DNS TTL beforehand so cached records expire sooner. Once the migration is stable, the TTL can be increased again.

You should also remember that local caches and provider-specific behavior can affect exactly when you observe a change.

So the next time someone says, “The DNS hasn’t propagated yet,” check the TTL.

Very often, DNS isn’t broken.

It’s simply doing exactly what the cache was told to do.

Posted in

DNS over HTTPS Explained Simply

DNS over HTTPS encrypts DNS queries between your device and a compatible DNS resolver by sending those queries over HTTPS.

It is usually shortened to DoH.

Traditional DNS traffic can be visible to networks between you and your resolver. DNS over HTTPS changes that by carrying DNS requests inside an HTTPS connection protected by TLS. DoH is standardized in RFC 8484.

Why does DNS over HTTPS matter?

Suppose you visit:

example.com

Before connecting, your device usually needs to discover the site’s IP address.

With traditional unencrypted DNS, that lookup may be observable on the local network.

With DNS over HTTPS, the DNS request and response are encrypted while traveling between your device and the DoH resolver.

Does DoH make you anonymous?

No.

That’s one of the biggest misconceptions about DNS over HTTPS.

DoH protects DNS traffic in transit to the resolver, but the resolver itself can still process the domains you’re requesting. Standard DoH therefore should not be confused with an anonymity service.

Is DNS over HTTPS the same as DNSSEC?

No.

They solve different problems.

DoH protects the connection carrying the DNS query. DNSSEC helps verify the authenticity of DNS data.

The two technologies are independent and can work together. RFC 8484 specifically notes that using one does not remove the usefulness of the other.

For home users, DNS over HTTPS can provide greater protection against local DNS monitoring and tampering.

For companies, things become more complicated because organizations may rely on DNS visibility for filtering, security monitoring and internal services. Managed DoH deployments therefore need to fit the organization’s wider DNS strategy.

In simple terms: DNS over HTTPS doesn’t change what DNS does. It changes how your DNS question travels to the resolver.

Posted in

How DNSSEC Works?

DNSSEC adds cryptographic verification to DNS so that a resolver can check whether DNS information is authentic and has been altered in transit.

Traditional DNS was designed primarily to answer a question: What address belongs to this name?

It wasn’t originally designed to cryptographically prove that the answer was genuine.

DNSSEC (Domain Name System Security Extensions) helps solve that problem.

How does DNSSEC work?

When DNSSEC is enabled, DNS information can be digitally signed.

A validating DNS resolver checks those signatures and follows a chain of trust through the DNS hierarchy. This allows the resolver to determine whether the response came from the expected DNS zone and whether the signed data has been modified.

You can think of ordinary DNS as receiving a letter.

DNSSEC is like receiving the same letter with a seal that can be independently verified.

Does DNSSEC encrypt DNS?

This is an important distinction.

DNSSEC does not encrypt your DNS queries.

Someone capable of observing your DNS traffic may still be able to see which domain you’re requesting. DNSSEC is primarily concerned with authenticity and integrity, not confidentiality.

Protocols such as DNS over HTTPS (DoH) address a different problem by encrypting communication between a client and DNS resolver. DNSSEC and encrypted DNS can therefore complement each other.

Do you need it?

For domain owners, enabling DNSSEC can provide another layer of protection against forged DNS information.

In many modern DNS platforms, much of the signing process is automated. However, configuration needs to be correct at both the DNS provider and domain registrar so the chain of trust remains intact.

It doesn’t solve every DNS security problem, but it answers one very important question: Can I trust that this DNS answer is authentic?

Posted in

What Is a DNS Sinkhole?

A DNS sinkhole is a security mechanism that prevents users or infected devices from reaching known malicious domains by redirecting their DNS requests to a controlled destination.

Normally, when your computer requests example.com, DNS finds the IP address associated with that domain.

A DNS sinkhole changes that process for domains known to be dangerous.

How does a DNS sinkhole work?

Imagine malware on an employee’s laptop trying to contact a command-and-control server at:

bad-domain.example

Instead of returning the attacker’s real server address, the organization’s DNS system recognizes the domain as malicious and redirects the request to a safe destination.

The malware has effectively reached a dead end.

CISA describes DNS sinkholing as a way to redirect clients trying to reach malicious domains toward a benign destination, helping block command-and-control communication.

DNS sinkholes can also detect infections

Blocking traffic isn’t their only advantage.

Security teams can monitor DNS sinkhole logs and identify devices repeatedly attempting to contact malicious domains. That can reveal an infected endpoint that might otherwise remain unnoticed. CISA specifically recommends sinkhole monitoring and logging for this reason.

Does a DNS sinkhole stop every attack?

No.

Malware might communicate directly with a hard-coded IP address instead of resolving a domain. Incorrect threat intelligence can also cause legitimate domains to be blocked.

DNS caching matters too. If a malicious address was already cached, a newly created DNS sinkhole rule may not take effect until the existing DNS TTL expires.

That makes a DNS sinkhole one layer of security rather than a complete security system.

Its biggest strength is simple: DNS happens early in many network connections, so stopping a malicious domain at the DNS layer can prevent the connection before it ever begins.

Posted in

BIMI Explained

BIMI is an email standard that can allow your organization’s verified brand logo to appear beside authenticated emails in supporting inboxes.

BIMI stands for Brand Indicators for Message Identification. Instead of simply telling an email provider who sent a message, it adds a visual identity to authenticated email by giving participating mailbox providers a published brand logo they can display.

How does BIMI work?

It relies heavily on email authentication.

Before implementing it, a domain should have SPF, DKIM and DMARC correctly configured and aligned. DMARC must be operating at enforcement, using p=quarantine or p=reject, with the policy applied to 100% of messages.

Next comes the logo. Your organization prepares its logo using the required SVG format and publishes a DNS TXT record.

A simplified record lives under a name such as:

default._bimi.example.com

The record tells supporting email providers where the approved logo can be found.

What about VMC and CMC certificates?

You may also need a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). These provide additional verification around the logo being displayed. Requirements vary between mailbox providers, and publishing a BIMI record does not guarantee that every inbox will show your logo.

Is BIMI a security feature?

Not exactly.

BIMI itself isn’t intended to replace email security. Its value comes partly from requiring strong authentication mechanisms such as DMARC before a brand becomes eligible.

Think of it as the visible layer at the end of a properly authenticated email setup.

If SPF, DKIM, and DMARC are the security team checking your identity at the door, BIMI is the name badge you get once you’ve made it inside.