DNS MX record

We just started to chat about DNS records with the DNS A Records, and now we will see a second DNS record – DNS MX record. MX does not mean Mexican. It means Mail Exchanger. We will go into details about why such a DNS record must exist and why can’t we freely send emails the way we want. 

Check this page if you need additional information about the DNS MX record!

What is a DNS MX record?

Every action that relates to domains needs DNS records for instruction. In the DNS MX record case, it is a text document, mail exchanger record, that shows which server is responsible for receiving the emails that go for a particular domain. 

(more…)

CAA DNS record

A TLS certificate helps a browser authenticate a website and establish an encrypted HTTPS connection. Before issuing one, a certificate authority validates control of the requested domain. A Certification Authority Authorization record adds a DNS-based policy layer: it lets the domain owner state which certificate authorities are permitted to issue certificates for that name.

CAA does not replace domain validation or prevent every form of certificate abuse. Its purpose is narrower and useful: reduce the set of certificate authorities that may issue, express separate policy for wildcard certificates, and optionally publish an incident-reporting contact. Correct deployment requires an inventory of every legitimate certificate workflow, careful DNS syntax, and verification before relying on enforcement.

What is a CAA DNS record?

CAA is a DNS resource-record type. A record contains flags, a property tag, and a property value. Certificate authorities are expected to check the relevant CAA policy before issuing a publicly trusted certificate. If an applicable policy authorizes the CA, issuance may continue after the CA’s normal validation. If the policy does not authorize it, the CA should not issue.

If no applicable CAA record exists, CAA itself does not restrict which certificate authority may issue. The absence of CAA is therefore different from an explicit restrictive policy.

For a refresher on where records fit in resolution, see Domain Name System explained. A focused setup reference is also available in the ClouDNS CAA record guide. Because it points to the ClouDNS domain, this contextual reference appears in the first half of the article.

The three commonly used CAA property tags

issue: authorize normal certificate issuance

The issue tag authorizes a certificate authority for certificates that are not wildcard certificates. A basic zone-file example is:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"

The value identifies the certificate authority according to its documented CAA issuer-domain name. Do not guess this value from the CA’s marketing name or website hostname. Obtain the exact identifier and any required parameters from the certificate authority’s current documentation.

Multiple issue records can authorize more than one CA. This is useful when production, disaster recovery, a CDN, and a managed hosting provider legitimately use different issuers. Every authorized issuer expands the policy, so keep the list intentional.

issuewild: control wildcard certificates separately

The issuewild tag applies to wildcard certificate requests. For example:

example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

If an applicable issuewild property is present, it governs wildcard issuance instead of issue. This allows a domain owner to permit one CA for ordinary certificates and a different CA for wildcard certificates.

An empty issuer value can explicitly prohibit the relevant category. A policy such as CAA 0 issuewild ";" can be used to deny wildcard issuance while still authorizing selected CAs for ordinary certificates. Verify how your DNS provider expects quotes and record fields to be entered before publishing.

iodef: publish an incident-reporting contact

The iodef tag provides a URL that a certificate authority may use to report policy violations or related issues. A mail-based example can point to a dedicated security mailbox:

example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

Publishing iodef does not guarantee that every CA will send a report. The destination should be monitored, protected from abuse, and incorporated into the organization’s incident-response process.

How CAA lookup and inheritance work

A CA starts with the domain name in the certificate request and follows the standardized CAA processing rules, including alias handling and tree climbing when the requested name has no CAA policy of its own. A policy found higher in the DNS hierarchy can therefore apply to subdomains that do not publish a more specific applicable record.

This inheritance is convenient, but it makes testing essential. An organization may operate delegated subdomains, external platforms, or independently managed business units with different certificate workflows. Inventory those boundaries before placing a restrictive policy at a parent name.

CAA records are their own resource-record type. They are not TXT records, even though their values contain text-like strings. The article TXT record – why to use it? covers the separate TXT type and its common verification and email-security uses.

What the flags field means

The first number in a CAA record is an eight-bit flags field. Most records use 0. The issuer-critical bit has value 128. When it is set, a CA that does not understand the property tag must treat the property as critical and refuse issuance rather than ignore it.

Do not set the critical flag casually or invent private tags without testing. A typo combined with critical processing can block legitimate issuance. For the standard issue, issuewild, and iodef properties, a flag value of 0 is the conventional starting point unless a documented requirement says otherwise.

A safe CAA deployment process

1. Inventory every certificate issuer

