Root
The top of the DNS tree. Root servers help resolvers find the right TLD.
Understand How Your Domain Connects — and How DNSSEC Helps Protect It
DNS connects your domain name to websites, email and online services. DNSSEC adds cryptographic validation that helps users and resolvers trust the DNS information they receive.
DNS stands for Domain Name System. It translates human-readable domain names such as example.com into information computers can use, such as 93.184.216.34.
Think of the domain as the address people remember, the IP as the address computers use, and DNS as the system that connects them.
What happens after someone enters your domain into a browser?
Someone enters example.com in a browser or app.
The recursive resolver starts the lookup if the answer is not already cached.
Root DNS points the resolver toward the correct top-level domain.
The TLD zone directs the resolver to the domain’s authoritative nameservers.
Authoritative servers hold the domain’s published records and return the answer.
The resolver receives the IP address or other record needed for the request.
The client uses that answer to reach the website, mail system or other service.
DNS is organized as a tree — from the root down to your domain’s authoritative zone.
The top of the DNS tree. Root servers help resolvers find the right TLD.
Top-level domains such as .com, .am or .ge manage delegations for their namespaces.
Authoritative servers publish the records that define where your domain points.
Recursive resolvers walk the hierarchy on behalf of users and cache answers.
These records tell the internet how your domain should connect to services.
Maps a hostname to an IPv4 address.
example.com → 93.184.216.34
Maps a hostname to an IPv6 address.
example.com → 2606:2800:220:1:248:1893:25c8:1946
Aliases one hostname to another hostname.
www.example.com → example.com
Directs email for the domain to mail servers.
example.com → mail.example.com
Publishes verification, SPF, DKIM and other text policies.
v=spf1 include:_spf.example.com ~all
Delegates the zone to authoritative nameservers.
example.com → ns1.example.net
DNS is the routing layer behind how people and systems find your online presence.
A and AAAA (and related) records decide which servers answer for your site.
MX and supporting TXT records guide mail delivery and authentication checks.
APIs, CDNs, verification tokens and SaaS tools often depend on DNS entries.
NS records and zone data define who publishes authoritative answers for the domain.
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS data so a validating resolver can verify that answers are authentic and have not been tampered with.
DNS still publishes and resolves records. DNSSEC adds a verification layer on top of that data.
A way to help validating resolvers confirm that DNS answers match the signed zone data in the chain of trust.
DNSSEC does not encrypt website traffic, replace HTTPS/TLS, hide IP addresses or make DNS private.
DNS finds the answer. DNSSEC helps verify the answer.
A DNSSEC-aware validating resolver checks signatures along the chain of trust before accepting an answer.
A client asks for DNS data for a signed domain.
A DNSSEC-aware recursive resolver requests answers and related signatures.
The authoritative zone returns records plus RRSIG signatures.
The resolver obtains the zone’s public keys published as DNSKEY records.
A DS record in the parent zone links the child key into the hierarchy.
Validation continues upward through TLD and root trust anchors as needed.
The validating resolver checks that signatures match the returned data.
Valid answers are accepted; failed validation can cause the response to be rejected.
Each link authenticates the next — from the root down to your domain’s signed data.
These records make cryptographic validation possible.
Publishes the public key used to verify signatures for a signed zone.
example.com DNSKEY …
Published in the parent zone to securely link a child DNSKEY into the chain.
example.com DS 2371 13 2 5A8F…
Carries the cryptographic signature covering a set of DNS records.
example.com RRSIG A …
DNSKEY signs zone data via RRSIG. DS at the parent authenticates the child DNSKEY. Together they form the validation path.
DNSSEC helps protect, detect and prevent certain classes of DNS integrity attacks — it is not a complete security solution by itself.
Helps detecting forged DNS answers that fail signature checks at a validating resolver.
Helps prevent accepting poisoned cache entries when validation fails for signed data.
Helps detect modified DNS records that no longer match their cryptographic signatures.
Helps protect users from being silently redirected via forged DNS destinations.
A simple view of how validation changes the outcome of a forged answer.
An attacker injects a forged DNS response. Without signatures to check, a resolver may accept the fake answer and send users to the wrong destination.
No cryptographic validation of the DNS answer
A validating resolver checks signatures. Invalid or tampered answers can be rejected; properly signed answers can be accepted with higher confidence.
Signature check before trusting the answer
They secure different layers. Together they are stronger.
Helps validating resolvers confirm that DNS records are authentic and untampered.
Encrypts and authenticates the connection between a client and a web server.
Use DNSSEC to strengthen DNS trust where supported, and HTTPS to protect website sessions. One does not replace the other.
Clear boundaries build trust. DNSSEC is powerful within the DNS layer — and only there.
For supported domains, GlobalR lets you manage DNSSEC DS records in the domain management interface. Availability depends on the domain extension and registry support.
Your DNS provider typically signs the zone and supplies DS details. You configure those DS values in GlobalR so the parent registry can publish them. GlobalR does not invent automatic key generation on this page.
Illustrative preview — not live domain status.
| Field | DS Record #1 | |
|---|---|---|
| Key Tag | 2371 | |
| Algorithm | 13 | |
| Digest Type | 2 | |
| Digest | 5A8F… | Edit |
Some DNSSEC configurations use multiple DS records — for example during key changes or depending on registry configuration.
├── DS Record 1 ├── DS Record 2 └── DS Record 3
Exact steps vary by DNS hosting provider, registry and TLD.
Signs the DNS zone and prepares DNSSEC material.
Provides DS / DNSSEC details needed at the parent.
DS record configured for a supported domain.
Parent zone publishes the DS information.
Can validate the chain of trust for signed answers.
Workflows differ across DNS hosts and registries. DNSSEC availability depends on the domain extension and registry support — GlobalR does not promise DNSSEC for every extension.
DNSSEC is especially useful wherever forged DNS responses would cause serious trust or brand harm.
Add another layer of DNS trust for company domains.
Useful where domain integrity matters strongly for transactions and accounts.
Helps protect DNS trust around login and account service hostnames.
Can contribute to a stronger DNS security posture. Enabling DNSSEC alone does not secure email content.
Helps reduce risks associated with forged DNS responses for high-value brands.
Useful for domains where authenticity of the destination is particularly important.
Example panel only — not live monitoring of a real domain.
Short answers about DNS, DNSSEC and managing DS records with GlobalR.
DNS (Domain Name System) translates human-readable domain names such as example.com into machine-usable answers like IP addresses, mail servers and other service records.
Without DNS, browsers and apps cannot look up where your domain should point. DNS connects your domain to websites, email and other online services.
A DNS record is a published instruction for a domain—such as A, AAAA, CNAME, MX, TXT or NS—that tells resolvers how to find a service or related name.
An A record maps a name directly to an IPv4 address. A CNAME maps a name to another hostname, which is then resolved further.
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures so validating resolvers can verify that DNS answers are authentic and have not been tampered with in transit.
No. DNSSEC extends DNS with validation. You still need DNS to publish and resolve records; DNSSEC helps confirm those answers are trustworthy.
No. DNSSEC signs DNS data for authenticity and integrity. It does not encrypt DNS queries or website traffic.
No. DNSSEC helps validate DNS answers. HTTPS/TLS encrypts and authenticates the connection to a web server. They protect different layers and work best together.
A DS (Delegation Signer) record is published in the parent zone. It links a child domain’s DNSKEY into the DNSSEC chain of trust.
A DNSKEY record publishes a public key used in a DNSSEC-signed zone so resolvers can verify signatures for that zone’s data.
An RRSIG record is a cryptographic signature that covers a set of DNS records (an RRset), allowing a validating resolver to check that the data matches the zone’s keys.
The chain of trust is the linked path of keys and DS records from the DNS root down through TLDs to your domain, letting a validating resolver prove answers are authentic.
DNSSEC availability depends on the domain extension and registry support. Your DNS provider and registrar workflow must also support signing and DS publication.
Yes. Some setups use multiple DS records—for example during key changes or based on registry requirements. GlobalR supports managing multiple DS records where DNSSEC is available.
For supported domains, sign in to your GlobalR account, open the domain’s DNSSEC settings and configure the DS record details provided by your DNS provider. DNSSEC availability depends on the domain extension and registry support.
Understand your DNS configuration, manage your domain infrastructure and add DNSSEC validation where supported.
DNSSEC availability depends on the domain extension and registry support.