List certificates used by web servers, load balancers, CDNs, cloud platforms, hosting control panels, mail systems, APIs, device-management platforms, and disaster-recovery environments. Identify both the visible service provider and the actual certificate authority it uses.

2. Review automated renewal

Check ACME clients, hosting automation, CDN-managed certificates, and provider-specific issuance workflows. A certificate that works today may renew through a different account or issuer path. Test the complete renewal process rather than checking only the current certificate.

3. Publish the minimum required authorizations

Add only the issuer-domain values required by approved workflows. Decide explicitly whether wildcard certificates are allowed and which CA may issue them. Avoid copying a long generic list from another domain.

4. Verify from authoritative and recursive DNS

Query the record directly from authoritative servers and through multiple recursive resolvers:

dig example.com CAA
dig example.com CAA @ns1.example.net

Confirm the expected flags, tags, values, TTL, and inheritance at relevant subdomains. If DNSSEC is enabled, also ensure the signed response validates correctly.

5. Test issuance and renewal before enforcement matters

Use a non-critical certificate or staging environment where possible. Confirm that each approved CA can issue or renew and that an unapproved path is denied. Keep an emergency procedure for updating CAA when a provider changes its issuer.

Common mistakes

  • Authorizing the wrong issuer-domain name: Use the identifier published by the CA, not an assumed company domain.
  • Forgetting a managed platform: CDNs, hosting providers, and SaaS products may obtain certificates automatically.
  • Ignoring wildcard policy: Decide deliberately whether issuewild should authorize or prohibit wildcard issuance.
  • Publishing malformed syntax: Quotes, semicolons, parameters, and provider-specific form fields require careful entry.
  • Expecting immediate universal visibility: Existing caches can retain the previous CAA set until its TTL expires.
  • Assuming CAA protects existing certificates: CAA is checked during issuance; it does not revoke certificates already issued.

CAA and DNSSEC solve different problems

CAA expresses authorization policy, while DNSSEC allows validating resolvers to detect forged or altered DNS data. Publishing CAA without DNSSEC can still restrict compliant certificate authorities, but DNSSEC adds origin authentication and integrity protection for signed DNS responses.

The guide DNSSEC Explained describes that chain of trust. Neither technology replaces account security at the registrar, DNS provider, hosting platform, or certificate authority.

What CAA does not do

CAA does not create HTTPS, validate control of the domain, encrypt traffic, or select which certificate visitors receive. It does not prevent compromise of an authorized CA account, DNS account, web server, or private key. It also does not revoke an unwanted certificate.

Use CAA alongside secure DNS administration, multi-factor authentication, DNSSEC where appropriate, certificate transparency monitoring, protected private keys, automated renewal monitoring, and a documented incident-response process.

The authoritative processing rules, property definitions, and security considerations are specified in RFC 8659: DNS Certification Authority Authorization.

Conclusion

A CAA DNS record narrows which certificate authorities may issue certificates for a domain. A reliable policy begins with a complete issuer inventory, uses correct issue and issuewild values, accounts for inherited policy, and is tested against every automated renewal path. CAA is most effective as one layer in a broader certificate and DNS security program.

DNS over HTTPS

Every visit to a website usually begins with a DNS lookup. Your device asks a resolver to translate a domain name into an IP address, then uses that address to contact the destination. Traditional DNS queries are commonly sent without encryption, which means someone able to observe the network may see the names being requested or interfere with the exchange.

DNS over HTTPS, abbreviated DoH, carries DNS queries and responses inside an encrypted HTTPS connection. It can improve privacy and protect DNS traffic while it travels between a client and a compatible resolver. However, it is not a complete anonymity tool, and a good deployment depends on choosing a trustworthy resolver and understanding how DoH interacts with browser, device, and network policies.

How DNS over HTTPS works

The underlying DNS question remains familiar: the client still asks for records such as A, AAAA, or MX. The difference is the transport. Instead of sending the request as ordinary DNS traffic, the client encodes it in an HTTPS request to a DoH endpoint. TLS encrypts that connection and authenticates the server certificate, while HTTP provides the request-and-response layer.

If you want to review the lookup process first, this introduction to how the Domain Name System works explains the path from a domain name to an address. DoH changes the protected connection between the client and recursive resolver; it does not replace authoritative DNS or alter the records published by a domain owner.

DoH compared with traditional DNS and DoT

Traditional DNS normally uses UDP or TCP on port 53. DNS over TLS, or DoT, encrypts DNS through a dedicated TLS connection, conventionally on port 853. DoH uses HTTPS, usually on port 443, so its traffic travels through the same protocol family used by websites and web APIs. For a direct comparison of the two encrypted transports, see this guide to DoT and DoH.

Neither transport is automatically better in every environment. DoT is straightforward for network administrators to identify and manage. DoH can work well inside browsers and applications and may be more resilient on networks that restrict dedicated DNS ports. The right choice depends on whether DNS policy is controlled centrally, per device, per application, or by the user.

The privacy and security benefits

Protection against local observation

Encryption prevents a passive observer on the path between the client and DoH resolver from reading the DNS request directly. This is valuable on public Wi-Fi and other untrusted local networks, where plaintext DNS could otherwise expose browsing-related metadata. The observer can still see IP addresses and other traffic characteristics, but the DNS message itself is protected inside TLS.

Integrity while the query is in transit

TLS also makes it substantially harder for an on-path party to modify the DNS exchange between the client and resolver. The client authenticates the DoH service through its HTTPS certificate and rejects traffic that fails the connection’s integrity checks. This protects the transport channel, provided the client configuration and certificate validation are correct.

Consistent resolver behavior across networks

An application configured with a specific DoH resolver may use the same service as a device moves between home, office, and mobile networks. That consistency can avoid unexpected resolver changes. It can also create policy conflicts, however, if an application bypasses a resolver that an organization relies on for internal names, filtering, incident response, or compliance.

What DoH does not protect

DoH encrypts one segment: communication from the client to the selected recursive resolver. The resolver must process the query and may be able to associate it with network metadata. Privacy therefore shifts from the local network or access provider toward the resolver operator. Before selecting a service, review its logging, retention, jurisdiction, filtering, and security policies rather than assuming that encryption alone guarantees privacy.

DoH also does not hide all browsing activity. A network observer may infer destinations from IP connections, traffic patterns, and other metadata. DoH is not a substitute for HTTPS on the website, a VPN, secure endpoint configuration, or careful browser privacy settings.

It is equally important to distinguish encrypted DNS transport from DNS data authentication. DoH protects the channel to the resolver, while DNSSEC lets a validating resolver verify signed DNS data. The two technologies solve different problems and can be used together. The article DNSSEC Explained describes that chain-of-trust model in more detail.

Browser-level and system-level deployment

DoH in a browser

A browser can send its own lookups to a DoH provider. This is convenient and can improve privacy for browser activity, but other applications on the same device may continue using the operating system’s DNS configuration. Troubleshooting becomes harder if the browser and system receive different answers or apply different filtering policies.

DoH at the operating-system or network layer

System-level configuration can provide a consistent encrypted resolver for multiple applications. Managed organizations may instead deploy an approved resolver through device policy or a controlled gateway. Administrators should test internal domain resolution, split-horizon DNS, parental controls, threat blocking, captive portals, and incident logging before a broad rollout.

How to choose a DoH resolver

A resolver becomes an important trust point, so selection should be based on more than latency. Evaluate:

  • Privacy policy: Determine which query and client data is logged, why it is collected, and how long it is retained.
  • Security practices: Look for current TLS support, DNSSEC validation, abuse response, and transparent operational documentation.
  • Reliability: Consider geographic reach, redundancy, historical uptime, and how the client behaves if the service is unavailable.
  • Filtering behavior: Decide whether you need an unfiltered response, malware protection, family filtering, or organizational policy controls.
  • Performance: Test real lookup latency from the networks and regions your users actually use rather than relying on a global average.

DNS availability still matters because failed resolution makes healthy websites appear offline. Resilient authoritative DNS, monitoring, and failover complement encrypted client-to-resolver transport. This overview of Premium DNS capabilities explains several availability-oriented considerations on the authoritative side.

A practical deployment checklist

  1. Define the goal. State whether the priority is privacy on untrusted networks, consistent policy, malware filtering, or another measurable outcome.
  2. Select and document the resolver. Review its privacy and security policies, endpoints, availability, and support model.
  3. Choose the control layer. Decide whether DoH belongs in the browser, operating system, managed endpoint, or network gateway.
  4. Test normal and internal names. Confirm public websites, private zones, VPN resources, captive portals, and local services resolve as expected.
  5. Plan failure behavior. Know whether the client fails closed, falls back to plaintext DNS, or switches to another encrypted resolver.
  6. Monitor after rollout. Measure lookup latency, resolution errors, policy impact, support cases, and resolver reachability.

The protocol details, including the HTTPS request formats and media types used for DNS messages, are defined in RFC 8484: DNS Queries over HTTPS.

Conclusion

DNS over HTTPS can prevent local networks and on-path observers from directly reading or modifying DNS messages between a client and resolver. Its value is real but specific: it protects DNS transport, not every layer of a browsing session. A sound deployment combines an appropriate control layer, a carefully evaluated resolver, clear fallback behavior, compatibility testing, and complementary protections such as HTTPS and DNSSEC.

DNSSEC

The Domain Name System is one of the Internet’s essential services. It translates familiar domain names into the IP addresses that computers use to communicate. That convenience also creates an important security question: how can a resolver know that the DNS answer it received is authentic and has not been replaced in transit?

DNS Security Extensions, usually called DNSSEC, address that problem with digital signatures. DNSSEC allows a validating resolver to verify where DNS data came from and whether it changed after the authoritative zone signed it. It strengthens trust in DNS without replacing the DNS protocol or encrypting ordinary DNS queries.

What problem does DNSSEC solve?

Traditional DNS was designed for availability and speed, not for cryptographic verification. A resolver can ask an authoritative server for a record, but the basic protocol does not prove that the response is genuine. An attacker who succeeds in inserting a forged answer could direct visitors to an unintended server even when they typed the correct domain name.

This risk is easier to understand after reviewing how the Domain Name System resolves a name. DNSSEC adds verifiable signatures to that process. A validating resolver can reject a forged or altered response instead of treating it as legitimate DNS data.

How DNSSEC creates a chain of trust

DNSSEC does not rely on one universal key for every domain. It creates a chain of trust that begins at the DNS root and continues through the top-level domain to the signed domain. Each level can securely point to the key used by the level below it.

DNSKEY records publish public keys

A signed zone publishes its public keys in DNSKEY records. The corresponding private keys remain protected by the zone operator and are used to sign groups of DNS records. Keeping the private key secure is critical because anyone who obtains it may be able to produce signatures that appear valid.

RRSIG records contain digital signatures

For each signed record set, the authoritative zone supplies an RRSIG record. A validating resolver uses the appropriate DNSKEY to check that signature. Successful validation confirms both the origin of the data and its integrity: the response was signed by the expected zone and was not modified after signing.

DS records connect parent and child zones

A DS record in the parent zone contains a digest associated with a key in the child zone. For example, a registrar can publish a domain’s DS information in the relevant top-level-domain zone. The resolver follows these references from a previously trusted level, building a verifiable path to the final answer.

NSEC and NSEC3 authenticate negative answers

DNSSEC must also prove when a requested name or record does not exist. NSEC and NSEC3 records provide authenticated denial of existence. This prevents an attacker from simply returning an unsigned “not found” response for valid signed data.

What DNSSEC protects—and what it does not

DNSSEC provides DNS data origin authentication, integrity protection, and authenticated denial of existence. These controls help defend against forged DNS answers and cache-poisoning scenarios when validation is performed correctly.

However, DNSSEC does not encrypt DNS traffic. Anyone able to observe an unencrypted DNS query may still see the requested name. DNSSEC also does not secure a vulnerable website, repair an infected server, prevent every distributed denial-of-service attack, or protect a registrar account with a weak password. HTTPS, access controls, monitoring, backups, and secure account practices remain necessary.

Why deployment has two important sides

DNSSEC works only when zone signing and validation connect correctly.

  • Authoritative side: The domain owner or DNS provider signs the zone, publishes DNSKEY and signature records, and keeps the signatures current.
  • Parent-side delegation: The correct DS record is published through the registrar or registry so the parent can establish trust in the child zone.
  • Resolver side: A validating recursive resolver checks the signatures and the chain of trust before returning an answer to the client.

If a signed zone changes its keys without updating the parent DS information correctly, validating users may receive failures even though the records look normal to a non-validating resolver. Careful key rollover and monitoring are therefore part of operating DNSSEC, not optional housekeeping.

A practical DNSSEC deployment checklist

  1. Confirm support. Check that the authoritative DNS provider, registrar, and top-level domain all support the required DNSSEC workflow.
  2. Review current DNS data. Make sure the zone is accurate before signing it. DNSSEC can authenticate incorrect data just as effectively as correct data.
  3. Enable zone signing. Generate or activate the signing keys through the authoritative DNS service and confirm that DNSKEY and RRSIG records appear.
  4. Publish the DS record. Submit the exact DS values through the registrar. A mismatch can break validation for the domain.
  5. Test from validating resolvers. Confirm the complete chain of trust, not merely the presence of DNSSEC records.
  6. Monitor signatures and rollovers. Watch expiration dates, DS consistency, and planned key changes. Include DNSSEC checks in routine DNS monitoring.

Reliable authoritative infrastructure still matters after a zone is signed. Features such as redundant servers, anycast distribution, monitoring, and failover address availability rather than authenticity. The distinction is similar to the operational benefits discussed in the guide to Premium DNS: security and resilience are strongest when several complementary controls work together.

DNSSEC is a trust layer, not a complete security stack

A successful DNSSEC deployment gives validating resolvers cryptographic evidence that DNS data is authentic. It reduces an important class of DNS manipulation risk, but it should be combined with HTTPS, secure registrar access, multi-factor authentication, protected signing keys, monitored DNS changes, and resilient authoritative service.

For a practical overview of the technology, see DNSSEC, the DNS Security extension. The protocol’s security model and requirements are defined in RFC 4033: DNS Security Introduction and Requirements.

Premium DNS

Premium DNS explanation

You may get more of everything with a Premium DNS service. More DNS zones and DNS servers are available. You can also better control the flow of traffic. You’ll notice a difference in loading speed once you start utilizing it. It will also result in improved uptime, security, and SEO.

If downtime is not an option for your company, the Premium DNS service should be explored. Implementing a DNS service like this could benefit any website larger than a small personal blog.

If visitors continue to rise, you should seriously consider using this service.

(more…)

Free DNS service

Free DNS service explained in details

Free DNS service gives your domain name the ability to be visible on the Internet. It provides simple and basic DNS infrastructure, allowing users to access your website.

This service is excellent for you if you manage a blog or a small local online business. Free DNS service delivers a stable domain, some features for DNS (Domain Name System) management, and average speed. It is an absolutely free opportunity. 

(more…)

IPv4 IPv6

IPv4 and IPv6 are two different versions of Internet protocol (IP). For that reason, it is important to understand what are the differences between them. So, let’s explain a little bit more!

Internet Protocol (IP) – What is it?

Internet protocol, or as we know it, more popular as IP, establishes a group of communication rules which control the format of the information transferred among the networks or the Internet. 

Thanks to the IP, it is easy to set the most suitable structures for packets to transport data until they are delivered. In addition, it includes several methods for addressing, and it routes datagrams across networks. Therefore, the transportation of data packets from their origin to their target destination depends on IP addresses.

When it comes to connections on the Internet, it is crucial to know who is requesting some data and who is supposed to provide the information, like routers, websites, servers, Internet of Things, and so on. IP addresses serve for identifying and connecting with the machines, devices, servers. That makes it possible to achieve communication and exchange of information.

(more…)

Domain parking

What is domain parking?

Domain parking is a service (usually free) that domain registrars offer to their clients (people who got themselves a domain name) to have a simple, non-interactive, single HTML page, where the clients can put their contact information and a short text message with more details about the future of the domain name.

(more…)

TXT record

Domain Name System (DNS) includes many different records to execute different functions required for the Internet to work as easily and efficiently as users expect.

TXT records’ functionality is absolutely essential. Check out why to use TXT record.

What is the TXT record?

Text or TXT record is a DNS record that holds text information related to a domain for external sources to read it. TXT records commonly have general information about a domain and important data frequently used for validating (security processes). They can validate information for e-mailing or for confirming if you really are the owner of a domain.

When created, the TXT record was for administrators’ notes. But machines have evolved through the years, and such text notes are also legible for them. This is very convenient for administrators because using TXT records, they can send text entries into the DNS, with specific instructions for machines to accomplish.

Do you know how to prevent your emails from going to spam? Check how DNS TXT record can help you!

(more…)

IaaS

In the last years, cloud computing services have become very popular. But still, while chatting with colleagues, some confusion comes around the term and the kinds of services that it involves.

What is cloud computing?

Shortly, cloud computing is an on-demand supply of tech resources through the Internet in exchange for a defined fee. Rephrasing, you can get everything you need, from data centers, servers, storage, databases, networking, software, etc., without the need to own them directly.

(more…)

DNS A record

Understanding DNS record is easy. The only thing that you need a simple explanation. We will see what a DNS record is, and we will start speaking about one of the most used ones – DNS A record. It is the simple record that connects what you are typing in your web browser and the address of the site, but let’ go in-depth. 

In the following page you can find in-depth information about the A record!

DNS and DNS records explained

We will not go into detail, but we should really define what DNS and DNS records are before we go to the topic of DNS A records. 

(more…)

Load More